Skip to main content

Machine à états

L’application est conçue autour d’une machine à états qui gère les différentes étapes d’une partie, de la préparation du lobby à sa finalisation. Le backend décide des transitions ; Unity et le client spectateur appliquent l’état reçu.

Cette page regroupe la machine à états des contrats d’API proposés. Les noms ci-dessous correspondent exactement aux valeurs de MatchState du modèle. Le lobby est représenté par MATCH_STARTING, sans état Lobby distinct.

Diagramme des états​

Responsabilités par état​

ÉtatResponsabilités du backend
MATCH_STARTINGPréparer le lobby, accepter inscriptions et affectations ; attendre la demande du créateur avec quatre joueurs répartis.
ROUND_STARTINGIncrémenter roundNumber, restaurer les HP de tous les joueurs, les placer à leurs points d’apparition avec leur rotation initiale, réinitialiser les séquences et données propres au round, notifier les clients. Conserver scores et statistiques cumulées.
ROUND_ONGOINGAccepter mouvement et combat, synchroniser, appliquer les dégâts déclarés, détecter les éliminations et suivre les survivants.
ROUND_ENDINGDéterminer le vainqueur, actualiser les scores, diffuser le résultat, décider du prochain round ou de la fin. Refuser le gameplay.
MATCH_ENDEDFinaliser les statistiques, persister les résultats et notifier tous les clients ; aucun nouveau round.

Lorsque tous les joueurs d’une équipe sont éliminés, le backend passe à ROUND_ENDING et l’équipe adverse gagne. Proposition de score : un round gagné ajoute 1 à Team.score. Les règles d’égalité, le nombre de rounds, une limite de score, les durées des phases et les timeouts restent configurables et à spécifier ; aucun seuil ni délai exact n’est imposé.

Un joueur avec hp <= 0 ne peut ni bouger, ni tirer, ni réapparaître pendant le round courant. Aucune requête cliente player.respawn n’existe. Seul le backend déclenche le prochain round et restaure les HP dans ROUND_STARTING. Unity applique les valeurs reçues avant de reprendre le gameplay à ROUND_ONGOING.

Conditions de transition​

  • Création → MATCH_STARTING : le créateur authentifié crée la partie et rejoint son lobby. Les joueurs peuvent rejoindre ou quitter le lobby ; le créateur affecte les équipes.
  • MATCH_STARTING → ROUND_STARTING : le créateur envoie match.start. Le backend vérifie exactement quatre joueurs connectés et deux équipes de deux.
  • ROUND_STARTING → ROUND_ONGOING : le backend termine la préparation du round, puis annonce son démarrage. Le protocole ne définit pas de commande cliente de confirmation de disponibilité.
  • ROUND_ONGOING → ROUND_ENDING : tous les joueurs d’une équipe sont éliminés. Le backend calcule le résultat et actualise le score une seule fois.
  • ROUND_ENDING → ROUND_STARTING ou MATCH_ENDED : le backend applique les règles de fin configurées. Le nombre de rounds et la limite de score restent à spécifier.
  • MATCH_ENDED → fin : le backend finalise et sauvegarde les résultats avant de confirmer la fin de partie.

État partagé et notifications​

Chaque transition produit un match.stateChanged avec l’instantané complet pour les joueurs et un spectate.stateChanged pour les spectateurs. La préparation d’un nouveau round restaure les HP et les points d’apparition sans effacer les scores ni les statistiques cumulées.

Les notifications de rounds et leur séquence détaillent round.started, round.ended, match.ended et les instantanés spectateurs. Les règles de reconnexion conservent le joueur dans l’état partagé pendant une partie lancée : une coupure réseau ne provoque ni mort ni réapparition automatique.