Co naprawdę może wiedzieć asystent AI zaginionej postaci w grze detektywistycznej?

Zacznij od kompletnego zapisu fabuły przeznaczonego dla autora: wydarzeń, wypowiedzi postaci, przedmiotów, wiadomości i kolejności, w jakiej pojawiają się w grze. Następnie określ mniejszy zakres informacji dostępnych asystentowi. Fakt może znajdować się w biblii świata, a mimo to nie być jeszcze dostępny asystentowi. To podstawa uczciwej zagadki: autor może wiedzieć, co się wydarzyło, podczas gdy asystent może korzystać wyłącznie z zapisów, do których dostęp dopuszcza jego fikcyjna rola.

Narzędzia do fikcji interaktywnej, takie jak Twine, porządkują historie w passage i mogą używać zmiennych oraz logiki warunkowej, by zmieniać to, co widzi gracz. To przydatna analogia projektowa: traktuj każdy zapis autora jako osobną jednostkę, a dostęp do niego uzależnij od odpowiedniego passage, wydarzenia lub wyboru. Podstawowe pojęcia Twine

Załóżmy na przykład, że fikcyjna postać o imieniu Mara przygotowuje wystawę w ogrodzie społecznym. Asystent może mieć dostęp do udostępnionej przez nią notatki z planami, harmonogramu wywieszonego na tablicy grupy oraz późniejszej wiadomości, w której pisze, że przenosi pomalowane tabliczki do środka. Nie powinien wyciągać wniosków o tym, gdzie jest Mara, tylko na podstawie tego, że lubi ogrodnictwo, ani widzieć prywatnego szkicu, którego nigdy mu nie udostępniono. Te ograniczenia wynikają z zasad dostępu zapisanych przez autora, a nie z twierdzeń o tym, do czego mają dostęp prawdziwe systemy AI.

Przydatny zapis faktu odpowiada na co najmniej cztery pytania: co jest stwierdzane, kto lub co dostarczyło tę informację, kiedy stała się dostępna asystentowi oraz czy jest bezpośrednia, czy wywnioskowana. Model pochodzenia danych W3C opisuje źródła informacji za pomocą encji, działań i agentów; pozwala też opisywać, w jaki sposób jeden element został wyprowadzony z innego. To praktyczne ramy dla fikcyjnych zapisów, nawet jeśli gra używa prostych etykiet zamiast formalnego modelu. Wprowadzenie do modelu W3C PROV

Zwięzły zapis może wyglądać tak:

Twierdzenie: Mara planowała pomalować tabliczki ogrodowe; Źródło: udostępniona notatka z planami; Znane asystentowi od: poniedziałku, 10:00; Rodzaj: bezpośrednia wypowiedź

Twierdzenie: tabliczki przeniesiono do środka; Źródło: aktualizacja na tablicy grupy; Znane asystentowi od: wtorku, 16:30; Rodzaj: bezpośrednia aktualizacja

Twierdzenie: Mara mogła przenieść je ze względu na prognozowany deszcz; Źródło: notatka pogodowa i aktualizacja; Znane asystentowi od: wtorku, 16:30; Rodzaj: wniosek; niepotwierdzony

Podane godziny są przykładowe. Ważne jest rozróżnienie między tym, kiedy wydarzenie miało miejsce, a tym, kiedy dowiedział się o nim asystent. Jeśli notatka utworzona w poniedziałek zostanie udostępniona we wtorek, wiedza asystenta zaczyna się we wtorek, chyba że fabuła wyraźnie zapewnia mu wcześniejszy dostęp. Gdy te czasy się różnią, zachowaj oba znaczniki czasu.

Samo źródło nie sprawia, że jego treść jest pewna. Postać może opisywać to, co widziała; notatka może być niekompletna; harmonogram może odnotowywać plan, a nie działanie, które rzeczywiście miało miejsce. Oznaczenie rodzaju zapisu pomaga asystentowi odpowiednio sformułować odpowiedź: „Na tablicy jest napisane, że tabliczki przeniesiono” to co innego niż „Mara przeniosła tabliczki”, a oba stwierdzenia różnią się od „Prawdopodobnie przeniosła je z powodu pogody”.

Używaj konsekwentnie niewielkiego zestawu kategorii: bezpośrednia obserwacja, relacja postaci, zapis autora i wniosek. Wniosek powinien wskazywać zapisy, na których się opiera, i pozostawać oznaczony jako wniosek. W3C PROV jawnie modeluje odpowiedzialność agentów za działania oraz wyprowadzanie jednej encji z drugiej; zastosowanie tego rozróżnienia w dialogach pomaga grze pokazać, skąd pochodzi konkluzja, zamiast przedstawiać ją jako nowy fakt. PROV-O W3C

To daje też autorowi przydatny test: czy gracz potrafi powiązać stanowcze stwierdzenie asystenta z zapisem, do którego miał on dostęp? Jeśli nie, popraw odpowiedź, dodaj brakujący zapis fabularny albo każ asystentowi powiedzieć, że nie ma wystarczających informacji.

Dla każdego zapisu określ wydarzenie, które odblokowuje dostęp asystenta. Udostępniona wiadomość może być dostępna od razu po wysłaniu; ogłoszenie przypięte do tablicy może stać się dostępne, gdy asystent sprawdzi tablicę; rozmowa może być dostępna dopiero wtedy, gdy gracz zdecyduje się o nią zapytać. Nie opieraj się na niejasnych etykietach, takich jak „asystent zna całe archiwum”, chyba że fabuła określa, co zawiera to archiwum i kiedy jest aktualizowane.

Praktyczna reguła dostępu składa się z trzech części: odbiorców zapisu, warunku jego udostępnienia oraz ewentualnego opóźnienia. Na przykład: „Asystent może czytać wpisy na tablicy grupy, gdy gracz ją otworzy; nie może czytać prywatnych szkiców”. Opóźnienie ma znaczenie w rozgałęzionych historiach. Jeśli gracz nie odwiedził tablicy, asystent nie powinien zachowywać się tak, jakby widział najnowszy wpis tylko dlatego, że istnieje on gdzieś w plikach autora.

W Twine zmienne fabularne mogą być dostępne w różnych passage, podczas gdy w Harlowe i SugarCube zmienne tymczasowe są ograniczone do bieżącego passage. Ta różnica pokazuje, dlaczego autorzy powinni świadomie decydować, czy fakt ma zachować ważność w całej historii, czy dotyczy tylko konkretnej sceny. Dokładna implementacja zależy od formatu historii, więc potraktuj tę regułę jako model projektowy, a nie instrukcję kodowania. Twine Cookbook: Zmienne

Gdy brakuje zapisu, jest on stary albo niejednoznaczny, pozwól asystentowi konkretnie opisać tę lukę. Może powiedzieć, że ma poniedziałkowy plan, ale nie ma późniejszego potwierdzenia, albo że jedna postać relacjonowała przeniesienie tabliczek, lecz na tablicy nie ma aktualizacji. Dzięki temu gracz dostaje sensowny następny krok: sprawdzić inne źródło przygotowane przez autora, wrócić do rozmowy z postacią albo uznać, że wskazówka pozostaje nierozstrzygnięta.

Takie podejście wspiera tajemnicę bez arbitralnej wszechwiedzy. W badaniach nad narracją interaktywną analizowano, jak ograniczona wiedza może kształtować zachowanie gracza, między innymi w badaniu wykorzystującym fikcję interaktywną Anchorhead do zbadania modeli gracza. W przypadku asystenta stworzonego przez autora wniosek projektowy jest prosty: to, czego dowiedzieli się gracz i asystent, może wpływać na ich kolejne wybory, więc należy jawnie śledzić stany ich wiedzy. Rivera-Villicana i in., „Informing a BDI Player Model for an Interactive Narrative”

Przed przygotowaniem odpowiedzi sprawdź poniższe kwestie dla każdego istotnego twierdzenia:

Czy twierdzenie znajduje się w zapisie autora, czy jest oznaczone jako wniosek?

Czy zapis podaje źródło i rozróżnia plan, relację, obserwację lub późniejsze potwierdzenie?

W którym momencie fabuły asystent uzyskał do niego dostęp?

Czy fikcyjna rola asystenta pozwala mu korzystać z tego źródła?

Jeśli zapis jest niekompletny lub sprzeczny z innymi, czy dialog zachowuje tę niepewność?

Jeśli odpowiedź na którekolwiek z tych pytań jest niejasna, zawęź wypowiedź asystenta tak, by odpowiadała dostępnemu zapisowi. Taka postać nadal może być pomocna: potrafi streścić to, co widziała, wskazać, co pozostaje niepotwierdzone, i skierować gracza do następnej przygotowanej przez autora wskazówki. Wiarygodność zapewnia jej widoczna granica między pełnym zapisem fabuły a informacjami, które rzeczywiście otrzymała.