Die Idee

Pen & Paper scheitert selten an den Spielern, sondern an der Spielleitung: Irgendjemand muss wochenlang vorbereiten, Regeln im Kopf haben und am Abend alles zusammenhalten. Die Idee hinter ai-dm ist ein virtueller Spieltisch im Browser, an dem dieser Platz von einem Menschen oder von einer KI besetzt werden kann.

Seit Anfang September baue ich daran. Nach gut drei Wochen ist die ganze Kette einmal durchgestochen: Karte mit Token und Echtzeitsynchronisation, Szeneneditor mit Wänden, Sicht und Licht, das Regelwerk D&D 5e (2024), ein 3D-Würfelbrett, ein Charakterbauer, und dahinter eine KI, die am Tisch leitet, sich an vergangene Sitzungen erinnert, zwischen den Abenden eine Zeitung über die Welt schreibt und über einen Sprachkanal mithört.

Hier steht, was ich dabei gelernt habe.

1. Die wichtigste Sicherheitsregel ist ein fehlendes Recht, kein Prompt

Das Kernrisiko jedes KI-Spielleiters ist, dass er sich überreden lässt. „Mein Zauber trifft doch, oder?“ – und das Modell gibt nach.

Mein erster Reflex war ein strengerer Prompt. Die bessere Antwort liegt in der Architektur: Jede Handlung am Tisch läuft durch dieselbe Kette aus Berechtigung → Validierung → Event → Zustand → Sicht je Empfänger. Ein menschlicher Spielleiter darf die Regel-Engine überstimmen, als sichtbares Event im Protokoll. Der KI fehlt dieses Recht schlicht. Sagt die Engine Nein, kann sie das Nein nur noch beschreiben.

Das LLM entscheidet also nie über Trefferpunkte oder Würfel. Es formuliert Anfragen an deterministischen Code und erzählt das Ergebnis. Keine Anweisung, die ein hartnäckiger Spieler umgehen kann.

2. Das Event-Log als einzige Wahrheit

Statt Zustand direkt zu verändern, schreibt der Server Events und faltet daraus den Zustand. Das hat sich mehrfach ausgezahlt:

• ▸Undo heißt: einen Batch als zurückgenommen markieren und neu falten. Kein rückwärts Anwenden, keine Sonderfälle.
• ▸Sicht je Rolle ist eine Projektion desselben Zustands. Spielleitung und Spieler sehen unterschiedliche Karten, weil der Server für jeden Empfänger eine eigene Sicht baut, und nicht, weil das Frontend etwas versteckt.
• ▸Ziehen ist Präsenz, Ablegen ist ein Event. Sechzig Positionen pro Sekunde gehören nicht ins Log, die anderen sollen die Bewegung aber trotzdem sehen.

Bewusst einfach gehalten: Bei jeder Änderung geht der vollständige Sichtzustand raus, kein Patch-System. Bei fünf Spielern sind das ein paar Kilobyte, und eine ganze Fehlerklasse fällt weg.

3. Alles, was ein Mensch tun kann, muss die KI aufrufen können

Lange habe ich den Tisch ohne KI gebaut und jede Fläche poliert, bevor die nächste stand. Dann bemerkte ich, dass die KI nie angeschlossen worden war, obwohl sie der eigentliche Grund für das Projekt ist.

Daraus wurden zwei Regeln:

• ▸Erst durchstechen, dann perfektionieren. Die ganze Kette läuft einmal, auch roh, bevor irgendetwas schön wird.
• ▸Jede Fähigkeit als Werkzeug. Am Tisch sind die Spielbefehle die Werkzeuge der KI. Für die Vorbereitung (Figuren anlegen, Karten bauen, Szenen vorbereiten) gibt es einen Katalog, aus dem ein MCP-Server automatisch seine Werkzeuge erzeugt. Eine neue Fähigkeit ist ein Eintrag im Katalog plus Route, das Werkzeug entsteht daraus.

Am Tisch spricht die KI jedes Modell mit OpenAI-kompatibler Schnittstelle an, damit ich nicht an einen Anbieter gebunden bin.

4. Mit KI-Agenten bauen heißt, Leitplanken zu bauen

Große Teile des Codes sind zusammen mit KI-Coding-Agenten (Claude Code) entstanden, oft mit mehreren parallel. Das hat die Geschwindigkeit möglich gemacht, aber auch eigene Probleme erzeugt:

• ▸Ein geteiltes Arbeitsverzeichnis geht schief. An einem Tag wurde jede der Regeln einmal verletzt, die ich hinterher aufgeschrieben habe: Ein Agent wechselt den Branch und ein anderer committet ahnungslos darauf; git add -A nimmt halbfertige fremde Arbeit mit. Die Lösung: jede parallele Arbeit in einem eigenen Git-Worktree mit eigenem Portpaar und einer Kopie der Dev-Datenbank, eingerichtet mit einem Befehl.
• ▸Fehler dort zurückmelden, wo sie entstehen. Ein Hook führt nach jeder Dateiänderung des Agenten den TypeScript-Typecheck aus, sodass Typfehler sofort auftauchen und nicht erst drei Schritte später.
• ▸Die Dokumente sind das Gedächtnis. Ein Agent kennt die letzte Sitzung nicht. Deshalb stehen jede Entscheidung und ihre Begründung in Architektur- und Plan-Dokumenten, und die Commit-Nachrichten erklären das Warum.
• ▸Ansehen statt vorstellen. Oberflächenänderungen prüfen die Agenten in einem echten Headless-Browser, mit Screenshots und gemessenen Abständen. Ein stiller Fehler in der Konsole sieht im Quelltext sonst aus wie eine Gestaltungsfrage.

5. Kleine Erkenntnisse unterwegs

• ▸Farbverwaltung in three.js: Der Hintergrund der Startseite wurde heller, sobald ein Effekt ausging. Der Grund war nicht das Licht: three.js wendet Tonwertkurve und sRGB-Umrechnung nur beim letzten Zeichnen auf den Bildschirm an. Sobald sich die Nachbearbeitungskette änderte, änderte sich auch, welche Stufe diese Umrechnung bekam. Ein fester OutputPass am Ende hat das Problem behoben.
• ▸Führen ist nicht Besitzen. Eine Figur kannte nur, wer sie steuert. Nicht-Spieler-Charaktere steuert niemand, also gehörten sie niemandem und verschwanden nach einem Umzug unauffindbar aus jeder Liste. Besitz und Befugnis sind zwei verschiedene Dinge und brauchen zwei Felder.
• ▸Rechte gehören getestet. Jede API-Route wird aus drei Blickwinkeln geprüft: Spielleitung, Spieler, Fremder. Die Identität kommt ausschließlich aus dem Token, nie aus einem Feld im Request.

Wo es gerade steht

213 Tests, Typecheck sauber, der Tisch ist ohne KI vollständig spielbar. Die ehrliche größte Unsicherheit: Bisher hat kein echtes Sprachmodell den Tisch gesehen. Alles mit KI ist gegen nachgebaute Modellserver getestet. Als Nächstes kommen echte Modellläufe und dann der erste Abend mit Freunden. Was dort hakt, bestimmt die weitere Arbeit.

Fortsetzung folgt.