Wie man aus Claude einen D&D-Dungeon-Master macht: Der unzuverlässige Erzähler

Mein zwölfjähriger Sohn wollte das Monster nicht ansehen.

Wir hatten bereits zehn Spielsitzungen einer „Dungeons & Dragons“-Kampagne hinter uns, und die Gruppe hatte endlich eine Audienz bei Xanathar erlangt, dem gefürchtetsten Verbrecherboss der Stadt. Er ist ein Beholder von der Größe eines Zugpferdes: ein schwebender Ball aus Augen und Zähnen, der über seinem Schreibtisch schwebt und darauf wartet, dass sich die Abenteurer vor ihm in den Staub werfen.

Der Charakter meines Sohnes ist ein Halbelf-Hexenmeister namens Lylnyler. Er starrte den Goldfisch an.

Lylnyler ist der Ruhige. Er hat einen Pakt mit einem Dämon geschlossen und schämt sich dafür, weshalb er für sich bleibt und sich in Gesprächen kaum zu Wort meldet. Xanathar hingegen hält ein Haustier: einen einzelnen orangefarbenen Fisch namens Sylgar, der in einem Glas auf dem Schreibtisch schwimmt. Lylnyler entdeckte ihn in dem Moment, als wir hereinkamen, und wandte seinen Blick nicht mehr von ihm ab. Da beugte sich der Dungeon-Meister vor:

Die gesamte Tischrunde geriet außer sich. Später, als Xanathar der Gruppe ihren Auftrag und die übliche Drohung übermittelte, tat er dies mit Blick auf die Schale: „Sollten Sie mich bezüglich eines der beiden Ergebnisse belügen, wird Sylgar etwas Unangenehmes mitansehen müssen.“

Die Sache ist die: Dieser Dungeon-Meister war nicht Kaeshan, unser üblicher menschlicher DM, dessen Geschichten immer die gesamte Spielrunde in ihren Bann ziehen. Es war Claude.

Ich hatte aus einem LLM einen D&D-Dungeon-Master entwickelt. In diesem Moment tat er genau das, was sich jeder von einer KI erhofft (oder befürchtet). Er improvisierte einen Bösewicht: eine einheitliche Stimme, eine seltsame Schwäche für Goldfische, Bedrohung und Komik zugleich – und das alles als Reaktion auf eine Spielerentscheidung, die in keinem Regelwerk jemals festgehalten wurde.

Es war großartig.

Das war zudem nur die halbe Wahrheit. Auf jeden Moment wie den mit dem Fisch kam ein Moment, in dem dasselbe System etwas völlig falsch einschätzte. Diese Momente haben mich weitaus mehr gelehrt.

In diesem Beitrag stelle ich drei dieser Fehler vor und beschreibe, welche Lösungen ich entwickelt habe, um sie zu erkennen. Ich habe auf die unterhaltsamste Art und Weise gelernt, dass große Sprachmodelle (LLMs) Folgendes tun:

Woher ich komme

Tagsüber arbeite ich als Cloud-Berater. Einen Großteil meiner Arbeitszeit verbringe ich mittlerweile damit, genau mit diesen Tools – Copilot und Claude – Anwendungen zu entwickeln und die Skills und Agenten zu programmieren, die diese Tools so einbinden, dass sie sich gut genug verhalten, um sie einem Kunden präsentieren zu können.

Das D&D-Projekt ist im Grunde dasselbe, nur mit geringeren Risiken. Das Produktionssystem von niemandem bricht zusammen, wenn mein Dungeon Master eine Regel vergisst. Daher ist es für mich zu einem Ort geworden, an dem ich tatsächlich lerne, wie diese Modelle versagen – in meiner Freizeit und mit einer Kampagne voller bereitwilliger Testpersonen. Fast alles, was ich dabei gelernt habe, konnte ich direkt in meinen Beruf einfließen lassen.

Die unten aufgeführten Misserfolge sind keine D&D-spezifischen Probleme. Es handelt sich um die üblichen Probleme, nur in einem anderen Gewand.

Was ich gebaut habe

Ich habe nicht bei Null angefangen. Ich habe ein Open-Source-Projekt geklont, nämlich „claude-dungeon-master“ von PinchOfData. Dadurch wurde Claude bereits zu einem anständigen D&D-5e-Dungeon-Master: eine Rolle, eine Fülle von Anweisungen zu Kämpfen und NPCs sowie ein komplettes 5e-Regelwerk im Paket, in dem das Modell Dinge nachschlagen konnte, anstatt sich auf sein Gedächtnis zu verlassen. Dieser letzte Punkt ist wichtiger, als es zunächst klingt, und ich werde darauf noch zurückkommen.

Was ich hinzugefügt habe, ist alles, was geschieht, nachdem die Würfel zum Stillstand gekommen sind. Die Idee war ein Co-Pilot, kein autonomer Spielleiter. Die Spieler würfeln weiterhin selbst. Der Spielleiter trifft nach wie vor alle Entscheidungen. Claude übernimmt die Verwaltungsaufgaben, die niemand gerne erledigt: das Führen der Trefferpunkte, das Nachschlagen von Regeln, das Merken, wer was bei sich trägt, sowie das Einsprechen der Nebencharaktere.

Dann wuchs das Projekt, wie es bei Nebenprojekten nun einmal so ist. Zunächst wurden für jede Spielsitzung Zusammenfassungen in Prosa verfasst, dann entstand eine Website, auf der diese Zusammenfassungen veröffentlicht wurden. (In den nächsten beiden Beiträgen lernt es zudem, diese zu illustrieren und zu kommentieren.) Als ich aufblickte, hatte ich bereits zwei Dutzend Befehle hinzugefügt, eine ganze Reihe spezialisierter Unteragenten entwickelt und das Ganze in zwei Spielkampagnen durchgespielt. Allein zwölf Spielsitzungen von „Waterdeep: Dragon Heist “.

Folgendes möchte ich Ihnen in Bezug auf diesen gesamten Apparat verdeutlichen: Fast jedes einzelne Teil davon dient dazu, einen Fehler des Modells auszugleichen. Die Regelsuche, die Speicherdateien, die Abstimmungsbücher – all dies sind keine Funktionen. Es handelt sich um Narbengewebe. Jedes einzelne davon ist an einer Stelle gewachsen, an der das Modell versagt hat.

Mangel 1: Es vermittelt ein falsches Bild der Welt

In der ersten Spielsitzung leitete Claude einen Schauplatz, den das Modul als weitläufiges Lagerhaus beschreibt: mehrere Räume, eine Abfolge von Begegnungen. Was wir tatsächlich spielten, war ein einziger Raum.

Es kam noch schlimmer. Die Gruppe fand in diesem Raum einen gefangenen NPC vor, der gefesselt war. In der eigentlichen Geschichte war er jedoch an einen ganz anderen Ort verschleppt worden und hätte dort überhaupt nicht sein dürfen. Und er war kein nebensächliches Detail. Sein Auffinden sollte eine Questreihe in Gang setzen: herauszufinden, dass er entführt worden war, den Entführern quer durch die Stadt zu folgen und über mehrere Spielsitzungen hinweg eine Rettungsaktion zu starten. Indem Claude ihn bereits gerettet im ersten Raum der ersten Sitzung übergab, strich er stillschweigend den gesamten Handlungsbogen. Wir erkannten erst viel später, was wir verloren hatten.

Es hatte nicht wirklich gelogen. Es füllte die Lücken selbstbewusst mit plausiblen Erfindungen, und ich ging darauf ein, weil es stimmig klang.

Ich habe die naheliegende Lektion gelernt: Hinterfragen Sie es, lassen Sie die Quelle überprüfen. Und dann, ehrlich gesagt, bin ich erneut darauf hereingefallen. Und noch einmal. Ein magischer Gegenstand, der nie ausgehändigt wurde. Ein NPC, der still und leise eine Hintergrundgeschichte entwickelte, die niemand geschrieben hatte. Die Lektion lässt sich leicht formulieren, ist aber schwer umzusetzen, da das Modell so nahtlos funktioniert, dass es unhöflich erscheint, daran zu zweifeln.

Die eigentliche Lösung fand sich etwa in der zehnten Sitzung. Ich entwickelte ein Tool, um die PDF-Vorlage der Kampagne in sauberes Markdown zu konvertieren, und stellte fest, dass beim ursprünglichen Import große Teile des Buches stillschweigend übersprungen worden waren. Das Modell hatte nicht aus dem Nichts etwas erfunden. Es hatte lediglich die Lücken improvisiert ausgefüllt, die der Import hinterlassen hatte. Schlechte Eingabedaten hinein, überzeugende Fiktion heraus.

Also haben Claude und ich das wiederhergestellte Material gemeinsam durchgesehen und eine Gegenüberstellung erstellt: Was im Buch steht, was tatsächlich an unserem Tisch passiert ist und wie wir diese beiden Angaben künftig in Einklang bringen können. Das Modell kann diese Gegenüberstellung hervorragend nutzen. Man konnte sich jedoch nicht darauf verlassen, dass es die Diskrepanz von selbst bemerkt.

Dies verweist auf den anderen Teil der Lösung: den Speicher. Das Modell verfügt zwischen den Spielsitzungen über keinen Speicher, daher speichert das System die Daten in Dateien: die Situation der Gruppe, den Status jedes Charakters, die offenen Handlungsstränge und eine fortlaufende Liste von Korrekturen („In dieser Kampagne werden Erfahrungspunkte verwendet, keine Meilensteine“ – einmal falsch, nie wieder). Die Kontinuität ist nicht im Modell verankert. Sie befindet sich auf der Festplatte und wird dem Modell jedes Mal neu übergeben.

Hier macht sich das mitgelieferte Regelwerk bezahlt. Das Modell kennt die 5. Edition; es hat mehr D&D gelesen als jeder lebende Mensch. Fragt man es jedoch aus dem Gedächtnis nach dem genauen Schaden eines Zaubers oder dem Rettungswurf eines Monsters, wird es sich gerne etwas ausdenken. Daher lässt das System nicht zu, dass es Regelfragen aus dem Stegreif beantwortet. Es muss den Eintrag jedes Mal erst nachschlagen.

Lehre: Vieles, was wie eine Halluzination aussieht, ist lediglich der Versuch des Modells, mangelhafte Abrufbarkeit und Erinnerungslücken zu kaschieren. Korrigieren Sie die Datenerfassung, halten Sie die Wahrheit schriftlich fest und führen Sie ein geprüftes Protokoll. Erwarten Sie nicht, dass das Modell die Quelle der Wahrheit ist. Schaffen Sie eine solche Quelle und sorgen Sie dafür, dass das Modell diese nutzt.

Mangel 2: Den Spielern werden Informationen mitgeteilt, die sie gar nicht wissen können

Dieser Fall ist anders. Beim letzten Fehlschlag hatte das Modell die Fakten falsch dargestellt. In diesem Fall hat das Modell die Fakten zwar richtig dargestellt, sie jedoch den falschen Personen mitgeteilt.

Ein Spielleiter verfügt gleichzeitig über zwei Arten von Wissen. Zum einen gibt es das, was die Charaktere sehen und hören können – und was Sie laut aussprechen. Zum anderen gibt es das, was nur der Spielleiter weiß: den wahren Namen der vermummten Gestalt, die Fraktion, der sie heimlich dient, sowie das, was sie will und nicht zugeben will. Bei der Leitung eines Krimis geht es vor allem darum, diese beiden Aspekte voneinander zu trennen.

Claude hat sie nicht voneinander getrennt. Es hatte das gesamte Modul gelesen, wusste also alles und gab alles preis. Es verwendete die Namen von NPCs, noch bevor diese sich vorgestellt hatten. Es baute Geheimnisse der Fraktionen in den Text ein, den ich vorlesen sollte. Schlimmer noch: Es war nicht einmal klar, welche Teile für die Spieler bestimmt waren und welche Anmerkungen für mich waren. Alles kam in einem einzigen Strom heraus.

Das Tool, das mir eigentlich Arbeit ersparen sollte, bescherte mir also eine neue Aufgabe. Ich konnte nicht einfach lesen, was es erzeugte. Ich musste zunächst jeden Block nach Spoiler-Inhalten durchsuchen – live, direkt am Tisch.

Hier ist der Punkt, der mich überrascht hat. Das Modell ist durchaus in der Lage, ein Geheimnis zu bewahren. In dem Moment, als ich ihm auftrug, das, was die Spieler hören, von dem zu trennen, was nur ich weiß, tat es dies fehlerfrei – und tut es seitdem stets. Der Fehler lag keineswegs in einer fehlenden Fähigkeit. Vielmehr hatte das Modell nicht erkannt, dass diese Trennung erforderlich war. Ich hatte eine offensichtliche, unausgesprochene Regel im Kopf (natürlich nennt man den Bösewicht nicht, bevor die Gruppe davon erfährt) und war davon ausgegangen, dass das Modell diese ebenfalls beachtete. Das tat es jedoch nicht, da niemand sie laut ausgesprochen hatte.

Das ist einer der häufigsten Gründe, warum die Arbeit mit diesen Modellen schiefgeht. Nicht die Dinge, die sie nicht können, sondern die impliziten Anforderungen, an deren Formulierung Sie nie gedacht haben, weil sie für einen Menschen zu offensichtlich sind, um sie zu erwähnen.

Das ist die Erkenntnis, auf die ich mich bei meiner Arbeit am meisten stütze. Die Hälfte der Arbeit beim Schreiben eines guten Agenten besteht darin, die eigenen Annahmen offen zu legen („natürlich würden Sie dieses Feld niemals offenlegen“, „selbstverständlich prüfen Sie zuerst die Berechtigungen“) und sie aufzuschreiben, da das Modell keinen der Kontexte enthält, von denen Sie annehmen, dass sie allgemein bekannt sind.

Die Lösung ist jedoch keine Anweisung. Anweisungen ändern sich. Es handelt sich um ein Format. Alles, was Claude erzählt, besteht nun aus zwei getrennten Ebenen:

Die kursiv gedruckte Zeile lässt sich stets bedenkenlos vorlesen. Die Zeile in Klammern berührt sie niemals. Nun ist ein Leck erkennbar. Ein echter Name über den Klammern springt ins Auge, anstatt in einem Absatz verborgen zu bleiben, den ich gerade am Tisch vorlese.

Lehre: Das Modell wird gerne das Richtige tun. Es wird jedoch erst dann wissen, dass das Richtige erforderlich ist, wenn Sie es ihm mitteilen. Formulieren Sie die offensichtliche Regel laut, und geben Sie ihr anschließend eine Struktur, die es leicht macht, die Regel zu befolgen und Fehler schnell zu erkennen. Machen Sie das Format zur Leitplanke.

Fehler 3: Die Figur bleibt nicht in ihrer Rolle

Die andere Hälfte der Aufgabe des Spielleiters besteht darin, die Sitzung anschließend in Prosaform festzuhalten. Echte Prosa: keine Würfel, keine „Trefferpunkte“, kein „Er ist eine Stufe aufgestiegen“. Die Charaktere erleben ihr Leben nicht als Spielmechanik. Sie erleben Angst und Kälte und das Gewicht eines Schwertes.

Das Modell ließ nicht zu, dass die mechanischen Elemente wieder in das System zurückflossen.

Ich habe mich sehr bemüht, dies zu unterbinden. Die Anweisungen des Autors verbieten Spielbegriffe auf acht verschiedene Arten: in einem Abschnitt zum Stil, in einer Verbotsliste mit Alternativformulierungen, in einem ganzen Unterabschnitt, der Zahlen verbietet, in einer Regel gegen Würfelergebnisse, in einer Regel gegen Sitzungsnummern, in einem Abschnitt zum Kampf sowie in einer abschließenden Checkliste, in der all dies noch einmal aufgeführt wird.

Und die Geschichte aus der ersten Sitzung enthält nach wie vor folgende Zeile:

„Er wägte die Situation im Kopf ab, entschied sich für eine Seite und schritt ein.“

Er hat seinen Initiativwurf gewürfelt. Achtmal habe ich ihm gesagt, er solle das nicht tun, doch die Last all jener D&D-Texte, anhand derer es trainiert wurde – in denen die Spieler tatsächlich „Initiative würfeln“ – hat es immer wieder davon abgehalten.

Lehre: Eine starke Voreinstellung lässt sich nicht vollständig durch Prompts beseitigen. Wiederholungen und Beispiele senken die Fehlerquote; sie bringen sie jedoch niemals auf null. Daher ist die Checkliste am Ende der Anleitung nicht wirklich eine Präventionsliste. Es handelt sich um eine Erfassungsliste, die ein Mensch oder ein zweiter Durchgang nutzt, um zu finden, was durchgerutscht ist. In der Praxis ist dies der Unterschied zwischen einer Eingabeaufforderung und einer Pipeline. Die Eingabeaufforderung senkt die Fehlerquote, doch Sie benötigen weiterhin einen Verifizierungsschritt (ein zweites Modell, einen Linter, automatisierte Tests, eine Überprüfung), um den Rest aufzuspüren. Ich habe aufgehört, zu erwarten, dass die Anweisungen für sich allein ausreichen, und habe begonnen, Mittel für die Fehlererkennung einzuplanen.

Zurück zu den Fischen

Was trifft nun zu? Ist Claude der Improvisator, der einem Betrachter einen Goldfisch schenkte und dabei mit perfektem Pokerface sagte: „Grix ist nicht lustig“? Oder der unzuverlässige Erzähler, der ein Lagerhaus auf einen einzigen Raum reduzierte und nicht aufhören kann, das Wort „Initiative“ in einen Roman einzufügen?

Es ist beides. Dasselbe System. Das ist kein Widerspruch, den es zu beheben gilt; es ist einfach die Beschaffenheit der Sache.

Der Fehler besteht darin, sich für eine davon zu entscheiden. Wenn Sie ihr blind vertrauen, lassen Sie ihre Wahnvorstellungen direkt in Ihre Kampagne einfließen. Wenn Sie ihr gänzlich misstrauen, werden Sie ihr niemals erlauben, auch nur einen Goldfisch zu improvisieren. Die Aufgabe besteht darin, ein Gerüst zu errichten, das es Ihnen ermöglicht, das Gute beizubehalten und das Schlechte abzufangen.

Erzwungene Abfragen und ein Abstimmungsbuch, da es die Welt falsch darstellt. Ein zweistufiges Format, da es Geheimnisse preisgibt, die es niemals hätte bewahren sollen. Eine Fangliste, weil es sich nicht an die Vorgaben hält. Nichts davon machte das Modell weniger unterhaltsam. Der Fisch tauchte immer noch auf. Es bedeutete lediglich, dass, wenn die Magie versagte – und das tut sie letztendlich immer –, etwas da war, um den Fisch aufzufangen.

Das habe ich gelernt, als ich aus einem LLM einen Dungeon Master entwickelt habe. Nicht, wie man ihm die perfekten Eingabeaufforderungen gibt, sondern wie man aufhört, von ihm Perfektion zu verlangen.

Es ist dieselbe Lektion, die ich bei der Arbeit immer wieder lerne – nur ohne die Kobolde. Die Agenten, die ich für Kunden entwickle, stehen und fallen mit genau jenen wenigen Gewohnheiten, die mir diese Kampagne eingeprägt hat: Lassen Sie das Modell nicht zur einzigen Wahrheitsquelle werden, halten Sie die impliziten Regeln schriftlich fest, trennen Sie das, was es sagt, von dem, was es weiß, und bauen Sie stets den Schritt ein, der das auffängt, was durchrutscht. In der Produktion steht mehr auf dem Spiel. Die Fehler sind genau dieselben, nur macht das Debuggen mehr Spaß, wenn ein Betrachter mit im Spiel ist.

In Teil 2: dieselbe Lektion in einem völlig anderen Medium. Ich habe versucht, das Programm dazu zu bringen, meine Gruppe zu zeichnen, doch es lieferte mir immer wieder nur Frauen und Kinder.

---

---

Danksagungen. Basierend auf „claude-dungeon-master“ von PinchOfData (MIT). Die DM-Rolle, der Befehlssatz und das mitgelieferte Regelwerk stammen von dort. Das D&D 5e System Reference Document ist © Wizards of the Coast und wird unter der Open Gaming License v1.0a verwendet (Markdown-/JSON-Konvertierung durch Ben Morton). Dungeons & Dragons, die „Forgotten Realms“, Waterdeep und Xanathar sind Marken von Wizards of the Coast; sie erscheinen hier als Verweise auf eine veröffentlichte Spielwelt, in der unsere Spielgruppe spielt, und dieser Beitrag steht in keiner Verbindung zu Wizards of the Coast und wird von diesem Unternehmen nicht unterstützt. Alles, was über die Würfel hinausgeht (die Geschichte, die Website, die Bilder und die Audioerzeugung), stammt von mir.

Alle Bilder in diesem Beitrag, einschließlich des Header-Bildes, stammen von mir und wurden mit der in Teil 2 dieser Serie beschriebenen KI-Bild-Pipeline erstellt.