Jakie decyzje gracza powinny pamiętać postacie w grach?

Decyzja zasługuje na miejsce we wspomnieniach postaci, gdy jej przywołanie zmienia obecną scenę. Zanim zapiszesz wybór, zapytaj: Co ta postać może zrobić, powiedzieć, ujawnić, czemu odmówić lub co zaoferować inaczej dzięki temu wyborowi? Jeśli odpowiedź brzmi „nic”, te informacje mogą należeć do dziennika zadań albo rejestru stanu świata lub w ogóle nie muszą być zachowywane.

Praktyczny sprawdzian polega na tym, by najpierw napisać późniejszy moment sceny. Na przykład: „Przy punkcie kontrolnym strażnik powierza graczowi zapieczętowany rejestr, bo wcześniej gracz zwrócił mu odznakę”. Jeśli ten moment zależy od zapamiętanej decyzji, zapisz istotny fakt. Jeśli strażnik zachowuje się tak samo w obu przypadkach, wspomnienie może być ozdobnikiem, a nie elementem dramaturgii.

Przydatne wspomnienia często należą do trzech nakładających się kategorii:

Zobowiązania i koszty: gracz coś obiecał, odrzucił, poświęcił, zwrócił lub ochronił, a wynik może mieć później znaczenie.

Ujawnione priorytety: przy wyborze ograniczającym możliwości to, co gracz postanowił chronić lub ryzykować, pomaga postaci zinterpretować późniejszą ofertę. Traktuj to jako wskazówkę wynikającą z konkretnego wyboru, a nie trwałą diagnozę gracza.

Nierozstrzygnięte konsekwencje: wybór pozostawił osobę, przedmiot lub zobowiązanie w zmienionym stanie. Wspomnienie ma znaczenie, gdy postać później zetknie się z tym stanem lub zdecyduje, co z nim zrobić.

To wskazówki projektowe, a nie twierdzenie, że każda gra potrzebuje trwałej pamięci postaci. Ich wartość zależy od tego, czy późniejsza scena nada zapamiętanemu wydarzeniu czytelne konsekwencje.

Rzetelny system narracyjny rozróżnia wydarzenie od wiedzy każdej postaci o nim. Gracz może potajemnie ukryć klucz (stan świata); towarzysz może zobaczyć, gdzie go schowano (wspomnienie postaci); sklepikarz może usłyszeć nieścisłą relację (plotka). Połączenie tych informacji w jedną flagę może sprawić, że postacie będą wyglądały na wszechwiedzące albo że pogłoska zabrzmi jak dowód.

Dla każdego wydarzenia o istotnych konsekwencjach zapisuj tyle informacji o jego pochodzeniu, by odpowiedzieć na cztery pytania:

Wydarzenie: Co stało się w świecie?. Gracz zwrócił mosiężny klucz.

Świadek: Kto widział lub słyszał to bezpośrednio?. Mara obserwowała przekazanie klucza.

Kanał: Jak dowiedziała się o tym reszta?. Przewoźnik usłyszał o tym od Mary.

Pewność: Jak wiarygodna jest ta informacja?. Zaobserwowana; przekazana; zakwestionowana.

Zwięzły zapis projektowy mógłby wyglądać tak: returned_key = true; Mara.knows_returned_key = witnessed; Ferryman.knows_returned_key = reported_by_Mara. To przykładowe pola, a nie narzucony format techniczny. Najważniejsze jest to, że fakt ze świata nie staje się automatycznie wiedzą każdej postaci.

Ten podział daje autorowi więcej możliwości w scenach. Mara może wspomnieć o przekazaniu klucza jako o czymś, co widziała. Przewoźnik może powtórzyć tę informację z niepewnością, zapytać, czy to prawda, albo zareagować na błędną wersję. Jeśli gracz ukrył klucz, a nikt tego nie widział ani nie odkrył kryjówki, postać musi mieć wiarygodny sposób, by się o tym dowiedzieć.

Rozważ fikcyjną scenę, w której gracz znajduje uszkodzoną latarnię sygnałową, a za zamkniętą bramą czeka kurier imieniem Iven. Gracz ma trzy możliwości:

Oddać Ivenowi jedyną działającą manierkę z oliwą. Sygnał pozostaje niewysłany, a Iven ucieka i później może dostarczyć wiadomość.

Wykorzystać oliwę, by zapalić sygnał. Patrol dostrzega ostrzeżenie, ale Iven pozostaje za bramą, dopóki nie nadejdzie pomoc.

Zachować oliwę i odejść. Gracz zachowuje zasób; bezpośredni los Ivena zależy od reguł ustalonych w scenie, a nieobecności gracza nie należy przedstawiać jako działania, którego ktoś był świadkiem.

Teraz ustal, kto co wie. Jeśli Iven widzi, jak gracz oddaje manierkę, pamięta, że otrzymał pomoc. Jeśli widzi, jak gracz zapala sygnał, może pamiętać, że gracz postanowił wezwać pomoc, a zarazem pamiętać, że musiał czekać za bramą. Jeśli gracz odchodzi niezauważony, Iven nie może zgodnie z prawdą wspominać, że widział, jak gracz odchodzi; inna postać może później donieść o zgaszonej latarni albo brakującej oliwie, ale te wskazówki nie dowodzą, kto co zabrał.

Późniejsza scena może pokazać te różnice przez działanie, zamiast streszczać wydarzenia. Po otrzymaniu oliwy Iven może powierzyć graczowi wiadomość, po oczekiwaniu na pomoc może poprosić o wyjaśnienie albo nie przypisywać graczowi zabrania oliwy, jeśli nie widział jego odejścia. To możliwe skutki w tym przykładzie, a nie uniwersalne reakcje emocjonalne. Scena musi wyjaśniać, dlaczego Iven reaguje w ten sposób, a inne wydarzenia mogą komplikować jego reakcję.

Zapisuj konkretne wspomnienia: „Iven widział, jak gracz oddaje mu manierkę z oliwą” jest przydatniejsze niż „Iven ufa graczowi”. Pierwszy zapis odnotowuje wydarzenie i jego źródło; drugi zamienia jedno wydarzenie w ogólną ocenę relacji. Jeśli zaufanie jest zmienną w grze, określ regułę, która je aktualizuje, oraz późniejsze zachowania, na które może wpływać. Zapamiętane wydarzenie może kształtować relację, ale nie musi automatycznie o niej przesądzać.

Nie każdy zapamiętany szczegół powinien na zawsze pozostawać równie wyrazisty. Dostosuj czas przechowywania do funkcji fabularnej: zachowaj wspomnienie, dopóki odblokowuje zaplanowaną scenę, pomaga rozwiązać zobowiązanie lub stanowi podstawę późniejszego nawiązania; pozwól, by szczegóły o niewielkich konsekwencjach zanikły, gdy przestaną wpływać na rozgrywkę. „Wygaśnięcie” nie musi oznaczać, że postać zapomni o wydarzeniu zmieniającym życie po upływie określonego czasu. Może oznaczać, że po jednorazowym użyciu gra przestaje uwzględniać drobny fakt w dialogach.

Korekta jest ważna, gdy wspomnienie pochodzi z plotki, niepełnej obserwacji lub mylnego pierwszego wrażenia. Postać, która usłyszała, że gracz zabrał oliwę z latarni, może się dowiedzieć, że gracz oddał ją Ivenowi. Zdecyduj, co dzieje się dalej: czy flaga plotki zostaje skorygowana, czy postać zachowuje zarówno pierwotną relację, jak i korektę, czy też nie daje się przekonać? Odpowiedź zależy od opowieści, ale korekta nie powinna po cichu zmieniać tego, co postać wcześniej usłyszała.

Przydatny wpis pamięci może zawierać status, taki jak current, disputed lub corrected, oraz źródło aktualizacji. Pomaga to uniknąć powtarzania w późniejszej kwestii obalonej plotki jako faktu. Jeśli dwóch świadków się nie zgadza, zachowaj tę rozbieżność tam, gdzie ma znaczenie, zamiast narzucać w dialogach wszystkich postaci jedną wszechwiedzącą prawdę.

Wspomnienie postaci powinno wiązać się z możliwą reakcją. Określ warunki tej reakcji i jej efekt: co musiało się wydarzyć, kto musi o tym wiedzieć i co zmienia się w późniejszej scenie? Taka struktura ułatwia testowanie pamięci i zapobiega zapisywaniu wyboru, który nigdy nie wpływa na grę.

Jest to zgodne z ograniczoną, istotną ideą opisaną w STORY2GAME: artykuł opisuje generowanie działań w fikcji interaktywnej za pomocą warunków wstępnych i efektów, które pomagają ustalić, jakie elementy stanu gry należy śledzić i jak działania ten stan zmieniają. Publikacja skupia się na generowaniu działań i stanu gry, a jej ocena dotyczy tego, czy wygenerowany kod działań umożliwia rozgrywanie wygenerowanych opowieści. Nie jest to badanie dowodzące, że zapamiętane wybory poprawiają napisaną przez autora narrację lub wrażenia gracza. Dla autorów przydatne zastosowanie jest węższe: określ warunek, pod którym zapamiętane wydarzenie ma znaczenie, oraz konkretny skutek, gdy do tego dochodzi.

Artykuł StratMem-Bench w ACL Anthology ocenia, jak wirtualne postacie wykorzystują wspomnienia w rozmowach skupionych na postaciach. Benchmark uwzględnia wspomnienia niezbędne, pomocne i nieistotne, a wyniki wskazują, że modele lepiej radziły sobie z rozróżnianiem wspomnień niezbędnych od nieistotnych niż w przypadkach, gdy pomocne wspomnienia komplikowały decyzję. Jest to benchmark rozmów z wirtualnymi postaciami, a nie badanie wyników narracji w grach. Nie ustala, które wybory autorzy gier powinni zapisywać; przypomina jednak, by rozważyć, czy wspomnienie jest niezbędne, jedynie pomocne czy nieistotne dla obecnej sceny.

Testuj wybór w chwili, gdy zostaje podjęty, a następnie przy każdym zaplanowanym późniejszym skutku. Krótki przegląd QA może wychwycić większość błędów ciągłości:

Sprawdzenie świadków: Przy każdej kwestii odnoszącej się do decyzji upewnij się, że mówiąca postać była jej świadkiem albo potrafi wskazać wiarygodne źródło informacji.

Sprawdzenie rozgałęzień: Przejdź każdą ścieżkę wyboru i upewnij się, że ustawia właściwe zapisy wydarzeń i wiedzy. Sprawdź, czy wykluczające się wyniki nie pozostają aktywne jednocześnie.

Sprawdzenie skutków: Upewnij się, że każde zapisane wspomnienie zmienia dostępną kwestię, reakcję w relacji, warunek sceny lub działanie. Jeśli niczego nie zmienia, zastanów się, czy trzeba je zachowywać.

Sprawdzenie plotek: Zweryfikuj, czy informacje z drugiej ręki są przedstawione z właściwym stopniem niepewności oraz czy korekta konsekwentnie aktualizuje późniejsze sceny.

Sprawdzenie wygaśnięcia: Wróć do sceny po zaplanowanym wykorzystaniu wspomnienia. Upewnij się, że informacje o niskim priorytecie mogą przestać się pojawiać, a istotne, nierozwiązane konsekwencje pozostają dostępne.

Sprawdzenie braku wiedzy: Sprawdź, jak postać zachowuje się, gdy nikt nie widział wydarzenia, nikt o nim nie doniósł albo zostało celowo ukryte. Brak flagi nie powinien domyślnie oznaczać wiedzy.

Końcowe pytanie projektowe jest proste: czy zapamiętanie tego wyboru daje postaci powód, by teraz zachować się inaczej, i czy gracz rozumie dlaczego? Gdy odpowiedź jest jasna, niewielka liczba dobrze udokumentowanych wspomnień może mieć większą siłę dramaturgiczną niż zapis każdej interakcji.