Wie man ein KI-Bot-Spiel mit klaren Regeln, Gedächtnis und Entscheidungsfreiheit für Spieler entwirft
Um ein spielbares KI-Bot-Spiel zu entwerfen, definieren Sie eine kleine wiederholbare Schleife, speichern Sie den Spielzustand außerhalb der Konversation und geben Sie jeder Spieleraktion eine klare Konsequenz. Lassen Sie den Bot Anfragen interpretieren und Ereignisse beschreiben; lassen Sie explizite Regeln Kosten, Fortschritt und Spielenden bestimmen. Dieser Leitfaden richtet sich an Spieleentwickler, die ein textbasiertes Spiel mit einem KI-Charakter oder -Erzähler erstellen. Die Aufgabe besteht darin, eine kurze, testbare Sitzung zu schaffen, in der die Spieler ihre Optionen verstehen, sehen, dass ihre Entscheidungen von Bedeutung sind, und ein gültiges Ende erreichen. Das folgende Lieferungsspiel ist ein illustrativer Entwurf, kein getestetes Produkt oder dokumentierte Fallstudie.
Beginnen Sie mit einer Kernschleife, die Sie ohne KI spielen können
Schreiben Sie die Schleife in einem Satz auf: Situation anzeigen → Aktion annehmen → Regeln prüfen → Zustand aktualisieren → Konsequenz und nächste Optionen anzeigen. Jeder Zug sollte diese Schleife abschließen oder erklären, warum es nicht weitergehen kann.
Bevor Sie einen Persönlichkeits-Prompt schreiben, definieren Sie das Ziel, die verfügbaren Aktionen, die Aktionskosten und die Bedingungen für das Spielende. Sie sollten in der Lage sein, das Spiel mit Karteikarten oder einer Tabellenkalkulation durchzuführen. Dadurch können Sie die Spielmechanik überprüfen, bevor generierte Dialoge für Variation sorgen.
Betrachten Sie ein kleines Spiel namens *Festival-Paket*. Der Spieler hat fünf Zeiteinheiten, um ein Paket auszuliefern. Er kann eine direkte Route oder eine Gartenroute wählen und vor dem Aufbruch optional eine dekorative Schleife einsammeln. Ein Bot übernimmt die Rolle des Festivalkuriers, der Routen erklärt und die Lieferung kommentiert.
Die vorgeschlagenen Regeln sind bewusst kompakt gehalten:
Zeigen Sie diese Regeln vor der ersten Entscheidung an. Erklären Sie, dass Lieferaktionen die Sitzung beenden, sodass die Spieler die Schleife vorher einsammeln müssen. Eine Lieferung, die die letzte Zeiteinheit verbraucht, ist dennoch erfolgreich, da die Erfolgsprüfung an erster Stelle steht.
Dieser Prototyp verfügt über einen vollständigen Anfang, einen Entscheidungsraum und ein Ende. Zusätzliche Charaktere oder Schauplätze sollten ihre Daseinsberechtigung dadurch verdienen, dass sie dieser Schleife sinnvolle Entscheidungen hinzufügen.
Machen Sie den expliziten Zustand zur maßgeblichen Instanz für Ergebnisse
Betrachten Sie den Zustand als die Dokumentation des Spiels darüber, was wahr ist. Konversationstext kann diese Dokumentation erklären, er sollte sie jedoch nicht stillschweigend ändern.
Robert Nystroms Kapitel über Zustände in *Game Programming Patterns* (https://gameprogrammingpatterns.com/state.html) beschreibt endliche Zustandsautomaten anhand von Zuständen, Eingaben und zulässigen Übergängen. Es veranschaulicht auch, wie lose kombinierte boolesche Flags ungültige Kombinationen erzeugen können. Wenden Sie dieses Prinzip auf den Lebenszyklus Ihres Spiels an: Verwenden Sie einen einzigen Sitzungsstatus, z. B. „aktiv“, „zugestellt“ oder „verpasst“, mit definierten Übergängen.
Für den Lieferungs-Prototyp reicht eine kleine Zustandsspezifikation aus:
Leiten Sie die Garten-Postkarte aus der gewählten Route ab, anstatt einen zweiten Wert zu speichern, der ihr widersprechen könnte. Berechnen Sie ebenso die aktuell verfügbaren Aktionen aus Zustand und Regeln.
Verwenden Sie eine feste Verarbeitungsreihenfolge: Interpretieren Sie die Anfrage, validieren Sie Aktion und Parameter, berechnen Sie das Ergebnis, schreiben Sie die Zustandsänderung fest und erzählen Sie sie erst dann nach. Übermitteln Sie dem Erzähler das festgeschriebene Ergebnis und die zulässigen nächsten Aktionen. Er sollte keine zweite Berechnung erfinden.
Nach dem Einsammeln der Schleife lautet das maßgebliche Ergebnis beispielsweise: Vier Zeiteinheiten verbleiben, die Schleife ist eingesammelt und beide Routen sind bezahlbar. Der Bot kann die Farbe der Schleife beschreiben, vorausgesetzt, diese Farbe hat keine mechanische Auswirkung. Er kann keine unangekündigten Zeitkosten hinzufügen oder eine zweite Schleife vergeben.
Sie können diese Bedingungen mit einem bestehenden Narrativ-Tool prototypisch umsetzen. Inkles offizielles Interactive-Fiction-Tutorial (https://www.inklestudios.com/ink/web-tutorial/) erklärt bedingte Entscheidungen, das Nachverfolgen von bereits besuchten Inhalten, Variablen und explizite Enden. Diese Funktionen bieten eine nützliche Grundlage, um das entworfene Spiel zu testen, bevor die KI-Erzählung hinzugefügt wird.
Geben Sie Spielern Entscheidungen, die sie verstehen und beeinflussen können
Beurteilen Sie die Handlungsfähigkeit der Spieler bei diesem Entwurf danach, ob sie einen bedeutsamen Unterschied vorhersehen und ihn dann im Ergebnis beobachten können. Mehrere unterschiedlich formulierte Schaltflächen, die zu einem identischen Ergebnis führen, tragen kaum dazu bei, dies zu testen.
In *Festival-Paket* unterstützt die Routenentscheidung unterschiedliche Spielerpräferenzen:
Dies sind illustrative Berechnungen aus den genannten Regeln. Sie bieten eine einfache Entscheidungshilfe: Wählen Sie die direkte Lieferung, um früher fertig zu werden, sammeln Sie die Schleife zur Dekoration ein oder nehmen Sie die Gartenroute für die Postkarte. Die verbleibende Zeit ist hier ein Detail des Endes; sie vergibt nicht heimlich Punkte.
Wenn das Spiel später ein bestimmtes Ergebnis belohnt, legen Sie diese Punktevergabe vor der Entscheidung offen. Andernfalls können die Spieler den von Ihnen beabsichtigten Kompromiss nicht abwägen.
Unterstützen Sie Freitext neben sichtbaren Aktionen. „Nehmen wir den malerischen Weg“ kann auf die Gartenlieferung abgebildet werden. „Mach es besonders“ ist mehrdeutig: Es könnte bedeuten, die Schleife einzusammeln, die Gartenroute zu nehmen oder beides. Bitten Sie um eine kurze Klärung, ohne dabei Zeit zu verbrauchen.
Akzeptieren Sie für den ersten Prototyp eine Gameplay-Aktion pro Nachricht. Wenn der Spieler eine Sequenz anfordert, präsentieren Sie deren Schritte und fordern Sie ihn auf, die erste Aktion auszuwählen. Dies verhindert die teilweise Ausführung eines Plans, dessen spätere Schritte sich als nicht verfügbar herausstellen.
Halten Sie nicht unterstützte Anfragen informativ. Wenn der Spieler darum bittet zu fliegen, erklären Sie, dass die verfügbaren Routen die direkte und die Gartenroute sind, zusammen mit ihren Kosten. Freitext kann die Ausdrucksmöglichkeiten erweitern, während das Aktionssystem einen vorhersehbaren Rahmen an Möglichkeiten aufrechterhält.
Definieren Sie, woran sich der Bot erinnert und was er wissen kann
Unterteilen Sie das Gedächtnis in drei Ebenen mit jeweils unterschiedlichem Zweck.
Der maßgebliche Sitzungszustand speichert Ressourcen, Fortschritt, gewählte Routen und Spielenden. Er bleibt über Speichern und Neuladen hinweg erhalten und ändert sich nur durch validierte Aktionen.
Ein Sitzungs-Ereignisprotokoll zeichnet festgeschriebene Aktionen und deren Konsequenzen auf. Ein Eintrag könnte besagen, dass Aktion 2 die Schleife eingesammelt und die Zeit von fünf auf vier reduziert hat. Dies erleichtert das Debuggen und präzise Zusammenfassungen. Behalten Sie Aktions-IDs bei, damit eine wiederholte Anfrage dasselbe Ereignis nicht zweimal ausführen kann.
Der narrative Kontext enthält die jüngsten Dialoge und eine kompakte Zusammenfassung, die dazu dient, Tonfall und Kontinuität aufrechtzuerhalten. Er kann gekürzt werden, ohne den eigentlichen Spielzustand zu löschen.
Anthropics Leitfaden für effektives Kontext-Engineering (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) thematisiert sowohl das Zusammenfassen des Gesprächsverlaufs als auch das Führen dauerhafter Notizen außerhalb des Kontextfensters. Er warnt auch davor, dass bei zu radikaler Zusammenfassung wichtige Details verloren gehen können. Die gestalterische Konsequenz hieraus ist, exakte mechanische Fakten in strukturiertem Speicher zu halten und Zusammenfassungen für die Konversationskontinuität zu nutzen.
Setzen Sie sowohl Wissensgrenzen als auch Speichergrenzen. Ein Charakter sollte nur die Fakten erhalten, die er wissen darf. Wenn eine spätere Version eine versteckte Route enthält, halten Sie diese aus dem Kontext des Charakters heraus, bis die Entdeckungsbedingung erfüllt ist. Zustandsdaten, die der Spiel-Engine zur Verfügung stehen, müssen nicht alle für den Erzähler verfügbar sein.
Behalten Sie bei diesem kleinen Spiel den Fortschritt innerhalb der gespeicherten Sitzung bei und löschen Sie ihn beim Start eines neuen Durchlaufs. Vermeiden Sie es, aus einer einzelnen Routenwahl auf dauerhafte Spielerpräferenzen zu schließen. Wenn Sie eine gespeicherte Präferenz hinzufügen, beispielsweise kürzere Beschreibungen, machen Sie diese explizit und bearbeitbar.
Testen Sie das Gedächtnis mit einer konkreten Sequenz: Sammeln Sie die Schleife ein, speichern Sie, laden Sie neu, fragen Sie nach dem Status und wählen Sie die Gartenlieferung. Die Schleife muss eingesammelt bleiben, vor der Lieferung müssen vier Zeiteinheiten verbleiben und die Endzeit muss null sein.
Entwerfen Sie getrennte Reaktionen für Spielfehlschläge und Systemfehler
Ein verfehltes Ziel ist Teil des Spiels. Eine fehlgeschlagene Generierungsanfrage ist ein Implementierungsproblem. Weisen Sie ihnen unterschiedliche Konsequenzen zu.
Benennen Sie bei einem Spielfehlschlag die Regel, die den Durchlauf beendet hat. Nach dreimaligem Warten verbleiben nur noch zwei Zeiteinheiten, sodass keine der beiden Lieferrouten mehr bezahlbar ist. Beenden Sie das Spiel sofort mit einer klaren Erklärung und einer Neustartoption, anstatt den Spieler in einer unlösbaren aktiven Sitzung zu belassen.
Definieren Sie bei Implementierungsfehlern das Wiederherstellungsverhalten, bevor Sie aufwendige Erzählungen hinzufügen:
Ersetzen Sie einen unlesbaren Spielstand nicht stillschweigend durch ein neues Spiel. Das verbirgt verlorenen Fortschritt und führt zu irreführenden Folgeantworten.
Erstellen Sie für jede Aktion eine schlichte Ergebnisnachricht: was passiert ist, was sich geändert hat und was als Nächstes verfügbar ist. Die ausdrucksstarke Erzählung des Bots kann dieses Ergebnis begleiten. Bei einem Timeout oder einer widersprüchlichen Antwort ermöglicht die schlichte Nachricht dem Spieler dennoch fortzufahren.
Schließen Sie Enden mit einer genauen Rekapitulation ab. Erwähnen Sie die Schleife nur, wenn sie eingesammelt wurde, und die Postkarte nur für die Gartenroute. Generierte Prosa sollte die Nuancen beibehalten, für die sich der Spieler während der Sitzung entschieden hat.
Testen Sie zuerst die Regeln, dann die Interpretation des Bots
Testen Sie das Spiel zunächst mit fest vorgegebenem Text. Decken Sie jede Aktion, jedes Ende und jede Randbedingung ab. Fügen Sie dann den Bot hinzu und wiederholen Sie diese Tests mit unterschiedlichen Formulierungen. Dadurch lässt sich eine fehlerhafte Regel von einer falsch verstandenen Anfrage unterscheiden.
Laden Sie repräsentative Spieler dazu ein, eine Lieferung ohne Hilfestellung abzuschließen. Bitten Sie sie, vor der Entscheidung zu erklären, was sie erwarten, und danach zu beschreiben, was sich ihrer Ansicht nach geändert hat. Der Leitfaden der Nielsen Norman Group für Usability-Tests nach dem „Lautes Denken“-Prinzip (https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/) empfiehlt repräsentative Teilnehmer und Aufgaben, während die Teilnehmer das Reden übernehmen; er mahnt auch zur Vorsicht, da Moderationshinweise das Verhalten beeinflussen können.
Nutzen Sie Beobachtungen parallel zum Aktionsprotokoll. Erfassen Sie versuchte Aktionen, Klärungsbitten, unerwartete Ergebnisse und jede Diskrepanz zwischen Erzählung und festgeschriebenem Zustand. Fragen Sie getrennt voneinander ab, ob die Spieler die Optionen verstanden haben und ob es ihnen Spaß gemacht hat, zwischen ihnen zu wählen.
Kompakte Playtest-Checkliste. Beheben Sie Fehler in den Regeln und der Zustandsverarbeitung, bevor Sie die Spielwelt erweitern. Wenn die Spieler die Entscheidungen verstehen, sie aber uninteressant finden, ändern Sie die Kompromisse. Wenn ihnen die Entscheidungen gefallen, sie die Kosten jedoch nicht vorhersehen können, verbessern Sie die Darstellung. Erweitern Sie den Prototyp erst, wenn die bestehenden Entscheidungen bei verschiedenen Formulierungen, gespeicherten Sitzungen und Fehlerpfaden verständlich bleiben.