Arbres de comportement et machines à états : sélection, transitions et interruption

Partir des responsabilités de décision

Un contrôleur d'IA doit choisir le travail à effectuer, maintenir les actions en cours et réagir quand la situation change. L'aspect d'un diagramme ne règle pas ces responsabilités. Avant de choisir entre un arbre de comportement et une machine à états, notez ce qui peut interrompre chaque action et quel système est responsable du déplacement, du ciblage et des engagements d'animation.

Sélection et transition

Les arbres de comportement organisent la sélection des tâches au moyen de nœuds composites et de conditions. La sémantique d'exécution et d'abandon varie ; l'implémentation d'Unreal s'appuie sur une observation pilotée par événements pour les abandons conditionnels concernés. [1] Les machines à états expriment des états actifs et des transitions. Le StateTree d'Unreal associe une sélection hiérarchique à des transitions qui déclenchent une nouvelle sélection, ce qui montre que les systèmes en production peuvent combiner ces deux approches. [2]

Exemple détaillé

Concevons un garde, à titre d'illustration, doté des comportements Patrol, Investigate et Attack, ainsi que d'une interruption Stunned de haute priorité. Un sélecteur d'arbre de comportement peut hiérarchiser les tâches éligibles ; une machine à états peut exprimer la même politique avec des transitions à garde. Ni l'une ni l'autre de ces représentations ne doit décider des dégâts d'une arme à l'intérieur d'une tâche de déplacement sans rapport.

Supposons que le garde commence Attack, réserve une position de tir, puis devienne Stunned. Il faut définir un contrat d'abandon : libérer la réservation, annuler le déplacement en attente et empêcher une attaque inachevée de valider des dégâts. Si des dégâts ont déjà été validés, l'abandon ne doit pas les annuler par accident. Au rétablissement, le comportement doit être choisi à partir des connaissances actuelles, et non en reprenant systématiquement une cible devenue obsolète.

Cet exemple met à l'épreuve la distinction qui compte : la manière dont la sélection est réévaluée et dont le travail en cours est annulé, et non l'éditeur qui utilise le plus de boîtes.

Méthode de conception

Donnez à chaque tâche un comportement clair au démarrage, pendant l'exécution, en cas de succès, en cas d'échec et en cas d'annulation. Les vérifications de conditions doivent rester purement observationnelles : une évaluation répétée ne doit ni consommer de munitions ni allouer de réservations. Placez les modifications durables du monde derrière des frontières d'action explicites.

Documentez en langage clair les priorités et les gardes de transition. Quand deux règles deviennent vraies en même temps, précisez laquelle l'emporte. N'introduisez une hystérésis délibérée ou un engagement minimal que là où la conception l'exige, et rendez explicites les règles d'interruption d'urgence. Un parent hiérarchique peut porter la gestion de sortie commune, sans qu'on ait à la copier dans chaque feuille.

Débogage et limites

Enregistrez l'action active, la condition qui l'a sélectionnée et la raison de chaque interruption. Testez la disparition de la cible pendant un déplacement, une animation qui se termine après l'annulation et l'entrée répétée dans un état. Avant d'appliquer des résultats, vérifiez que les rappels asynchrones appartiennent bien à l'instance d'action courante.

Les arbres peuvent s'enchevêtrer à cause de dépendances cachées au blackboard ; les machines à états peuvent accumuler des réseaux de transitions difficiles à suivre. Aucune des deux structures ne supprime les problèmes de propriété de l'état partagé. Préférez la structure qui garde inspectables les priorités et les cycles de vie propres à votre jeu, et envisagez de combiner une petite machine à états de haut niveau avec des sous-comportements orientés tâches lorsque leurs frontières sont explicites.

Sources

[1] Behavior Tree overview — Epic Games.

[2] StateTree overview — Epic Games.