Quand le canon du monde d'un jeu entre en conflit avec l'improvisation de l'IA, lequel doit l'emporter ?
Pour un scénariste ou un concepteur de jeu qui doit décider de la manière dont un personnage IA doit répondre à un joueur, la règle est simple : les faits établis de l'univers et l'état actuel du chapitre prévalent sur l'improvisation. Laissez le modèle varier la formulation, l'attitude et les discussions informelles à l'intérieur de ces limites. Lorsque le jeu ne dispose d'aucune réponse établie, le personnage doit manifester de l'incertitude ou s'abstenir, plutôt que d'inventer un fait et de le présenter comme canonique.
Considérer le canon et l'état du chapitre comme l'autorité
Un système efficace distingue deux questions : qu'est-ce qui est vrai dans cet univers, et qu'est-ce qui est vrai à ce stade précis de cette partie ? Le canon englobe les faits établis tels que l'identité d'un personnage, l'histoire d'un lieu ou le fonctionnement d'un appareil. L'état du chapitre couvre ce qui s'est produit au cours de cette partie précise : quelle porte a été ouverte, qui le joueur a rencontré, ou si un événement a déjà eu lieu. Le modèle de dialogue peut exploiter ces faits, mais ne doit pas les réécrire en silence.
Cette distinction reflète une caractéristique pratique des systèmes narratifs interactifs. ink, un langage de script développé par Inkle Studios, prend en charge la logique d'histoire à embranchements et le suivi des états ; ses auteurs décrivent l'utilisation de l'état pour faire varier le texte en fonction de ce qui s'est passé auparavant. La documentation de Microsoft pour Minecraft décrit de même des fichiers de scène pour des PNJ individuels ou des chapitres narratifs, ainsi que la modification des dialogues en fonction des actions du joueur. Ce sont des exemples de dialogues écrits contrôlés par le contexte de l'histoire, et non la preuve qu'une conception d'IA spécifique est requise. Ils montrent pourquoi un jeu a intérêt à garder explicites les faits liés à la progression. (Inkle Studios sur ink, documentation de Microsoft sur le dialogue des PNJ)
Donner au modèle un rôle restreint
Définissez la réponse générée comme une interprétation d'informations connues, et non comme une source de nouvelles vérités sur le monde. Le personnage peut expliquer un événement connu avec sa propre voix, réagir aux propos du joueur ou proposer une observation pertinente. Il ne doit pas créer un nouveau membre de la fratrie, changer le détenteur d'une clé, déclarer qu'un événement d'un chapitre clos s'est produit, ni établir une cause cachée sans fondement dans les données de l'histoire.
Une consigne claire pourrait être : « Utilisez uniquement les faits et l'état du chapitre fournis ici. Vous pouvez choisir la formulation et le ton. N'ajoutez pas de noms, d'événements, de relations, de motivations ou de dénouements en tant que faits. Si la réponse n'est pas fournie, dites que vous ne savez pas ou que vous ne pouvez pas le confirmer. » Il s'agit d'un exemple de règle de conception, et non d'une garantie qu'un modèle d'IA la respectera toujours. Le jeu doit continuer à contrôler quelles informations parviennent au personnage et quelles actions une réponse peut déclencher.
Distinguer la croyance d'un personnage d'un fait du monde
Les personnages peuvent se tromper, être évasifs ou hésitants lorsque l'histoire écrite le prévoit. La distinction essentielle réside dans la manière dont le jeu formule une déclaration : s'agit-il du point de vue personnel de ce personnage ou d'un fait avéré concernant le monde ? « J'ai entendu dire que le pont était fermé » peut être une rumeur si la narration autorise les rumeurs. « Le pont est fermé » peut être interprété comme une mise à jour d'état fiable, en particulier si le jeu s'appuie dessus par la suite.
Pour chaque réponse incertaine ou contestée, déterminez si le personnage partage une connaissance personnelle, répète une rumeur, spécule ou énonce un élément canonique confirmé. Marquez cette catégorie dans le prompt ou dans les données de dialogue, et veillez à la cohérence de la formulation. Si l'histoire n'a pas établi qui a bâti la vieille tour, un PNJ peut dire qu'il a entendu des versions contradictoires ; le modèle ne doit pas trancher le mystère sous prétexte qu'une réponse semble plausible.
Garder l'état du chapitre à jour et précis
Un modèle ne peut pas respecter de manière fiable un fait qui ne lui a pas été transmis. Ne transmettez que l'état nécessaire à la conversation, mais soyez précis : le chapitre en cours, les événements accomplis pertinents, les questions importantes non résolues et tous les faits connus personnellement par le personnage. Évitez les résumés généraux qui confondent les événements prévus et les événements accomplis. Une note telle que « la grille s'ouvre après que le joueur a trouvé le sceau » ne doit pas être confondue avec « le joueur a trouvé le sceau ».
Les recherches sur les modèles de langage dans les jeux de rôle sur table traitent le suivi des états et la génération de dialogues comme des tâches connexes mais distinctes. Les auteurs de *Dungeons and Dragons as a Dialog Challenge for Artificial Intelligence* décrivent la génération de tours de parole et la prédiction de l'état du jeu à partir de l'historique des dialogues, les informations d'état comprenant les détails des personnages et l'évolution des actions. Cela confirme l'intérêt de traiter l'état comme une entrée explicite et une préoccupation distincte ; cela n'établit pas qu'une réponse générée doive être autorisée à modifier l'état de référence du jeu. (Callison-Burch et al., « Dungeons and Dragons as a Dialog Challenge for Artificial Intelligence »)
Utiliser une réponse de repli lorsque le canon fait défaut
Choisissez une réponse par défaut pour combler les lacunes de l'historique. Selon le personnage et la scène, la réponse peut être « Je n'étais pas là », « Je ne sais pas » ou « Personne ne me l'a dit ». Si une rumeur ou une supposition du personnage est appropriée, indiquez-le clairement comme telle. L'objectif est de préserver la question ouverte jusqu'à ce que l'histoire écrite la résolve, tout en permettant à la conversation de se poursuivre.
Cette solution de secours doit également couvrir les contradictions. Si l'état fourni du chapitre indique que le joueur n'a pas rencontré le capitaine, mais que l'historique de la conversation semble indiquer le contraire, évitez que le PNJ affirme l'une ou l'autre version avec assurance. Demandez au système de jeu de résoudre la divergence, ou laissez le PNJ donner une réponse qui ne dépend pas du détail contesté. Cette politique de réponse est une recommandation de conception déduite du besoin de maintenir la cohérence entre l'état et le dialogue ; il ne s'agit pas du résultat d'une étude de jeu spécifique.
Vérifier la conformité des répliques générées avec les limites établies
Avant d'afficher une réponse, vérifiez si elle introduit un nouveau fait ayant des conséquences. Une vérification légère peut poser les questions suivantes : la réponse mentionne-t-elle un événement, une relation, un motif, un lieu, le détenteur d'un objet ou un dénouement ? Ce détail figure-t-il dans le canon ou dans l'état actuel ? Est-il explicitement présenté comme une croyance ou une rumeur ? Implique-t-il une transition de chapitre ou une action que le jeu n'a pas enregistrée ? Si un détail lourd de conséquences manque de fondement, régénérez la réponse avec des contraintes plus strictes ou utilisez la réponse de repli d'incertitude.
L'ingénierie de prompt peut aider à maintenir la cohérence des personnages, mais ne doit pas être traitée comme une base de données canonique. Un rapport de recherche de 2026 sur les PNJ pilotés par LLM dans un jeu d'enquête sous Minecraft décrit l'utilisation de techniques d'incitation (prompting) pour améliorer la cohérence des personnages et des dialogues. Cela témoigne d'une approche de recherche dans un prototype particulier, et non de la preuve que le prompt seul empêche les contradictions dans d'autres jeux. Conservez les faits écrits et la progression du jeu dans une source que le jeu peut consulter, et traitez le dialogue généré comme une simple proposition de réponse. (Portail de recherche de Heriot-Watt, « Designing and Evaluating Interactive Narratives with Generative AI: LLM-Driven NPCs for a Minecraft Murder Mystery »)
Une règle de décision pratique
Lors de l'examen d'une réplique contestée, appliquez ces vérifications dans l'ordre :
L'affirmation est-elle un fait établi de l'univers ? Conservez la version écrite.
Dépend-elle de ce qui s'est produit dans cette partie ? Utilisez l'état actuel du chapitre, et non un résumé générique de l'histoire.
S'agit-il du point de vue limité ou incertain du personnage ? Rendez cette perspective explicite dans la réplique.
N'y a-t-il aucune réponse étayée ? Laissez le personnage le dire ; laissez la question ouverte.
La déclaration modifierait-elle ce que le jeu considère comme vrai ou accompli ? Seule la logique de progression écrite du jeu doit apporter cette modification.
Cette approche laisse la place à des conversations vivantes tout en préservant la lisibilité de la paternité de l'œuvre et de la continuité. Le modèle peut improviser la façon dont un personnage connu s'exprime ; le registre officiel du monde décide de ce que le personnage peut légitimement affirmer comme vrai. Là où le registre est muet, l'incertitude est une réponse valable, et non une lacune que le modèle doit combler à tout prix.