IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Machines à états dans un environnement de jeu


Sujet :

C++

  1. #1
    Membre habitué
    Profil pro
    Dev
    Inscrit en
    Mai 2009
    Messages
    257
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Dev

    Informations forums :
    Inscription : Mai 2009
    Messages : 257
    Points : 190
    Points
    190
    Par défaut 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

  2. #2
    screetch
    Invité(e)
    Par défaut
    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?

  3. #3
    Membre habitué
    Profil pro
    Dev
    Inscrit en
    Mai 2009
    Messages
    257
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Dev

    Informations forums :
    Inscription : Mai 2009
    Messages : 257
    Points : 190
    Points
    190
    Par défaut
    Citation Envoyé par screetch Voir le message
    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

  4. #4
    screetch
    Invité(e)
    Par défaut
    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é

  5. #5
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Points : 4 551
    Points
    4 551
    Par défaut
    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).
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  6. #6
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    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.

  7. #7
    Membre habitué
    Profil pro
    Dev
    Inscrit en
    Mai 2009
    Messages
    257
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Dev

    Informations forums :
    Inscription : Mai 2009
    Messages : 257
    Points : 190
    Points
    190
    Par défaut
    Citation Envoyé par Klaim Voir le message
    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 :





    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

Discussions similaires

  1. [Design] Jeu de la vie, machine à état
    Par r0d dans le forum C++
    Réponses: 16
    Dernier message: 24/06/2013, 16h39
  2. Réponses: 1
    Dernier message: 10/10/2011, 13h11
  3. [Moteur de jeu] Le kernel vu comme une machine à état
    Par Kromagg dans le forum Développement 2D, 3D et Jeux
    Réponses: 8
    Dernier message: 22/04/2009, 13h50
  4. [Crystal reports 10] Sous états dans un sous état
    Par jidea dans le forum SAP Crystal Reports
    Réponses: 1
    Dernier message: 12/08/2004, 11h53
  5. Serveur Linux dans un environnement Windows
    Par Loth dans le forum Réseau
    Réponses: 6
    Dernier message: 29/05/2004, 11h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo