State Machines: State Object versus Sequential Check: quels sont les avantages / inconvénients?

8

Je ne connais pas grand-chose à la machine à états finis en IA ou aux autres comportements de jeu dans le jeu, à l'exception de ce tutoriel rapide avec un mineur: http://www.ai-junkie.com/architecture/state_driven/tut_state1.html qui est orienté objet.

Je ne sais pas vraiment si ce tutoriel décrit le modèle State ou non, qu'en pensez-vous?

Je ne parle pas d'autres choses plus orientées vers l'arithmétique comme la direction ou la physique ou la recherche de chemin ou les collisions, mais plutôt de la logique du jeu, de l'IA pilotée par l'état et de choses qui impliquent beaucoup d'états simultanés et ifs et / ou switches

Quels sont les avantages / inconvénients de l'utilisation d'un modèle d'état ou d'une vérification séquentielle d'une structure d'état simple comme celle-ci:

struct States
{
bool is_walking, is_running, holds_a_weapon, is_crouch;
int weapon_id, int id_team;
};

void HandleStates (States state)
{
//etc
}
jokoon
la source
2
Je pense que vous pourriez avoir besoin de mieux formuler votre question, mais une réponse rapide à ce qui précède pour que vous puissiez le faire est qu'en général, l'État supprime les vérifications If. switch (state) {case blah} pour créer une table de saut, ou ma façon préférée de faire les choses, les pointeurs de fonction ou les délégués sur une pile ou une file d'attente si l'IA doit revenir à ce qu'elle faisait avant ou passer à la chose suivante. ..
James

Réponses:

10

J'essaierai d'y répondre du mieux que je pourrai, mais il y a certaines "meilleures pratiques" sur lesquelles je ne suis pas sûr, mais j'essaierai de les décomposer aussi clairement que possible.

FSM

Tout d'abord, le didacticiel Miner provient de Programming Game AI by Example de Mat Buckland (que je vous recommande d'obtenir comme introduction à l'IA). Il utilise une énumération pour chaque état, PAS une structure. Avec la structure dans votre exemple, vous avez des booléens comme états, vous pouvez donc avoir n'importe quel nombre de ceux-ci en même temps. Cela peut conduire au comportement que vous souhaitez, mais le plus souvent avec les FSM (Finite State Machines), il conduit à un comportement indésirable.

Par exemple:

enum
{
WANDER_AROUND,
ATTACK,
RUN_AWAY,
};

Deuxièmement, ce n'est pas la seule façon dont il décrit les États. La manière que je préfère personnellement (selon la situation) est de créer une classe abstraite appelée State qui a une fonction Enter (), Exit () et Update (). Créez ensuite mes états en tant que sous-classes de la classe State.

Comme cette image (qui se trouve en fait à la page 2 de ce lien): texte alternatif

Modèle d'état

À mon avis personnel, le modèle d'état n'est qu'une partie de la conception de logiciels où le logiciel a un certain nombre d'états. L' implémentation appartient au développeur. Je ne pense pas qu'il y ait une différence appropriée entre l'utilisation d'une instruction Big Switch ou la création d'une machine d'état complète pour exécuter tous vos états comme je l'ai indiqué ci-dessus. Ils font essentiellement la même chose. À cet égard, la réponse à l'une de vos questions est oui, je crois que cette page décrit le modèle d'état.

Avantages / inconvénients

Il existe des avantages et des inconvénients à toute méthode que vous utilisez pour implémenter une conception pilotée par l'état.

Utilisation d'une instruction If / Else ou Switch

Avantages:

  • Très facile à ajouter et à vérifier les conditions des états
  • Peut être prototypé très rapidement

Les inconvénients:

  • Lorsque vous avez une charge d'états, cela peut devenir très moche, très rapidement.
  • Il est difficile de suivre les transitions, les effets lorsque l'état est entré / quitté ou tout ce qui est spécifique à l'état

Utilisation d'une machine à états orientée objet

Avantages:

  • Très extensible - la seule chose que vous devez faire est de créer un nouvel état qui hérite de la classe d'état abstraite
  • Facilement maintenable - Vous n'avez pas à vous soucier du code d'aspect spaghetti car chaque état réside dans sa propre classe. Vous pouvez facilement voir les conditions associées à cet état sans vous soucier des autres états.
  • Intuitif - Si vous travaillez sur un projet d'équipe avec ce type de machine d'état, ce sera beaucoup plus facile pour la personne qui lit votre code. Ils n'auront pas à lire des lignes sur des lignes de code juste pour arriver à un certain état ("Toujours programmer comme si le programmeur qui maintient votre code est un psychopathe qui sait où vous vivez!" :))

Les inconvénients:

  • Légère courbe d'apprentissage - Cette conception peut prendre un certain temps pour obtenir votre tête complètement ronde lors de sa mise en œuvre
  • Honnêtement, je ne peux plus penser à cela, car je préfère cette façon, mais si quelqu'un souhaite y ajouter, commentez et je les ajouterai.

J'espère que cela répond à toutes vos questions. En fait, je viens d'ouvrir ma copie de Programming Game AI par exemple et Mat mentionne que la machine d'état est connue sous le nom de "modèle de conception d'état". Personnellement, je ne suis pas d'accord, mais pour chacun le sien.

J'espère que cela aide :)

Ray Dey
la source
1
+1, cela décrit essentiellement comment j'ai créé ma State Machine. Ça marche bien.
Kyle C
Pourriez-vous dire qu'il y a un impact sur les performances avec le modèle de "machine à états orientée objet" - si léger soit-il?
Noob Saibot
@NoobSaibot Oui, mais vous pouvez en discuter à propos de n'importe quoi. Le if-else pourrait souffrir d'une mauvaise prédiction de branchement, le modèle d'état tel que décrit ci-dessus peut souffrir de la surcharge de recherche de table. Les deux sont peu probables, sauf si vous avez une tonne d'états. La vraie réponse à votre question est donc "ça dépend".
Ray Dey