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):
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 :)