Blog Metlivi

La mémoire de l'IA dans les jeux vidéo doit-elle persister d'un chapitre à l'autre ? Une conception pratique pour déterminer quoi conserver et quoi réinitialiser

Pour un jeu articulé en chapitres, la mémoire de l'IA ne devrait franchir la limite d'un chapitre que lorsqu'elle représente un fait durable destiné à avoir de l'importance plus tard. Conservez les engagements du joueur, les relations établies et les faits confirmés de l'univers dans un registre structuré et scénarisé. Laissez l'IA extraire une vue restreinte et pertinente de ce registre, accompagnée de tous les souvenirs délibérément conservés. Réinitialisez le contexte propre à la scène, les objectifs temporaires et les détails éphémères du moment, à moins que le chapitre suivant n'en ait explicitement besoin. L'état sauvegardé du jeu doit rester l'autorité suprême ; les dialogues générés peuvent le décrire, mais ne doivent pas le réécrire silencieusement.

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

Séparer le canon durable de la mémoire de scène

Le terme « mémoire » peut désigner différentes choses : un historique d'événements, un résumé ou une interprétation de ces événements, et les faits que le jeu considère comme vrais. Les mélanger rend les transitions de chapitres difficiles à raisonner. Un personnage peut avoir entendu une rumeur, par exemple, mais cette rumeur ne doit pas automatiquement devenir un fait avéré de l'univers simplement parce que l'IA s'en souvient avec assurance.

Une conception efficace consiste à maintenir deux couches liées. La première est un état canonique détenu par le jeu : des faits structurés tels que promised_to_return: true, gave_map_to: Mira, ou bridge_status: repaired. Ceux-ci sont sauvegardés et modifiés par les règles du jeu ou une écriture explicite. La seconde est une vue d'extraction pour l'IA : des faits sélectionnés, des souvenirs et le contexte de la scène actuelle fournis pour orienter une réponse. Cette vue peut être concise et propre au personnage sans devenir pour autant le fichier de sauvegarde lui-même.

Cette recommandation est une déduction d'ordre architectural, et non une fonctionnalité garantie par un moteur particulier. Les systèmes d'écriture narrative distinguent déjà les variables d'histoire qui peuvent être lues à travers tout le récit des valeurs temporaires ayant une portée plus restreinte ; Ink, par exemple, documente séparément les variables globales et les variables temporaires. Son moteur d'exécution (runtime) expose également un moyen de sérialiser et de restaurer l'état de l'histoire. Ces capacités fournissent un modèle utile : représenter l'état de manière délibérée, puis décider de la portée et de la persistance nécessaires à chaque valeur. Documentation sur les variables et la logique d'Ink et documentation sur la sauvegarde et le chargement du runtime d'Ink

Section 2

Déterminer ce qui mérite une place dans le registre inter-chapitres

Pour chaque souvenir candidat, posez-vous la question : une scène ultérieure pourrait-elle légitimement dépendre de ce fait, et existe-t-il un événement de jeu clair ou une règle scénarisée capable de le confirmer ? Si oui, envisagez de le stocker comme un état durable. Le nom choisi par le joueur pour un compagnon, une promesse tenue, ou le fait qu'une porte ait été ouverte peuvent convenir dès lors que l'histoire s'en sert plus tard. Stockez une valeur et sa portée, et non une transcription sans fin, chaque fois que le fait sous-jacent peut être formulé clairement.

Un registre pratique peut identifier le sujet, le fait, l'événement source et la portée de la persistance. Par exemple : subject: Mira ; fact: player shared the map ; source: chapter_2_choice_14 ; scope: campaign. L'événement source aide à résoudre les incohérences : si une réplique générée ultérieurement affirme que le joueur a donné la carte alors que le choix enregistré indique le contraire, le jeu peut donner la priorité au registre d'événements. Ce schéma est une suggestion de conception, pas un format imposé par les outils cités.

Distinguez bien les éléments incertains ou non confirmés. « Le garde soupçonne le joueur d'avoir pris la clé » et « le joueur a pris la clé » sont deux faits différents. Un personnage peut se souvenir d'un soupçon après la fin d'un chapitre, alors que le registre canonique de l'univers indique toujours que la clé se trouve à son emplacement d'origine. Utilisez des étiquettes telles que rumeur, observation, déduction et événement confirmé si les dialogues ultérieurs doivent préserver ces nuances.

Section 3

Réinitialiser ce qui appartient à la scène actuelle

L'état de la scène comprend souvent le sujet immédiat de la conversation, un objectif temporaire, les derniers échanges, la mise en scène locale et des détails éphémères comme la porte actuellement ouverte. Ces détails peuvent aider l'IA à formuler la réplique suivante, mais ils ont rarement vocation à intégrer la mémoire de la campagne. Effacez-les à la sortie de la scène ou reconstruisez-les à partir de la configuration scénarisée de la scène suivante.

Cette frontière est essentielle car la persistance recouvre plusieurs réalités. Le tutoriel de persistance des données d'Unity distingue les données qui suivent un joueur d'une scène à l'autre au cours d'une même session de la progression sauvegardée et restaurée d'une session à l'autre ; il souligne également que les données créées au sein d'une scène sont généralement perdues lors du passage à une autre scène, à moins que le jeu ne les transmette activement. Une transition de chapitre est donc une décision de transfert délibérée, et non une raison automatique de préserver chaque valeur active. Unity Learn : Implémenter la persistance des données entre les scènes

Essayez une routine de transition en quatre étapes : finaliser les événements confirmés du chapitre ; mettre à jour le registre canonique de la campagne ; éliminer le contexte temporaire de la scène ; puis construire le contexte de l'IA pour le chapitre suivant à partir de sa configuration scénarisée et des faits durables pertinents. Cela évite que des détails obsolètes ne s'infiltrent dans une nouvelle scène tout en préservant la continuité explicitement prévue par l'histoire.

Section 4

Maintenir l'autorité de l'état de sauvegarde scénarisé

Au début d'un chapitre, fournissez à l'IA l'état actuel sous forme de contexte en lecture seule pour la narration et les dialogues. Si les actions du joueur peuvent modifier des faits durables, faites en sorte que le jeu valide l'action par rapport à ses propres règles et mette à jour le registre de sauvegarde via le circuit standard de modification d'état. Considérez la réponse du modèle comme une proposition de réplique ou d'action, et non comme la preuve qu'un événement s'est produit. Cette séparation est une recommandation de conception née de la nécessité de distinguer l'état sauvegardé du texte généré ; elle doit être implémentée et testée dans l'architecture propre au jeu.

Il existe un précédent instructif dans la recherche sur la narration : l'article sur les agents génératifs (Generative Agents) décrit comment stocker des expériences, synthétiser des réflexions et extraire dynamiquement des souvenirs sélectionnés pour guider le comportement. Cela justifie l'utilisation de l'extraction et de la synthèse pour déterminer ce qu'un agent prend en compte. En revanche, cela n'établit pas qu'un souvenir généré doive constituer l'état canonique du jeu. La distinction est capitale : un résumé peut être un contexte précieux tout en restant modifiable ou incomplet. Park et al., « Generative Agents: Interactive Simulacra of Human Behavior »

Pour des sauvegardes reproductibles, faites persister les faits structurés du jeu ainsi que l'état d'exécution de l'histoire dont le jeu a besoin pour reprendre. La documentation du runtime d'Ink illustre comment sérialiser l'état de l'histoire en JSON et le recharger. Un résumé généré peut également être conservé par commodité, mais reconstruisez-le ou confrontez-le au registre structuré lors du chargement ; ne laissez pas un résumé obsolète prévaloir sur un choix sauvegardé plus récent. Runtime d'Ink : Sauvegarde et chargement

Section 5

Rendre la frontière visible aux joueurs

Les joueurs n'ont pas besoin de voir les structures de mémoire internes, mais ils doivent pouvoir comprendre quels choix ont été répercutés. Montrez les conséquences au sein de la fiction là où elles s'intègrent naturellement : un compagnon qui se rappelle la carte, ou une scène ultérieure qui fait écho à une promesse passée. Lorsque la sauvegarde ou le récapitulatif du chapitre s'y prête, résumez quelques faits confirmés déterminants en langage clair. Évitez de laisser entendre que chaque réplique improvisée est devenue une règle intangible du canon.

Offrez aux joueurs un moyen de corriger les erreurs lourdes de conséquences lorsque le jeu le permet : recharger une sauvegarde, revoir une décision ou recourir à une interaction de correction explicite. Si un personnage géré par l'IA se souvient mal de quelque chose, le dialogue ne devrait pas obliger le joueur à accepter cette erreur comme un nouveau fait établi de l'univers. La présence de telles options de correction relève d'un choix de conception du produit, mais le principe fondamental demeure : une affirmation mémorisée et un événement sauvegardé ne sont pas interchangeables.

Section 6

Tester les transitions de chapitres avec des cas concrets

Concevez une courte liste de vérification des transitions autour des faits réellement suivis par votre jeu. Pour chaque cas, inspectez à la fois le registre sauvegardé et le contexte d'IA fourni après le changement de chapitre.

Un choix confirmé du joueur persiste et peut influencer le chapitre suivant là où le contenu scénarisé l'utilise.

Une rumeur ou une déduction de personnage reste étiquetée comme incertaine au lieu de devenir un événement confirmé.

Un objectif de scène temporaire et les détails conversationnels récents disparaissent, à moins que la scène suivante ne les exige explicitement.

Une sauvegarde fraîchement chargée restaure les mêmes choix canoniques, même si l'IA a précédemment produit une narration contradictoire.

Un nouveau chapitre sans lien pertinent ne reçoit pas de souvenirs hors de propos simplement parce qu'ils existent.

Ces vérifications constituent une méthode de diagnostic proposée, et non une expérience documentée. Elles facilitent l'identification de deux anomalies courantes : la perte de continuité, où des faits durables s'effacent, et la fuite de mémoire, où d'anciens détails d'une scène ressurgissent dans un contexte qui aurait dû être réinitialisé. Lorsque l'un ou l'autre problème survient, examinez la portée de la persistance et l'étape de construction du contexte avant d'essayer d'y remédier par une invite plus longue.

Section 7

Une règle concise pour la mémoire par chapitres

Faites persister un fait lorsque le jeu scénarisé peut le nommer, en confirmer la source et lui définir une utilité ultérieure. Conservez les souvenirs personnels comme un contexte extrait lorsqu'ils enrichissent la personnalité d'un personnage ou la continuité, tout en préservant leur part d'incertitude et leur provenance. Réinitialisez l'état propre à la scène lors du franchissement de la limite. À chaque étape, laissez l'état de jeu sauvegardé et scénarisé déterminer ce qui est vrai ; laissez la mémoire de l'IA aider le personnage à réagir à cette vérité.

À lire aussi

Continuer sur ce thème