Hoe je spelers in het eerste hoofdstuk van een game leert wat NPC-gesprekken kunnen doen
Voor een ontwerper van verhalende games heeft het eerste hoofdstuk een specifieke taak: spelers helpen begrijpen wat ze een NPC kunnen vragen, wat een antwoord kan veranderen en wat er gebeurt als het personage niet genoeg informatie heeft. Leer die regels aan de hand van één optioneel gesprek met weinig inzet dat spelers kunnen uitproberen en bekijken. Houd het los van de tutorial over de besturing aan het begin: het doel hier is de grenzen van gesprekken vast te stellen, niet uit te leggen hoe je beweegt, menu’s gebruikt of vecht.
Wat moet het eerste hoofdstuk spelers leren over AI-gesprekken?
Leer spelers een kleine, nauwkeurige reeks verwachtingen aan in plaats van te beloven dat ze alles kunnen vragen. Spelers moeten kunnen zien:
Dit zijn beloftes over het gesprekssysteem van deze game, dus zorg dat ze overeenkomen met de daadwerkelijke implementatie. Als slechts bepaalde onderwerpen of acties worden ondersteund, laat die beperking dan zien voordat je spelers uitnodigt om vrijuit vragen te stellen. Laat een personage niet beweren dat elke vraag een zinvol antwoord krijgt als het systeem dat niet kan waarmaken.
Welke invoer wordt geaccepteerd: bijvoorbeeld een voorgesteld onderwerp kiezen of een korte vraag typen.
Waar de NPC over kan praten: bijvoorbeeld een persoon, plaats of gebeurtenis die het personage heeft meegemaakt.
Welke reacties de game beïnvloeden: maak onderscheid tussen informatie of sfeerdialoog en een actie die een bijgehouden status verandert.
Wat het personage niet weet: onbeantwoorde vragen moeten een duidelijke, bij het personage passende grens opleveren in plaats van een verzonnen feit.
Hoe je veilig kunt experimenteren: laat één voorbeeldvraag zien met een makkelijk te begrijpen resultaat, zonder dat de speler zich vastlegt op een grote keuze.
Een korte speelbare reeks voor het eerste hoofdstuk
Gebruik een moment dat spelers tijdens normaal spelen kunnen bereiken, nadat de besturing beschikbaar is en het verhaal een personage heeft geïntroduceerd dat een reden heeft om te praten. De volgende reeks is een ontwerpvoorbeeld; pas de namen en statuslabels aan de game aan.
Deze reeks leert spelers via een concrete interactie: een ondersteunde informatievraag, een zichtbare grens voor acties, een optionele keuze die de spelstatus verandert en een manier om het gesprek te beëindigen. De statuslabels hier zijn een illustratief ontwerpmiddel en geen bewering over een specifieke game-engine of implementatie.
Bied een optioneel gesprek aan. Een koerier genaamd Iven wacht naast een afgesloten poort. Een zichtbare interactieprompt zegt: “Vraag Iven naar de noordelijke weg.” De speler kan doorlopen en het hoofdstuk vervolgen. Geen verplichte doelstelling vereist dat de dialoog wordt geopend.
Laat de grens zien in de context. Wanneer de speler interactie aangaat, zegt Iven: “Ik kan je vertellen wat ik op de noordelijke weg heb gezien. Ik kan de poort niet openen en weet niet wat er gebeurde nadat ik vertrok.” Een compact interface-element geeft twee mogelijke onderwerpen aan: “Wegomstandigheden” en “De poort”. Een klein label of pictogram maakt onderscheid tussen “gesprek” en “actie in de wereld”.
Laat de speler één veilige voorbeeldvraag uitproberen. Bied een voorgestelde vraag aan: “Was de noordelijke weg geblokkeerd?” Iven antwoordt met een bekend detail: “Een omgevallen kar hield de mensen vanochtend op, maar ik was er voor het middaguur al voorbij.” Het antwoord is nuttig en begrensd, en verandert op zichzelf de spelstatus niet. Als de speler hetzelfde in eigen woorden vraagt, kan het systeem laten zien dat ondersteunde vragen niet exact dezelfde formulering hoeven te gebruiken.
Laat een echte statusverandering apart zien. De speler kan daarna vragen: “Kun je de kar verplaatsen?” Als Iven dat kan, moet de game een duidelijke actieoptie tonen, zoals “Vraag Iven om de kar te verplaatsen”. Na bevestiging registreert de game de relevante status, bijvoorbeeld cart_moved = true, en toont het gevolg in de wereld of het gesprek. Als de actie nog niet mogelijk is, leg dan uit aan welke voorwaarde nog niet is voldaan.
Beëindig het gesprek zonder spelers te dwingen het af te maken. De speler kan op elk moment weggaan. Het hoofdstuk gaat verder, of die nu één vraag heeft gesteld, meerdere onderwerpen heeft verkend of het gesprek heeft overgeslagen.
Hoe je statusveranderingen duidelijk maakt
Maak in zowel de tekst als het interfaceontwerp onderscheid tussen drie uitkomsten:
Informatie: “De kar blokkeerde vanochtend de noordelijke weg.” — De NPC heeft informatie gedeeld; dit houdt geen actie in de wereld in.
Bevestiging of sfeerdialoog: “Ik zal onthouden dat je het vroeg.” — Tenzij de game een gevolg bijhoudt, is dit alleen dialoog. Wek niet de indruk dat er een verborgen effect is.
Statusveranderende actie: “Ik verplaats de kar.” — Er is een actie beschikbaar en de game werkt een benoemde of waarneembare toestand bij.
Toon het gevolg van een actie
Een nuttige regel is om actietaal te koppelen aan een expliciete keuze en die op te volgen met zichtbaar bewijs: een veranderd voorwerp, een bijgewerkt logboek, een nieuwe route of een duidelijke bevestiging. Als een actie een sleutel, eerdere aanwijzing, relatievlag of mijlpaal in het hoofdstuk vereist, maak dan duidelijk aan welke voorwaarde niet is voldaan wanneer die de actie blokkeert. Vertel de speler niet dat een actie heeft plaatsgevonden als de relevante status niet is veranderd.
Breng ondersteunde interacties met NPC's in kaart voordat je schrijft
Voor een kleine ontmoeting in het eerste hoofdstuk kan een ontwerper elke ondersteunde interactie in kaart brengen voordat die de dialoog schrijft:
Met deze eenvoudige kaart houd je de dialoog makkelijker in overeenstemming met de spelstatus en spoor je onbedoelde beloftes in de tekst op.
Onderwerp: Waar vraagt de speler naar?
Kennisbron: Waarom zou dit personage het antwoord weten?
Voorwaarde: Welke feiten of statussen moeten gelden voordat het antwoord beschikbaar is?
Uitkomst: Geeft het antwoord alleen informatie, of verandert het iets?
Terugvalreactie: Wat moet het personage zeggen als de vraag buiten de ondersteunde reikwijdte valt of de benodigde informatie ontbreekt?
Wat moet een NPC zeggen als die iets niet weet?
Een NPC moet onderscheid kunnen maken tussen iets niet weten, niet kunnen handelen en de vraag niet begrijpen. Dit zijn verschillende uitkomsten voor de speler en vereisen verschillende reacties.
De terugvalreactie mag geen aanwijzing verzinnen alleen om het gesprek gaande te houden. De speler mag ook niet worden gestraft voor het uitproberen van de interface. Houd de toon in lijn met het personage, maar maak de praktische uitkomst duidelijk: het antwoord is onbekend, de actie is niet beschikbaar of de formulering moet worden verduidelijkt.
Grens aan kennis: “Ik ben niet voorbij de oostelijke brug geweest.” Dit geeft het perspectief van het personage weer en voorkomt dat die gaat gissen.
Ontbrekende game-informatie: “Ik weet niet wie de sleutel heeft meegenomen. Ik heb hem sinds gisteren niet meer gezien.” Gebruik dit wanneer de game het feit niet heeft vastgesteld of het personage geen basis heeft om het te weten.
Actie niet beschikbaar: “Ik kan de kar niet verplaatsen zolang de poortploeg die gebruikt.” Benoem de voorwaarde als die later kan veranderen, wanneer dat nuttig is.
Onduidelijk of niet-ondersteund verzoek: “Ik kan vragen beantwoorden over de weg en de poort. Wat wil je weten?” Geef een ondersteunde richting aan in plaats van een vage foutmelding.
Herhaalde of irrelevante vraag: Geef een korte reactie die de grens handhaaft en laat de speler daarna een ander onderwerp proberen of vertrekken.
Houd het gesprek optioneel en laagdrempelig
Zorg dat de uitnodiging opvalt, maar laat spelers die negeren, vroegtijdig weggaan of na het voorbeeld stoppen. Als de informatie nodig is om het hoofdstuk te voltooien, bied dan een andere manier om die te vinden of maak het gesprek een duidelijke, bewuste vereiste; vermom een verplichte blokkade niet als optioneel. Dwing spelers niet om elk onderwerp af te lopen om te ontdekken welke ertoe doen.
Een korte visuele aanwijzing kan helpen om invoertypen van elkaar te onderscheiden: voorgestelde onderwerpen, een vrij tekstveld en actieopties moeten er niet hetzelfde uitzien als ze verschillende gevolgen hebben. Houd instructies dicht bij de bijbehorende interactie. Het artikel “Less Text, More Visuals” beschrijft een kwalitatief onderzoek met 12 spelers van talige games en taalspellen. De deelnemers verwachtten visuele elementen en vonden te veel onboardingtekst overweldigend. Ook wezen ze op problemen met de taalkundige context en feedback. Dit is een beperkt onderzoek naar een GWAP voor NLP, geen bewijs dat elke game minder tekst nodig heeft of dat dezelfde aanpak in alle genres werkt. Zie het als een reden om te testen, niet als een universele regel: maak de aanwijzing duidelijk en controleer vervolgens of spelers die in je eigen game begrijpen.
Onderzoek naar de verankering van dialoog biedt een verwante, maar afzonderlijke les. In “A Framework for Exploring Player Perceptions of LLM-Generated Dialogue in Commercial Video Games” beoordeelden 28 spelers die via een Disco Elysium-subreddit waren geworven, dialoog in een nagebouwde RPG-gespreksinterface. De auteurs melden dat de spelers de tekst van de oorspronkelijke ontwerpers significant beter vonden dan de door GPT-4 gegenereerde tekst. Deelnemers noemden daarbij de logische opbouw en de verankering in de spelstatus. Dit was een beoordeling van dialoog, geen test van onboarding in het eerste hoofdstuk. Het onderstreept het belang van samenhangende gesprekken die rekening houden met de spelstatus, maar toont niet aan hoe je alle spelers gespreksregels kunt aanleren.
Controleer of spelers de juiste regels hebben geleerd
Observeer na het bouwen van de reeks of een nieuwe speler vier praktische vragen kan beantwoorden zonder lange uitleg:
Let op verschillen tussen wat spelers afleiden en wat het systeem werkelijk doet. Als ze denken dat elk antwoord de wereld verandert, maak dan het onderscheid tussen informatie en actie duidelijker. Als ze denken dat een weigering een bug is, verduidelijk dan de grens of de beschikbare onderwerpen. Als ze denken dat de voorbeeldvraag verplicht was, pas dan de prompt aan en zorg ervoor dat het hoofdstuk zonder die vraag verder kan.
Het eerste hoofdstuk hoeft niet elk mogelijk dialoogpad uit te leggen. Spelers moeten één representatieve interactie met weinig inzet kunnen uitproberen, de uitkomst begrijpen en zien hoe de NPC met een grens omgaat. Zodra die regels duidelijk zijn, kunnen ze verdere gesprekken verkennen met een beter beeld van wat hun vragen kunnen doen.
Waar kan dit personage over praten?
Welke keuze veranderde eventueel de spelstatus?
Wat doet het personage als die een antwoord niet weet?
Kan de speler het gesprek beëindigen of overslaan?