tuubes / gameanalysis-iut Goto Github PK

Dès qu'un joueur envoie un message, récupérer sa taille et la sauvegarder en BDD.

• Définir plus de tâches et leur attribuer une durée
• Si possible automatiquement => trouver un logiciel
• Sinon, trouver au moins un bon éditeur de graphes

• Récuperer un objet Connection
• Créer les tables si elles n'existent pas déjà
• Régler la connection (autocommit, autosave, etc.)
• Expliquer les PreparedStatements
• Fermer la connexion lors de la désactivation du plugin

-> PlayerInteractEvent

RH2 ne fonctionne pas correctement, donc ça ne sert à rien de le garder.

Reprendre le tableau des observations intéressantes à réaliser, l'expliquer, et déterminer le type statistique des données.

Quand un joueur casse un bloc, récuperer l'ID du bloc et le temps de jeu du joueur avec

long ticks = player.getStatistic(Statistic.PLAY_ONE_TICK);

L'évènement bukkit est BlockBreakEvent

En exécutant le fichier h2.jar on a une interface graphique qui permet d'executer des requêtes SQL.
Faire un SELECT * FROM table sur chaque table et mettre les copies d'écran dans le rapport final.

Avec un listener pour le CraftItemEvent.
Il faut aussi enregistrer les items qui ont servi à fabriquer l'objet. Il y a 9 cases possibles pour les "ingrédients" et 1 case pour le résultat.

En effet, on n'enregistre dans la base de données que les IDs.
On pourrait utiliser factor mais il y a plus de 200 blocs différents donc cherchons plutôt un autre moyen ^^

Par exemple si on pouvait avoir les blocs avec leur nom dans une table SQL on pourrait faire un SELECT sur les deux tables et récupérer le nom.

• Barre de navigation
• Image de fond et overlay
  Update:
• Changer la couleur des liens
• Mettre en forme le pied de page
• Mettre en forme les paragraphes et h2, h3
• Ajouter un logo et nos photos ?
• Transitions/animations sympas ?

• Refaire les analyses blocs posés, blocs placés, taille des messages mais pour chaque serveur, et regarder les différences/similarités.
• Essayer de regarder les 2, 3 ou 4 blocs les plus utilisés par joueur, et interpréter les différences/similarités

Par rapport à la dernière apparition du joueur.
Attention : quand le joueur meurt et réapparait, le nouveau point d'apparition doit être pris en compte. Chercher comment on pourrait faire ça.

Version 3 ou 4 ?

-> PlayerInteractEvent

• Trouver un modèle
• Trouver un plan
• Logos/Photos et présentation des parties prenantes
• Contexte du projet
• Objectifs du projet
• Solution technique
• Outils utilisés

Tester avec une clé USB Linux + avec nos ordinateurs personnels (pas forcément tous mais au moins 1)

Pour chaque serveur et si possible pour chaque joueur

• Compiler et exporter la dernière version du plugin
• Installer le plugin sur le serveur
• Jouer
• Vérifier que les analyses avec R fonctionnent, ou au moins qu'on arrive tous à connecter R à la base de données et que l'on arrive à élaborer des analyses statistiques pertinentes pour chaque évènement.

• Bref rappel du projet
• Travail réalisé jusqu'à présent:
  • Apprendre à utiliser Java, Bukkit, Git, Github, Gitkraken, Eclipse
  • Mise en place d'un projet sur github
  • Programmation d'un plugin bukkit pour enregistrer les évènements
  • Programmation de l'enregistrement des données dans une BDD
  • Installation du plugin sur un serveur, récolte pendant les vacances -> combien de données récoltées ?
  • Résultats des analyses statistiques
• Gestion de projet
• Conclusion ??

Dès qu'un joueur pose un bloc, récupérer l'ID du bloc et le temps de jeu du joueur en minutes.
Pour récupérer le temps de jeu du joueur en ticks (1 tick = 50 millisecondes) :

long ticks = player.getStatistic(Statistic.PLAY_ONE_TICK);

Que chacun comprenne comment utiliser R pour analyser les données.
-> Voir le fichier test.R pour un exemple de connexion à une base de données. Le développement R se fera dans le dossier analysis.

Connecter R à la base de données nécessite

1. D'installer le package RJDBC dans RStudio. Pour cela:
   • Dans RStudio, utiliser le menu Tools > Install packages...
   • Choisir Install from: Repository (CRAN) et entrer RJDBC dans le champ "Packages"
   • Cocher Install dependencies et valider
2. De télécharger le fichier h2.jar et de spécifier son chemin dans le fichier R.
3. La base de données de l'itération 4 est sur le drive.

• Labels pour le type d'issue : bug, tâche, refractoring, etc. et le type de travail : programmation, conception BDD, analyse statistique, gestion de projet
• Une Milestone par itération de travail
• Décider de quels Kanbans on a besoin. Comment utiliser à la fois les milestones et les projects ?
• Automatiser les Kanbans (un simple réglage Github)
• Expliquer le fonctionnement de tout ça aux autres membres du groupe

Pour gérer les dépendances (bukkit, H2) et créer un fichier .jar facilement, nous utiliserons un projet Gradle au lieu d'un simple projet Eclipse/Ant.
Sous-tâches :

• Créer fichier settings.gradle
• Ecrire un build.gradle avec H2 et Bukkit
• Faire une fonction fatJar pour exporter le plugin en y incluant la base de données H2 mais pas les fichiers de Bukkit, qui seront fournis par le serveur de jeu.
• Installer le plugin Gradle sur Eclipse, pour tous les membres du groupe
• Ajouter le wrapper gradle

Applis à terminer :

• Taille des messages
• Utilisation des blocs et items
• Types d'entités
• PRÉPARATION/TEST : afficher les déplacements avec rgl (3D avec cube3d et shade3d) et ggplot2 (2D avec geom_raster et scale_fill_gradient).
• PRÉPARATION/TEST : trouver les échelles les plus appropriées pour comprendre les données.
• PRÉPARATION/TEST : pouvoir filtrer les couches Y par joueur
• Déplacement des joueurs, par couche Y
• Déplacement des joueurs, par couche Y, de façon individuelle
• Déplacement des joueurs, visualisation 3D

Applis à mettre sur le site web :

• PRÉPARATION/TEST : trouver comment on peut charger le contenu des TABS Bootstrap quand ils sont activés et non au chargement de la page.
• PRÉPARATION/TEST : vérifier que rgl fonctionne avec Shiny, et si c'est bien le cas, comprendre la méthode pour afficher un rendu 3D sur navigateur.
• PRÉPARATION/TEST : réfléchir à l'optimisation du rendu 3D qui prend entre 20 et 30 secondes à être calculé. => stocker les rendus déjà calculés dans une liste qui fera office de cache.
• PRÉPARATION/UPLOAD : mettre les applis sur le serveur et installer les packages requis
• Taille des messages
• Utilisation des blocs et items
• Types d'entités
• Déplacement des joueurs, par couche Y
• Déplacement des joueurs, par couche Y, de façon individuelle
• Déplacement des joueurs, visualisation 3D

• Page de garde
• Remerciements
• Sommaire automatique qui fonctionne correctement sans casser tous les annexes
• Introduction
• Récolte des données : plugin
• Récolte des données : BDD
• Récolte des données : informations ajoutées après coup dans la BDD
• Méthode de travail : Git, Gitkraken
• Méthode de travail : Itérations et Kanbans
• Analyse utilisation : blocs
• Analyse utilisation : items
• Analyse utilisation : types d'entités
• Analyse optimisation : taille messages
• Analyse optimisation : déplacements joueurs par serveur
• Analyse optimisation : déplacements joueurs individuels
• Conclusion : résultats
• Conclusion : prolongement de l'étude et aspects à améliorer
• Annexes : CDC
• Annexes : RACI
• Annexes : CR Réunions
• Annexes : Extraits des tables SQL
• Annexes : Schémas des tables SQL
• Annexes : JDB

Une table par évènement enregistré, donc une table par listener.
Les tables sont créés dans PluginMain, il faut reprendre les instructions CREATE TABLE pour avoir le schéma sql.

Vous vous en occupez ? @alexandre714 @Rayouu42

Plus de commentaires, mais pas n'importe comment ! Le but est d'expliquer ce que fait le code et pourquoi il le fait, pas de recopier le programme en remplaçant les mots-clés anglais par du français.

cf document observations

• Lire le tutoriel
• Faire la classe principale
• Ecrire le fichier plugin.yml
• Tester la tâche gradle fatJar : elle doit produire un fichier .jar reconnu comme un plugin par le serveur Minecraft

Les commandes sont des messages envoyés dans le chat et qui commencent par /.
Il se peut que l'AsyncPlayerChatEvent ne compte que les messages "normaux", auquel cas il faut créer un autre Listener pour les commandes.