Stany niepowodzenia w grach tekstowych: jak odróżnić niepowodzenie w grze od problemu z poleceniem lub dostarczeniem wiadomości

Praktyczne pytanie na początek brzmi: czy gra zrozumiała zamierzone działanie i rozstrzygnęła je w świecie fikcji? Jeśli tak, wynikiem może być niepowodzenie. Jeśli nie, ustal, czy problem dotyczy polecenia, wiedzy postaci czy dostarczenia wiadomości przez system. Ten czteroczęściowy podział jest pomocą projektową, wywnioskowaną ze sposobu, w jaki systemy fikcji interaktywnej rozdzielają parsowanie poleceń, reguły świata, przebieg fabuły i cofanie zmian; nie jest uniwersalnym standardem technicznym. Dokumentacja Inform opisuje na przykład parser i symulowany model świata jako oddzielne części gry, a parser może zgłaszać kilka różnych powodów niedopasowania polecenia. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)

Traktuj komunikat jako część umowy gry z graczem dotyczącą odpowiedzi. Powinien wyjaśniać trzy kwestie: co się stało, czy zmienił się stan świata fikcji i co gracz może teraz zrobić. Krótki komunikat, taki jak „Papierowa łódka przewraca się, zanim dopływa do przeciwległego brzegu. Złożona notatka wciąż jest w twojej dłoni. Możesz spróbować szerszego kanału albo wybrać inną drogę na drugą stronę”, jasno przedstawia niepowodzenie, zachowany przedmiot i następny krok.

Niepowodzenie jest właściwe, gdy gra zrozumiała działanie, sprawdziła je w kontekście bieżącej sceny i celowo wywołała konsekwencję w świecie fikcji. Gracz może próbować nieść naraz zbyt wiele książek z biblioteki i jedna z nich zsuwa się na pobliskie krzesło. Papierowa łódka może nabrać wody, zanim dotrze na drugi brzeg płytkiego strumienia. Wynik może być kłopotliwy lub zaskakujący, ale nie powinien zmieniać wymiany zdań w ocenę gracza.

Cechą rozstrzygającą jest zmiana stanu. Jeśli scena mówi, że łódka zatonęła, w świecie opowieści powinno to być prawdą. Jeśli gracz może ją odzyskać, wyjaśnij jak; jeśli łódka przepadła, nie sugeruj, że ponowienie tego samego tekstu cofnie to zdarzenie. Ponowienie próby może oznaczać zbudowanie kolejnej łódki, wybranie innej trasy lub kontynuowanie w zmienionej scenie. Konkretna możliwość zależy od reguł gry.

Przydatny komunikat o niepowodzeniu nazywa podjęte działanie, jego konsekwencję i dostępne dalsze możliwości. Nie przedstawiaj obsługiwanego działania jako błędu polecenia tylko dlatego, że wynik był niekorzystny. Z drugiej strony nie sugeruj, że zaszła jakaś konsekwencja, jeśli stan fabuły faktycznie się nie zmienił. Dzięki temu gracz rozumie, czy kontynuuje w nowej sytuacji, czy poprawia nierozpoznane polecenie.

Nieobsługiwane polecenie oznacza, że system nie potrafi przypisać wiadomości gracza do obsługiwanego działania. Gracz może wpisać „zapytaj piekarza o morele” w scenie, w której gra akceptuje tylko kilka przycisków wyboru, albo użyć nazwy nierozpoznawanej przez parser. Mówi to coś o zakresie obsługi interfejsu, a nie o jakości pomysłu gracza.

Parsery fikcji interaktywnej pokazują, dlaczego przydatna informacja zwrotna powinna być konkretna: Inform rozróżnia błędy dotyczące nierozpoznanego czasownika, niejasnego odniesienia, zbyt krótkiego polecenia i obiektu, którego nie widać. Jego podręcznik pokazuje też, jak gra może zastąpić ogólny błąd parsera bardziej informacyjnym komunikatem. (Inform 7 §18.35: Printing a parser error) W grze czatowej zwięzła odpowiedź mogłaby brzmieć: „Nie potrafię tu rozpoznać polecenia „zapytaj o morele”. Możesz zapytać o dostawę albo wybrać temat przy ladzie.”

Wskaż sposób poprawienia polecenia. Zależnie od interfejsu możesz pokazać rozpoznawane opcje, zadać jedno konkretne pytanie doprecyzowujące albo poprosić gracza o inne sformułowanie. Nie opisuj nieobsługiwanego polecenia jako niepowodzenia w świecie fikcji: jeśli żadne działanie nie zostało wykonane, powiedz to jasno. Zachowaj poprzednią scenę i wyjaśnij, że wysłanie poprawionego polecenia ponowi próbę w tej samej chwili, a nie cofnie zdarzenie fabularne.

Czasem polecenie jest zrozumiałe, ale postać nie wie wystarczająco dużo, by na nie zareagować. Gracz może zapytać pomocnika sprzedawcy, gdzie dostarczono paczkę, zanim ten zobaczył potwierdzenie odbioru. Gra może rozpoznać pytanie i jednocześnie słusznie nie udzielić jednoznacznej odpowiedzi.

To coś innego niż nieobsługiwane polecenie: temat lub działanie jest poprawne, a ograniczenie wynika z wiedzy postaci w świecie fikcji. Wyraźnie zaznacz tę granicę. Na przykład: „Mina nie widziała potwierdzenia dostawy, więc nie zna nazwy ulicy. Etykieta paczki wciąż leży na ladzie.” Jeśli gracz może sprawdzić etykietę, zapytać kogoś innego albo wrócić później, wskaż tę możliwość. Jeśli nie, powiedz, co faktycznie wiadomo, zamiast wymyślać podpowiedź lub traktować pytanie jako błędnie sformułowane.

Ustal, czy ta odpowiedź przesuwa czas lub zmienia stan. Jeśli zadanie pytania jest zwykłym działaniem w świecie fikcji, gra może odnotować tę rozmowę albo wpłynąć na późniejsze reakcje postaci. Jeśli pytania o wiedzę mają być w grze darmowe, zachowaj scenę i pozwól zadać kolejne pytanie. Gracz nie powinien zgadywać, czy prośba o informację po cichu pozbawiła go jakiejś możliwości.

Problem z dostarczeniem występuje poza światem fikcji: odpowiedź nie nadchodzi na czas, pojawia się dwukrotnie albo urywa się w połowie zdania. Gra nie może bezpiecznie twierdzić, że postać zadziałała lub fabuła posunęła się naprzód, jeśli nie wie, czy działanie zostało przetworzone. To coś innego niż komunikat ze świata fikcji, taki jak „kurier nie mógł znaleźć adresu”, który jest wynikiem fabularnym.

Używaj prostych komunikatów o stanie i podawaj to, co wiadomo. Jeśli gra może potwierdzić, że tura nie została przetworzona, powiedz to i pozwól graczowi wysłać ją ponownie. Jeśli nie może ustalić, czy tura została przetworzona, nie zachęcaj do bezrefleksyjnego ponowienia, które mogłoby wykonać działanie dwukrotnie. Krótko wyjaśnij tę niepewność i zaproponuj sposób sprawdzenia bieżącej sceny lub wznowienia od ostatniego potwierdzonego punktu. Są to zalecenia projektowe wynikające z potrzeby odróżnienia niedopasowania polecenia od wyniku fabularnego; przywołane systemy fikcji nie definiują uniwersalnego protokołu obsługi błędów dostarczenia wiadomości na czacie.

Gdy dostarczanie znów działa, przywróć ostatnią potwierdzoną wiadomość albo pokaż zwięzłe streszczenie sceny i ostatniego działania, o którym wiadomo, że zostało wykonane. Oznacz streszczenie jako streszczenie, a nie nową turę fabularną. Jeśli gracz zdecyduje się wysłać polecenie ponownie, wyjaśnij, czy będzie to potraktowane jako nowa próba. Taka drobna przejrzystość zapobiega pomyleniu powtórzonego działania z celowym ponowieniem.

Te słowa opisują różne skutki dla stanu gry, więc nie używaj ich zamiennie. Ponowienie próby wysyła działanie jeszcze raz w bieżącym stanie; nie powinno po cichu wymazywać utrwalonej konsekwencji. Cofnięcie przywraca wcześniejszy stan. Wznowienie kontynuuje grę od ostatniego potwierdzonego stanu po przerwaniu. Restart rozpoczyna historię od początku.

Podręcznik Harlowe dla Twine opisuje cofnięcie jako powrót do poprzedniego fragmentu i usunięcie zmian zmiennych wprowadzonych w bieżącym fragmencie; restart opisuje jako ponowne wczytanie strony i rozpoczęcie historii od nowa. Zwraca też uwagę, że historia cofania może być ograniczona. Te mechanizmy pokazują, dlaczego kontrolka powinna jasno komunikować swój zakres, zamiast polegać na nieprecyzyjnej etykiecie „spróbuj ponownie”. (Harlowe 3.3.8 Manual: undo and restart)

Zwięzła sekwencja decyzji pomaga zachować spójność interfejsu:

Czy gra zrozumiała i rozstrzygnęła działanie? Jeśli tak, podaj wynik w świecie fikcji i opisz, jaki stan pozostał.

Czy system nie potrafił przypisać sformułowania do obsługiwanego działania? Wyjaśnij, czego nie rozpoznał, i wskaż sposób poprawienia polecenia; zachowaj scenę.

Czy działanie zostało zrozumiane, ale postaci brakuje informacji? Wyjaśnij granice jej wiedzy i wskaż dostępne sposoby zdobycia informacji w świecie fikcji.

Czy nie wiadomo, czy przetwarzanie lub dostarczenie się powiodło? Powiedz, co jest potwierdzone, a potem zaproponuj bezpieczny sposób sprawdzenia stanu lub kontynuowania.

Jeśli gracz chce się cofnąć, nazwij kontrolkę „Cofnij” i określ, jaki moment lub jakie zmiany przywraca. Etykietę „Restart” zarezerwuj na rozpoczęcie gry od początku.

Przed wysłaniem odpowiedzi sprawdź ją pod kątem zgodności ze stanem fabuły. Jeśli opisuje niepowodzenie, czy świat rzeczywiście się zmienił? Jeśli dotyczy nieobsługiwanego polecenia, czy gra nie udaje, że działanie miało miejsce? Jeśli postaci brakuje wiedzy, czy odpowiedź odróżnia to od nierozpoznanego polecenia? Jeśli wystąpił problem z dostarczeniem, czy gracz wie, czy tura została przetworzona? Na koniec: czy kontrolka ponowienia próby lub wznowienia działa zgodnie z obietnicą zawartą w etykiecie?

Gra tekstowa wydaje się sprawiedliwa, gdy informacja zwrotna pomaga graczowi odróżnić to, czego doświadczyła postać, od tego, czego nie potrafił zrobić interfejs. Jasno opisane konsekwencje zachowują spójność historii; konkretne wskazówki dotyczące poleceń umożliwiają kolejną próbę; uczciwie zaznaczone granice wiedzy utrzymują spójność fikcji; a określona ścieżka odzyskiwania stanu daje graczowi niezawodny sposób na dalszą grę.