Wanneer de canon van een gamewereld botst met improvisatie door AI, wat moet dan voorrang krijgen?

Een bruikbaar systeem maakt onderscheid tussen twee vragen: wat is waar in deze wereld, en wat is waar op dit punt in deze speelsessie? De canon omvat vastgestelde feiten, zoals de identiteit van een personage, de geschiedenis van een locatie of de werking van een apparaat. De hoofdstukstatus omvat wat er in deze speelsessie is gebeurd: welke deur is geopend, wie de speler heeft ontmoet of een gebeurtenis al heeft plaatsgevonden. Het dialoogmodel kan die feiten gebruiken, maar mag ze niet ongemerkt herschrijven.

Dit onderscheid weerspiegelt een praktische eigenschap van interactieve vertelsystemen. ink, een scripttaal ontwikkeld door Inkle Studios, ondersteunt vertakkende verhaalstructuren en het bijhouden van de status; de makers beschrijven hoe je die status kunt gebruiken om tekst te variëren op basis van wat eerder is gebeurd. Ook in de documentatie van Microsoft voor Minecraft staan scènebestanden voor afzonderlijke NPC's of verhaalhoofdstukken en wordt beschreven hoe dialogen veranderen op basis van acties van spelers. Dit zijn voorbeelden van geschreven dialogen die worden gestuurd door de verhaalcontext, geen bewijs dat een bepaald AI-ontwerp vereist is. Ze laten zien waarom een game baat heeft bij het expliciet vastleggen van voortgangsfeiten. (Inkle Studios over ink, Microsoft-documentatie over NPC-dialogen)

Definieer het gegenereerde antwoord als een vertolking van bekende informatie, niet als een bron van nieuwe feiten over de wereld. Het personage mag een bekende gebeurtenis in eigen woorden uitleggen, reageren op de formulering van de speler of een relevante observatie delen. Het mag geen nieuwe broer of zus verzinnen, veranderen wie een sleutel heeft, verklaren dat een gebeurtenis uit een afgesloten hoofdstuk heeft plaatsgevonden of zonder steun in de verhaalgegevens een verborgen oorzaak vaststellen.

Een duidelijke instructie kan luiden: “Gebruik alleen de feiten en hoofdstukstatus die hier zijn aangeleverd. Je mag zelf de formulering en toon kiezen. Voeg geen namen, gebeurtenissen, relaties, motieven of uitkomsten als feiten toe. Als het antwoord niet is gegeven, zeg dan dat je het niet weet of niet kunt bevestigen.” Dit is een voorbeeld van een ontwerpregel, geen garantie dat een AI-model die altijd zal volgen. De game moet nog steeds bepalen welke informatie het personage krijgt en welke acties een antwoord kan activeren.

Personages mogen zich vergissen, ontwijkend reageren of onzeker zijn als het geschreven verhaal dat beoogt. Het belangrijkste onderscheid is of de game een uitspraak presenteert als het perspectief van dat personage of als een bevestigd feit over de wereld. “Ik heb gehoord dat de brug dicht is” kan een gerucht zijn als het verhaal ruimte laat voor geruchten. “De brug is dicht” kan worden opgevat als een betrouwbare statusupdate, vooral als de game er later op voortbouwt.

Bepaal bij elk onzeker of betwist antwoord of het personage uit eigen kennis spreekt, een gerucht herhaalt, speculeert of bevestigde canon weergeeft. Geef die categorie aan in de prompt of dialooggegevens en houd de formulering consistent. Als het verhaal niet heeft vastgesteld wie de oude toren heeft gebouwd, kan een NPC zeggen dat die verschillende verhalen heeft gehoord; het model moet het mysterie niet oplossen alleen omdat één antwoord aannemelijk klinkt.

Een model kan een feit niet betrouwbaar respecteren als het dat niet heeft gekregen. Geef alleen de status door die nodig is voor het gesprek, maar maak die precies: het huidige hoofdstuk, relevante gebeurtenissen die al hebben plaatsgevonden, belangrijke onopgeloste vragen en feiten die het personage zelf kent. Vermijd algemene samenvattingen die geplande gebeurtenissen verwarren met gebeurtenissen die al zijn gebeurd. De notitie “de poort gaat open nadat de speler het zegel vindt” mag niet worden verward met “de speler heeft het zegel gevonden”.

Onderzoek naar taalmodellen in tabletop-rollenspellen behandelt het bijhouden van de status en het genereren van dialogen als verwante maar afzonderlijke taken. De auteurs van Dungeons and Dragons as a Dialog Challenge for Artificial Intelligence beschrijven het genereren van beurten en het voorspellen van de gamestatus op basis van de dialooggeschiedenis, waarbij statusinformatie onder meer personagegegevens en veranderende acties omvat. Dit ondersteunt het idee om status als expliciete invoer en als afzonderlijk aandachtspunt te behandelen; het bewijst niet dat een gegenereerd antwoord de gezaghebbende status van de game mag wijzigen. (Callison-Burch et al., “Dungeons and Dragons as a Dialog Challenge for Artificial Intelligence”)

Kies een standaardreactie voor hiaten in de gegevens. Afhankelijk van het personage en de scène kan het antwoord bijvoorbeeld zijn: “Ik was er niet bij”, “Dat weet ik niet” of “Niemand heeft het me verteld.” Als een gerucht of een vermoeden van het personage passend is, maak dat dan duidelijk. Het doel is de open vraag open te houden totdat het geschreven verhaal die beantwoordt, terwijl het gesprek wel kan doorgaan.

Deze terugvaloptie moet ook tegenstrijdigheden opvangen. Als de aangeleverde hoofdstukstatus aangeeft dat de speler de kapitein nog niet heeft ontmoet, maar de gespreksgeschiedenis iets anders lijkt te zeggen, moet de NPC niet stellig een van beide versies bevestigen. Laat het gamesysteem de tegenstrijdigheid oplossen of laat de NPC een antwoord geven dat niet afhangt van het betwiste detail. Dit antwoordbeleid is een ontwerpaanbeveling, afgeleid van de noodzaak om status en dialoog coherent te houden; het is geen bevinding uit een specifiek gameonderzoek.

Controleer voordat je een antwoord toont of het een nieuw belangrijk feit introduceert. Je kunt daarbij vragen: noemt het antwoord een gebeurtenis, relatie, motief, locatie, bezitter van een voorwerp of uitkomst? Staat dat detail in de canon of de huidige status? Wordt het uitdrukkelijk als overtuiging of gerucht aangeduid? Impliceert het een overgang naar een ander hoofdstuk of een actie die de game niet heeft vastgelegd? Als een belangrijk detail niet wordt ondersteund, genereer dan opnieuw met striktere beperkingen of gebruik de terugvalreactie voor onzekerheid.

Prompten kan helpen om personages consistent te houden, maar behandel het niet als een database voor de canon. Een onderzoeksrapport uit 2026 over NPC's in Minecraft die worden aangestuurd door grote taalmodellen beschrijft hoe prompttechnieken zijn ingezet om de consistentie van personages en de samenhang van dialogen te verbeteren. Dat is bewijs voor een onderzoeksaanpak in een bepaald prototype, geen bewijs dat prompten alleen tegenstrijdigheden in andere games voorkomt. Bewaar geschreven feiten en spelvoortgang op een plek die de game kan raadplegen, en behandel gegenereerde dialogen als kandidaat-antwoorden. (Heriot-Watt Research Portal, “Designing and Evaluating Interactive Narratives with Generative AI: LLM-Driven NPCs for a Minecraft Murder Mystery”)

Pas bij het beoordelen van een betwiste regel deze controles in deze volgorde toe:

Is de bewering een vastgesteld feit over de wereld? Houd dan de geschreven versie aan.

Hangt het af van wat er in deze speelsessie is gebeurd? Gebruik dan de huidige hoofdstukstatus, niet een algemene samenvatting van het verhaal.

Gaat het om het beperkte of onzekere perspectief van het personage? Maak dat perspectief dan duidelijk in de regel.

Is er geen onderbouwd antwoord? Laat het personage dat dan zeggen en houd de vraag open.

Zou de uitspraak veranderen wat de game als waar of voltooid beschouwt? Alleen de geschreven voortgangslogica van de game mag die verandering doorvoeren.

Deze aanpak laat ruimte voor levendige gesprekken en houdt tegelijk duidelijk wie de wereld en de continuïteit bepaalt. Het model mag improviseren over hoe een bekend personage iets zegt; de wereldgegevens bepalen wat het personage betrouwbaar als waar kan beweren. Als de gegevens geen uitsluitsel geven, is onzekerheid een geldig antwoord en geen hiaat dat het model moet opvullen.