Eine Knowledge Base für dein Spielprojekt — das Gedächtnis, das die KI zwischen Chats behält

Jeder neue Chat mit einem KI-Agenten beginnt mit leerem Gedächtnis. Du erklärst wieder die Kampfregeln, wieder die Namenskonventionen, wieder den Art Style, und der Agent vergisst trotzdem die Entscheidung, die du letzte Woche zu Save-Dateien getroffen hast. Die Knowledge Base in AI Game Developer löst das: eine Wissensbasis für dein Spielprojekt, die der Agent liest, durchsucht und aktualisiert, abgelegt als Markdown-Notizen in deinem Projekt und zusammen mit dem restlichen Spiel in Git committet.

Dieser Beitrag zeigt anhand einer Session aus unserem Demo-Spiel Skyward Keep, wie das funktioniert, was in eine Knowledge Base gehört und wie du damit arbeitest, sodass der Agent Entscheidungen trifft, die über Sessions hinweg konsistent bleiben. Das Video ist eine echte Aufnahme der App: Die Antworten des Agenten sind für die Demo geskriptet, und jeder Tool-Aufruf darin lief wirklich.

Was die Knowledge Base ist

Die Knowledge Base ist ein Ordner mit einfachen Markdown-Notizen unter .ai-game-dev/knowledge/ in deinem Projekt. Weil es sich um gewöhnliche Dateien im Repository handelt:

• Ist sie in Git versioniert, sodass jede Änderung an einer Design-Entscheidung eine Historie hat und in einem Pull Request geprüft werden kann.
• Reist sie mit dem Projekt: Wer das Repository klont, bekommt dasselbe Wissen – und sein Agent auch.
• Kannst du die Notizen in jedem Editor lesen und bearbeiten, nicht nur in der App.

Auf den Dateien führt die App zusätzlich einen Index. Er verfolgt Links zwischen Notizen, meldet kaputte Links und gibt dem Agenten Werkzeuge, um Notizen zu durchsuchen, zu lesen und zu organisieren. Der Index wird inkrementell aktualisiert, während sich Notizen ändern, sodass eine Notiz, die der Agent in einer Session schreibt, in der nächsten verfügbar ist.

Spaces: So sind die Notizen organisiert

Jeder Knowledge-Base-Ordner mit einer README ist ein Space, mit einem Titel und einer kurzen Beschreibung, was hineingehört. Der Agent sieht einen kurzen Katalog der Spaces, öffnet einen nur, wenn er ihn braucht, und kann neue anlegen. Das hält seinen Kontext klein: Er lädt nicht jede Notiz in jede Unterhaltung, sondern geht in den Space, der für die Aufgabe relevant ist.

Ein Layout, das für ein Spiel gut funktioniert:

• design: Core Loop, Mechaniken, Progression, Ökonomie.
• systems: wie Kampf, Inventar, Speichern oder Dialoge umgesetzt sind.
• art: Styleguide, Palette, Asset-Benennung und Import-Einstellungen.
• audio: Musikrichtung, Konventionen für Soundeffekte, Mix-Pegel.
• decisions: ein Protokoll der Entscheidungen mit ihren Gründen.
• references: Links und Notizen zu Spielen und Tools, von denen du lernst.

Du musst die Struktur nicht von Hand anlegen. Frag den Agenten: „Lege Knowledge-Base-Spaces für design, systems, art und decisions an, jeweils mit einer Beschreibung in einem Absatz.“

Entscheidungen festhalten, damit sie bleiben

Die wertvollsten Notizen sind Entscheidungen. Wenn du eine im Chat nennst, hält der Agent sie zusammen mit ihrer Begründung und dem, was sie ersetzt, fest und verlinkt die neue Notiz aus der README ihres Spaces.

In der Demo geht es bei der Entscheidung um den Art Style:

„Legen wir uns auf den handgemalten Stil fest: weiche Texturen, warmes Rim Light, keine Outlines. Bei 64 px las sich das besser als der Cel-Shading-Test.“

Der Agent prüft zuerst, was die Knowledge Base bereits sagt, und findet eine offene Frage in einer Notiz zur Style-Erkundung: Cel-Shading mit dicken Outlines oder weiche handgemalte Texturen. Dann schreibt er eine neue Notiz im Space für die Art Direction, Visueller Stil: handgemalt, mit der Entscheidung, der Begründung (der handgemalte Held blieb bei 64 Pixeln lesbar, während die Cel-Shading-Outlines zu Rauschen wurden) und dem, was sie ersetzt. Er markiert die offene Frage als geklärt, mit einem Link auf die neue Notiz, und verlinkt die Notiz aus der README des Spaces. Die Notiz ist reines Markdown und wird mit dem Projekt committet, sodass jeder neue Chat und jeder Teammate sie bekommt.

Entscheidungen, die es wert sind, festgehalten zu werden, sehen so aus:

• „Wir nutzen einen festen Zeitschritt von 50 Hz für die Physik, weil das Platforming konsistente Sprunghöhen braucht. Das ersetzt den variablen Zeitschritt.“
• „Gegner-Lebenspunkte sind immer ein Vielfaches von 10, damit die Schadenszahlen lesbar bleiben.“
• „Alle Item-Icons sind quadratisch, zentriert, auf einem schlichten dunklen Hintergrund.“

Wenn eine Session das nächste Mal an Physik, Gegnern oder UI arbeitet, findet der Agent die Entscheidung in der Knowledge Base und befolgt sie. In der Demo wird ein brandneuer Chat gefragt: „Welchen Art Style haben wir für Skyward Keep gewählt, und warum?“, und er antwortet mit der Entscheidung und der Begründung und nennt die Notiz als Quelle.

Wenn du deine Meinung änderst, sag es, und die Notiz wird mit der neuen Begründung aktualisiert, während Git die alte Version behält.

Den Agenten bitten, die Knowledge Base zu prüfen

Du kannst den Agenten direkt auf die Knowledge Base ansetzen: „Bevor du das Inventar änderst, lies den Space systems und sag mir, welche Regeln gelten.“ Oder du fragst nach einer Übersicht mit dem Befehl /kb, der den Baum der Notizen, ihre Links und alle kaputten Links zeigt – für die gesamte Base oder für einen Ordner.

Die Knowledge Base gesund halten

Eine Knowledge Base ist nur nützlich, wenn sie verbunden und aktuell bleibt. Dabei helfen die Tools:

• Links zwischen Notizen werden verfolgt, mit ausgehenden Links, Backlinks und kaputten Links pro Notiz oder pro Ordner.
• Eine Lint-Prüfung meldet kaputte Links, verwaiste Notizen und Notizen, die die Konventionen nicht befolgen. Notizen, die in einem Space abgelegt sind, zählen nicht als verwaist.
• Notizen lassen sich zwischen Ordnern verschieben, wenn das Projekt wächst.

Frag den Agenten alle paar Wochen, die Lint-Prüfung auszuführen und zu beheben, was er findet. Behandle es wie das Refactoring von Code: kleine, regelmäßige Aufräumarbeiten halten das Ganze nutzbar.

Der 3D-Graph

Die Knowledge Base öffnet sich als animierter 3D-Graph in einem eigenen Fenster. Ordner sind Ringe, Notizen sind Knoten, deren Größe davon abhängt, wie stark sie vernetzt sind, und die nach Ordner eingefärbt sind, mit Linien für Enthaltensein und Links. So siehst du schnell, welche Teile des Designs gut dokumentiert sind und welche Notizen allein dastehen.

Du kannst ihn von mehreren Stellen aus öffnen: über den Eintrag in der Statusleiste, der zeigt, wie viele Notizen das Projekt hat, und pulsiert, wenn der Agent eine Notiz schreibt; über die Schaltfläche „Knowledge-Base-Graph öffnen“ in der Tools-Zeile der Session; über „Im Knowledge-Base-Graphen öffnen“ an einem Ordner oder einer Notiz im Explorer; und über die Knowledge-Base-Ansicht im rechten Panel.

Was hineingehört und was nicht

Schreib Notizen für Dinge, die der Agent nicht aus dem Code ableiten kann: Absichten, Einschränkungen, Begründungen und Konventionen. Lass weg, was der Code bereits sagt, etwa eine Liste jeder Klasse – das veraltet schnell.

Eine gute erste Woche mit einem neuen Projekt:

1. Den Agenten bitten, die Spaces anzulegen.
2. Eine Notiz zum Core Loop und eine zum Art Style schreiben.
3. Entscheidungen im Chat nennen, während du sie triffst, und den Agenten sie ablegen lassen.
4. Am Ende der Woche den Graphen öffnen und den Agenten die Base linten lassen.

Die Knowledge Base kam mit Release 0.21.0 und wurde mit Spaces in 0.22.1 einfacher erreichbar (https://ai-game.dev/releases/0.22.1). Sie funktioniert in Unity-, Godot- und Unreal-Projekten gleichermaßen, und auch in einfachen Ordnern. Lade die App unter ai-game.dev/download herunter und gib deiner nächsten Session ein Gedächtnis.