Misslyckade tillstånd i textspel: så skiljer du ett bakslag från ett inmatnings- eller leveransproblem

En bra första fråga är: förstod spelet den avsedda handlingen och hanterade den i fiktionen? Om ja, kan resultatet vara ett bakslag. Om inte, ta reda på om problemet gäller inmatningen, rollfigurens information eller systemets leverans. Den här fyrdelade uppdelningen är ett designhjälpmedel som härletts från hur interaktiva fiktionstexter skiljer mellan tolkning, världens regler, berättelsens förlopp och ångring; den är ingen universell teknisk standard. Informs dokumentation beskriver till exempel parsern och den simulerade världsmodellen som separata delar av ett spel, och parsern kan ange flera olika orsaker till att ett kommando inte kunde tolkas. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)

Behandla meddelandet som en del av spelets återkoppling. Det bör svara på tre frågor: vad hände, ändrades det fiktiva tillståndet och vad kan spelaren göra nu? En kort rad som ”Pappersbåten välter innan den når den bortre stranden. Den vikta lappen är fortfarande i din hand. Du kan prova en bredare kanal eller välja ett annat sätt att ta dig över” gör bakslaget, föremålet som finns kvar och nästa steg tydliga.

Ett bakslag passar när spelet förstod handlingen, prövade den mot den aktuella scenen och avsiktligt skapade en konsekvens i spelvärlden. Spelaren kanske försöker bära för många biblioteksböcker på en gång och en av dem glider ner på en stol intill. En pappersbåt kanske tar in vatten innan den når andra sidan av en grund bäck. Utfallet kan vara besvärligt eller överraskande utan att samtalet blir en bedömning av spelaren.

Det avgörande kännetecknet är att tillståndet förändras. Om scenen säger att båten sjönk ska det utfallet vara sant i berättelsen. Om spelaren kan hämta den, förklara hur; om båten är borta, antyd inte att det går att upphäva händelsen genom att försöka igen med samma text. Ett nytt försök kan innebära att bygga en ny båt, välja en annan väg eller fortsätta från den förändrade scenen. Exakt vilket alternativ som gäller beror på spelets regler.

Ett användbart meddelande om ett bakslag nämner den försökta handlingen, konsekvensen och hur spelet kan fortsätta. Klä inte en handling som stöds i ett inmatningsfel bara för att resultatet var ogynnsamt. Omvänt ska du inte antyda att en konsekvens inträffade om spelets tillstånd faktiskt inte ändrades. Den skillnaden hjälper spelaren att förstå om hen fortsätter från en ny situation eller korrigerar ett kommando som inte behandlades.

Inmatning som inte stöds innebär att systemet inte kan koppla spelarens meddelande till en handling som spelet stöder. Spelaren kanske skriver ”fråga bagaren om aprikoser” i en scen där spelet bara godtar ett litet antal knappval, eller använder ett namn som parsern inte känner igen. Det säger något om gränssnittets täckning, inte om kvaliteten på spelarens idé.

Parserar för interaktiv fiktion visar varför återkopplingen bör vara specifik: Inform har separata felmeddelanden för ett okänt verb, en oklar hänvisning, för lite inmatning och ett föremål som inte går att se. Manualen visar också hur ett spel kan ersätta ett generiskt parserfel med ett mer informativt meddelande. (Inform 7 §18.35: Printing a parser error) I ett chattspel kan ett kort svar vara: ”Jag kan inte tolka ’fråga om aprikoser’ här. Du kan fråga om leveransen eller välja ett ämne vid disken.”

Erbjud ett sätt att rätta till inmatningen. Beroende på gränssnittet kan det innebära att visa kända val, ställa en enda fokuserad följdfråga eller be spelaren formulera sig på nytt. Berätta inte om ett kommando som inte stöds som om det hade misslyckats i fiktionen: om ingen handling utfördes ska du säga det tydligt. Behåll den föregående scenen och gör klart att en korrigerad inmatning försöker igen i samma ögonblick, i stället för att spola tillbaka en händelse i berättelsen.

Ibland är inmatningen begriplig, men rollfiguren vet inte tillräckligt för att agera. Spelaren kanske frågar en butiksbiträde var ett paket levererades innan biträdet har sett kvittot. Spelet kan förstå frågan och ändå med rätta låta bli att ge ett definitivt svar.

Detta skiljer sig från inmatning som inte stöds: ämnet eller handlingen är giltig, och begränsningen hör till rollfigurens kunskap i fiktionen. Markera den gränsen tydligt. Till exempel: ”Mina har inte sett följesedeln, så hon kan inte säga vilken gata det gäller. Paketetiketten ligger fortfarande på disken.” Om spelaren kan läsa etiketten, fråga någon annan eller återkomma senare, ange den möjligheten. Om inte, säg vad som faktiskt är känt i stället för att hitta på en ledtråd eller behandla frågan som felaktigt formulerad.

Bestäm om svaret för tiden framåt eller ändrar tillståndet. Om det är en vanlig handling i spelvärlden att ställa frågan kan spelet registrera samtalet eller påverka hur en rollfigur svarar senare. Om spelet avser att kunskapsfrågor ska vara kostnadsfria, behåll scenen som den är och låt spelaren ställa en ny fråga. Spelaren ska inte behöva gissa om en informationsfråga i tysthet förbrukade en möjlighet.

Ett leveransfel uppstår utanför fiktionen: ett svar tar för lång tid, visas två gånger eller avbryts mitt i en mening. Spelet kan inte tryggt hävda att rollfiguren agerade eller att berättelsen gick vidare om det inte vet att handlingen behandlades. Detta skiljer sig från ett meddelande i spelvärlden, som ”budet kunde inte hitta adressen”, vilket är ett fiktivt resultat.

Använd tydlig statusinformation och rapportera det som är känt. Om spelet kan bekräfta att spelrundan inte behandlades, säg det och låt spelaren skicka den igen. Om det inte går att avgöra om spelrundan behandlades, undvik att uppmana till en blind upprepning som kan utföra handlingen två gånger. Förklara kort vad som är osäkert och erbjud ett sätt att kontrollera den aktuella scenen eller återuppta spelet från den senast bekräftade punkten. Detta är designrekommendationer som härletts från behovet av att skilja en misslyckad tolkning av inmatningen från ett utfall i berättelsen; de citerade fiktionstexterna definierar inget universellt protokoll för leveransfel i chatt.

När leveransen fungerar igen ska du återställa det senast bekräftade meddelandet eller visa en kort sammanfattning av scenen och den senaste handling som bekräftat slutförts. Märk sammanfattningen som just en sammanfattning, inte som en ny spelrunda i berättelsen. Om spelaren väljer att skicka igen, klargör om det räknas som ett nytt försök. Den lilla tydligheten hindrar att en upprepad handling misstas för en avsiktlig upprepning.

De här orden beskriver olika effekter på tillståndet, så använd dem inte om vartannat. Att försöka igen skickar en handling på nytt från det aktuella tillståndet; det ska inte i tysthet radera en redan etablerad konsekvens. Att ångra återställer ett tidigare tillstånd. Att återuppta fortsätter från det senast bekräftade tillståndet efter ett avbrott. Att starta om börjar berättelsen från början.

Twines Harlowe-manual beskriver ångring som att gå tillbaka till det föregående avsnittet och glömma variabeländringar som gjorts i det aktuella avsnittet; omstart beskrivs som att ladda om sidan för att börja berättelsen igen. Den påpekar också att ångerhistoriken kan vara begränsad. Dessa mekanismer visar varför en kontroll bör förmedla sin omfattning i stället för att förlita sig på den vaga etiketten ”försök igen”. (Harlowe 3.3.8 Manual: undo and restart)

En kort beslutsordning hjälper till att hålla gränssnittet konsekvent:

Förstod och hanterade spelet handlingen? Om ja, beskriv det fiktiva utfallet och vilket tillstånd som kvarstår.

Misslyckades systemet med att koppla formuleringen till en handling som stöds? Förklara vad det inte kunde tolka och visa hur spelaren kan rätta till det; behåll scenen.

Förstod spelet handlingen, men saknar rollfiguren information? Förklara kunskapsgränsen och hur man kan ta reda på mer i spelvärlden.

Är det osäkert om handlingen behandlades eller levererades? Ange vad som är bekräftat och erbjud sedan ett säkert sätt att kontrollera läget eller fortsätta.

Om spelaren vill gå tillbaka, märk kontrollen ”Ångra” och ange vilket ögonblick eller vilka ändringar den återställer. Reservera ”Starta om” för att börja om.

Kontrollera meddelandet mot berättelsens tillstånd innan det publiceras. Om det beskriver ett bakslag, förändrades världen faktiskt? Om det beskriver inmatning som inte stöds, undvek spelet att låtsas att handlingen utfördes? Om rollfiguren saknar kunskap, skiljer svaret det från ett kommando som inte känns igen? Om leveransen misslyckades, vet spelaren om spelrundan behandlades? Och gör funktionen för att försöka igen eller återuppta det som etiketten lovar?

Ett textspel känns rättvist när återkopplingen hjälper spelaren att skilja mellan vad rollfiguren upplevde och vad gränssnittet inte kunde göra. Tydliga konsekvenser bevarar berättelsen; specifik vägledning om inmatningen gör ett nytt försök möjligt; ärliga kunskapsgränser håller fiktionen sammanhängande; och en tydligt definierad återställningsväg ger spelaren en pålitlig väg framåt.