Je viens de tomber sur cet article par hasard (excellent d’ailleurs, bien expliqué et très intéressant).

Je suis pas un expert mais quel est l’avantage de cette approche avec une table de pointeurs sur fonctions, comparée à une machine d’état qui serait implémentée façon OO: une classe abstraite “State” et la dériver pour chaque état spécifique? Les états pourraient eux-mêmes décider des transitions et ainsi éviter les transitions interdites (s’accroupir alors que l’entité vole). Les méthodes OnEnter(), OnExit(), OnProcess() etc seraient aussi appelées correctement car définies dans la classe de base.

Problème de performances? de facilité à modifier si nécessaire?

Concernant les machines à états et leurs langages, regardes plutôt cette page :

http://www.lri.fr/~blanch/publications/ihm2002/ihm2002-hsm.html

(c’est destiné aux IHMs mais ça peut aussi être adapter à l’IA)

Debugger est clairement pas la joie, selon le language script il est aussi difficile de faire ce que l’on veut avec, mais le plus dur est d’avoir une ligne clair entre code et script.

Si on fait un language script pour les designers il est minimaliste et au final un designer n’est pas un programmer et ca loupera pas, un programmeur devra s’y coller. Si c’est un programmeur qui s’y colle un language script minimaliste va le frustrer au plus haut point.

Bref je suis pas fan de language script.

L’usage le plus ridicule que j’ai vue d’un langage script c’etait avec Catwoman. Les pauvres programmeurs utilisaient un language script fait maison pour faire le gameplay.
Du coup le language etait inadapte, impossible a debugger, et le plus drole de tous il ne se relancait pas pendant le jeu. Du coup y’avait aucun avantage a etre un language script.

Pour la programmation de machine à état, il y a plusieurs manière de la programmer. Certains utilisent des macros (pour cacher des switchs et des if /else) avec pour chaque états des macros du genre : OnInit, OnExit, OnUpdate, OnChange… (bien entendu chaque état peut possèdé un timeout et passer à l’état suivant). D’autres font des machines à états comme ce que tu as décrit. Par contre, une machine à état est quelque chose qui est souvent ammené à être changé. L’idéal serait qu’elle fasse partie des données de ton jeu et non qu’elle soit à l’interieur de ton code. Pour cela, tu peux faire appel à un langage script et implementer un bouton reset qui te permettra de changer ta machine à état ingame…ça te fera gagner du temps pour le dév de ton jeu.

Très bon article Jérémy, c’est sympa de voir que c’est pas si compliqué de faire de l’IA