Jak powstrzymać dialogi postaci AI przed wymyślaniem wskazówek w grach detektywistycznych

W grze detektywistycznej gracze zbierają informacje, wyciągają wnioski i wykorzystują zdobytą wiedzę, by szukać kolejnych informacji. Dlatego relacja między wskazówkami a wiedzą gracza należy do głównej pętli rozgrywki, a nie jest tylko kwestią stylu dialogu. Postać, która z przekonaniem wspomina o nieodnalezionym liście albo wymienia osobę, której gracz nigdy nie spotkał, może przypadkiem stworzyć nowy trop. Gracz nie ma pewności, czy to szczegół zaprojektowany jako wskazówka, celowe kłamstwo, czy wymysł modelu. Artykuł „Generative Forensics: Procedural Generation and Information Games” opisuje gry informacyjne jako rozgrywkę polegającą na zbieraniu wiedzy i wykorzystywaniu jej do zrozumienia zagadki; zastosowanie tego ujęcia pokazuje, że nieśledzone wypowiedzi generowane przez model mogą zamącić wiedzę, na której gracz powinien opierać swoje wnioski.

Rozwiązanie zaczyna się od jasnego rozróżnienia: wskazówka to fakt w grze, na podstawie którego gracz może podjąć działanie; element fabularny to ekspresyjny dialog, który nie dodaje ani nie zmienia faktów w grze. Postać może brzmieć niepewnie, wymijająco, zabawnie lub obrazowo, ale wypowiedź nie staje się dowodem tylko dlatego, że brzmi przekonująco.

Dla każdej wskazówki, na podstawie której gracz może podjąć działanie, prowadź krótki, jawny zapis. Może on znajdować się w bazie danych, pliku z treścią albo narzędziu narracyjnym; najważniejsze, żeby model nie wymyślał jego zawartości. Uwzględnij pola określające, co mówi wskazówka, skąd pochodzi, kto może ją znać i kiedy staje się dostępna.

Pole: clue_id; Co zawiera: Stały identyfikator dowodu; Przykład (ilustracyjny): note_blue_01

Pole: canonical_fact; Co zawiera: Fakt ustalony przez grę; Przykład (ilustracyjny): „Notatka jest podpisana inicjałem M.”

Pole: source_id; Co zawiera: Przygotowany przez twórców obiekt, scena lub kwestia potwierdzająca fakt; Przykład (ilustracyjny): archive_note_03

Pole: discovery_condition; Co zawiera: Wymagany stan gry przed omówieniem wskazówki; Przykład (ilustracyjny): found_archive_note_03

Pole: allowed_speakers; Co zawiera: Postacie, które mogą znać wskazówkę lub o niej mówić; Przykład (ilustracyjny): Mara, Ivo

Pole: certainty; Co zawiera: Informację, czy źródło podaje fakt, czy sugeruje interpretację; Przykład (ilustracyjny): explicit

Pole: player_facing_label; Co zawiera: Nazwę dowodu w dzienniku, jeśli ma zastosowanie; Przykład (ilustracyjny): „Niepodpisana notatka”

Powyższe nazwy i wartości to zmyślony przykład formatu, a nie informacja o konkretnej grze. Zwróć uwagę, że zapis oddziela treść podaną wprost przez źródło od interpretacji: sam inicjał w podpisie nie dowodzi, kto napisał notatkę. Dzięki temu system dialogowy może pozwolić postaci na spekulacje, nie przedstawiając ich jako nowo zweryfikowanych dowodów.

Przechowuj stan odkrycia w logice gry. Na przykład found_archive_note_03 przyjmuje wartość true dopiero wtedy, gdy gracz rzeczywiście znajdzie notatkę. Na początku rozmowy przekaż postaci listę przygotowanych przez twórców faktów, o których może mówić, przefiltrowaną według stanu odkrycia gracza i wiedzy postaci. Wskazówka jest dostępna tylko wtedy, gdy spełnione są oba warunki: gracz osiągnął wymagany stan odkrycia, a rozmówca ma prawo ją znać.

To praktyczne zastosowanie generowania wspomaganego wyszukiwaniem (RAG): wyszukaj istotne zapisy, dodaj je do kontekstu modelu i generuj odpowiedź na ich podstawie. Omówienie RAG firmy Microsoft opisuje ten proces: wyszukiwanie, wzbogacanie kontekstu i generowanie; zwraca też uwagę, że niepełne lub słabe wyniki wyszukiwania nadal mogą prowadzić do nieprawidłowych odpowiedzi. W grze wyszukiwanie powinno uwzględniać warunki odkrycia, zanim wyniki trafią do modelu. Polecenie modelowi „nie zdradzaj niczego” jest słabszym zabezpieczeniem niż całkowite ukrycie przed nim nieodkrytych dowodów.

Jeśli to możliwe, przeprowadzaj kontrolę uprawnień poza modelem. To gra, a nie wygenerowana kwestia, powinna decydować, czy dowód trafia do dziennika, spełnia warunek zagadki albo odblokowuje interakcję. Model może ująć autoryzowany fakt w odpowiednie słowa; to stan gry powinien rozstrzygać, czy fakt jest w ogóle dozwolony.

Dobry prompt powinien określać głos postaci, bieżącą scenę, dozwolone zapisy wskazówek oraz różnicę między dowodem a elementem fabularnym. Powiedz, jak postać ma odpowiedzieć, gdy pytanie wykracza poza przekazane dowody: odmówić potwierdzenia, przyznać, że postać nie wie, albo odpowiedzieć w jej stylu, nie podając szczegółów, na podstawie których można podjąć działanie. Uwzględnij też instrukcje dotyczące sprzecznych lub niejednoznacznych zapisów. Wytyczne Microsoftu dotyczące tworzenia promptów dla RAG zalecają jawne ograniczenia co do ugruntowania odpowiedzi, zachowanie awaryjne, identyfikatory źródeł i instrukcje na wypadek sprzeczności. To przydatne zasady projektowania kontrolowanego dialogu postaci, a także asystentów informacyjnych.

Na przykład, jeśli gracz pyta, czy inicjał M dowodzi, że to Mara napisała notatkę, dozwolona odpowiedź mogłaby brzmieć: „M tam jest, ale to jeszcze nie mówi nam, kto się podpisał”. System może dopuścić taką wypowiedź, ponieważ zachowuje ona różnicę między faktem podanym w źródle a wnioskiem. Nie powinien wymyślać świadka, zgodności charakteru pisma ani drugiego dokumentu, żeby odpowiedź wydawała się bardziej satysfakcjonująca.

Niech model zwraca ustrukturyzowane pola, takie jak spoken_text, claim_type i source_ids. W odpowiedzi zawierającej wskazówkę wymagaj co najmniej jednego poprawnego identyfikatora źródła i sprawdzaj go względem zapisów przekazanych modelowi na tę turę. Wypowiedzi będące elementem fabularnym oznaczaj jako niedowodowe i nie pozwalaj im ustawiać flag wskazówek. Ustrukturyzowany wynik nie dowodzi prawdziwości tekstu; pozwala jednak grze sprawdzić go przed wyświetleniem lub zmianą stanu.

Tekst będący elementem fabularnym może obejmować nastrój postaci, niewinny żart albo ogólną reakcję na pomieszczenie. Nie powinien po cichu wprowadzać daty, miejsca, przedmiotu, nazwiska świadka, motywu ani innego szczegółu, który gracz mógłby rozsądnie uznać za trop. Jeśli chcesz dopuścić spekulacje, zadbaj, by niepewność była wyraźna w sformułowaniu, i nie wprowadzaj takich wypowiedzi do systemów obiektywnych, takich jak lista dowodów, stan zadań czy interakcje oparte na wskazówkach.

To rozróżnienie można odzwierciedlić zarówno w danych, jak i w prezentacji. Wewnętrznie oznaczaj wypowiedzi jako dowód, interpretację lub element fabularny; w interfejsie zachowaj styl dowodów i wpisy w dzienniku dla wskazówek przygotowanych przez twórców gry. Postać może powiedzieć: „Może ktoś zostawił tę notatkę w pośpiechu”, ale jeśli gra nie przewiduje tej możliwości jako dozwolonej interpretacji, nie powinna ona pojawić się jako potwierdzona wskazówka ani uruchamiać nowej ścieżki. Ten podział na trzy kategorie to zalecenie projektowe wynikające z potrzeby zachowania rozróżnienia między treścią źródła, czyimś wnioskiem i zwykłym ekspresyjnym dialogiem.

Nie potrzebujesz konkretnego silnika, by zastosować to podejście. Narzędzia do narracji interaktywnej często obsługują fragmenty treści, zmienne i zawartość warunkową. Oficjalna dokumentacja Ink dotycząca pisania opisuje zmienne i logikę warunkową używane do sterowania treścią opowieści; przewodnik po fragmentach w Twine Cookbook wyjaśnia, że fragmenty są sekcjami treści, które mogą zawierać kod wpływający na sposób wyświetlania tekstu lub jego reakcję na działania gracza. Funkcje te mogą odzwierciedlać stan odkrycia, wiedzę rozmówcy i dialog warunkowy niezależnie od tego, czy dialog jest generowany, czy napisany wcześniej.

Utrzymuj spójne identyfikatory wskazówek i nazwy stanów w zapisach narracyjnych i logice gry. Zmienna taka jak found_archive_note_03 jest łatwiejsza do sprawdzenia niż niejasna flaga clue2, zwłaszcza gdy różne sceny ją odczytują lub ustawiają. Dodaj możliwe do prześledzenia powiązanie każdej wygenerowanej wypowiedzi, na podstawie której można podjąć działanie, z dozwolonym zapisem źródłowym; jeśli wypowiedź nie ma poprawnego źródła, środowisko uruchomieniowe może ją odrzucić albo poprosić o bezpieczną odpowiedź awaryjną, zamiast traktować ją jako dowód.

Testuj rozmowy w momentach granicznych odkryć, bo właśnie wtedy najłatwiej o błędy w regułach stanu. Rozpocznij nową rozmowę przed znalezieniem wskazówki, zaraz po jej znalezieniu oraz po odezwaniu się postaci dysponującej inną wiedzą. Zadawaj bezpośrednie pytania o nieodkryte dowody, pytaj o kwestie, na które źródło odpowiada tylko częściowo, i powtarzaj scenę, jeśli gra na to pozwala. Porównuj wyświetloną wypowiedź, zwrócone identyfikatory źródeł oraz wszelkie zmiany w dzienniku lub stanie fabuły.

Krótka lista kontrolna pomoże przeprowadzić konkretne sprawdzenia:

Każda wypowiedź, na podstawie której można podjąć działanie, jest powiązana z przygotowaną przez twórców wskazówką lub jawnie dozwoloną interpretacją.

Warunek odkrycia wskazówki jest spełniony, zanim pojawi się ona jako dostępna wiedza.

Rozmówca może znać te informacje w danej scenie.

Na pytania bez potwierdzenia model odpowiada zgodnie z wybranym wariantem awaryjnym, zamiast dodawać nowy, konkretny fakt.

Wypowiedzi fabularne nie mogą dodawać wpisów do dziennika, spełniać warunków dostępu do wskazówek ani zmieniać stanu dowodów.

Niejednoznaczne lub sprzeczne zapisy prowadzą do wyrażenia niepewności albo do możliwej do sprawdzenia odpowiedzi awaryjnej, a nie do cichego, nowego rozstrzygnięcia.

Ugruntowanie odpowiedzi ogranicza możliwość tworzenia fałszywych tropów, ale nie gwarantuje, że generowany tekst zawsze będzie zgodny z przekazanymi faktami. Wyszukiwanie może pominąć istotny zapis, a model może wygenerować nieprawdziwy tekst mimo ugruntowania, jak zauważa Microsoft w wytycznych o ograniczeniach RAG. Ostateczną władzę nad wskazówkami pozostaw zapisom przygotowanym przez twórców i logice gry; wykorzystuj generowanie do nadania dialogowi charakteru w ramach tych granic.

Praktyczna zasada jest prosta: pozwól modelowi dobierać słowa, ale to przygotowana przez twórców zagadka i bieżący stan gry mają decydować, co te słowa mogą ustalać. Gdy każda wskazówka, na podstawie której można podjąć działanie, ma źródło, warunek odkrycia i jasno określony status, postacie mogą brzmieć bardziej naturalnie, nie podając graczom dowodów, których gra nigdy nie wprowadziła.