Blog Metlivi

Que peut réellement savoir l’assistant IA d’un personnage disparu dans un jeu d'enquête ?

Dans un jeu d'enquête de fiction, un assistant IA ne devrait connaître que les éléments narratifs que l'auteur met à sa disposition — et uniquement à partir du moment de l'histoire où ces éléments lui deviennent accessibles. Donnez à chaque fait une source, un moment où il a été porté à sa connaissance et une règle d'accès. Cela permet à l'assistant d'aider les joueurs à relier les indices sans se transformer insidieusement en narrateur omniscient.

30 septembre 20266 min de lectureLecture, arts et culturePar Metlivi Editorial Team
Section 1

Distinguer les archives de l'histoire des accès accordés à l'assistant

Commencez par un inventaire complet de l'histoire destiné à l'auteur : événements, déclarations des personnages, objets, messages, ainsi que l'ordre dans lequel ils entrent en jeu. Définissez ensuite une vue plus restreinte pour l'assistant. Un fait peut très bien exister dans la bible narrative sans être encore accessible à l'assistant. Cette distinction constitue le fondement d'une enquête équitable : l'auteur peut savoir ce qui s'est passé, tandis que l'assistant ne peut exploiter que les informations que son rôle fictif l'autorise à consulter.

Les outils de fiction interactive comme Twine structurent les récits en passages et peuvent utiliser des variables ainsi qu'une logique conditionnelle pour modifier ce que voit le joueur. Cela offre une analogie de conception fort utile : traitez chaque note de l'auteur comme une unité discrète et conditionnez son accès au passage, à l'événement ou au choix pertinent. Twine’s basic concepts

Par exemple, supposons qu'un personnage de fiction nommé Mara prépare une exposition pour un jardin partagé. L'assistant pourrait avoir accès à une note de planification partagée par celle-ci, à un planning affiché sur le panneau d'affichage du groupe, et à un message ultérieur dans lequel elle explique avoir rentré les panneaux peints à l'intérieur. Il ne devrait pas déduire où se trouve Mara simplement parce qu'il sait qu'elle aime le jardinage, et il ne devrait pas voir un brouillon privé qui ne lui a jamais été transmis. Ces restrictions découlent des règles d'accès rédigées pour l'histoire, et non d'une quelconque affirmation sur ce à quoi de véritables systèmes d'IA auraient accès.

Section 2

Attribuer à chaque fait une source et un horodatage de découverte

Un enregistrement factuel utile répond à au moins quatre questions : quelle est l'affirmation, qui ou quoi l'a fournie, quand est-elle devenue accessible à l'assistant, et s'agit-il d'une information directe ou déduite. Le modèle de provenance du W3C décrit l'origine des informations à travers des entités, des activités et des agents ; il permet également de documenter la manière dont un élément a été dérivé d'un autre. Il s'agit d'un cadre pratique pour les données narratives, même si le jeu utilise de simples étiquettes au lieu d'un modèle formel. W3C PROV Model Primer

Une fiche synthétique pourrait se présenter ainsi :

Affirmation : Mara prévoyait de peindre les panneaux du jardin ; Source : Note de planification partagée ; Connu de l'assistant dès le : lundi, 10 h 00 ; Type : Déclaration directe

Affirmation : Les panneaux ont été rentrés à l'intérieur ; Source : Mise à jour sur le panneau du groupe ; Connu de l'assistant dès le : mardi, 16 h 30 ; Type : Mise à jour directe

Affirmation : Mara les a peut-être rentrés car de la pluie était prévue ; Source : Bulletin météo combiné à la mise à jour ; Connu de l'assistant dès le : mardi, 16 h 30 ; Type : Déduction ; non confirmée

Ces horaires sont donnés à titre d'exemple. La distinction primordiale réside entre le moment où un événement a eu lieu et celui où l'assistant en a pris connaissance. Si une note rédigée le lundi n'est partagée que le mardi, la connaissance de l'assistant ne débute que le mardi, à moins que le récit ne lui accorde explicitement un accès antérieur. Conservez les deux horodatages dès lors qu'ils diffèrent.

Section 3

Différencier clairement observation, rapport et déduction

La présence d'une source ne rend pas automatiquement son contenu certain. Un personnage peut décrire ce qu'il a vu ; une note peut être incomplète ; un emploi du temps peut consigner un projet plutôt qu'une action réellement accomplie. Qualifier le type d'enregistrement aide l'assistant à formuler sa réponse avec précision : « Le panneau indique que les enseignes ont été déplacées » est différent de « Mara a déplacé les enseignes », et ces deux phrases diffèrent encore de « Elle les a probablement déplacées en raison de la météo. »

Utilisez avec cohérence un vocabulaire restreint : observation directe, rapport de personnage, note d'auteur et déduction. Une déduction doit renvoyer à ses éléments justificatifs et rester expressément qualifiée de déduction. W3C PROV modélise explicitement la responsabilité des agents dans les activités et la dérivation d'une entité à partir d'une autre ; appliquer cette distinction aux dialogues aide le jeu à montrer d'où provient une conclusion au lieu de la présenter comme un fait nouveau. W3C PROV-O

Cela fournit également un test de rédaction précieux : un joueur peut-il remonter de l'affirmation assurée de l'assistant jusqu'à un élément auquel celui-ci avait le droit d'accéder ? Si ce n'est pas le cas, rectifiez la réponse, ajoutez la note narrative manquante, ou faites en sorte que l'assistant indique qu'il ne dispose pas de suffisamment d'informations.

Section 4

Définir l'accès dans la chronologie de l'histoire, pas seulement par personnage

Pour chaque élément, précisez l'événement qui débloque l'accès de l'assistant. Un message partagé peut être accessible dès son envoi ; un avis épinglé sur un tableau peut le devenir lorsque l'assistant consulte ce tableau ; une conversation peut n'être accessible qu'une fois que le joueur décide de poser une question à ce sujet. Évitez de vous reposer sur des formulations vagues comme « l'assistant sait tout ce qui se trouve dans les archives », à moins que le récit n'établisse précisément ce que ces archives contiennent et à quel moment elles sont mises à jour.

Une règle d'accès pratique comporte trois volets : les destinataires de la note, son déclencheur de mise à disposition et les éventuels délais. Par exemple : « L'assistant peut lire les publications du panneau d'affichage du groupe après que le joueur a ouvert le panneau ; il ne peut pas lire les brouillons personnels. » Ce délai est fondamental dans les récits à embranchements. Si un joueur n'a pas consulté le panneau, l'assistant ne doit pas agir comme s'il avait pris connaissance du dernier message sous prétexte que ce message existe par ailleurs dans les fichiers de l'auteur.

Dans Twine, les variables d'histoire peuvent être accessibles d'un passage à l'autre, tandis que les variables temporaires sont cantonnées au passage en cours dans Harlowe et SugarCube. Cette différence illustre bien pourquoi les auteurs doivent décider délibérément si un fait persiste sur l'ensemble de l'histoire ou s'il n'appartient qu'à une scène particulière. L'implémentation exacte dépend du format de l'histoire : appréhendez donc cette règle comme un modèle de conception plutôt que comme des instructions de code. Twine Cookbook: Variables

Section 5

Rendre l'incertitude utile au joueur

Lorsqu'un élément est manquant, ancien ou ambigu, laissez l'assistant formuler ce manque en termes concrets. Il peut indiquer qu'il dispose du planning du lundi mais d'aucune confirmation ultérieure, ou qu'un personnage a affirmé avoir rentré les panneaux alors que le panneau d'affichage ne comporte aucune mise à jour. Cela offre au joueur une étape suivante constructive : examiner une autre source narrative, réinterroger un personnage ou décider que l'indice reste en suspens.

Cette démarche entretient le mystère sans recourir à une omniscience arbitraire. Des recherches sur la narration interactive ont analysé la façon dont des connaissances limitées peuvent guider le comportement du joueur, notamment via une étude s'appuyant sur la fiction interactive *Anchorhead* pour explorer les modèles de joueur. Pour un assistant conçu par un auteur, l'implication en matière de conception est modeste : ce que le joueur et l'assistant ont appris peut influer sur leurs choix futurs ; suivez donc explicitement ces états de connaissance. Rivera-Villicana et al., « Informing a BDI Player Model for an Interactive Narrative »

Section 6

Une vérification rapide avant d'écrire les répliques de l'assistant

Avant de rédiger une réponse, passez en revue ces points pour chaque affirmation importante :

L'affirmation figure-t-elle dans une archive narrative, ou est-elle signalée comme une déduction ?

L'enregistrement mentionne-t-il sa source et fait-il la différence entre un plan, un rapport, une observation ou une confirmation ultérieure ?

À quel moment de l'histoire l'assistant y a-t-il eu accès ?

Le rôle fictif de l'assistant l'autorise-t-il à accéder à cette source ?

Si l'enregistrement est incomplet ou contradictoire, le dialogue reflète-t-il cette incertitude ?

Si la réponse à l'une de ces questions reste incertaine, réduisez la portée de la déclaration de l'assistant jusqu'à ce qu'elle corresponde exactement aux éléments disponibles. Le personnage n'en restera pas moins utile : il pourra récapituler ce qu'il a constaté, souligner ce qui demeure non confirmé et orienter le joueur vers l'indice narratif suivant. Sa crédibilité repose sur une frontière bien visible entre l'ensemble des faits de l'histoire et les informations qu'il a véritablement reçues.

À lire aussi

Continuer sur ce thème