Jak testować rozgałęziające się historie w grach
Gdy rozgałęziająca się fabuła się rozrasta, testuj decyzje i zmiany stanu, które sprawiają, że ścieżki zachowują się inaczej, zamiast tworzyć osobny skrypt testowy od początku do końca dla każdej możliwej trasy. Przedstaw narrację jako graf, określ warunki i skutki każdej decyzji, a następnie zbuduj niewielki zestaw testów obejmujący krytyczne przejścia, punkty ponownego połączenia i sytuacje błędne. Następnie próbkuj trasy na podstawie ryzyka i przeprowadzaj testy z udziałem graczy, aby wychwycić problemy, których nie da się ocenić za pomocą ustrukturyzowanych kontroli. Dzięki temu projektanci narracji i zespoły QA zyskują powtarzalny sposób wykrywania usterek bez twierdzenia, że przetestowano wszystkie ścieżki.
Zacznij od grafu, który odzwierciedla zachowanie
Każdy grywalny fragment lub scenę przedstaw jako węzeł, a każdy wybór jako skierowaną krawędź. Opisz krawędzie ich warunkami i skutkami: na przykład has_key = true umożliwia „Odblokuj bramę”, co ustawia gate_open = true. Wyraźnie oznacz zakończenia, pętle i punkty ponownego połączenia. Punkt ponownego połączenia to miejsce, w którym spotykają się różne trasy; warto sprawdzić, czy fabuła może być dalej kontynuowana po wielu różnych historiach bez przenoszenia niezamierzonego stanu.
Graf powinien odzwierciedlać to, co faktycznie sprawdza gra, a nie tylko strukturę tekstu. Zapisz, które zmienne odczytuje dany wybór, które zmienia i od których zależą późniejsze węzły. Uwzględnij wartości domyślne, zasady resetowania i wszelkie efekty jednorazowe. Jeśli flaga zostanie ustawiona w jednej gałęzi i nigdy nie jest kasowana, może to być zamierzone; udokumentowanie tego sprawia, że konsekwencja staje się widoczna podczas przeglądu i testowania.
Taka struktura pomaga też znaleźć punkty decyzyjne, które łatwo przeoczyć w długim skrypcie. Artykuł Alexeya Tikhonova z 2024 roku dotyczy wykrywania punktów decyzyjnych postaci w rozgałęziających się narracjach i proponuje zbiór danych oparty na grafach gier z serii Choose Your Own Adventure. Opisane zadanie dotyczy identyfikacji narracyjnych punktów decyzyjnych, a nie walidacji metody QA; może pomóc zespołom sporządzać wykaz wyborów, ale nie dowodzi skuteczności opisanej tu metody testowania. Tikhonov, „Branching Narratives: Character Decision Points Detection”
Testuj przejścia między stanami, a nie tylko odwiedzanie scen
Test potwierdzający wyświetlenie węzła może nie wykryć błędnego działania wyboru. Dla każdego ważnego wyboru sprawdź trzy rzeczy: czy wybór jest dostępny przy założonym warunku, czy jego wybranie powoduje oczekiwaną zmianę stanu oraz czy następny węzeł i widoczny wynik odpowiadają temu stanowi. Takie kontrole traktują fabułę jako system przejść między stanami: dla danego stanu początkowego i działania weryfikują stan wynikowy i miejsce docelowe.
Na przykład test wyboru „Pokaż mapę” może sprawdzać, czy mapa została pokazana, czy trust pozostało bez zmian i czy trasa prowadzi do wspólnej sceny w obserwatorium. Powiązany test rozpoczyna się od has_map = false i sprawdza, czy ten wybór jest niedostępny lub prowadzi do określonej alternatywy. Dokładne oczekiwane zachowanie zależy od specyfikacji narracji; ważne jest, by określić je wprost, zamiast wnioskować o poprawności na podstawie tytułu fragmentu.
W punktach ponownego połączenia sprawdzaj nie tylko samo dotarcie. Porównaj stan, który każda trasa powinna zachować, zmienić lub wyzerować. Strażnik przekonany w jednej gałęzi może pozostać sojusznikiem po ponownym połączeniu, podczas gdy tymczasowe przebranie powinno przestać działać. Uwzględnij te zasady w oczekiwanym stanie po ponownym połączeniu. Jeśli trasy mają się całkowicie zbiegać, sprawdzaj wspólny stan; jeśli powinny zachować istotne różnice, sprawdzaj także te różnice.
Użyj fikcyjnego przykładu, aby pokazać zakres testów
Załóżmy, że w krótkiej historii detektywistycznej gracz podejmuje decyzję w archiwum. Może poprosić o pomoc, zakraść się do środka albo użyć pożyczonego klucza; każda z tych tras prowadzi do tego samego korytarza, a późniejszy wybór decyduje, czy gracz zabierze zapieczętowany list. Poniższa fikcyjna macierz przedstawia niewielki zestaw wymagań testowych. „Objęte testem” oznacza, że zaplanowano test konkretnego wymagania, a nie że sprawdzono całą trasę lub każdą kombinację.
A: trust = high; poproś archiwistę o pomoc. Opcja pomocy jest widoczna; trust pozostaje wysokie; trasa prowadzi do korytarza. Dostępność wyboru i przejście
B: trust = low; poproś o pomoc. Opcja pomocy jest ukryta lub następuje odmowa, zgodnie ze specyfikacją. Warunek negatywny
C: has_key = true; odblokuj boczne drzwi. Drzwi się otwierają; trasa prowadzi do korytarza; klucz zostaje zużyty tylko wtedy, gdy tak określono. Efekt stanu i ponowne połączenie
D: has_key = false; spróbuj otworzyć boczne drzwi. Nie da się ich otworzyć; flaga powodzenia nie zostaje ustawiona. Negatywne stwierdzenie
E: Z korytarza zabierz zapieczętowany list. has_letter = true; w późniejszej scenie z dowodami pojawia się kwestia dotycząca listu. Późniejszy skutek
F: Z korytarza zostaw list. has_letter = false; kwestia dotycząca listu się nie pojawia. Kontrast wyników i negatywne stwierdzenie
To narzędzie wspomagające podejmowanie decyzji, a nie procentowy wynik pokrycia testami ani uniwersalny minimalny zestaw testów. Ułatwia dostrzeżenie braków: w tym przypadku bramka zależna od niskiego poziomu zaufania oraz wynik „listu nie ma” zasługują na osobne kontrole, ponieważ przejście ścieżki pozytywnej ich nie zweryfikuje. Każdy wiersz powinien wskazywać odpowiedni węzeł lub przejście w grafie, aby można było prześledzić, na które testy wpłynęła zmiana warunku.
Przy wielu kombinacjach nadaj priorytet pokryciu gałęzi
Jeśli historia ma wiele niezależnych flag, liczba możliwych kombinacji może szybko rosnąć. Nie odpowiadaj na to, wypisując każdą teoretyczną trasę jako obowiązkową rozgrywkę od początku do końca. Najpierw zidentyfikuj krawędzie wysokiego ryzyka: wybory, które odblokowują zakończenia, zużywają przedmioty, zapisują trwałe informacje o relacjach albo łączą różne historie. Testuj bezpośrednio te przejścia i ich ważne późniejsze skutki.
Następnie celowo próbkuj kombinacje. Uwzględnij warunki brzegowe (minimalną wartość zmieniającą dostępność wyboru), obie strony każdego krytycznego warunku, reprezentatywne kombinacje flag, które mogą na siebie wpływać, oraz trasy docierające do punktu ponownego połączenia po różnych historiach. Priorytetowo traktuj ostatnie zmiany i ścieżki o złożonych warunkach wstępnych. Gdy dwie zmienne mogą na siebie wpływać, dodaj test tej pary zamiast zakładać, że osobne kontrole każdej zmiennej dowodzą poprawnego działania kombinacji.
Zapisz jednostkę pokrycia i jego ograniczenia. Zespół może śledzić, czy przetestowano każdą krytyczną krawędź wyboru, czy w razie potrzeby sprawdzono każdy warunek zarówno dla wartości prawdziwej, jak i fałszywej oraz czy każdy warunek zakończenia został osiągnięty przez co najmniej jeden zaplanowany test. To przydatne raporty z wykonanych próbek; żaden z nich nie dowodzi, że sprawdzono każdą możliwą historię, kombinację stanów ani problem z brzmieniem tekstu.
Badania nad testowaniem gier z udziałem graczy mogą dostarczyć powiązanej, ale ograniczonej wskazówki. Artykuł Gordilla i współautorów z 2021 roku opublikowany w arXiv opisuje agentów uczenia przez wzmacnianie, nagradzanych za nowe działania, w celu eksploracji pokrycia stanów w złożonym scenariuszu 3D. Praca dotyczy eksploracji środowiska gry 3D, a nie wyborów w rozgałęziającej się narracji ani opisanej tu konkretnej metody testowania przejść. Uzasadnia traktowanie automatycznej eksploracji jako możliwego uzupełnienia, ale ani to badanie, ani artykuł Tikhonova nie walidują dokładnie tej metody testowania narracji. Gordillo i in., „Improving Playtesting Coverage via Curiosity Driven Reinforcement Learning Agents”
Dodaj negatywne stwierdzenia i testy z udziałem graczy
Pozytywne stwierdzenia potwierdzają, że oczekiwany wybór lub wynik istnieje. Negatywne stwierdzenia potwierdzają, że nie dzieje się coś, co nie powinno się wydarzyć: zablokowana opcja się nie pojawia, zużyta wskazówka nie zostaje przyznana ponownie, nieobecny list nie wywołuje związanej z nim kwestii, a nieudana próba nie ustawia flagi powodzenia. Kontrole negatywne są szczególnie pomocne w pobliżu wspólnych węzłów, gdzie nieaktualny stan z innej trasy może przedostać się do bieżącej sceny.
Testy automatyczne mogą weryfikować logikę trasy i dokładne zmiany stanu, ale nie oceniają niezawodnie, czy przejście jest spójne, czy kwestia nie przeczy temu, co gracz pamięta, ani czy wybór jest zrozumiały w danym kontekście. Dlatego w testach z udziałem graczy należy wybrać konkretne trasy i określić ich cel: poprosić testerów o przejście rzadziej wybieraną gałęzią, dotarcie do punktu ponownego połączenia z określoną historią albo próbę osiągnięcia zakończenia bez kluczowego przedmiotu. Obserwuj zarówno wynikowy stan, jak i interpretację gracza.
Notatki z testów z udziałem graczy powiąż z identyfikatorami węzłów i wyborów, a także ze stanem początkowym i wykonanymi krokami. Dzięki temu zgłoszony problem można odtworzyć i łatwiej odróżnić zastrzeżenie do tekstu od usterki logicznej. Po poprawce ponownie uruchom testy dotyczące danego przejścia oraz co najmniej jedną reprezentatywną trasę przez zmieniony punkt ponownego połączenia lub wynik.
Praktyczny cykl testowania zmieniającej się historii
Przy każdej aktualizacji historii wyeksportuj lub przejrzyj graf, wskaż zmienione węzły, warunki, skutki i punkty ponownego połączenia, a następnie zaktualizuj macierz pokrycia. Najpierw uruchom ukierunkowane testy przejść między stanami, a potem wybrane próbki tras i testy z udziałem graczy dla sekcji o dużym wpływie lub ostatnio zmienionych. Gdy pojawi się błąd, zapisz stan początkowy i sekwencję wyborów, aby zespół mógł go odtworzyć, poprawić odpowiednią regułę lub fragment i zachować przypadek jako test regresji.
Celem jest udokumentowanie, co sprawdzono i dlaczego, w sposób umożliwiający testowanie. Graf pozwala przejrzeć strukturę, testy przejść jasno określają logikę, próbkowanie gałęzi kieruje wysiłek na istotne różnice, negatywne stwierdzenia wychwytują przeciekający stan, a testy z udziałem graczy oceniają interpretację. Łącznie zapewniają użyteczne pokrycie w miarę przybywania ścieżek i jasno pokazują granice tego, co pozostaje nieprzetestowane.