Machines à états dans un environnement de jeu

J'essaye actuellement de réaliser une petite machine à états pour un jeu et je me heurte à quelques problèmes de conception

Basiquement, ma boucle de jeu se présente ainsi :

• réception des inputs (clavier, souris) et transmission par message-passing à la logique de jeu
• update de la logique de jeu (déplacements des objets, collisions, IA...) à chaque frame
• rendu

L'ensemble des objets est regroupé dans un objet Scène, contenu dans la logique de jeu

Par ailleurs, la logique de jeu peut se trouver dans différents états, que ce soit l'initialisation, le chargement, le menu principal, la scène, menu pause, etc... La navigation entre les différents menus implique des changements d'état

La modélisation de ces états et leurs transitions m'a conduit au design pattern State et par extension, aux FSM

Le problème, c'est que dans les FSM un état ne contient pas de données (seulement un comportement) et ne présente que deux méthodes, onEntry et onExit, executées à chaque transition

Or j'ai besoin d'appliquer deux actions sur la logique de jeu :

• update à intervalles réguliers, même s'il n'y a pas d'input utilisateurs
• traitement des inputs utilisateurs à intervalles irréguliers

Les états sont alors le seul moyen de communiquer avec la Logique
Faut il leur ajouter deux méthodes représentant les actions ci-dessus ? Ou bien une seule méthode Handle(evt) avec en paramètre des évènements "update" ou "keyboard" ?

Il y a également le problème des données partagées, que sont la Scène et l'IA
Il faut bien que l'état puisse communiquer avec s'il veut leur transmettre les évènements; comment faire s'il ne contient aucune donnée ni référence ? Une possibilité serait de tricher avec unique pointeur sur un objet GameLogic
et de dispatcher le traitement en interne

Voilà les quelques pistes que j'ai pu élaborer

Sans doute certains d'entre vous ont été confrontés à ce genre de situation, mais dans d'autres contextes :)
Si vous avez de meilleures idées, n'hésitez pas :)

merci :)

FSM c'est un Flying Spaghetti Monster?

Plus sérieusement, pourquoi pas de données dans un état?
il faut bien appliquer le comportement a quelque chose non?

Citation:

---

Envoyé par screetch

FSM c'est un Flying Spaghetti Monster?

Plus sérieusement, pourquoi pas de données dans un état?
il faut bien appliquer le comportement a quelque chose non?

---

C'est ce que je me suis dit mais il me semble que le DP State et UML spécifient qu'un état est une représentation "qualitative" et non "quantitative", et donc qu'il ne transporte pas de données

Mais je suis d’accord qu'il faut appliquer le comportement à un objet tangible

ben moi mes états ont des données, j'avoue que je vois mal comment faire sans. Si un expert en machines a état passe par la, je regarderai avec curiosité :)

Je crois que la réponse tiens dans le mot "état" :) Si un état n'a pas de donnée, comment le différencier d'un autre ? Si les états différents ne sont pas différentiables, en quoi sont-il des états ?

Les transitions n'ont pas besoin de données, puisqu'il s'agit de fonctions permettant de passer d'un état A à un état B (B pouvant être A si besoin) en fonction d'une condition (paramètres).

1. FSM : Finite State Machine
2. Les FSM sont en passe d'être remplacées par les Behaviour Tree coté IA, mais a priori c'est pas le sujet.

3. Je ne comprends pas pourquoi tes FSM sont le seul moyen de communiquer : ils doivent permettre de passer d'un contexte à un autre, mais C'EST TOUT.
4 Pour la communication, met en place un ou plusieurs "black board", c'est à dire un objet dont le but est juste de stocker des evenements, et de les balancer à ceux qui sont intéréssés pour des évènements précis - mais seulement lorsque tu appelles une fonction qui va traiter tout ça. De cette façon, tu accumule des évènements, puis tu les fait traiter quand il est temps et ensuite tu mets a jour l'état du jeu, éventuellement tu lui fait prendre des décisions.
5. Tes FSM et le système de communication doivent être orthogonaux. (dans l'idéal) Peut être que si tes FSM attendaient des évènements dans le système d'events, ça te permettrai de les faire intéragir de manière indirecte.

J'espère que ça va t'aider.

Citation:

---

Envoyé par Klaim

1. FSM : Finite State Machine
2. Les FSM sont en passe d'être remplacées par les Behaviour Tree coté IA, mais a priori c'est pas le sujet.

3. Je ne comprends pas pourquoi tes FSM sont le seul moyen de communiquer : ils doivent permettre de passer d'un contexte à un autre, mais C'EST TOUT.
4 Pour la communication, met en place un ou plusieurs "black board", c'est à dire un objet dont le but est juste de stocker des evenements, et de les balancer à ceux qui sont intéréssés pour des évènements précis - mais seulement lorsque tu appelles une fonction qui va traiter tout ça. De cette façon, tu accumule des évènements, puis tu les fait traiter quand il est temps et ensuite tu mets a jour l'état du jeu, éventuellement tu lui fait prendre des décisions.
5. Tes FSM et le système de communication doivent être orthogonaux. (dans l'idéal) Peut être que si tes FSM attendaient des évènements dans le système d'events, ça te permettrai de les faire intéragir de manière indirecte.

J'espère que ça va t'aider.

---

4.En fait mes composants communiquent déjà via un système de publish/subscribe (ce que tu décris)

voici un schéma grossièrement représentatif de l'ensemble du système :

http://img405.imageshack.us/img405/2285/fig128050.png



comme tu peux le voir, l'évènement keyboard est envoyé depuis l'InputManager, consommé par le LogicListener puis présenté à l'état courant de la StateMachine; Selon l'état, la méthode execute() ne fera pas la même chose de cet évènement; ensuite elle modifiera des données dans le bloc Logic (déplacement d'un objet par exemple)

Ce que je voulais dire c'est que si la boucle dans le Main veut faire un Update sur la logique, elle doit obligatoirement passer par l'EventManager + la StateMachine; elle ne peut pas l'atteindre autrement

Enfin ça c'est mon idée de départ :)