Jak zaprojektować grę z botem AI, mając jasne zasady, pamięć i wybory gracza

Zapisz pętlę w jednym zdaniu: Pokaż sytuację → przyjmij akcję → sprawdź zasady → zaktualizuj stan → pokaż skutek i kolejne opcje. Każda tura powinna realizować tę pętlę albo wyjaśniać, dlaczego nie może być kontynuowana.

Zanim napiszesz prompt definiujący osobowość, określ cel, dostępne akcje, ich koszty i warunki zakończenia. Powinno dać się rozegrać grę za pomocą fiszek lub arkusza kalkulacyjnego. Dzięki temu można sprawdzić mechanikę, zanim generowany dialog wprowadzi zmienność.

Rozważ niewielką grę o nazwie Paczka na festiwal. Gracz ma pięć jednostek czasu na dostarczenie paczki. Może wybrać trasę bezpośrednią albo przez ogród, a przed wyruszeniem może też zebrać ozdobną wstążkę. Bot wciela się w kuriera festiwalowego, który wyjaśnia trasy i komentuje dostawę.

Proponowane zasady są celowo zwięzłe:

Pokaż te zasady przed pierwszym wyborem. Wyjaśnij, że akcje dostawy kończą rozgrywkę, więc wstążkę trzeba zebrać wcześniej. Dostawa zakończona po wykorzystaniu ostatniej jednostki czasu nadal się udaje, ponieważ najpierw sprawdzany jest warunek sukcesu.

Ten prototyp ma kompletny początek, zestaw decyzji i zakończenie. Dodatkowe postacie lub lokacje powinny zasłużyć na miejsce, wnosząc użyteczne decyzje do tej pętli.

Traktuj stan jako zapis tego, co w grze jest prawdą. Tekst rozmowy może objaśniać ten zapis, ale nie powinien po cichu go zmieniać.

Rozdział o stanach autorstwa Roberta Nystroma w książce Game Programming Patterns (https://gameprogrammingpatterns.com/state.html) opisuje maszyny stanów skończonych za pomocą stanów, danych wejściowych i dozwolonych przejść. Pokazuje również, jak luźno połączone flagi logiczne mogą prowadzić do nieprawidłowych kombinacji. Zastosuj tę zasadę do cyklu życia gry: użyj jednego statusu rozgrywki, takiego jak aktywna, dostarczona lub nieudana, i określ przejścia między nimi.

W przypadku prototypu gry o dostawie wystarczy krótka specyfikacja stanu:

Wyznacz pocztówkę z ogrodu na podstawie wybranej trasy zamiast przechowywać ją jako drugą wartość, która mogłaby być z nią sprzeczna. Podobnie obliczaj aktualnie dostępne akcje na podstawie stanu i zasad.

Stosuj ustaloną kolejność przetwarzania: zinterpretuj prośbę, sprawdź poprawność akcji i jej parametrów, oblicz wynik, zapisz zmianę stanu, a następnie ją opisz. Przekaż narratorowi zatwierdzony wynik i dozwolone kolejne akcje. Nie powinien wykonywać drugiego obliczenia ani wymyślać innego wyniku.

Na przykład po zebraniu wstążki zatwierdzony wynik jest następujący: pozostały cztery jednostki czasu, wstążka została zebrana i obie trasy są dostępne. Bot może opisać kolor wstążki, o ile nie wpływa on na mechanikę. Nie może doliczyć nieogłoszonego kosztu czasu ani przyznać drugiej wstążki.

Możesz prototypować te warunki za pomocą istniejącego narzędzia narracyjnego. Oficjalny samouczek Inkle dotyczący fikcji interaktywnej (https://www.inklestudios.com/ink/web-tutorial/) wyjaśnia wybory warunkowe, śledzenie wcześniej odwiedzonych treści, zmienne i jawne zakończenia. Te funkcje stanowią przydatną podstawę do testowania napisanej gry przed dodaniem narracji AI.

W tym projekcie sprawdzaj sprawczość gracza, oceniając, czy może przewidzieć istotną różnicę i zobaczyć ją w wyniku. Kilka przycisków z różnymi opisami, które prowadzą do identycznego skutku, niewiele pozwala w tym zakresie sprawdzić.

W grze Paczka na festiwal wybór trasy odpowiada różnym preferencjom graczy:

To przykładowe obliczenia wynikające z podanych zasad. Ułatwiają podjęcie prostej decyzji: wybierz dostawę bezpośrednią, by szybciej zakończyć, zbierz wstążkę dla ozdoby albo wybierz trasę przez ogród, by zdobyć pocztówkę. Pozostały czas jest tu szczegółem zakończenia; nie przyznaje potajemnie punktów.

Jeśli gra ma później nagradzać konkretny wynik, ujawnij sposób punktacji przed podjęciem decyzji. W przeciwnym razie gracze nie będą mogli ocenić zamierzonego przez ciebie kompromisu.

Oprócz widocznych akcji obsługuj też swobodny tekst. „Jedźmy malowniczą trasą” można przypisać do dostawy przez ogród. „Zróbmy coś wyjątkowego” jest niejednoznaczne: może oznaczać zebranie wstążki, wybór trasy przez ogród albo jedno i drugie. Poproś krótko o doprecyzowanie, nie zużywając czasu.

W pierwszym prototypie przyjmuj jedną akcję w grze na wiadomość. Jeśli gracz prosi o wykonanie sekwencji, przedstaw jej kroki i poproś o wybór pierwszej akcji. Dzięki temu unikniesz częściowego wykonania planu, którego dalszych kroków nie dałoby się zrealizować.

Udzielaj konkretnych odpowiedzi na prośby o niedostępne akcje. Jeśli gracz poprosi o lot, wyjaśnij, że dostępne są trasy bezpośrednia i przez ogród, wraz z ich kosztami. Swobodny tekst może urozmaicać sposób wyrażania próśb, a system akcji zapewnia przewidywalny zestaw możliwości.

Podziel pamięć na trzy warstwy, z których każda pełni inną funkcję.

Autorytatywny stan rozgrywki przechowuje zasoby, postępy, wybrane trasy i zakończenia. Utrzymuje się po zapisaniu i ponownym wczytaniu gry, a zmienia się wyłącznie w wyniku sprawdzonych akcji.

Dziennik zdarzeń rozgrywki zapisuje zatwierdzone akcje i ich skutki. Wpis może informować, że akcja 2 zebrała wstążkę i zmniejszyła czas z pięciu do czterech jednostek. Ułatwia to debugowanie i sporządzanie dokładnych podsumowań. Zachowuj identyfikatory akcji, aby ponowiona prośba nie zastosowała tego samego zdarzenia dwa razy.

Kontekst narracyjny obejmuje ostatnie wypowiedzi i krótkie podsumowanie pomagające zachować ton oraz ciągłość. Można go skrócić bez usuwania właściwego stanu gry.

Poradnik Anthropic dotyczący skutecznego inżynierowania kontekstu (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) omawia zarówno podsumowywanie historii rozmowy, jak i przechowywanie trwałych notatek poza oknem kontekstu. Ostrzega też, że zbyt agresywne podsumowywanie może prowadzić do utraty ważnych szczegółów. Wniosek projektowy jest taki, by dokładne fakty mechaniczne przechowywać w ustrukturyzowany sposób, a podsumowań używać dla zachowania ciągłości rozmowy.

Określ granice wiedzy, podobnie jak granice przechowywania danych. Postać powinna otrzymywać tylko fakty, które może znać. Jeśli późniejsza wersja gry zawiera ukrytą trasę, nie udostępniaj jej w kontekście postaci, dopóki nie zostanie spełniony warunek jej odkrycia. Stan dostępny silnikowi gry nie musi być w całości dostępny narratorowi.

W tej niewielkiej grze zachowuj postępy w zapisanej rozgrywce i usuwaj je przy rozpoczęciu nowej. Nie wyciągaj wniosków o trwałych preferencjach gracza na podstawie pojedynczego wyboru trasy. Jeśli dodasz zapisywaną preferencję, taką jak krótsze opisy, powinna być jawna i możliwa do edycji.

Przetestuj pamięć na konkretnym przebiegu: zbierz wstążkę, zapisz grę, wczytaj ją ponownie, poproś o status i wybierz dostawę przez ogród. Wstążka musi pozostać zebrana, przed dostawą muszą pozostać cztery jednostki czasu, a po niej czas musi wynosić zero.

Nieosiągnięcie celu jest częścią gry. Nieudane generowanie odpowiedzi to problem implementacji. Każde z tych zdarzeń powinno mieć inne skutki.

W przypadku niepowodzenia w grze wskaż zasadę, która zakończyła rozgrywkę. Po trzech okresach czekania pozostają tylko dwie jednostki czasu, więc żadna trasa dostawy nie jest dostępna. Zakończ grę natychmiast jasnym wyjaśnieniem i opcją rozpoczęcia od nowa, zamiast pozostawiać gracza w aktywnej rozgrywce bez możliwości wygranej.

Zanim dodasz rozbudowaną narrację, określ sposób odzyskiwania działania po awarii:

Nie zastępuj po cichu nieczytelnego zapisu nową grą. Ukrywa to utratę postępów i sprawia, że kolejna odpowiedź wprowadza w błąd.

Przygotuj prosty komunikat z wynikiem dla każdej akcji: co się wydarzyło, co uległo zmianie i co można zrobić dalej. Ekspresyjna narracja bota może uzupełniać ten wynik. Podczas przekroczenia limitu czasu lub w przypadku sprzecznej odpowiedzi prosty komunikat pozwala graczowi kontynuować.

Kończ grę dokładnym podsumowaniem. Wspomnij o wstążce tylko wtedy, gdy została zebrana, a o pocztówce tylko w przypadku trasy przez ogród. Generowany tekst powinien zachowywać różnice, o których wyborze decydował gracz w trakcie rozgrywki.

Najpierw przetestuj grę z ustalonym tekstem. Sprawdź każdą akcję, zakończenie i sytuację graniczną. Następnie dodaj bota i powtórz testy, używając różnych sformułowań. Dzięki temu można odróżnić błąd w zasadach od niezrozumianej prośby.

Poproś reprezentatywnych graczy, by ukończyli dostawę bez podpowiedzi. Zapytaj, czego spodziewają się przed wyborem i co ich zdaniem zmieniło się później. Poradnik Nielsen Norman Group dotyczący testów użyteczności metodą głośnego myślenia (https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/) zaleca zadania i uczestników reprezentatywnych dla badanej grupy, a także pozostawienie uczestnikom przestrzeni do mówienia; ostrzega też, że podpowiedzi prowadzącego mogą wpływać na ich zachowanie.

Obserwuj graczy i korzystaj z dziennika akcji. Zapisuj próby wykonania akcji, prośby o doprecyzowanie, nieoczekiwane wyniki i wszelkie rozbieżności między narracją a zatwierdzonym stanem. Osobno sprawdzaj, czy gracze rozumieli dostępne opcje i czy podobał im się wybór między nimi.

Krótka lista kontrolna do testów gry. Napraw błędy w zasadach i obsłudze stanu, zanim rozbudujesz świat. Jeśli gracze rozumieją wybory, ale nie uważają ich za interesujące, zmień kompromisy. Jeśli decyzje im się podobają, ale nie potrafią przewidzieć kosztów, popraw sposób ich przedstawienia. Rozbuduj prototyp, gdy jego obecne wybory pozostają zrozumiałe przy różnych sformułowaniach, zapisanych rozgrywkach i ścieżkach niepowodzenia.