Kiedy gra powinna oferować wybór po wielokrotnym niezrozumieniu polecenia gracza?

Jednorazowe doprecyzowanie jest przydatne, gdy gra rozumie większość działania, ale nie potrafi ustalić, o który obiekt chodzi graczowi: „Masz na myśli mosiężny klucz czy srebrny klucz?”. Wielokrotne nierozpoznawanie tekstu to inny problem. System może nie wiedzieć, co gracz próbuje zrobić, albo jego słownik może nie zawierać użytych przez gracza słów. Powtarzanie „Spróbuj inaczej” zmusza gracza do zgadywania ukrytych zasad parsera.

Badania nad interfejsami dialogowymi w grach opisują ten dylemat: swobodny język może umożliwiać szerszy zakres odpowiedzi, ale system może nie rozpoznać intencji gracza; stałe menu odpowiedzi łatwiej zinterpretować, lecz ogranicza ono dostępne sposoby wyrażania się. Te ustalenia przemawiają za użyciem menu wyboru jako ścieżki awaryjnej, a nie jako domyślnego zamiennika swobodnego wpisywania tekstu. „Playing with words: from intuition to evaluation of game dialogue interfaces”

Praktycznym wyzwalaczem mogą być dwie kolejne nierozpoznane próby dotyczące tej samej sceny lub działania. To zalecenie projektowe, a nie uniwersalny próg ustalony w przywołanych badaniach. Ważne, by wyzwalacz był przewidywalny, powiązany z bieżącym zadaniem i uruchamiał się, zanim gra wciągnie gracza w długą pętlę. Inny próg może być potrzebny, jeśli metoda wprowadzania tekstu jest szczególnie podatna na błędy albo eksperymentowanie w scenie stanowi część rozgrywki; należy świadomie go ustalić i przetestować wynikającą z niego interakcję.

Gdy pojawi się opcja awaryjna, zachowaj ostatnio wpisany tekst w polu wprowadzania, dzienniku lub innym widocznym miejscu. Jeśli gra go usunie, gracz może być zmuszony odtworzyć już sformułowane działanie. Wyświetlenie wpisanej frazy pomaga też wyjaśnić, że gra otrzymała tekst, ale nie przypisała go do obsługiwanego działania.

Komunikat awaryjny może potwierdzać próbę, nie obwiniając gracza: „Nie udało mi się dopasować polecenia „podnieś kratę hakiem” do żadnego działania w tej scenie”. Jeśli gra rozpoznała prawdopodobny element działania, powiedz, co udało się ustalić: „Znalazłem kratę, ale nie wiem, co chcesz z nią zrobić”. Nie sugeruj, że system rozumie więcej, niż faktycznie rozumie. Takie sformułowanie odróżnia nierozpoznane polecenie od rozpoznanego celu, dla którego nie ustalono działania.

W objaśnieniu kryterium Error Suggestion W3C stwierdza, że gdy dane wejściowe zostają odrzucone, a znana jest użyteczna korekta, system powinien ją zaproponować. Przykłady obejmują pokazanie akceptowanych wartości lub prawdopodobnych poprawek. Wytyczne dotyczą treści internetowych, a nie dialogów w grach, więc ich zastosowanie w grze jest świadomą adaptacją projektową. Przydatna jest wspólna zasada: podaj konkretny następny krok, jeśli system może to zrobić. W3C, „Understanding Success Criterion 3.3.3: Error Suggestion”

Menu awaryjne powinno zawierać kilka opracowanych działań dostępnych w bieżącej scenie. Na przykład, jeśli gracz stoi przed zamkniętą bramą, opcje mogą brzmieć: „Obejrzyj zamek”, „Użyj klucza” i „Odejdź”. To przykładowe opcje, a nie twierdzenia o konkretnej grze. Powinny opisywać różne działania, używać jasnych czasowników i nie kierować gracza do rozgałęzień, których gra obecnie nie obsługuje.

Dopasuj opcje do sceny i jej stanu. Ogólne menu, takie jak „Eksploruj”, „Rozmawiaj” i „Użyj przedmiotu”, może być mniej pomocne, gdy przeszkodą jest konkretny obiekt. Z kolei bardzo szczegółowa opcja powinna pojawiać się tylko wtedy, gdy spełnione są jej warunki. Jeśli gracz nie ma klucza w ekwipunku, nie proponuj „Użyj klucza”. Menu oferujące niemożliwe działania zastępuje jeden rodzaj dezorientacji innym.

Badania nad dialogami w grach pokazują również, że styl menu wpływa na wrażenia: pełne zdania mogą ułatwiać zrozumienie, co powie postać, a abstrakcyjne etykiety mogą sprawiać, że interakcja bardziej przypomina strategiczne sterowanie. Odpowiedni poziom szczegółowości zależy od działania i jego konsekwencji. Użyj krótkiej etykiety przy prostym działaniu; wyjaśnij więcej, gdy wybór może zmienić scenę lub przesądzić o istotnej reakcji gracza. „Playing with words: from intuition to evaluation of game dialogue interfaces”

Menu powinno umożliwiać kontynuowanie gry, a nie po cichu wyłączać swobodne wpisywanie tekstu. Dodaj widoczną opcję, taką jak „Pisz dalej” lub „Wróć do swobodnego wpisywania”, i poinformuj, że gracz może z niej skorzystać. Jeśli gra przyjmuje swobodny tekst, gdy wyświetlają się opcje, jasno to zaznacz; jeśli wybranie opcji zamyka menu, również o tym poinformuj.

Używaj etykiet opisujących działanie na przyciskach i w opcjach. W3C Design System zaleca, by tekst na przycisku nazywał działanie użytkownika zamiast stosować ogólną etykietę, taką jak „Prześlij”. W grze „Obejrzyj zamek” lub „Pisz dalej” przekazuje więcej informacji niż „Kontynuuj”. Konkretne zalecenia dotyczące interfejsu pochodzą z formularzy internetowych, ale zasada jasnego nazywania działania łatwo przekłada się na sterowanie w grze. W3C Design System, „Forms”

Zadbaj o spójny sposób wyjścia. Jeśli w jednym menu awaryjnym pojawia się opcja „Pisz dalej”, a w innym „Anuluj”, gracze mogą nie wiedzieć, czy obie zachowują ten sam stan. Jeśli wyjście z menu spowoduje usunięcie tekstu, ostrzeż przed jego skasowaniem. Jeśli gracz może wybierać opcje za pomocą klawiatury, kontrolera, ekranu dotykowego lub innej obsługiwanej metody, upewnij się, że da się do nich dotrzeć i je aktywować przy użyciu standardowego sterowania w grze.

Po wyświetleniu menu nie wracaj od razu do tego samego komunikatu „Nie zrozumiałem; spróbuj ponownie”, gdy gracz wpisze kolejne nieobsługiwane polecenie. To tylko odtwarza schemat niepowodzenia. Zamiast tego zachowaj nową próbę i pozostaw dostępne zaproponowane opcje albo podaj bardziej szczegółową wskazówkę, jeśli parser ma wystarczająco dużo informacji. Pozwól graczowi wybrać opracowane działanie, zmienić tekst i wysłać go ponownie albo opuścić interakcję, jeśli pozwala na to scena.

Wytyczne Microsoft dotyczące awaryjnych odpowiedzi w rozmowie zalecają zaprojektowanie sekwencji takich odpowiedzi, unikanie powtarzania identycznych przeprosin oraz zachowanie miejsca, w którym dana osoba przerwała, gdy system przekierowuje ją dalej. Wytyczne dotyczą produktów konwersacyjnych, więc dokładne wskazówki o przekazywaniu rozmowy nie muszą mieć zastosowania w grze. Można jednak wykorzystać zasadę, by każdy krok naprawczy był przydatny i nie zmuszał gracza do ponownego wykonywania już wykonanej pracy. Microsoft Learn, „Design graceful fallbacks and handoffs”

Prosta sekwencja odzyskiwania może wyglądać tak:

Pierwsze nieobsługiwane polecenie: poinformuj, że działanie nie zostało rozpoznane; zachowaj tekst i podaj krótką wskazówkę związaną ze sceną, jeśli jest dostępna.

Drugie nieobsługiwane polecenie: wyświetl małe menu poprawnych, opracowanych działań obok zachowanego tekstu.

Z poziomu menu: pozwól graczowi wybrać działanie, edytować tekst i wysłać go ponownie albo opuścić interakcję, jeśli gra na to pozwala.

Jeśli kolejne polecenie nadal nie jest obsługiwane: pozostaw dostępne opcje naprawcze i wyjaśnij, jakie działania są możliwe, zamiast ponownie wyświetlać ten sam komunikat z prośbą o przeformułowanie.

Przetestuj sekwencję na wiarygodnych poleceniach, które różnią się od sformułowań preferowanych przez projektantów: synonimach, krótkich poleceniach, nazwach obiektów i dłuższych opisach. Sprawdź, czy gra zachowuje wpisany tekst po każdej porażce, pokazuje opcje dostępne w bieżącej scenie i pozwala wrócić do pisania bez utraty miejsca. Przetestuj również, co się dzieje, gdy opcja przestaje być poprawna, bo stan sceny zmienia się przed jej wybraniem.

Przy każdym teście zadaj konkretne pytanie: czy po nieudanej próbie gracz potrafi stwierdzić, czego gra nie zrozumiała? Czy widzi przydatne następne działanie? Czy może nadal realizować swój pierwotny pomysł bez konieczności wybierania opcji z menu? Jeśli odpowiedź na którekolwiek z tych pytań brzmi „nie”, popraw komunikat, zestaw opcji lub sposób powrotu. To proponowana lista kontrolna do oceny, oparta na przedstawionych wyżej zasadach interakcji; nie są to wyniki opublikowanego badania z udziałem użytkowników.

Celem jest ograniczona do kilku kroków procedura naprawcza: potwierdź, że wpisane polecenie nie jest obsługiwane, zachowaj je, po powtarzających się niepowodzeniach zaproponuj pasujące opcje i wyraźnie umożliwiaj dalsze swobodne wpisywanie tekstu. Menu powinno ograniczać zgadywanie, pozostawiając graczowi decyzję, czy z niego skorzystać.