Arbres de comportement collaboratifs dans un jeu en bien commun
July 2, 2025
Les biens communs sont des propriétés qui s’ouvrent à l’usage de tous et qui sont détenus et gérés par les personnes qui les utilisent… mais qu’est-ce que cela signifie pour l’IA dans le développement de jeux vidéo ?
Je travaille sur le concept d’un Games Commons (jeu en bien commun), qui est une nouvelle façon de concevoir les jeux, axée sur la flexibilité, la collaboration et le concept « Do-It-Together » (Bricolons ensemble). Ce sont des jeux créés autour d’une communauté créative de hackers, comme Wikipédia, mais pour le contenu des jeux.
Notre jeu phare porte sur la création et la destruction de systèmes sociaux. Dans le jeu, les systèmes sociaux sont constitués d’agents en réseau qui suivent des scripts comportementaux créés par les joueurs, partagés en commun et soumis à un contrôle qualité par les communautés. La conception des outils qui permettent au joueur de collaborer à ces scripts est le sujet de l’article d’aujourd’hui.
L'interface est encore en cours d'élaboration.
Les agents ont besoin d’un script d’IA pour prendre des décisions ; en termes simples, celui-ci leur indique quoi faire ensuite. Nous supposons parfois que l’IA dans les jeux est stratégique : l’agent pourrait être un pair du joueur humain, travaillant avec lui ou contre lui. À l’autre extrême, cependant, l’agent peut être simplement là pour décorer le monde et le rendre crédible. En général, un seul jeu utilise plusieurs types d’IA différents, chacun ayant des objectifs différents. Une « bonne IA de jeu » n’est donc pas nécessairement une IA suffisamment stratégique ou adaptative pour passer le test de Turing ; c’est une IA qui correspond aux objectifs du concepteur du jeu pour l’agent qui la déploie.
La conception de Sim Polis s’articule autour de systèmes flexibles qui évoluent en fonction des interactions des joueurs. L’IA doit donc être adaptable au « principe du monde ouvert » (c’est-à-dire que tout est possible). Il ne suffit pas qu’un marchand des pommes se présente chaque matin sur la place du village dans l’espoir de vendre ses pommes, si en raison de l’interaction des joueurs pensent désormais que les pommes sont toxiques. Mieux vaut cela que de ne pas se présenter du tout, le marchand de pommes devrait se rendre sur la place du village et commencer à se disputer avec les villageois, ce qui pourrait aboutir à son arrestation. Une telle flexibilité représente déjà un défi en soi, mais nous avons également besoin d’une structure suffisamment accessible pour que les joueurs puissent créer et partager eux-mêmes ces scripts via l’interface. Notre approche pour atteindre ces objectifs consistera à utiliser une conception modulaire pour notre IA, en nous appuyant sur l’abstraction.
Les arbres de comportement sont essentiellement des organigrammes qui orientent les décisions à prendre et les actions à mener par un agent. Un arbre de comportement simple peut par exemple demander à un agent de manger s’il a faim :
L’arbre commence ici par le nœud de contrôle « l’agent a-t-il faim ? ». Si l’agent a faim, il exécutera le nœud d’action « manger quelque chose ». Si l’agent n’a pas faim, il suivra l’autre branche de l’arbre. Il en résulte que la faim est prioritaire. Si l’agent n’a pas faim, le flux se poursuit. Nous pouvons imaginer une situation où (une fois rassasié), l’agent est libre de poursuivre une chaîne de comportements plus fantaisiste :
Dans l’exemple ci-dessus, l’agent va errer, puis crier. Cette branche de l’arbre se termine par un nœud forget, un type spécial de nœud de contrôle permettant de modifier de manière permanente l’arbre de comportement lui-même. L’exécution de ce nœud détruira la sous-branche « errer-crier », car le comportement ne doit être exécuté qu’une seule fois : il était censé être fantaisiste, un moment de folie. Cela démontre également que les arbres de comportement sont modulaires : on peut imaginer que la branche « errer-crier » soit suffisante pour définir l’arbre de comportement complet d’un fou furieux, mais pour un autre agent, on pourrait insérer la même branche comme un seul aspect de son comportement :
Si l’agent est ivre, il erre, crie et oublie, avant d’exécuter un nouveau nœud, « apprendre ». Si le joueur n’est pas ivre, le graphique passe à l’état de faim du premier exemple. Nous pouvons voir ici comment les comportements « errer-crier-oublier » et « faim-manger » ont été regroupés en branches. Une fois regroupés, ils peuvent être réutilisés par leur créateur dans les arbres de comportement de différents agents, et publiés en ligne avec des métadonnées sur le fonctionnement de la branche. Une fois publiés en ligne, les autres joueurs peuvent importer le comportement dans leurs propres agents, ce qui constitue un mécanisme puissant pour créer un espace commun de jeux. En outre, nous avons le nœud « apprendre » qui, avec les métadonnées appropriées, peut utiliser des paramètres de recherche pour permettre à l’agent de découvrir en ligne un nouveau comportement d’ivresse à partir des jeux communs. La prochaine fois que cet arbre s’exécutera et que l’agent sera encore ivre, il aura oublié le comportement errer-crier, mais il pourra découvrir un comportement que quelqu’un a publié sur les jeux communs et qui le fera tomber et commencer à chanter.
Le fait que les nœuds de nos arbres de comportement soient guidés par des données qui peuvent être publiées puis découvertes au moment de l’exécution permet l’émergence d’un comportement spontané et unique qui n’est pas envisageable dans la conception traditionnelle des jeux. La flexibilité du système d’arbres de comportement au sein de la technologie sociale d’un bien commun permet la conception de jeux qui peuvent évoluer grâce à la créativité de leurs joueurs.