Faalstatussen in tekstgames: hoe je een tegenslag onderscheidt van een invoer- of afleverprobleem

Een praktische eerste vraag is: heeft de game de bedoelde actie begrepen en die in de fictie afgehandeld? Zo ja, dan kan het resultaat een tegenslag zijn. Zo niet, bepaal dan of het probleem bij de invoer, de informatie van het personage of de aflevering door het systeem ligt. Dit onderscheid in vier categorieën is een ontwerphulpmiddel, afgeleid van de manier waarop interactieve fictiesystemen parsing, wereldregels, verhaalverloop en ongedaan maken van elkaar onderscheiden; het is geen universele technische standaard. De documentatie van Inform beschrijft bijvoorbeeld de parser en het gesimuleerde wereldmodel als afzonderlijke onderdelen van een game, en de parser kan verschillende redenen melden waarom een opdracht niet overeenkwam. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)

Behandel het bericht als onderdeel van het responscontract van de game. Het moet antwoord geven op drie vragen: wat is er gebeurd, is de fictieve toestand veranderd en wat kan de speler nu doen? Een korte zin als “Het papieren bootje slaat om voordat het de overkant bereikt. Het opgevouwen briefje heb je nog in je hand. Je kunt een bredere geul proberen of een andere manier kiezen om over te steken” maakt de tegenslag, het behouden voorwerp en de volgende stap duidelijk.

Een tegenslag past wanneer de game de actie heeft begrepen, aan de huidige scène heeft getoetst en bewust een gevolg binnen de fictie heeft voortgebracht. Misschien probeert de speler te veel bibliotheekboeken tegelijk te dragen en glijdt er een op een stoel in de buurt. Misschien loopt een papieren bootje vol water voordat het de overkant van een ondiepe beek bereikt. De uitkomst kan lastig of verrassend zijn zonder dat het gesprek verandert in een oordeel over de speler.

Het bepalende kenmerk is een verandering van toestand. Als de scène zegt dat de boot is gezonken, moet dat in het verhaal ook echt zijn gebeurd. Als de speler hem kan terughalen, leg dan uit hoe; als de boot verloren is, wek dan niet de indruk dat het opnieuw proberen van dezelfde tekst die gebeurtenis ongedaan maakt. Opnieuw proberen kan betekenen dat de speler een nieuwe boot maakt, een andere route kiest of verdergaat in de veranderde scène. De precieze optie hangt af van de regels van de game.

Een bruikbaar bericht over een tegenslag benoemt de poging, het gevolg en de beschikbare vervolgstap. Geef een ondersteunde actie niet de schijn van een invoerfout alleen omdat de uitkomst ongunstig was. Wek omgekeerd ook niet de indruk dat er een gevolg is opgetreden als de verhaaltoestand niet werkelijk is veranderd. Zo begrijpt de speler of die vanuit een nieuwe situatie verdergaat of een niet-verwerkte opdracht corrigeert.

Niet-ondersteunde invoer betekent dat het systeem het bericht van de speler niet kan koppelen aan een actie die het ondersteunt. De speler typt misschien “vraag de bakker naar abrikozen” in een scène waarin de game alleen een kleine reeks keuzeknoppen accepteert, of gebruikt een naam die de parser niet herkent. Dit zegt iets over de mogelijkheden van de interface, niet over de kwaliteit van het idee van de speler.

De parsers van interactieve fictie laten zien waarom bruikbare feedback specifiek moet zijn: Inform vermeldt afzonderlijke fouten voor een niet-herkend werkwoord, een onduidelijke verwijzing, te weinig invoer en een object dat niet zichtbaar is. In de handleiding staat ook hoe een game een algemene parserfout kan vervangen door een informatiever bericht. (Inform 7 §18.35: Printing a parser error) Een beknopte reactie in een chatgame kan zijn: “Ik kan ‘vragen naar abrikozen’ hier niet verwerken. Je kunt naar de levering vragen of een onderwerp van de toonbank kiezen.”

Bied een manier om de invoer te herstellen. Afhankelijk van de interface kan dat betekenen dat je herkende keuzes toont, één gerichte verduidelijkingsvraag stelt of de speler uitnodigt om de formulering aan te passen. Vertel een niet-ondersteunde opdracht niet na als een fictieve mislukking: als er geen actie is uitgevoerd, zeg dat dan duidelijk. Laat de vorige scène intact en maak duidelijk dat een gecorrigeerde invoer hetzelfde moment opnieuw probeert en geen verhaalgebeurtenis terugdraait.

Soms is de invoer begrijpelijk, maar weet het personage niet genoeg om erop te handelen. Een speler vraagt bijvoorbeeld aan de assistent van een winkelier waar een pakket is bezorgd, voordat de assistent het ontvangstbewijs heeft gezien. De game kan de vraag herkennen en toch terecht geen stellig antwoord geven.

Dit verschilt van niet-ondersteunde invoer: het onderwerp of de actie is geldig en de beperking komt voort uit de informatie waarover het personage binnen de fictie beschikt. Geef die grens duidelijk aan. Bijvoorbeeld: “Mina heeft het afleverbonnetje niet gezien en kan daarom de straat niet noemen. Het etiket van het pakket ligt nog op de toonbank.” Als de speler het etiket kan bekijken, iemand anders kan vragen of later kan terugkomen, benoem dan die mogelijkheid. Zo niet, zeg dan wat er daadwerkelijk bekend is in plaats van een hint te verzinnen of de vraag als onjuist geformuleerd te behandelen.

Bepaal of dit antwoord tijd laat verstrijken of de toestand verandert. Als de vraag stellen een gewone handeling binnen de fictie is, kan de game dat gesprek vastleggen of later van invloed laten zijn op de reactie van een personage. Als kennisvragen volgens de bedoeling van de game geen tijd kosten, laat de scène dan ongewijzigd en geef ruimte voor een volgende vraag. De speler moet niet hoeven raden of een verzoek om informatie ongemerkt een kans heeft gekost.

Een afleverprobleem ontstaat buiten de fictie: een reactie loopt vast, verschijnt twee keer of breekt halverwege een zin af. De game kan niet veilig beweren dat het personage heeft gehandeld of dat het verhaal is gevorderd, tenzij zeker is dat de actie is verwerkt. Dit verschilt van een bericht binnen de fictie zoals “de koerier kon het adres niet vinden”, wat een fictieve uitkomst is.

Gebruik duidelijke statusmeldingen en geef de bekende toestand aan. Als de game kan bevestigen dat de beurt niet is verwerkt, zeg dat dan en laat de speler die opnieuw verzenden. Als niet duidelijk is of de beurt is verwerkt, nodig de speler dan niet uit om blind opnieuw te proberen, want dan kan de actie twee keer worden uitgevoerd. Leg de onzekerheid kort uit en bied een manier om de huidige scène te controleren of vanaf het laatst bevestigde punt verder te gaan. Dit zijn ontwerpaanbevelingen, afgeleid van de noodzaak om een mislukte koppeling van invoer te onderscheiden van een verhaaluitkomst; de aangehaalde fictiesystemen definiëren geen universeel protocol voor afleverproblemen in chat.

Herstel bij een probleem met de aflevering de laatst bevestigde boodschap of toon een beknopte samenvatting van de scène en de meest recente actie waarvan bekend is dat die is voltooid. Geef duidelijk aan dat het om een samenvatting gaat en niet om een nieuwe verhaalbeurt. Als de speler ervoor kiest de actie opnieuw te verzenden, verduidelijk dan of die als een nieuwe poging wordt behandeld. Met die kleine dosis transparantie wordt voorkomen dat een dubbele actie wordt aangezien voor een bewuste herhaling.

Deze woorden beschrijven verschillende effecten op de toestand, dus gebruik ze niet door elkaar. Opnieuw proberen voert een actie nogmaals uit in de huidige toestand; een vaststaand gevolg mag daardoor niet ongemerkt worden uitgewist. Ongedaan maken herstelt een eerdere toestand. Hervatten gaat na een onderbreking verder vanaf de laatst bevestigde toestand. Opnieuw starten begint het verhaal opnieuw.

De Harlowe-handleiding van Twine beschrijft hoe je met ongedaan maken terugkeert naar de vorige passage en variabele wijzigingen uit de huidige passage worden vergeten; opnieuw starten wordt beschreven als het herladen van de pagina om het verhaal opnieuw te beginnen. Ook staat erin dat de geschiedenis voor ongedaan maken beperkt kan zijn. Deze werking laat zien waarom een bedieningselement duidelijk moet maken wat het herstelt, in plaats van te vertrouwen op een vaag label als “probeer opnieuw”. (Harlowe 3.3.8 Manual: undo and restart)

Met een korte reeks beslissingen houd je de interface consistent:

Heeft de game de actie begrepen en verwerkt? Zo ja, meld dan de fictieve uitkomst en de toestand die overblijft.

Kon het systeem de formulering niet koppelen aan een ondersteunde actie? Leg uit wat het niet kon verwerken en toon hoe de speler de invoer kan herstellen; laat de scène intact.

Is de actie begrepen, maar mist het personage informatie? Leg de kennisgrens uit en vermeld eventuele mogelijkheden binnen de fictie om meer te weten te komen.

Is het onzeker of de actie is verwerkt of afgeleverd? Benoem wat vaststaat en bied daarna een veilige manier om dit te controleren of verder te gaan.

Wil de speler teruggaan? Label het bedieningselement dan met “Ongedaan maken” en vermeld welk moment of welke wijzigingen worden hersteld. Gebruik “Opnieuw starten” alleen om opnieuw te beginnen.

Controleer elk antwoord aan de hand van de verhaaltoestand voordat je het uitbrengt. Als het een tegenslag beschrijft, is de wereld dan echt veranderd? Als het niet-ondersteunde invoer beschrijft, heeft de game dan vermeden te doen alsof de actie heeft plaatsgevonden? Als het personage kennis mist, maakt het antwoord dan duidelijk dat dit iets anders is dan een niet-herkende opdracht? Als de aflevering mislukte, weet de speler dan of de beurt is verwerkt? Doet de knop voor opnieuw proberen of hervatten ten slotte wat het label belooft?

Een tekstgame voelt eerlijk aan wanneer de feedback de speler helpt te onderscheiden wat het personage heeft meegemaakt van wat de interface niet kon doen. Duidelijke gevolgen houden het verhaal intact; specifieke aanwijzingen voor invoer maken een nieuwe poging mogelijk; eerlijke grenzen aan kennis houden de fictie samenhangend; en een duidelijk herstelpad biedt de speler een betrouwbare manier om verder te gaan.