Discussion :

[Le Kamikaze]

bonjour, j'ai programmé un système où les personnages changent de comportement sans arrêt, mais j'ai peur d'un bug qui survienne dans un cas rare et pas prévu

explication: lorsque j'envoie un ordre qui indique aux personnages de changer de comportement (l'ordre peut venir de l'objet lui-même ou d'un évènement extérieur), ils ont tous un autre comportement qui est en train de s'exécuter et dont les variables sont paramétrées d'une certaine façon... à partir de là je dois changer plein de variables avant de trouver et lancer la nouvelle routine de comportement, seulement, en fonction de leur comportement courant, ces variables ne vont pas être modifiées de la même manière, le nouveau comportement ne va pas être le même, et c'est vite arrivé de faire une erreur, d'oublier une variable qui va tout planter

j'ai regardé du côté du design pattern "finite state machine", apparemment la technique employée pour être sûr de n'avoir oublié aucun cas, consiste à créer une fonction de transition entre chaque couple de deux états.

or cette méthode me pose problème, il se trouve que j'ai une vingtaine de comportements pour mes personnages, si je dois coder une fonction de transition entre chaque combinaison, ça me fait genre 200 fonctions à coder. et en plus pour la plupart d'entre elles le code va être identique. en plus le FSM semble calculé pour faire tourner une seule routine, or j'en fais pas forcément tourner une seule, ça dépend justement du comportement, dès fois y'en a une imbriquée dans une autre (car elle est appelée ou pas en fonction de ce qui se passe dans l'autre), ha et puis en plus y'a aussi que selon le comportement courant, un event de changement ne va pas déclencher le même choix de nouveau comportement... bref ce design pattern a apparemment une logique beaucoup trop simple pour le plaquer sur mon truc et risque d'alourdir mon code inutilement

là j'ai un code simple avec des bêtes enchainements de routine, à vue de pif ça marche bien et le code est simple, mais j'ai le risque d'avoir oublié un cas qui s'exécute presque jamais. j'ai testé l'envoi d'ordre de changement de comportement à chaque frame pour vérifier que y'a pas un moment où ça plante, mais je suis pas sur que ça soit 100% fiable

y'a pas un système qui permet de simplifier la sauce ?

[kain_tn]

Bonsoir,

c'est un peu difficile de te répondre sachant qu'on en sait finalement assez peu sur le contexte, les 'comportements', le langage utilisé, ...

Du coup ben je vais te dire comment je vois le truc...

Pour commencer je regarderai les points communs entre tes personnages selon les comportements (par exemple, les méthodes marcher() et parler(), etc)

Ensuite, peut-être que j'essayerai d'utiliser un pattern de type Visiteur pour découpler les algorithmes des différents comportements de l'implémentation des personnages.

Enfin, je dessinerai des diagrammes d'états bien déterministes pour savoir comment passer d'un comportement à l'autre etc...

Du coup pour chaque comportement (= pour chaque visiteur), tu n'as plus qu'à implémenter les bonnes actions, tu isole bien le code et donc tu évite beaucoup de bugs, etc...

[bafman]

moi, je te conseillerai de regarder du coté des agent orienté but (goal based agent). en gros, ça ressemble pas mal à une machine à état, mais au lieu d'avoir un etat "suivre tel chemin", on a plutôt un "état" "aller à tel position", après, il se débrouille en interne pour effectuer son objectif en fonction du context. Par dessus ça, tu exécute le tout sur une pile d'actions, ce qui te permet de comportement du genre "je doit aller à tel position. Je perçoit un ennemi, j'empile un nouvel ordre "tuer ennemi". Quand cet ordre est terminé, je dépile l'ordre et je reprend mon ordre précedent ou il en était".

l’avantage de cette méthode, c'est qu'elle permet une grand souplesse. On peut aussi bien coder des comportement complexes en les divisant en sous ordres que des comportement "reflexe".

L’expérience que j'ai eu avec ce genre de système, c'est que c'est relativement simple à mettre en place et que ça permet un découpage des tache très efficace. ça peut s'utiliser aussi bien avec des bêtes condition booléens pour sélectionner la prochaine action, ou avec des truc plus complexes comme de la logique flou. Bref, c'est un vrai pattern d'IA qui marche

c'est très bien décrit dans ce bouquin Programming Game AI By Example: Amazon.fr: Mat Buckland: Livres anglais et ?trangers@@AMEPARAM@@http://ecx.images-amazon.com/images/I/51jAoX1id6L.@@AMEPARAM@@51jAoX1id6L

[Le Kamikaze]

merci pour votre aide je vais jeter un oeil à ces deux pattern


Bon j'ai regardé les pattern et je vois vraiment pas comment faire rentrer mon code là dedans...

En fait je vise des smartphone avec des perf très pauvres et j'ai un délai scandaleusement court à tenir, alors j'ai un peu codé comme dans les années 80, tout en procédural (pas gagné de caler un pattern poo là dessus), en essayant avant tout d'exécuter le moins de code possible au runtime comme priorité, et aussi d'en taper le moins possible.

Du coup j'ai une logique compliquée avec un code très simple, pour vous décrire ma logique faudrait directement que je fasse un copier-coller du code vu que c'est à la variable près.

Or les pattern c'est un peu le contraire, on complique le code pour simplifier la logique afin de réduire le risque de bugs, on exécute pas mal de code qui sert uniquement à vérifier qu'on a pas fait de bêtises

Si y'a des "pattern" qui peuvent m'aider faudrait regarder du côté des techniques de prog des années 80 (c'est utile de déterrer ces vieux trucs maintenant qu'on est à l'ère de la régression technique smartphone), mais je suis pas tout à fait sûr qu'on avait besoin de patterns pour faire l'ia de la tortue de super mario..

[shaiHulud]

Je rebondis juste sur

ça me fait genre 200 fonctions à coder. et en plus pour la plupart d'entre elles le code va être identique

il suffit de coder une seule fonction et de l'associer 200 fois (à chaque transition possible). En plus en utilisant la décoration, tu devrais pouvoir modifier légèrement la fonction de transition principale pour gerer tous tes edge case.

[Le Kamikaze]

Ouais c'est vrai j'y ai pensé mais bon c'est injouable de mixer les méthodes de travail d'aujourd'hui avec celles d'il y'a 30 ans.

Le problème de fond c'est qu'un chef de projet incompétent a trouvé moyen de me faire bosser dans ces conditions...

[kain_tn]

La POO existe depuis très longtemps (1970 je crois) mais certains patterns n'ont été popularisé qu'à partir des années 90 par le GoF (Gang of Four).

Le seul conseil que je peux te donner à ce moment là c'est de faire le moins de variables globales possibles et de passer ce dont tu as besoin en paramètre à tes fonctions (plus la fonction prendra de paramètres et plus elle pourra gérer des cas proches. Du coup tu réduit le nombre de fonctions à coder et si il n'y a pas ou peu de variables globales tes bugs auront peu d'impact sur le reste).
En espérant que le langage que tu utilise te permet de passer des références ou des pointeurs ou au pire de retourner des valeurs multiples...

Sans passer par de l'objet rien ne t'empêche de catégoriser tes fonctions: tu gère les fonctions pour ton arbre d'état, tes fonctions de transition etc, du coup pour tes 200 transitions ça peut revenir à 200 appels d'une dizaine de fonctions avec des paramètres différents. Encore une fois ici l'idée est d'encapsuler tes différentes parties dans des fonctions (pas besoin de faire de l'objet pour ça) pour tout bien isoler (en gros une fonction = une boite noire avec des paramètres et des valeurs de retour)

[Le Kamikaze]

Bah vu que j'ai fait mes 200 transitions avec une seule fonction de 5 lignes au lieu de 200 fonctions, ça marche bien aussi comme ça