Fehlerzustände in Textspielen: Wie man einen Rückschlag von einem Eingabe- oder Übertragungsproblem unterscheidet
In einem Textspiel im Chat-Stil bedeutet ein erfolgloser Spielzug nicht immer, dass die spielende Person eine schlechte Entscheidung getroffen hat. Die Szene hat möglicherweise einen echten fiktionalen Rückschlag erreicht, das Spiel unterstützt die Formulierung womöglich nicht, dem Charakter fehlt eventuell das nötige Wissen zum Handeln oder die Nachricht ist vielleicht gar nicht erst angekommen. Diese Situationen erfordern unterschiedliche Rückmeldungen und verschiedene Effekte bei erneuten Versuchen. Bestimmen Sie zuerst die Ursache und teilen Sie der spielenden Person anschließend mit, was sich geändert hat und wie es weitergehen kann.
Fragen Sie zuerst, was fehlgeschlagen ist
Eine praktische erste Frage lautet: Hat das Spiel die beabsichtigte Aktion verstanden und sie innerhalb der Fiktion aufgelöst? Wenn ja, ist das Ergebnis möglicherweise ein Rückschlag. Wenn nicht, stellen Sie fest, ob das Problem bei der Eingabe, den Informationen des Charakters oder der Übertragung durch das System liegt. Diese vierteilige Unterscheidung ist eine Entwurfshilfe, die sich daraus ableitet, wie interaktive Fiktionssysteme Parsing, Weltregeln, Handlungsablauf und Rückgängig-Verhalten trennen; sie ist kein allgemeingültiger technischer Standard. Die Dokumentation von Inform beschreibt beispielsweise den Parser und das simulierte Weltmodell als getrennte Teile eines Spiels, und sein Parser kann verschiedene Gründe dafür melden, warum ein Befehl nicht passte. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)
Betrachten Sie die Nachricht als Teil der Antwortvereinbarung des Spiels. Sie sollte drei Dinge beantworten: Was ist passiert, hat sich der fiktionale Zustand geändert und was kann die spielende Person nun tun? Eine kurze Zeile wie „Das Papierboot kentert, bevor es das andere Ufer erreicht. Die gefaltete Notiz liegt noch in deiner Hand. Du kannst es an einer breiteren Stelle versuchen oder einen anderen Weg hinüber wählen“ macht den Rückschlag, den behaltenen Gegenstand und den nächsten Schritt transparent.
1. Ein echter fiktionaler Rückschlag
Ein Rückschlag ist angebracht, wenn das Spiel die Handlung verstanden, mit der aktuellen Szene abgeglichen und bewusst eine Konsequenz innerhalb der Welt herbeigeführt hat. Vielleicht versucht die spielende Person, zu viele Bibliotheksbücher auf einmal zu tragen, und eines rutscht auf einen nahen Stuhl. Vielleicht zieht ein Papierboot Wasser, bevor es die andere Seite eines flachen Bachs erreicht. Das Ergebnis kann unbequem oder überraschend sein, ohne dass der Austausch zu einer Verurteilung der spielenden Person wird.
Das entscheidende Merkmal ist die Zustandsänderung. Wenn die Szene besagt, dass das Boot gesunken ist, sollte dieses Ergebnis in der Geschichte wahr sein. Wenn die spielende Person es bergen kann, erklären Sie, wie; wenn das Boot verloren ist, erwecken Sie nicht den Eindruck, dass eine Wiederholung desselben Textes dieses Ereignis rückgängig macht. Ein neuer Versuch könnte bedeuten, ein neues Boot zu falten, eine andere Route zu wählen oder in der veränderten Szene fortzufahren. Die genaue Option hängt von den Regeln des Spiels ab.
Eine nützliche Rückschlagmeldung nennt die versuchte Handlung, die Konsequenz und die verfügbare Fortsetzung. Sie sollte eine unterstützte Handlung nicht als Eingabefehler tarnen, nur weil das Ergebnis ungünstig war. Umgekehrt sollten Sie nicht andeuten, dass eine Konsequenz eingetreten ist, wenn das Spiel den Zustand der Geschichte gar nicht geändert hat. Diese Unterscheidung ermöglicht es der spielenden Person zu verstehen, ob sie in einer neuen Situation weiterspielt oder einen nicht verarbeiteten Befehl korrigiert.
2. Nicht unterstützte Eingabe: Das Spiel konnte die Formulierung nicht auflösen
Eine nicht unterstützte Eingabe bedeutet, dass das System die Nachricht der spielenden Person keiner unterstützten Aktion zuordnen kann. Vielleicht tippt die Person in einer Szene, in der das Spiel nur wenige Button-Auswahlen akzeptiert, „frage den Bäcker nach Aprikosen“ ein oder verwendet einen Namen, den der Parser nicht erkennt. Dies sagt etwas über den Abdeckungsgrad der Schnittstelle aus, nicht über die Qualität der Idee der spielenden Person.
Parser für interaktive Fiktion verdeutlichen, warum nützliches Feedback spezifisch sein sollte: Inform listet getrennte Fehler für ein nicht erkanntes Verb, einen unklaren Verweis, eine unvollständige Eingabe und ein nicht sichtbares Objekt auf. Das Handbuch zeigt auch, wie ein Spiel einen generischen Parser-Fehler durch eine informativere Nachricht ersetzen kann. (Inform 7 §18.35: Printing a parser error) In einem Chat-Spiel könnte eine prägnante Antwort lauten: „Ich kann ‚nach Aprikosen fragen‘ hier nicht auflösen. Du kannst nach der Lieferung fragen oder ein Thema von der Theke wählen.“
Bieten Sie einen Lösungsweg an. Je nach Schnittstelle könnte dies bedeuten, erkannte Auswahlmöglichkeiten anzuzeigen, eine gezielte Klärungsfrage zu stellen oder die spielende Person zu bitten, die Eingabe umzuformulieren. Stellen Sie einen nicht unterstützten Befehl nicht als fiktionales Scheitern dar: Wenn keine Aktion ausgeführt wurde, stellen Sie das klar fest. Belassen Sie die vorherige Szene intakt und machen Sie deutlich, dass das Senden einer korrigierten Eingabe denselben Moment wiederholt, anstatt ein Handlungsereignis zurückzuspulen.
3. Nicht verfügbares Charakterwissen: Eine gültige Frage ohne bisherige Antwort
Manchmal ist die Eingabe verständlich, aber der Charakter weiß nicht genug, um danach zu handeln. Eine spielende Person fragt die Aushilfe eines Ladenbesitzers vielleicht, wohin ein Paket geliefert wurde, noch bevor die Aushilfe die Quittung gesehen hat. Das Spiel kann die Frage erkennen und gleichzeitig eine definitive Antwort richtigerweise verweigern.
Dies unterscheidet sich von einer nicht unterstützten Eingabe: Das Thema oder die Handlung ist gültig, und die Einschränkung liegt im Wissensstand des Charakters innerhalb der Fiktion begründet. Machen Sie diese Grenze deutlich. Zum Beispiel: „Mina hat den Lieferschein noch nicht gesehen und kann die Straße daher nicht nennen. Der Paketaufkleber liegt noch auf der Theke.“ Wenn die spielende Person den Aufkleber untersuchen, jemand anderen fragen oder später wiederkommen kann, nennen Sie diesen Weg. Wenn nicht, sagen Sie, was tatsächlich bekannt ist, anstatt einen Hinweis zu erfinden oder die Frage als fehlerhaft zu behandeln.
Entscheiden Sie, ob diese Antwort die Zeit voranschreiten lässt oder den Zustand ändert. Wenn das Stellen der Frage eine normale Handlung innerhalb der Spielwelt ist, kann das Spiel dieses Gespräch festhalten oder verändern, wie ein Charakter später reagiert. Wenn das Spiel vorsieht, dass Wissensfragen kostenlos sind, bewahren Sie die Szene und lassen Sie eine weitere Frage folgen. Die spielende Person sollte nicht raten müssen, ob eine Informationsanfrage stillschweigend eine Handlungschance verbraucht hat.
4. Technischer Übertragungsfehler: Die Aktion hat die Geschichte womöglich nie erreicht
Ein Übertragungsfehler geschieht außerhalb der Fiktion: Eine Antwort überschreitet das Zeitlimit, erscheint doppelt oder bricht mitten im Satz ab. Das Spiel kann nicht sicher behaupten, dass der Charakter gehandelt oder die Geschichte sich weiterbewegt hat, solange es nicht weiß, dass die Aktion verarbeitet wurde. Dies unterscheidet sich von einer Nachricht innerhalb der Spielwelt wie „Der Bote konnte die Adresse nicht finden“, was ein fiktionales Ergebnis darstellt.
Verwenden Sie klare Statusformulierungen und melden Sie den bekannten Zustand. Wenn das Spiel verifizieren kann, dass der Spielzug nicht verarbeitet wurde, sagen Sie das und lassen Sie die Person die Eingabe erneut senden. Wenn nicht bestimmt werden kann, ob der Spielzug verarbeitet wurde, fordern Sie nicht blind zu einer Wiederholung auf, die die Aktion möglicherweise doppelt ausführt. Erläutern Sie die Ungewissheit kurz und bieten Sie eine Möglichkeit an, die aktuelle Szene zu überprüfen oder am letzten bestätigten Punkt fortzufahren. Dies sind Designempfehlungen, die sich aus der Notwendigkeit ableiten, einen fehlgeschlagenen Eingabeabgleich von einem Handlungsergebnis zu unterscheiden; die zitierten Fiktionssysteme definieren kein allgemeingültiges Protokoll für Chat-Übertragungsfehler.
Wenn die Übertragung wiederhergestellt ist, bringen Sie die letzte bestätigte Nachricht zurück oder zeigen Sie eine prägnante Zusammenfassung der Szene und der letzten Aktion, von der bekannt ist, dass sie abgeschlossen wurde. Kennzeichnen Sie eine Zusammenfassung als solche und nicht als neuen Spielzug der Geschichte. Wenn die spielende Person sich entscheidet, die Eingabe erneut zu senden, stellen Sie klar, ob dies als neuer Versuch gewertet wird. Dieses kleine Stück Transparenz verhindert, dass eine duplizierte Aktion fälschlicherweise für eine bewusste Wiederholung gehalten wird.
Geben Sie Wiederholen, Rückgängig und Fortsetzen unterschiedliche Bedeutungen
Diese Begriffe beschreiben unterschiedliche Zustandseffekte; verwenden Sie sie daher nicht austauschbar. Ein Wiederholen („Retry“) sendet eine Aktion im aktuellen Zustand erneut; es sollte eine eingetretene Konsequenz nicht stillschweigend löschen. Ein Rückgängigmachen („Undo“) stellt einen früheren Zustand wieder her. Ein Fortsetzen („Resume“) fährt nach einer Unterbrechung am letzten bestätigten Zustand fort. Ein Neustart („Restart“) beginnt die Geschichte von vorn.
Das Handbuch von Twines Harlowe dokumentiert „Undo“ als die Rückkehr zum vorherigen Abschnitt unter Löschung von Variablenänderungen, die im aktuellen Abschnitt vorgenommen wurden; es beschreibt „Restart“ als das Neuladen der Seite, um die Geschichte von vorn zu beginnen. Es weist auch darauf hin, dass der Verlauf für das Rückgängigmachen begrenzt sein kann. Diese Mechanismen zeigen, warum ein Bedienelement seinen Umfang vermitteln sollte, anstatt sich auf ein vages Label wie „Nochmal versuchen“ zu verlassen. (Harlowe 3.3.8 Manual: undo and restart)
Eine kompakte Entscheidungsabfolge hilft dabei, die Schnittstelle konsistent zu halten:
Hat das Spiel die Aktion verstanden und aufgelöst? Wenn ja, melden Sie das fiktionale Ergebnis und den verbleibenden Zustand.
Konnte das System den Wortlaut keiner unterstützten Aktion zuordnen? Erklären Sie, was nicht aufgelöst werden konnte, und zeigen Sie einen Lösungsweg auf; belassen Sie die Szene unverändert.
Wurde die Handlung verstanden, aber dem Charakter fehlen Informationen? Erklären Sie die Wissensgrenze und wie man innerhalb der Spielwelt mehr erfahren kann.
Ist die Verarbeitung oder Übertragung ungewiss? Geben Sie an, was bestätigt ist, und bieten Sie dann einen sicheren Weg zur Prüfung oder Fortsetzung an.
Wenn die spielende Person zurückgehen möchte, beschriften Sie das Bedienelement mit „Rückgängig“ und geben Sie an, welchen Moment oder welche Änderungen es wiederherstellt. Reservieren Sie „Neustart“ für das Beginnen von vorn.
Eine kurze Konsistenzprüfung für jede Fehlermeldung
Bevor Sie eine Antwort ausliefern, prüfen Sie sie gegen den Zustand der Geschichte. Wenn sie einen Rückschlag beschreibt: Hat sich die Welt tatsächlich verändert? Wenn sie eine nicht unterstützte Eingabe beschreibt: Hat das Spiel darauf verzichtet, so zu tun, als habe die Aktion stattgefunden? Wenn dem Charakter Wissen fehlt: Unterscheidet die Antwort dies von einem fehlenden Befehl? Wenn die Übertragung fehlschlug: Weiß die spielende Person, ob der Spielzug verarbeitet wurde? Hält das Bedienelement für Wiederholen oder Fortsetzen schließlich das, was seine Beschriftung verspricht?
Ein Textspiel fühlt sich fair an, wenn sein Feedback der spielenden Person dabei hilft, zu unterscheiden, was der Charakter erlebt hat und was die Schnittstelle nicht leisten konnte. Klare Konsequenzen bewahren die Geschichte; spezifische Eingabehilfen machen einen weiteren Versuch möglich; ehrliche Wissensgrenzen halten die Fiktion kohärent; und ein definierter Wiederherstellungsweg gibt der spielenden Person einen verlässlichen Weg nach vorn an die Hand.