You are here: Links of Interest » HEIG-VD » [GEN] Génie Logiciel » Ars Tactica: Rapport Intermédiaire
Ars Tactica: Rapport Intermédiaire
Table of Contents
Ars Tactica: Rapport Intermédiaire
Ars Tactica est un jeu de stratégie au tour par tour qui oppose deux ou plusieurs joueurs dont l’objectif est de détruire la base de leur adversaire(s).
Fonctionnement
Le jeu oppose deux camps (1v1 ou 2v2) dans un match à mort pour la destruction de tous les bâtiments affectés à une équipe, ceci en tour par tour. Chaque joueur contrôle un bâtiment principal qui lui sert de point de départ pour produire des unités de combat ainsi que des bâtiments collecteurs de ressources qui lui permettent d’augmenter sa production d’unités. Le joueur devra aussi investir des ressources dans des technologies qui lui débloqueront l’accès à des différents types d’unité.
Déroulement d'une partie
Chaque joueur commence la partie avec un bâtiment principal permettant de créer des unités. Un joueur est éliminé de la partie lorsque tous ses bâtiments sont détruits. L'ordre de passage des joueurs est déterminé aléatoirement lors du début de la partie.
Au début du tour d'un joueur, toutes les unités en cours de production dont le temps de production restant
arrive à zero sont placés sur la carte le plus proche possible de leur bâtiment producteur. Le joueur peut
ensuite déplacer et controller ses unités sur la carte. Chaque unité peut être déplacée une fois par tour et peut
attaquer une autre unité/bâtiment un nombre de fois par tour correspondant à sa valeur Spd (Vitesse).
Un joueur peut aussi demander la production d'unités par ses bâtiments (chaque bâtiment possède un
certain nombre de modules de production parallèles spécifiés par sa valeur Prod).
Lorsque le joueur à terminé ses actions, il passe alors sont tour au joueur suivant dans l'ordre de passage.
Archétypes
| Nom | Paramètres | Description |
|---|---|---|
Actor | Type, Hp, Cost | Archétype de base pour toute entité active dans la partie (unités, bâtiments) |
Movable | Mov | Permet à l'entité de se déplacer sur la carte |
Attacker | Atk, Spd | Permet à l'entité d'attaquer d'autre entités. |
Spawner | Types, Queue | Permet à l'entité de produire des Actor |
Carrier | Size | Permet à l'entité de contenir d'autres entités (ex: transport) |
Caster | Spells[] | Permet à l'entité d'utiliser des capacités spéciales (ex: construction, bombardement, …) |
Unités
Une unité est un type d'entité possédant les archétypes Actor, Movable et Attacker. Il leur est aussi possible de posséder l'archétype Caster, Carrier ou Spawner.
| Nom | Type | Hp | Cost | Mov | Atk | Spd |
|---|---|---|---|---|---|---|
| Tank | Heavy | 2 | 5 | 1 | 15 | 3 |
| Soldier | Light | 1 | 2 | 1 | 5 | 1 |
Bâtiments
Un bâtiment est un type d'acteur possédant l'archétypes Actor. Il ne peut pas être déplacé mais peut posséder les archétypes Spawner, Carrier et Attacker.
| Nom | Hp. | Archétypes |
|---|---|---|
| Base | 20 | Spawner of [Light, Heavy], Queue: 5 |
Responsabilités
Le jeu fonctionne selon une architecture client-serveur avec le serveur servant d’autorité pour la connexion, le matchmaking et le déroulement des parties. Les deux parties utilisent la libraire Netty pour faciliter l’échange des données sur le réseau. Une interface d'administration externe permet aux administateurs de gérer les joueurs.
Serveur de Jeu
Le serveur de jeu permet au client d'établir une session ce qui leur permet d'entrer dans la file d'attente pour participer à une partie de jeu. Lorsque suffisament de joueurs sont prêts, le serveur notifie les clients qu'ils sont placés dans un Lobby. Chaque joueur doit alors éventuellement sélectionner ses paramètres de jeu (future proofing). Lorsqu'ils sont prêts, les clients le signalent alors au serveur. Le Lobby possède aussi un timer interne qui empêche un client malveillant d'empêcher le départ de la partie. Une fois que tous les clients ont déclaré qu’ils sont prêts à démarrer la partie le serveur crée alors une session de jeu (partie) avec les paramètres spécifiés dans le lobby et notifie les clients du début de la partie. La création d'une session de jeu consiste à construire l’ECS représentant l’état de jeu et tirer au sort l’ordre de passage des joueurs. Lorsqu’un client demande d’effectuer une action, le serveur tente de l’appliquer à l’ECS. Si l’action est un succès tous les joueurs sont notifiés des changements à l’état de jeu, dans le cas contraire, seul le joueur ayant initié l’action est notifié.
Client
Le client est composé d’un écran de login, d’un menu ainsi que d’une interface de jeu. Lorsqu’il est démarré, le client affiche l’interface de login, qui donne accès au Lobby sur le serveur. Une fois connecté, une interface menu permet de se déconnecter ou d’indiquer que l’on est prêt à commencer la partie. Le client entre alors en phase d’attente d’une partie de la part du serveur. Une fois la partie reçue, l’interface de jeu est alors affichée, la carte, la base et les unités éventuelles sont présentes (voir annexe 1). Chaque action faite par le client est vérifiée par le serveur. Une réponse de la part du serveur est reçue dans tous les cas (valide ou non-valide).
Administration
La base de données de l'application peut être gérée à l'aide d'une interface web par les administrateurs.
Technologies Utilisées
Le système utilise Netty 4.1 comme librarie réseau client-serveur qui offre une gestion robuste du pipeline d'encodage/décodage des données à travers le réseau. La librarie Google Guava est utilisée pour son mécanisme de services et son bus de message. La librarie Ashley est utilisée pour la gestion de l'état de jeu à l'aide d'un ECS.
Le client utilise libGDX comme moteur d'affichage. Cette librarie fournit de nombreuses abstractions au dessus de OpenGL qui permettent de facilement manipuler de nombreux éléments graphiques sans impact de performance.
Le tout est programmé dans le language Kotlin.
Cas d'utilisation
<uml title=“UseCase”>
Anonymous –> (Create Account)
Player –> (Play a Game) (Play a Game) ..> (Queue up for a Game) : <include> (Queue up for a Game) ..> (Log in to the Client) : <include>
Player <|– Administrator
Administrator –> (Ban Account) (Ban Account) ..> (Login in to the Admin)
Administrator <|– :System Administrator: :System Administrator: –> (Start Server)
</uml>
Acteurs
| Nom | Description |
|---|---|
| Anonymous | Utilisateur ne possédant pas de compte |
| Player | Utilisateur possédant un compte |
| Administrator | Rôle permettant d’administrer le système |
Rôles
| Nom | Description |
|---|---|
| Create Account | Un utilisateur peut créer un compte |
| Login to the Game | Un utilisateur peut s’authentifier auprès du serveur et récupérer une session |
| Queue up for a Game | Un utilisateur peut entrer dans la file d’attente pour une partie |
| Play a Game | Un utilisateur peut participer à une partie |
| Login to the Admin | Un administrateur peut se connecter à l’interface d’administration |
| Ban Account | Un administrateur peut bannir un joueur |
| Start Server | Un administrateur système peut démarrer le serveur de jeu |
Scénarios
Create Account
Prérequis: Le client doit être lancé
- Le jeu présente l'écran de création de compte
- L'utilisateur remplis le formulaire
- L'utilisateur soumet le formulaire
- Le client envoie une demande de création de compte au serveur
- Le serveur crée le compte (
LoginSystem) - Le serveur répond favorablement au jeu
- Le jeu présente l'écran de connexion
Scénarios Alternatifs
- Le compte existe déjà
- Le nom d'utilisateur est déjà pris
- Le serveur répond de manière négative
- Le jeu présente un message d'erreur à l'utilisateur
Login to the Game
Prérequis: Le client doit être lancé, L'utilisateur doit avoir crée un compte
- Le jeu présente l'écran de connexion
- L'utilisateur saisit ses credentials (username, password)
- Le client envoie une demand de connexion au serveur
- Le serveur authentifie l'utilisateur (
LoginSystem) - Le serveur répond favorablement à la connexion
- Le jeu présente le menu principal
Scénarios Alternatifs
- Les credentials de l'utilisateur ne sont pas valides
- Le serveur répond de manière négative
- Le jeu présente un message d'erreur à l'utilisateur
Queue up for a Game
Prérequis: L'utilisateur doit être authentifié auprès du serveur
- L'utilisateur sélectionne la file d'attente de son choix (1v1, …)
- Le jeu envoie une notification au serveur
- Le serveur place le joueur dans la file d'attente
- Le serveur attend que suffisament de joueurs soient dans la file d'attente (2 joueurs pour du 1v1, 4 joueurs pour du 2v2, etc)
- Le serveur crée le lobby et y place les joueurs
- Le serveur notifie les clients de la création d'un Lobby
- Le jeu affiche l'écran de Lobby
- L'utilisateur signale qu'il est prêt
- Le jeu envoie une notification au serveur
- Le serveur attend que tous les joueurs soient prêts (ou que le timer interne soit échu)
- Le serveur crée une partie et y place les joueurs
- Le serveur notifie les clients du début de la partie
- Le jeu affiche l'écran de jeu
Scénarios Alternatifs
- Le timer du lobby expire
- Le serveur notifie les clients que le lobby est fermé
- Le jeu affiche le menu principal
- Le jeu affiche un message d'erreur
Play a Game
Prérequis: Le joueur doit être dans une partie
- Le serveur notifie les clients qu'ils sont entrés dans une partie
- Le jeu affiche l'écran de jeu
- Le serveur crée l'état de jeu original
- Le serveur détermine l'ordre de passage des joueurs
- A effectuer tant qu'il reste plus d'un joueur
- Le serveur informe les clients du joueur en cours
- Tant que le joueur peut effectuer une action
- Le joueur effectue une action (déplacement, attaque, …)
- Le serveur valide l'action et l'applique à l'état de jeu
- Le serveur informe les clients des changements dans l'état de jeu
- Si un joueur à été éliminé
- Informer tous les joueurs du joueur éliminé
- Le joueur termine son tour
- Le serveur sélectionne le prochain joueur dans l'ordre de passage
- La serveur notifie de la fin de la partie
- Le jeu affiche le menu principal
Scénarios Alternatifs
- La connexion est interrompue lors d'une partie
- Si un joueur met plus d'un certain temps à ne rien faire durant son tour il est éliminé
- Si un joueur est éliminé
- Le jeu affiche une notification “Vous avez perdu”
- Le jeu affiche le menu principal
Login to the Admin
- L'administrateur ouvre son navigateur à l'adresse de la console d'administration
- L'administrateur entre ses credentials pour se connecter
- La console d'administration vérifie la validité des credentials
- La console d'administration affiche son menu de gestion
Ban Account
Prérequis: Connexion à la console d'administration
- L'administrateur sélectionne un compte utilisateur
- L'administrateur ajoute un banissement
Start Server
- L'administrateur système se connecte au serveur
- L'administrateur système lance l'application serveur
Protocole
Authentification
<uml title=“Authentication Packets”> hide empty methods hide empty fields
abstract class Packet {
+ id: long
}
Packet <|– ResponsePacket abstract class ResponsePacket {
+ responseTo: long
}
Packet <|– LoginRequest class LoginRequest «(P,Salmon)» {
+ username: String + password: String <i>hashed</i>
}
ResponsePacket <|– LoginResponse abstract class LoginResponse
LoginResponse <|– LoginSuccess class LoginSuccess «(P,Salmon)» {
+ sessionId: String + user: User
}
LoginResponse <|– LoginFailure class LoginFailure «(P,Salmon)» {
+ message: String
} </uml>
Authentification
<uml title=“Authentication Network Exchange”> Client → Server: LoginRequest(username, password) Server –> UserManager: authenticate(username) Server ←- UserManager: «success» Server → Client: LoginSuccess(user, sessionId) alt Failure Server ←- UserManager: «failure» Server → Client: LoginFailure(reason) end </uml>
<uml title=“Authentication Workflow”> title authenticate(user) start if (user in database?) then (no)
:LoginFailure;
elseif (password matches?) then (no)
:LoginFailure;
elseif (banned?) then (yes)
:LoginFailure;
else
:create session id; :LoginSuccess;
endif stop </uml>
Création de Compte
<uml title=“Account Creation Network Exchange”> Client → Server: CreateAccount(username, …) Server –> UserManager: createAccount(…) Server ←- UserManager: «success» Client ← Server: CreateSuccess() alt Failue Server ←- UserManager: «failure» Client ← Server: CreateFailure() end </uml>
Matchmaking
<uml title=“Matchmaking Packets”> hide empty methods hide empty fields
enum QueueType {
1v1 2v2 3v3
}
Packet <|– EnterQueue EnterQueue – QueueType : type
Packet <|– EnterLobby class EnterLobby «(P,Salmon)» {
+ lobby: Lobby
}
Packet <|– PlayerReady class PlayerReady «(P,Salmon)» {
+ player: User
}
Packet <|– EnterGame class EnterGame «(P,Salmon)» {
+ gameId: long
} </uml>
<uml title=“Matchmaking Workflow”> actor ClientA actor ClientB box “Server Software” participant Server participant “1v1 Queue” as Queue participant “Lobby #1” as Lobby participant “Game #1” as Game end box note over Queue: is empty
ClientA → Server: EnterQueue(1v1) Server –> Queue: enterQueue(ClientA, 1v1) activate Queue
ClientB → Server: EnterQueue(1v1) Server –> Queue: enterQueue(ClientB, 1v1)
Queue –> Lobby: «new» deactivate Queue activate Lobby
ClientA ← Lobby: EnterLobby(#1) ClientB ← Lobby: EnterLobby(#1)
ClientA → Lobby: PlayerReady(ClientA) hnote over Lobby broadcast PlayerReady(ClientA) endnote
ClientB → Lobby: PlayerReady(ClientB) hnote over Lobby broadcast PlayerReady(ClientB) endnote
Lobby –> Game: «new» activate Game Lobby –> Game: start() deactivate Lobby
ClientA ← Game: EnterGame(#1) ClientB ← Game: EnterGame(#1) deactivate Game </uml>
Partie de Jeu
<uml title=“Game Packets”> hide empty methods hide empty fields
abstract class Packet {
+id: long
}
Packet <|– EnterGame class EnterGame «(P,Salmon)» {
+gameId: long
}
Packet <|– EndGame class EndGame «(P,Salmon)» {
+winner: PlayerRef
}
Packet <|– MoveTurn class MoveTurn «(P,Salmon)» {
+nextPlayer: PlayerRef
}
Packet <|– SyncGameState class SyncGameState «(P,Salmon)» {
+gameWorld: GameWorld
}
Packet <|– SyncEntityState class SyncEntityState «(P,Salmon)» {
+entityId: long +components: Component[]
} </uml>
<uml title=“Game Workflow”> actor Player box “Server Software” participant GameHandler participant TurnHandler participant StateHandler participant ActionFactory participant Action participant GameWorld end box
Start of Game
Player ← GameHandler: EnterGame(#1)
GameHandler –> TurnHandler: initialize() activate TurnHandler GameHandler ←- TurnHandler: «done» deactivate TurnHandler GameHandler –> StateHandler: initialize() activate StateHandler StateHandler –> GameWorld: construct() activate GameWorld StateHandler ←- GameWorld: «done» deactivate GameWorld GameHandler ←- StateHandler: «done» deactivate StateHandler Player ← GameHandler: SyncGameState(world)
Player Turn
Player –> Player: Select Actor Player –> Player: Request Action Player → GameHandler: PerformAction(entity, action) GameHandler –> TurnHandler: isTurnOf activate TurnHandler alt Out of Turn GameHandler ←- TurnHandler: «false» Player ← GameHandler: Error(“Out of Turn”) end GameHandler ←- TurnHandler: «true» deactivate TurnHandler GameHandler –> StateHandler: performAction() activate StateHandler
StateHandler –> ActionFactory: getAction() activate ActionFactory ActionFactory –> Action: «create» activate Action StateHandler ←- ActionFactory: «return Action» deactivate ActionFactory
StateHandler –> Action: isValid? note left: Checks if the entity is able to perform the action
StateHandler –> GameWorld: beginAction() activate GameWorld #LightBlue note left: Tracks changes to entities
StateHandler –> Action: apply() activate Action #DarkSalmon Action –> GameWorld: «changes» StateHandler ←- Action: «done» deactivate Action deactivate Action
StateHandler ←- GameWorld: getChanges() deactivate GameWorld
hnote over StateHandler broadcast SyncEntityState(changes) endnote
StateHandler –> StateHandler: checkVictory()
alt Player Wins hnote over StateHandler broadcast GameEnd(victor) endnote end
GameHandler ←- StateHandler: «done» deactivate StateHandler
… Passing Turn …
Player → GameHandler: EndTurn() GameHandler –> TurnHandler: nextTurn() activate TurnHandler GameHandler ←- TurnHandler: «new player» deactivate TurnHandler hnote over GameHandler broadcast MoveTurn(new player) endnote
</uml>
Modèle de Domaine
Jeu
<uml title=“Game Domain Model”> hide empty members
class Partie class Carte class Acteur class Bâtiment class Unité class Joueur class Equipe
Acteur <|– Bâtiment Acteur <|– Unité
Partie *– “*” Carte Partie *- “*” Equipe Equipe *– “*” Joueur
Joueur *- “*” Acteur
</uml>
Client
<uml title=“Client Domain Model”> hide empty fields hide empty methods hide class circle hide interface circle
package “Networking” { interface NetworkService
LoginService ←- NetworkService LobbyService ←- NetworkService GameService ←- NetworkService
NetworkService <.d.> Netty
class Netty «(L,lightblue)» }
package “Display” { LoginScreen —> LoginService
LoginScreen <.r.> MenuScreen
MenuScreen —> LobbyService
MenuScreen <.r.> GameScreen
}
GameScreen –> Interactor Interactor –> GameState Interactor —> GameService
</uml>
Notes
Ecrans
libGDX permet la gestion des écrans (Screen). Un écran occupe toute la surface de rendu
et permet de rapidement changer la présentation.
Chaque écran agit à la fois comme un Contrôlleur et une Vue. Il est chargé d'afficher sa Vue dans sa méthode render().
Services Réseau
Les services réseau servent à abstraire l'interaction avec le réseau.
Interacteur
Permet d'abstraire les interactions avec l'état de jeu à travers le réseau. Il notifie des modifications effectuées à l'état aux observateurs pour qu'ils puissent les afficher.
Serveur
<uml title=“Server Domain Model”> hide empty members hide empty fields hide class circle hide interface circle
package “Networking” { class Netty class NetworkHandler } class GameHandler class LoginHandler class MatchmakingHandler package “Login” { class User «Model» class Session class SessionManager «Singleton» } package “Matchmaking” { class MatchmakingManager «Service» class Queue } package “Game” { class GameSession class GameState class StateHandler class TurnHandler class ActionFactory }
SessionManager *– “*” Session Session *- User
Netty <..> NetworkHandler
note as N1 Packets are dispatched to the correct handler as defined by the user session endnote
NetworkHandler ..> N1 Session .r.> N1 N1 ..> MatchmakingHandler N1 ..> LoginHandler N1 ..> GameHandler
Session <.. LoginHandler: creates
MatchmakingHandler — MatchmakingManager
MatchmakingManager – Queue
GameHandler – GameSession
GameSession *– TurnHandler GameSession *–o StateHandler GameSession *– GameState StateHandler *– ActionFactory
</uml>
Notes
Session (de Connexion)
Une session est crée à l'établissement d'une connexion au serveur et persiste jusqu'à la déconnexion du client. La session permet de gérer l'état d'authentification ainsi que la cible des paquets.
Matchmaking
Le matchmaking s'effectue en plaçant les sessions dans des files d'attente. Une fois qu'une file d'attente à atteint le nombre requis de joueurs en fonction de sa configuration. Une session de jeu est crée en y ajoutant les joueurs.
Session de Jeu
Lorsqu'une session de jeu est crée elle est initialisée avec ses paramètres de jeu (joueurs, carte, …). Elle transmet ensuite l'état de jeu initial les joueurs du début de partie et les notifie qu'elle est prête à recevoir les interactions des joueurs.
- GameState: Contient l'état de la partie. Toutes les unités en jeu ainsi qu'une représentation de la carte.
- StateHandler: Effectue les opérations de modification sur le GameState et garde trace des changements pour pouvoir effectuer les mises à jour différentielles.
- ActionFactor: Mécanisme générique de gestion des actions sur l'état de jeu.
- TurnHandler: Gère le turn order pour la partie.
Base de Données
<uml title=“Data Model”> hide methods
class User «(E,lightblue)» {
+username +password <i>hashed</i> +rating
}
class Game «(E,lightblue)» {
+startedAt +length
}
class Stats «(E,lightblue» {
+isWinner +rating <i>At time of game</i> +score
}
class Role «(E,lightblue)» {
+name
}
class Ban «(E,lightblue)» {
+start +end +reason
}
Player “1” -d- “*” Role: roles Player “1” -r- “*” Ban: bans Game “*” -l- “1” Player (Game, Player) .. Stats </uml>
Notes
La base de données sert à répertorier les joueurs et garder trace des parties jouées pour déterminer le rating d'un joueur.
La trace des banissements des joueurs est aussi inscrite dans la base de données afin de leur refuser l'accès au jeu.
| Entité | Description |
|---|---|
| User | Utilisateur de l'application, peut se connecter via le client |
| Role | Permet de déterminer les actions auquels à droit un utilisateur |
| Ban | Historique de banissement des joueurs |
| Game | Partie joué |
| Stats | Statistiques de la partie pour un joueur |
Gestion du Projet
Rôles
Rôle des participants au sein du groupe de développement
| Role | Laureline | Yves | Samuel | Christophe |
|---|---|---|---|---|
| Project Manager | Primary | Assistant | ||
| Software Architect | Primary | |||
| Analyst | Primary | |||
| Game Designer | Assistant | Primary | ||
| Documentalist | Primary | Assistant | Assistant | Assistant |
| Implementer | Server | Server | Client | Client |
| Tester | Server | Server | Client | Client |
Plan d'Iterations
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.
Equipes de Travail
- Client
- Samuel
- Christophe
- Serveur
- Laureline
- Yves
Travail déjà Réalisé
- Squelette de projet
- Mise en place du gestionnaire de paquets Netty
Iteration 1
<columns 100% 50% 50%> Dates 14 Avril - 20 Avril
Charge de Travail 4h30 par personne (total 18h)
Objectifs
- 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>
Implémentation
Client
- Mise en place des écrans (stubs)
LoginScreen,MenuScreen,LobbyScreenetGameScreen. - Implémenter la logique du
LoginScreen - Utilisation de service dummy pour la gestion du réseau.
Serveur
- 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>
Bilan
<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>
Laureline (~6h)
- Effectué la mise en place du NetworkHandler.
Samuel (~15h)
- Création des dummy classes pour les tests
- Création du LoginScreen, LobbyScreen, CreateScreen, MainMenu
- Implémentation partielle de la logique du LobbyScreen
Yves (10h)
- 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.
Christophe (6h)
- 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>
Iteration 2
<columns 100% 50% 50%> Dates 28 Avril - 4 Mai
Charge de Travail 4h30 par personne (total 18h)
Objectifs
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>
Implémentation
Client
- Mettre en place le
NetworkManagerutilisant le réseau - Implémenter la logique du
MenuScreenetLobbyScreen
Serveur
- Mise en place du
LobbyHandler - Mise en place du système de Matchmaking
Admin
- Mettre en place l'application web
- Se connecter à la base de données du jeu
</columns>
Bilan
<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>
Laureline (~6h)
- 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é.
Samuel (3h)
- Avancement dans la logique du Lobby Screen
Yves (0h)
- Rien fait…
Christophe (0h)
- Rien fait…
</columns>
Iteration 3
<columns 100% 50% 50%> Dates 5 Mai - 11 Mai
Charge de Travail 4h30 par personne (total 18h)
Objectifs
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>
Implémentation
Client
- Recevoir l'état de jeu
- Afficher la carte
- Afficher les acteurs (bâtiments, unités)
Serveur
- Initialiser l'état de jeu
- Charger la carte
- Définir le Turn Order
- Placer les Bases
- Le transmettre au client
Admin
- Mettre en place une interface pour bannir un joueur
</columns>
Bilan
<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>
Laureline (~6h)
- 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.
Samuel (0h)
- Hum…
Yves (0h)
- Rien fait…
Christophe (3h)
- Tests et tuto libgdx avec Tiled
</columns>
Iteration 4
<columns 100% 50% 50%> Dates 12 Mai - 18 Mai
Charge de Travail 6h00 par personne (total 24h)
Objectifs
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>
Implémentation
Client
- 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
Serveur
- 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
Admin
- Compléter l'admin (Login admin, bannir et lister les joueurs)
</columns>
Bilan
<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>
Laureline (6h)
- Initialisation de l'état de jeu
- Correction de bugs divers
Samuel (2h)
- Correction sur le MainMenu
- Test du LoginScreen
Yves (~4h)
- Création de l'interface d'administration (4h)
Christophe (6h)
- 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>
Iteration 5
<columns 100% 50% 50%> Dates 19 Mai - 25 Mai
Charge de Travail 5h00 par personne (total 20h)
Objectifs
- Réaliser Play a Game (gras = fait)
- Le serveur notifie les clients qu'ils sont entrés dans une partie
- Le jeu affiche l'écran de jeu
- Le serveur crée l'état de jeu original
- Le serveur détermine l'ordre de passage des joueurs
- A effectuer tant qu'il reste plus d'un joueur
- Le serveur informe les clients du joueur en cours
- Tant que le joueur peut effectuer une action
- Le joueur effectue une action (déplacement, attaque, …)
- Le serveur valide l'action et l'applique à l'état de jeu (retard)
- Le serveur informe les clients des changements dans l'état de jeu (retard)
- Si un joueur à été éliminé
- Informer tous les joueurs du joueur éliminé
- Le joueur termine son tour
- Le serveur sélectionne le prochain joueur dans l'ordre de passage
- La serveur notifie de la fin de la partie
- Le jeu affiche le menu principal
<newcolumn>
Implémentation
Client (10h - Samuel et Christophe)
- 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)
Serveur (10h - Laureline et Yves)
- Transmettre l'état de jeu au client
- Gestion de la requête de déplacement
- Broadcast si succès
- Reply si échec
Admin (1h - Yves)
- Afficher l'historique des parties dans l'admin
</columns>
Bilan
<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>
Laureline (8h)
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.
Samuel (4h)
- 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.
Yves (1h)
- Création de la page statistiques (historique des parties) déjà implémentée dans l'itération 4 (avance).
Christophe (4h)
- 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>
Iteration 6
<columns 100% 50% 50%> Dates 26 Mai - 01 Juin
Charge de Travail 5h par personne (total 20h)
Objectifs
Gestion des actions (dépendantes des archétypes) des acteurs
- Réaliser Play a Game en entier
- Le serveur notifie les clients qu'ils sont entrés dans une partie
- Le jeu affiche l'écran de jeu
- Le serveur crée l'état de jeu original
- Le serveur détermine l'ordre de passage des joueurs
- A effectuer tant qu'il reste plus d'un joueur
- Le serveur informe les clients du joueur en cours
- Tant que le joueur peut effectuer une action
- Le joueur effectue une action (déplacement, attaque, …)
- Le serveur valide l'action et l'applique à l'état de jeu
- Le serveur informe les clients des changements dans l'état de jeu
- Si un joueur à été éliminé
- Informer tous les joueurs du joueur éliminé
- Le joueur termine son tour
- Le serveur sélectionne le prochain joueur dans l'ordre de passage
- La serveur notifie de la fin de la partie
- Le jeu affiche le menu principal
<newcolumn>
Implémentation
Client (10h) Christiophe et Samuel
- 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
Serveur (10h) Yves et Laureline
- Terminer le serializer (50%)
- Gestion des requètes d'action
</columns>
Bilan
<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>
Laureline (0h)
- Rien
Samuel (4h)
- Interactor
Yves (0h)
- Rien
Christophe (0h)
- Rien
</columns>
Iteration 7
<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>
Implémentation
Client (12h) Christiophe et Samuel
- 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
Serveur (8h) Laureline
- Terminer le serializer (50%)
- Gestion des requêtes d'action
Documentation 12h (8h Yves / 2h Samuel / 2h Christophe)
- Finaliser la documentation
</columns>
Bilan
<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>
Laureline (10h)
- Terminé le serializer
- Implémenté la gestion des actions
- Fonctionne en théorie ;)
- Implémentation de la gestion du jeu (fin de partie)
Samuel (4h)
- Terminer l'interacteur
Yves (4h)
- Documentation
Christophe (2h)
- Avancement du client
</columns>
Iteration 8
<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>
Implémentation
Client (5h) Christiophe et Samuel
Serveur (4h) Laureline
Documentation (5h Yves et 2h les autres)
- Finaliser la documentation
</columns>
Bilan
<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>
Laureline (???h)
Samuel (???h)
Yves (???h)
- Documentation
Christophe (???h)
</columns>
16 Juin 2016
Rendu du projet et Présentation.