Gdy kanon świata gry koliduje z improwizacją AI, co powinno mieć pierwszeństwo?

Przydatny system rozdziela dwa pytania: co jest prawdą w tym świecie i co jest prawdą na tym etapie danego przejścia gry? Kanon obejmuje ustalone fakty, takie jak tożsamość postaci, historia miejsca czy sposób działania urządzenia. Stan rozdziału obejmuje to, co wydarzyło się podczas tego przejścia: które drzwi zostały otwarte, kogo spotkał gracz lub czy dane wydarzenie już nastąpiło. Model dialogowy może korzystać z tych faktów, ale nie powinien po cichu ich zmieniać.

To rozróżnienie odzwierciedla praktyczną cechę systemów narracji interaktywnej. ink, język skryptowy opracowany przez Inkle Studios, obsługuje rozgałęzioną logikę fabuły i śledzenie stanu; jego twórcy opisują wykorzystanie stanu do zmieniania tekstu w zależności od wcześniejszych wydarzeń. Dokumentacja Microsoftu dotycząca Minecrafta również opisuje pliki scen dla poszczególnych NPC lub rozdziałów narracyjnych oraz zmienianie dialogów w zależności od działań gracza. To przykłady dialogów tworzonych przez autorów i kontrolowanych przez kontekst fabularny, a nie dowód na to, że wymagany jest konkretny projekt AI. Pokazują, dlaczego warto jawnie zapisywać informacje o postępach w grze. (Inkle Studios o ink, dokumentacja Microsoftu dotycząca dialogów NPC)

Zdefiniuj generowaną odpowiedź jako sposób przekazania znanych informacji, a nie źródło nowych prawd o świecie. Postać może wyjaśnić znane wydarzenie własnymi słowami, zareagować na sposób, w jaki gracz zadał pytanie, lub podzielić się trafną obserwacją. Nie powinna wymyślać nowego rodzeństwa, zmieniać tego, kto ma klucz, ogłaszać, że wydarzenie z zamkniętego rozdziału już nastąpiło, ani ustalać ukrytej przyczyny bez poparcia w danych fabularnych.

Jasna instrukcja może brzmieć: „Korzystaj wyłącznie z podanych tutaj faktów i stanu rozdziału. Możesz dobierać słowa i ton. Nie dodawaj nazw, wydarzeń, relacji, motywów ani konsekwencji jako faktów. Jeśli odpowiedź nie została podana, powiedz, że nie wiesz lub nie możesz tego potwierdzić”. To przykład zasady projektowej, a nie gwarancja, że model AI zawsze jej przestrzega. Gra nadal musi kontrolować, jakie informacje docierają do postaci i jakie działania może wywołać odpowiedź.

Postacie mogą się mylić, wymijać odpowiedź lub wyrażać niepewność, jeśli przewiduje to napisana fabuła. Istotne jest, czy gra przedstawia wypowiedź jako punkt widzenia postaci, czy jako potwierdzony fakt dotyczący świata. „Słyszałem, że most jest zamknięty” może być plotką, jeśli narracja dopuszcza plotki. „Most jest zamknięty” może zostać odebrane jako wiarygodna informacja o stanie świata, zwłaszcza jeśli gra później na niej polega.

W przypadku każdej niepewnej lub spornej odpowiedzi zdecyduj, czy postać przekazuje własną wiedzę, powtarza plotkę, snuje przypuszczenia czy podaje potwierdzony kanon. Oznacz tę kategorię w prompcie lub danych dialogowych i konsekwentnie dobieraj sformułowania. Jeśli fabuła nie ustaliła, kto zbudował starą wieżę, NPC może powiedzieć, że słyszał różne wersje; model nie powinien rozstrzygać zagadki tylko dlatego, że jedna odpowiedź brzmi wiarygodnie.

Model nie może wiarygodnie uwzględnić faktu, którego mu nie podano. Przekazuj tylko informacje potrzebne w rozmowie, ale podawaj je precyzyjnie: bieżący rozdział, istotne zakończone wydarzenia, ważne nierozstrzygnięte kwestie oraz fakty znane osobiście postaci. Unikaj ogólnych streszczeń, które zacierają różnicę między planowanymi a zakończonymi wydarzeniami. Notatki „brama otworzy się, gdy gracz znajdzie pieczęć” nie wolno pomylić z informacją „gracz znalazł pieczęć”.

Badania nad modelami językowymi w grach fabularnych rozgrywanych przy stole traktują śledzenie stanu i generowanie dialogów jako powiązane, ale odrębne zadania. Autorzy pracy Dungeons and Dragons as a Dialog Challenge for Artificial Intelligence opisują generowanie kolejnych wypowiedzi i przewidywanie stanu gry na podstawie historii dialogu; informacje o stanie obejmują szczegóły dotyczące postaci i zmieniające się działania. Uzasadnia to traktowanie stanu jako jawnego wejścia i odrębnej kwestii; nie dowodzi jednak, że wygenerowana odpowiedź powinna móc zmieniać nadrzędny stan gry. (Callison-Burch i in., „Dungeons and Dragons as a Dialog Challenge for Artificial Intelligence”)

Ustal domyślną odpowiedź na braki w zapisanych informacjach. Zależnie od postaci i sceny może ona brzmieć: „Nie było mnie tam”, „Nie wiem” albo „Nikt mi o tym nie powiedział”. Jeśli pasuje plotka lub przypuszczenie postaci, wyraźnie je tak oznacz. Celem jest pozostawienie otwartego pytania, dopóki fabuła nie przyniesie odpowiedzi, przy jednoczesnym podtrzymaniu rozmowy.

Ta odpowiedź awaryjna powinna obejmować także sprzeczności. Jeśli podany stan rozdziału mówi, że gracz nie spotkał kapitana, ale historia rozmowy sugeruje coś innego, nie pozwalaj NPC z przekonaniem potwierdzać żadnej z tych wersji. Poproś system gry o rozstrzygnięcie rozbieżności albo pozwól NPC odpowiedzieć w sposób niezależny od spornej informacji. Taka polityka odpowiedzi to zalecenie projektowe wynikające z potrzeby zachowania spójności stanu i dialogu, a nie wynik opublikowanego badania konkretnej gry.

Zanim pokażesz odpowiedź, sprawdź, czy wprowadza ona nowy istotny fakt. Prosta kontrola może obejmować pytania: Czy odpowiedź wymienia wydarzenie, relację, motyw, miejsce, osobę posiadającą przedmiot lub konsekwencję? Czy ta informacja należy do kanonu lub bieżącego stanu? Czy jest wyraźnie przedstawiona jako przekonanie lub plotka? Czy sugeruje zmianę rozdziału lub działanie, którego gra nie zapisała? Jeśli istotna informacja nie ma potwierdzenia, wygeneruj odpowiedź ponownie, stosując ściślejsze ograniczenia, lub skorzystaj z odpowiedzi wyrażającej niepewność.

Promptowanie może pomóc zachować spójność postaci, ale nie należy traktować go jako bazy danych kanonu. Raport badawczy z 2026 roku dotyczący NPC sterowanych przez LLM w tajemnicy w Minecrafcie opisuje wykorzystanie technik promptowania do poprawy spójności postaci i dialogu. Jest to przykład podejścia badawczego zastosowanego w konkretnym prototypie, a nie dowód na to, że samo promptowanie zapobiega sprzecznościom w innych grach. Przechowuj fakty stworzone przez autorów i postępy w grze w źródle, z którego gra może korzystać, a wygenerowany dialog traktuj jako propozycję odpowiedzi. (Heriot-Watt Research Portal, „Designing and Evaluating Interactive Narratives with Generative AI: LLM-Driven NPCs for a Minecraft Murder Mystery”)

Oceniając sporną kwestię, zastosuj kolejno te kryteria:

Czy twierdzenie dotyczy ustalonego faktu o świecie? Zachowaj wersję stworzoną przez autorów.

Czy zależy od tego, co wydarzyło się podczas tego przejścia gry? Korzystaj z aktualnego stanu rozdziału, a nie z ogólnego streszczenia fabuły.

Czy to ograniczony lub niepewny punkt widzenia postaci? Zaznacz tę perspektywę w wypowiedzi.

Czy nie ma potwierdzonej odpowiedzi? Pozwól postaci to powiedzieć i pozostaw pytanie otwarte.

Czy wypowiedź zmieni to, co gra uznaje za prawdziwe lub zakończone? Taką zmianę powinna wprowadzać wyłącznie logika postępów w grze stworzona przez autorów.

Takie podejście pozostawia miejsce na żywą rozmowę, a zarazem pozwala zachować jasny podział między autorstwem a ciągłością fabuły. Model może improwizować, jak znana postać coś powie; zapis świata określa, co postać może wiarygodnie przedstawiać jako prawdę. Jeśli zapis milczy, wyrażenie niepewności jest prawidłową odpowiedzią, a nie luką, którą model musi wypełnić.