Notion d’état (1) – Définition

Les jeux et applications sont généralement conçus en “mélangeant” toutes les notions sans définir des frontières entre elles. Cela pose tout un ensemble de problèmes dont l’énumération est fastidieuse: je vous invite à (re)lire la page A propos pour plus de détails. Parmi les notions à considérer lors de la conception d’un jeu ou d’une application, les premières à prendre en compte sont celles qui concerne les données. Pour les identifier et bien les gérer, je propose de vous présenter une approche basée sur la notion d’état.

Avec cette approche, l’idée est de rassembler toutes les informations qui définissent l’état du jeu ou de l’application. Ces informations se limitent aux données qui sont au cœur des traitements ou de la progression dans le jeu, et ne considèrent pas des informations annexes comme l’interaction avec l’utilisateur. Cet état est également défini dans le temps d’une manière très précise. Ainsi, lorsque l’état est modifié, on passe d’un état t à un état t+1.

Ceux qui travaillent avec des bases de données, comme SQL, connaissent bien cette approche: la base de donnée est l’état à un temps t, et une requête fait passer la base de donnée d’un état t à un état t+1. La base ne contient que les informations utiles aux traitements (elles sont souvent dites “métiers”), et ne contient pas les valeurs requises à une activité tierce comme celles d’un client SQL. En parlant de client SQL, si celui-ci est bien conçu, il doit également avoir sa propre notion d’état, différente de celle de la base. Un moyen de le prédire est d’observer s’il y a une fonction de retour arrière: si c’est le cas, il y a de grandes chance que la notion d’état soit utilisée.

Prenons un exemple avec le jeu du taquin: son état est défini par la position des différentes tuiles sur la grille. Si la grille fait 3×3 cellules, 9 valeurs sont suffisantes pour former l’état du jeu. Puis, chaque déplacement d’une tuile modifie l’état, le faisant passer d’une configuration à l’autre, par exemple:

Cette notion d’état simplifie énormément de choses. Tout d’abord, il n’y a pas de confusion possible entre la logique du jeu et les autres notions comme l’interaction utilisateur ou l’affichage à l’écran. Cela aide aussi énormément pour la gestion du temps et des synchronisations: le périmètre d’un état étant bien défini, toute évolution du jeu est toujours maîtrisée. Il n’y a pas de place pour les comportements indéfinis et les bugs hasardeux qui les accompagnent toujours. La notion simplifie aussi la sauvegarde et le chargement: tout est dans une boite, il ne reste plus qu’à sérialiser/désérialiser ! En outre, il est garanti que ce qui a été sauvegardé sera parfaitement reproduit au chargement. De même pour le jeu en réseau: il devient très simple d’assurer que toutes les machines ont le même contenu. Enfin, pour tout ce qui concerne l’intelligence artificielle, cela ouvre en grand les portes de toutes les méthodes de la littérature, avec les performances qui les accompagnent.

Définition d’un état

Pour bien mettre en œuvre cette notion d’état, il faut commencer par bien la définir sur le papier. J’ai bien conscience que c’est contre-nature pour beaucoup de débutants (et moins débutants !), mais cette étape “papier” fait gagner un temps fou. Par “papier” j’entends tout outils non lié à la programmation pure, de la feuille blanche aux outils UML en passant par tous les outils de “brainstorming”.

Les types d’informations requises pour représenter les données sont très nombreux. Parmi ceux-ci, il faut souvent choisir une manière de représenter la position d’un éléments dans le monde, comme des coordonnées 2D (x,y). Pour les jeux dont le monde est en 3D, une troisième coordonnée est requise, par exemple (x,y,z). A cela peut s’ajouter des notions de lieux, comme le niveau et/ou l’étage dans un bâtiment. Il faut également se poser la question de la superposition des éléments. Dans certains cas, les éléments peuvent avoir des coordonnées similaires, mais dans un certain ordre. Par exemple, dans les jeux de stratégie les unités peuvent s’empiler sur une même case, comme Civilization. Dans ces cas, un attribut de position dans la pile est requis.

Il existe ensuite un grand nombre de propriétés qui peuvent qualifier un élément ou un groupe d’éléments. Par exemple, dans les jeux de rôles, il y a des notions de vie ou de mana. Ces attributs ont souvent des valeurs minimales et maximales, qu’il faut définir dès ce niveau de conception. Il faut également préciser s’il est possible d’avoir des doublons de propriétés et/ou d’élément : cela aura un impact important sur la conception informatique qui va suivre (i.e., choix d’une structure de donnée). Il peut également y avoir des notions de durée de vie d’éléments : celles-ci sont le plus souvent représentées par un compteur de temps.

Exemple de définition

Je vous propose ici un exemple de définition pour le jeu Pacman. Ce n’est pas celle du original, j’ai simplifié et choisi des cas qui permettent une meilleure illustration.

Un état du jeu Pacman est formée par un ensemble d’éléments fixes (le monde) et un ensemble d’éléments mobiles (Pacman et fantômes). Tous les éléments possèdent les propriétés suivantes :

  • Type d’élément
  • Coordonnées (x,y) dans la grille

Éléments fixes

Le monde est formé par une grille d’éléments nommés « cases » ou « cellules ». La taille de cette grille est fixée au démarrage du niveau. Les types de cases sont :
Cases « Mur ». Les cases « mur » sont des éléments infranchissable pour les éléments mobiles. Les textures possibles sont :

  • Coin haut gauche, coin haut droit, coin bas gauche, coin bas droit
  • Horizontal, Vertical

Le choix de la texture est purement esthétique, et n’a pas d’influence sur l’évolution du jeu.

Cases « Espace ». Les cases « espace » sont les éléments franchissables par les éléments mobiles. On considère les types de cases « espace » suivants :

  • Les espaces « vides »
  • Les espaces « pastille », qui contiennent une pastille
  • Les espaces « super pastille », qui contiennent une super pastille
  • Les espaces « cimetière », qui servent à définir les lieux où les fantômes apparaissent au début du jeu, mais également les lieux où ceux dévorés par Pacman peuvent reprendre une forme normale.
  • Les espaces « départ », qui définissent une position initiale possible pour Pacman.

Éléments mobiles

Les éléments mobiles possèdent une direction (aucune, gauche, droite, haut ou bas), une vitesse, et une position. Une position à zéro signifie que l’élément est exactement sur la case ; pour les autres valeurs, cela signifie qu’il est entre deux cases (l’actuelle et celle définie par la direction de l’élément). Lorsque la position est égale à la vitesse, alors l’élément passe à la position suivante. Ainsi, plus la valeur numérique de vitesse est grande, plus le personnage aura un déplacement lent. Ce système est choisi pour pouvoir être toujours synchronisé avec une horloge globale.

Élément mobile « Pacman ». Cet élément est dirigé par le joueur, qui commande la propriété de direction. Pacman dispose également d’un « compteur super », qui sert à déterminer le temps restant avant de repasser en normal. Enfin, on utilise une propriété que l’on nommera « statut », et qui peut prendre les valeurs suivantes :

  • Statut « normal » : cas le plus courant, où Pacman peut se déplacer dans le labyrinthe, et doit éviter les fantômes.
  • Statut « super » : cas où Pacman peut manger les fantômes
  • Statut « mort » : cas où Pacman a été pris par un fantôme.

Éléments mobiles « Fantôme ». Ces éléments sont également commandés par la propriété de direction, qu’elle proviennent d’un humain ou d’une IA. Ces éléments possèdent deux propriétés particulières. La première est la « couleur », qui est purement esthétique. La seule règle concernant cette couleur est qu’elle est unique pour chaque fantôme. La seconde propriété particulière est le « statut », qui peut prendre les valeurs suivantes :

  • Statut « normal » : cas le plus courant, où le fantôme peut tuer Pacman.
  • Statut « fuite » : cas où le fantôme peut être tué par « super » Pacman.
  • Statut « mort » : cas où le fantôme a été dévoré par « super » Pacman.
Ce contenu a été publié dans Tutoriel. Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire