Comment concevoir un jeu avec un bot IA doté de règles claires, d'une mémoire et de choix pour le joueur
Pour concevoir un jeu jouable avec un bot IA, définissez une boucle courte et répétable, stockez l'état du jeu en dehors de la conversation et donnez à chaque action du joueur une conséquence claire. Laissez le bot interpréter les requêtes et décrire les événements ; laissez des règles explicites déterminer les coûts, la progression et les fins. Ce guide s'adresse aux créateurs de jeux qui développent un jeu textuel intégrant un personnage ou un narrateur IA. L'objectif est de créer une session courte et testable dans laquelle les joueurs comprennent leurs options, constatent que leurs décisions ont un impact et atteignent une fin valide. Le jeu de livraison ci-dessous est un modèle illustratif, et non un produit testé ou une étude de cas documentée.
Commencez par une boucle centrale jouable sans IA
Résumez la boucle en une phrase : présenter la situation → accepter une action → vérifier les règles → mettre à jour l'état → afficher la conséquence et les options suivantes. Chaque tour doit exécuter cette boucle ou expliquer pourquoi il ne peut pas progresser.
Avant d'écrire un prompt de personnalité, définissez l'objectif, les actions disponibles, le coût des actions et les conditions de fin. Vous devriez pouvoir faire tourner le jeu avec des fiches bristol ou un tableur. Cela permet d'inspecter les mécaniques avant que les dialogues générés n'introduisent des variations.
Prenons l'exemple d'un petit jeu intitulé *Festival Parcel*. Le joueur dispose de cinq unités de temps pour livrer un colis. Il peut choisir un itinéraire direct ou un itinéraire par les jardins, et éventuellement récupérer un ruban décoratif avant de partir. Un bot incarne le coursier du festival qui explique les itinéraires et commente la livraison.
Les règles proposées sont délibérément concises :
Affichez ces règles avant le premier choix. Expliquez que les actions de livraison terminent la session, le joueur doit donc récupérer le ruban au préalable. Une livraison qui consomme la dernière unité de temps réussit tout de même, car la vérification de la réussite intervient en premier.
Ce prototype dispose d'un début complet, d'un espace de décision et d'une fin. Tout personnage ou lieu supplémentaire ne doit trouver sa place qu'en apportant des décisions utiles à cette boucle.
Faites d'un état explicite l'autorité pour les résultats
Considérez l'état comme le registre de vérité du jeu. Le texte de la conversation peut expliciter ce registre, mais il ne doit pas le modifier discrètement.
Le chapitre sur l'état (State) de Robert Nystrom dans *Game Programming Patterns* (https://gameprogrammingpatterns.com/state.html) décrit les machines à états finis à travers les états, les entrées et les transitions autorisées. Il démontre également comment des indicateurs booléens combinés sans rigueur peuvent générer des combinaisons invalides. Appliquez ce principe au cycle de vie de votre jeu : utilisez un seul statut de session, tel que « active », « delivered » ou « missed », avec des transitions définies.
Pour le prototype de livraison, une brève spécification de l'état suffit :
Déduisez la carte postale du jardin de l'itinéraire sélectionné au lieu de stocker une seconde valeur susceptible de le contredire. De même, calculez les actions actuellement disponibles à partir de l'état et des règles.
Suivez un ordre de traitement fixe : interprétez la demande, validez l'action et ses paramètres, calculez le résultat, enregistrez le changement d'état, puis racontez-le. Fournissez au narrateur le résultat acté et les actions suivantes autorisées. Il ne doit pas inventer un second calcul.
Par exemple, après avoir récupéré le ruban, le résultat officiel est : il reste quatre unités de temps, le ruban est récupéré et les deux itinéraires sont abordables. Le bot peut décrire la couleur du ruban, tant que cette couleur n'a aucun effet mécanique. Il ne peut pas ajouter un coût en temps imprévu ni accorder un deuxième ruban.
Vous pouvez prototyper ces conditions à l'aide d'un outil de fiction narrative existant. Le tutoriel officiel de fiction interactive d'Inkle (https://www.inklestudios.com/ink/web-tutorial/) explique les choix conditionnels, le suivi des contenus déjà visités, les variables et les fins explicites. Ces fonctionnalités offrent une base utile pour tester le jeu rédigé avant d'y intégrer la narration par IA.
Offrez aux joueurs des choix qu'ils peuvent comprendre et influencer
Pour cette conception, évaluez l'agentivité de l'utilisateur selon sa capacité à anticiper une différence significative et à l'observer ensuite dans le résultat. Proposer plusieurs boutons formulés différemment mais menant à un résultat identique ne permet guère de tester cela.
Dans *Festival Parcel*, la décision d'itinéraire répond à différentes préférences de jeu :
Ce sont des calculs illustratifs issus des règles établies. Ils constituent une aide à la décision simple : choisir la livraison directe pour finir plus tôt, récupérer le ruban pour décorer le colis ou emprunter l'itinéraire des jardins pour la carte postale. Le temps restant est ici un détail de fin ; il n'accorde aucun point en secret.
Si le jeu récompense ultérieurement un résultat particulier, annoncez ce système de score avant la prise de décision. Sinon, les joueurs ne pourront pas évaluer le compromis que vous aviez prévu.
Autorisez la saisie libre en parallèle des actions visibles. « Prenons le chemin panoramique » peut correspondre à la livraison par les jardins. « Faisons quelque chose de spécial » est ambigu : cela peut signifier récupérer le ruban, passer par les jardins, ou les deux. Demandez une brève clarification sans décompter de temps.
Pour le premier prototype, n'acceptez qu'une seule action de jeu par message. Si le joueur demande une séquence, présentez ses étapes et invitez-le à choisir la première action. Cela évite d'exécuter partiellement un plan dont les étapes suivantes s'avèrent indisponibles.
Faites en sorte que les requêtes non prises en charge restent informatives. Si le joueur demande à voler, expliquez que les itinéraires disponibles sont le chemin direct et les jardins, en précisant leurs coûts. Le texte libre peut élargir l'expression tandis que le système d'actions préserve un ensemble prévisible de possibilités.
Définissez ce dont le bot se souvient et ce qu'il peut savoir
Séparez la mémoire en trois couches, chacune ayant un objectif distinct.
L'état de session officiel stocke les ressources, la progression, les itinéraires sélectionnés et les fins. Il persiste après une sauvegarde et un rechargement, et ne change que par le biais d'actions validées.
Un journal d'événements de la session enregistre les actions validées et leurs conséquences. Une entrée peut indiquer que l'action 2 a permis de récupérer le ruban et a réduit le temps de cinq à quatre. Cela facilite le débogage et permet des récapitulatifs fidèles. Conservez les identifiants d'action afin qu'une requête répétée ne puisse pas appliquer le même événement deux fois.
Le contexte narratif contient le dialogue récent et un récapitulatif compact utilisé pour préserver le ton et la continuité. Il peut être raccourci sans supprimer le véritable état du jeu.
Le guide d'Anthropic sur l'ingénierie efficace de contexte (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) aborde à la fois le résumé de l'historique de conversation et la conservation de notes persistantes en dehors de la fenêtre de contexte. Il avertit également qu'une synthèse trop agressive risque de faire perdre des détails importants. La conclusion à en tirer pour la conception est de conserver les données mécaniques exactes dans un stockage structuré et d'utiliser les résumés pour la continuité de la conversation.
Définissez les limites du savoir ainsi que les limites de stockage. Un personnage ne doit recevoir que les faits qu'il est autorisé à connaître. Si une version ultérieure intègre un itinéraire caché, gardez-le hors du contexte de ce personnage jusqu'à ce que la condition de sa découverte soit remplie. L'état accessible au moteur de jeu n'a pas nécessairement à être entièrement accessible au narrateur.
Pour ce petit jeu, conservez la progression dans la session sauvegardée et réinitialisez-la au lancement d'une nouvelle partie. Évitez de déduire des préférences durables du joueur à partir du choix d'un seul itinéraire. Si vous ajoutez une préférence enregistrée, telle que des descriptions plus courtes, rendez-la explicite et modifiable.
Testez la mémoire avec une séquence concrète : récupérez le ruban, sauvegardez, rechargez, demandez l'état actuel et sélectionnez la livraison par les jardins. Le ruban doit rester acquis, quatre unités de temps doivent rester avant la livraison, et le temps final doit être de zéro.
Concevez des réponses distinctes pour l'échec en jeu et la défaillance du système
Un objectif manqué fait partie du jeu. Une requête de génération en échec est un problème technique. Attribuez-leur des conséquences différentes.
Pour l'échec en jeu, nommez la règle qui a mis fin à la partie. Après trois attentes, il ne reste que deux unités de temps, de sorte qu'aucun itinéraire de livraison n'est abordable. Terminez immédiatement la partie avec une explication claire et une option pour recommencer, au lieu de laisser le joueur dans une session active impossible à remporter.
Pour les défaillances techniques, définissez le comportement de reprise avant d'ajouter une narration élaborée :
Ne remplacez pas discrètement une sauvegarde illisible par une nouvelle partie. Cela masquerait la perte de progression et rendrait la réponse suivante trompeuse.
Générez un message de résultat clair et factuel pour chaque action : ce qui s'est produit, ce qui a changé et ce qui est disponible ensuite. La narration expressive du bot peut accompagner ce résultat. En cas de délai d'attente dépassé ou de réponse contradictoire, le message factuel permet tout de même au joueur de poursuivre.
Concluez les fins par un récapitulatif fidèle. Ne mentionnez le ruban que s'il a été récupéré et la carte postale que pour l'itinéraire des jardins. La prose générée doit préserver les distinctions que le joueur s'est efforcé d'établir tout au long de la session.
Testez d'abord les règles, puis l'interprétation par le bot
Testez d'abord le jeu avec du texte figé. Vérifiez chaque action, chaque fin et les cas limites. Ajoutez ensuite le bot et répétez ces tests en variant les formulations. Cela permet de distinguer une règle défaillante d'une requête mal comprise.
Invitez des joueurs représentatifs à effectuer une livraison sans assistance. Demandez-leur d'expliquer ce qu'ils attendent avant de choisir, puis ce qu'ils pensent avoir changé par la suite. Le guide du Nielsen Norman Group sur les tests d'utilisabilité par réflexion à voix haute (https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/) préconise de faire appel à des participants et des tâches représentatifs tout en laissant parler les participants ; il rappelle aussi que les interventions de l'animateur risquent d'influencer le comportement.
Appuyez-vous sur l'observation directe parallèlement au journal des actions. Consignez les tentatives d'action, les demandes de clarification, les issues inattendues et tout décalage entre la narration et l'état validé. Évaluez séparément si les joueurs ont bien compris les options et s'ils ont pris du plaisir à choisir entre elles.
Liste de contrôle pour les playtests. Corrigez les anomalies de règles et de gestion de l'état avant d'enrichir l'univers. Si les joueurs comprennent les choix mais les trouvent inintéressants, modifiez les compromis. S'ils apprécient les décisions mais ne parviennent pas à anticiper les coûts, améliorez la présentation. N'étendez le prototype que lorsque ses choix actuels restent compréhensibles à travers différentes formulations, des sessions sauvegardées et les parcours d'échec.