Ars Tactica: Plan d'itérations

Le plan d'itérations considère les semaines du Jeudi au Mercredi suivant. Ceci est pour permettre d'avoir une réunion lors des séances de Laboratoire le Jeudi après-midi.

• Client
  • Samuel
  • Christophe
• Serveur
  • Laureline
  • Yves

• Squelette de projet
• Mise en place du gestionnaire de paquets Netty

<columns 100% 50% 50%> Dates 14 Avril - 20 Avril

Charge de Travail 4h30 par personne (total 18h)

• Réaliser Log in to the Client (logique client)
• Réaliser Create Account (logique client)
• Réaliser Log in to the Client (logique serveur)
• Réaliser Create Account (logique serveur)

<newcolumn>

• Mise en place des écrans (stubs) LoginScreen, MenuScreen, LobbyScreen et GameScreen.
• Implémenter la logique du LoginScreen
• Utilisation de service dummy pour la gestion du réseau.

• Gestionnaire de Réseau NetworkHandler (Module Partagé)
  • Enregistrer un handler de réponse
  • Enregistrer un handler pour un type de paquet (Pour Client)
  • Notification lors d'une réponse à un paquet
• Mise en place du LoginHandler
• Mise en place de base de données utilisateur

</columns>

<columns 100% 50% 50%> Avancement des Objectifs: 100%

Révision des Itérations: Les itérations suivantes ont été déplacées d'une semaine vers l'avant en éliminant l'itération tampon. Ceci nous calque sur le programme “normal”.

Améliorations Possibles: Optimiser la répartition des tâches entre les membres du groupe. Ceci est difficile principalement à cause du manque d'expérience avec des “gros” projets de cerains membres du groupe.

<newcolumn>

• Effectué la mise en place du NetworkHandler.

• Création des dummy classes pour les tests
• Création du LoginScreen, LobbyScreen, CreateScreen, MainMenu
• Implémentation partielle de la logique du LobbyScreen

• Création de la base de donnée
• Mise en place du LoginHandler

L'effort prévu ne prenait pas en compte le manque de connaissance vis à vis du language. C'était la perte de temps la plus importante, les itérations futures ne subiront normalement pas cela.

• Aide à l'implémentation du LobbyScreen

Malheureusement j'ai perdu beaucoup de temps à cause du langage et de la compréhension globale de la structure du projet. Le partage du travail ne s'est pas fait équitablement au final, ce qui est dommage car certains ont travaillé plus que d'autres. Avec la génération de la map je vais pouvoir plus m'impliquer. </columns>

<columns 100% 50% 50%> Dates 28 Avril - 4 Mai

Charge de Travail 4h30 par personne (total 18h)

Pouvoir effectuer une demande de matchmaking, entrer dans un lobby et “lancer” une partie une fois que tous les joueurs sont prêts

• Intégrer la communication client/serveur
• Réaliser Queue up for a Game
• Réaliser Log in to the Admin

<newcolumn>

• Mettre en place le NetworkManager utilisant le réseau
• Implémenter la logique du MenuScreen et LobbyScreen

• Mise en place du LobbyHandler
• Mise en place du système de Matchmaking

• Mettre en place l'application web
• Se connecter à la base de données du jeu

</columns>

<columns 100% 50% 50%> Avancement des Objectifs: Client (70%), Serveur (70%), Admin (70%)

Explication du Retard: Mauvaise gestion du temps par rapport aux autre projets et laboratoires en cours.

Révision des Itérations: Les itérations ne vont pas être replanifiées le ratrd peut être rattrapé.

<newcolumn>

• Création du LobbyHandler
• Mise en place du sytème de matchmaking

Les modules ont été mis en place, mais ils n'ont pas pu être testés car le client n'était pas implémenté.

• Avancement dans la logique du Lobby Screen

• Rien fait…

• Rien fait…

</columns>

<columns 100% 50% 50%> Dates 5 Mai - 11 Mai

Charge de Travail 4h30 par personne (total 18h)

Initialiser l'état de jeu côté serveur et le transmettre au client.

• Réaliser Play a Game (initialisation)
• Réaliser Ban Account (admin side)

<newcolumn>

• Recevoir l'état de jeu
• Afficher la carte
• Afficher les acteurs (bâtiments, unités)

• Initialiser l'état de jeu
  • Charger la carte
  • Définir le Turn Order
  • Placer les Bases
• Le transmettre au client

• Mettre en place une interface pour bannir un joueur

</columns>

<columns 100% 50% 50%> Avancement des Objectifs: Client (0%), Serveur (0%), Admin (0%)

Explication du Retard: Mauvaise gestion du temps par rapport aux autre projets et laboratoires en cours.

Révision des Itérations: Les itérations ne vont pas être replanifiées le retard peut être rattrapé.

Révision Itération 2: Le match making a été partiellement implémenté, et présentait un bug non-directement résolvable. Il a donc été choisi que cet élément, non-indispensable au fonctionnement du jeu, serait supprimé de l'implémentation finale. Ceci permettra de rattraper le retard accumulé lors de cette itération (itération 3).

<newcolumn>

• Création d'un client de débug

La création d'un client de débug permet de tester les changements dans le serveur sans attendre que le client fasse ces modifications ce qui permet d'accélérer le développement du serveur.

• Hum…

• Rien fait…

• Tests et tuto libgdx avec Tiled

</columns>

<columns 100% 50% 50%> Dates 12 Mai - 18 Mai

Charge de Travail 6h00 par personne (total 24h)

Gérer le passage de tours entre les joueurs.

• Réaliser Play a Game (initialisation)(passage de tours)
• Réaliser Ban Account (admin side)(server side)

<newcolumn>

• Afficher la carte (données de test)
• Afficher les acteurs (bâtiments, unités) (données de test)
• Gérer l'affichage des tours (données de test)
  • Afficher le joueur en cours
  • Afficher le bouton “End Turn” pour terminer son tour
  • Cacher le bouton “End Turn” hors tour

• Initialiser l'état de jeu
  • Charger la carte
  • Placer les Bases
  • Définir le Turn Order
• Gérer le passage de tour entre les joueurs
  • Envoyer les paquets
  • Assurer que seul le posséseur du jeton de tour peut terminer son tour
• Gérer les joueurs bannis dans le login manager

• Compléter l'admin (Login admin, bannir et lister les joueurs)

</columns>

<columns 100% 50% 50%> Avancement des Objectifs: Client (90%), Serveur (90%), Admin (100%)

Explication du Retard: Le retard se situe seulement au niveau de la gestion des tours côté client et serveur. Ce n'est pas terminé, mais fini à 80% de chaque côté.

Révision des Itérations: La gestion des tours est presque terminée et sera rattrapée durant l'Itération suivante. Il reste environ 1h de travail partagée entre chaque côté, pour terminer cela.

Avance: La gestion du déplacement des unités a été implémentée, côté client, dans cette Itération au lieu de l'itération 5, ceci pour effectuer des tests sur la gestion de la carte. Cette étape est donc presque terminée du côté client.

<newcolumn>

• Initialisation de l'état de jeu
• Correction de bugs divers

• Correction sur le MainMenu
• Test du LoginScreen

• Création de l'interface d'administration (4h)

• Chargement d'un écran de jeu (map) avec tests de chargement de différentes sprite (base, unité)
• Test de gestion de la souris, clic, drag and drop
• Test de gestion des entrées clavier

</columns>

<columns 100% 50% 50%> Dates 19 Mai - 25 Mai

Charge de Travail 5h00 par personne (total 20h)

• Réaliser Play a Game (gras = fait)
  1. Le serveur notifie les clients qu'ils sont entrés dans une partie
  2. Le jeu affiche l'écran de jeu
  3. Le serveur crée l'état de jeu original
  4. Le serveur détermine l'ordre de passage des joueurs
  5. A effectuer tant qu'il reste plus d'un joueur
     1. Le serveur informe les clients du joueur en cours
     2. Tant que le joueur peut effectuer une action
        1. Le joueur effectue une action (déplacement, attaque, …)
        2. Le serveur valide l'action et l'applique à l'état de jeu (retard)
        3. Le serveur informe les clients des changements dans l'état de jeu (retard)
        4. Si un joueur à été éliminé
           1. Informer tous les joueurs du joueur éliminé
     3. Le joueur termine son tour
     4. Le serveur sélectionne le prochain joueur dans l'ordre de passage
  6. La serveur notifie de la fin de la partie
  7. Le jeu affiche le menu principal

<newcolumn>

• Recevoir l'état de jeu
• Sélection d'unité à l'aide de la souris (70% done)
• Requète de déplacement lors d'un clic droit (70% done)
• Afficher un message lors d'un refus du serveur
• Déplacement d'une unité lors d'un message du serveur (70% done)

• Transmettre l'état de jeu au client
• Gestion de la requête de déplacement
  • Broadcast si succès
  • Reply si échec

• Afficher l'historique des parties dans l'admin

</columns>

<columns 100% 50% 50%> Avancement des Objectifs: Client (40%), Serveur (50%), Admin (100%)

Révision des Itérations: La gestion du déplacement d'une unité côté client a été implémentée en partie dans l'itération 4.

Explication du retard:

• Les transferts réseaux entre le client et le serveur demandent que l'on puisse sérializer les objets ciblés (carte, unités, etc.). Ceci a pour impact de devoir implémenter un serializer, car l'ECS (Entity Component System) Ashley n'est pas compatible avec l'interface serializable.
• L'interactor est un objet complexe, qui permet de synchroniser l'état de jeu et la gestion graphique du jeu (clic souris, etc.). Il a besoin de l'intégration du réseau notamment, nous avons donc pris du retard là dessus.

Améliorations Possibles: Prévoir ce que les tâches (transfert, etc.) vont devoir utiliser en background, le serializer par exemple.

<newcolumn>

La transmission de l'état de jeu nécéssite l'implémentation d'une serialisation personnalisée pour pouvoir effectuer les synchronisations différentielles.

L'implémentation malheureusement pris plus de temps que prévu et n'est toujours pas terminé. Le retard est du à plusieurs tentatives de solutions qui n'ont pas abouti.

• Création de l'Interactor (Mise à jour du GameState à partir des informations provenant du serveur).
• Mise en place de la logique de mise à jour de l'interface graphique.

• Création de la page statistiques (historique des parties) déjà implémentée dans l'itération 4 (avance).

• Implémentation Requête de déplacement (70% avance étape 4)
• Ajout de la gestion d'objets graphique par cellule (et non plus par pixel)

</columns>

<columns 100% 50% 50%> Dates 26 Mai - 01 Juin

Charge de Travail 5h par personne (total 20h)

Gestion des actions (dépendantes des archétypes) des acteurs

• Réaliser Play a Game en entier
  1. Le serveur notifie les clients qu'ils sont entrés dans une partie
  2. Le jeu affiche l'écran de jeu
  3. Le serveur crée l'état de jeu original
  4. Le serveur détermine l'ordre de passage des joueurs
  5. A effectuer tant qu'il reste plus d'un joueur
     1. Le serveur informe les clients du joueur en cours
     2. Tant que le joueur peut effectuer une action
        1. Le joueur effectue une action (déplacement, attaque, …)
        2. Le serveur valide l'action et l'applique à l'état de jeu
        3. Le serveur informe les clients des changements dans l'état de jeu
        4. Si un joueur à été éliminé
           1. Informer tous les joueurs du joueur éliminé
     3. Le joueur termine son tour
     4. Le serveur sélectionne le prochain joueur dans l'ordre de passage
  6. La serveur notifie de la fin de la partie
  7. Le jeu affiche le menu principal

<newcolumn>

• Synchronisation état de jeu et gui (Interactor) (50%)
• Afficher un panneau d'actions pour l'unité/bâtiment sélectionné
• Requète d'action au serveur
• Afficher un message lors d'un refus du serveur
• Mettre à jours l'affichage lors du succès

• Terminer le serializer (50%)
• Gestion des requètes d'action

</columns>

<columns 100% 50% 50%> Avancement des Objectifs: Client (10%), Serveur (10%)

Révision des Itérations: La synchronization de l'état de jeu avec la gui (Interactor) et le serializer ont en partie été implémentés durant l'itération précédente, mais n'ont pas été terminés. Ils sont donc à terminer dans cette itération-ci.

Cette itération a été complètement déplacée dans l'itération 7. Ceci est dû à une mauvaise gestion du temps du Projet de semestre (PRO) qui nous a pris énormément de temps cette dernière semaine afin de le terminer. Ce projet a aussi ces propres problèmes poru la gestion du temps, laissant cette itération-ci impossible à réaliser.

Améliorations Possibles: Eviter de prévoir des charges de travail trop grandes lors de la finalisation de projets concurrents.

<newcolumn>

• Rien

• Interactor

• Rien

• Rien

</columns>

<columns 100% 50% 50%>

Dates 02 Juin - 08 Juin

Charge de Travail 8h00 par personne (total 32h)

Objectifs

• Terminer le scénario Play a Game
• Finaliser la documentation du projet

<newcolumn>

• Synchronisation état de jeu et gui (Interactor) (50%)
• Afficher un panneau d'actions pour l'unité/bâtiment sélectionné
• Requète d'action au serveur
• Afficher un message lors d'un refus du serveur
• Mettre à jours l'affichage lors du succès

• Terminer le serializer (50%)
• Gestion des requêtes d'action

• Finaliser la documentation

</columns>

<columns 100% 50% 50%> Avancement des Objectifs: Client (90%), Serveur (90%)

Révision des Itérations: L'itération 6 a été complètement déplacée dans cette itération. (voir bilan itération 6 pour plus de précision)

L'implémentation des “actions” d'unités est à compléter sur le serveur (créer, attaquer). L'implémentation des “actions” d'unités est à compléter sur le client (créer, attaquer, bouger). Déplacement dans l'itération 8.

Améliorations Possibles:

<newcolumn>

• Terminé le serializer
• Implémenté la gestion des actions
  • Fonctionne en théorie ;)
• Implémentation de la gestion du jeu (fin de partie)

• Terminer l'interacteur

• Documentation

• Avancement du client

</columns>

<columns 100% 50% 50%>

Dates 09 Juin - 15 Juin

Charge de Travail 5h00 par personne (total 20h)

Objectifs

• Terminer le client
• Terminer la documentation
• Préparation de la présentation

<newcolumn>

• Finaliser la documentation

</columns>

<columns 100% 50% 50%> Avancement des Objectifs: Client (???%), Serveur (???%)

Révision des Itérations: Rattrapage des derniers problèmes de fonctionnement du client et serveur (itération 7).

Améliorations Possibles:

<newcolumn>

• Documentation

</columns>

Rendu du projet et Présentation.