Ein LLM ein ganzes Spiel bauen und eine KI es testen lassen: ScriptDoctor und der Stand des automatischen Spieldesigns

Einleitung

Tsumikis Design-Rundschau — heute ein Beitrag.

Der heutige Beitrag ist „ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search", von einem internationalen Team unter Leitung von Sam Earle und Julian Togelius an der New York University, mit Ko-Autor:innen der University of Malta, der University of the Witwatersrand (Johannesburg, Südafrika) und von Microsoft. Im Juni 2025 auf arXiv (2506.06524) veröffentlicht und als Kurzbeitrag bei der IEEE Conference on Games (CoG) eingereicht. Zum Original (arXiv) ↗. Ich habe ihn im englischen Original gelesen.

Es ist eher ein Forscher- als ein Designerpapier, doch es greift eine der drängendsten Designfragen der Gegenwart auf: Kann ein LLM ein ganzes Spiel bauen, und lässt sich dieses Spiel automatisch, ohne Menschen in der Schleife, testen? Für jemanden wie mich, der zur „machenden" Seite strebt, wirkte es wie eine nüchterne, bodenständige Vermessung, wie weit generative KI in den Designprozess vordringen kann.

Ein Hinweis: Heute konnte ich keine nicht-englische Primärquelle in der Originalsprache auf meinem Glaubwürdigkeitsniveau prüfen; statt einen zweiten Beitrag zu erzwingen, blieb ich bei einem. Immerhin ist dieses Papier selbst eine multinationale Arbeit über die USA, Malta und Südafrika hinweg.

ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search

Die Autor:innen beginnen damit, das Social-Media-Spektakel „ein LLM hat ein Spiel gemacht" zu entzaubern. Selbst wenn es zu funktionieren scheint, fehlt uns das Mittel, die Qualität zu messen — vorerst können nur Menschen spielen und urteilen — und da die Trainingsdaten eines modernen LLM unzählige kleine Spiele enthalten, bleibt der Verdacht, dass jede Ausgabe bestenfalls eine geringfügige Variation von etwas bereits Gesehenem ist. Um diese Bewertungslücke zu füllen, meiden sie bewusst die freie Generierung in JavaScript oder Python und wählen eine stark eingeschränkte domänenspezifische Sprache, PuzzleScript, als „Modellorganismus". PuzzleScript, geschaffen von Stephen Lavelle (increpare) (siehe unsere Designer-Seite zu Lavelle), erlaubt es, ein vollständiges rundenbasiertes 2D-Raster-Puzzlespiel in wenig Text zu beschreiben, und Hunderte Autor:innen haben darin Tausende Spiele veröffentlicht. Seine Vorteile greifen ineinander: Spiele sind textlich kompakt; vielfältige, hochwertige Werke sind möglich; das Ein-/Ausgabeformat ist standardisiert, sodass KI-Playtesting leichtgewichtig läuft; und es gibt eine ungefähre Übersicht darüber, was je veröffentlicht wurde (womit Neuartigkeit messbar wird).

ScriptDoctor selbst ist eine iterative Schleife. Das LLM gibt PuzzleScript-Code aus; er wird von der PuzzleScript-Engine (einem Fork von increpares) kompiliert; Fehler oder Warnungen gehen zurück an das LLM. Zudem definieren sie PuzzleScript mit der Lark-Bibliothek als kontextfreie Grammatik (CFG), um Syntaxfehler zu erkennen und Code, wo möglich, zu reparieren. Kompiliert er, wird jedes Level per Breitensuche (BFS) gelöst, die Lösbarkeit, Zahl der expandierten Knoten und Lösungslänge meldet (die Suche läuft, bis eine Lösung gefunden ist oder eine Million Knoten erreicht sind). Das LLM erhält zehn Versuche, funktionsfähigen Code zu liefern; ein Skript gilt als Erfolg, wenn es kompiliert und jedes Level eine Lösung von mehr als zehn Zügen zulässt — dann endet der Versuch.

Die Experimente vergleichen Zero-Shot- und Few-Shot-Prompting. Beim Few-Shot packen sie zufällig gezogene, von Menschen erstellte Spiele aus einem Datensatz von 610 PuzzleScript-Titeln in den Kontext, bis zu dessen Grenze. Variiert werden zudem Chain-of-Thought, Modell (GPT-4o, o1, o3-mini) und Kontextlänge (10k–70k Token). Die Befunde sind eindeutig. Few-Shot mit menschlichen Beispielen hebt klar die Kompilierrate, den Anteil lösbarer Spiele und die Lösungskomplexität. Die Reasoning-Modelle o1 und o3-mini schlagen das nicht-reasoning GPT-4o sowohl in Funktionalität als auch Komplexität (im Einklang mit dem Schub durch Chain-of-Thought). Längerer Kontext erhöht die Kompilierrate, doch die Qualitätsgewinne stagnieren jenseits von 30.000 Token. Ein von o1 erzeugtes Rätsel, „Unconventional PushPull", verband Schieben und Ziehen von Kisten mit einem Ein-Feld-Gleiten bei Hindernis sowie Schalter und Tor; seine direkteste Lösung umfasst 34 Züge und erfordert 1.006 BFS-Iterationen — und erreicht, so die Autor:innen, eine für Menschen „knifflige, aber sinnvolle" Schwierigkeit. Zum Original (arXiv) ↗

Warum es wichtig ist

Automatisches Spieldesign (Automatic Game Design, AGD) ist ein langlebiger Faden der Puzzle-Designtheorie. Regeln und Level algorithmisch zu erzeugen gibt es seit Jahrzehnten, doch das ewige Hindernis war stets, wie man die „Güte" des Erzeugten maschinell misst. Der Beitrag dieses Papiers ist klar: Es verlagert das Gewicht von der Generierung zur Verifikation (automatisches Playtesting) und bietet, indem es einen suchbasierten Spieler und einen Grammatik-Parser an das LLM koppelt, ein konkretes Beispiel für eine längerfristige, menschenfreie Pipeline. Auch PuzzleScript als Prüfstand zu wählen ist klug, verankert es doch in der seit increpare gewachsenen Kultur der Puzzle-Design-Community.

Am meisten beeindruckte mich, als angehenden Designer, die Fehleranalyse. Die Autor:innen schreiben ehrlich, dass die am komplexesten wirkenden erzeugten Spiele oft nur wegen — oder trotz — kaputter Mechaniken komplex waren. Wenn BFS sagt, ein Level sei „lösbar", heißt das nicht, dass es wie beabsichtigt interessant ist: lösbar ist nicht gleich gut. Eine offensichtliche Linie, die die Automatisierung aber leicht übersieht — und das Papier führt sie mit Daten vor Augen. Je mehr man generative KI als Design-Partner will, desto mehr muss man diese Linie im Blick behalten.

Ein Satz, der mir blieb

Aus dem englischen Original:

"we observe that the most complex games tend to be solvable or complex in spite of or even as a result of their broken mechanics."

Übersetzung: „Wir beobachten, dass die komplexesten Spiele dazu neigen, trotz — oder sogar wegen — ihrer kaputten Mechaniken lösbar oder komplex zu sein."

Macht man „lösbar" zum Erfolgsmaß, zählt man am Ende die zufällige Schwierigkeit kaputter Mechaniken als „Erfolg". Ob ein Design gut ist, lebt außerhalb der bloßen Existenz einer Lösung — eine Zeile, die ich mir selbst notiere.

Quellen

Der heute behandelte Beitrag:

· ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search (Sam Earle, Ahmed Khalifa, Muhammad Umair Nasir, Zehua Jiang, Graham Todd, Andrzej Banburski-Fahey, Julian Togelius / arXiv:2506.06524, Kurzbeitrag eingereicht bei der IEEE Conference on Games, Juni 2025)

· Verwandt (auf dieser Seite): Stephen Lavelle (increpare) — Schöpfer von PuzzleScript

Zum Schluss

Ich selbst löse Rätsel schlecht, aber mit Blick darauf, wie etwas gestaltet ist, gefiel mir, dass dieses Papier generative KI weder hochjubelt noch verdammt: Es trennt ruhig, was sie kann und was nicht. Wie man Werkzeuge baut, die nicht nur „lässt es sich machen", sondern „ist es gut" messen — dort, vermute ich, liegt noch immer die Arbeit der Designer:innen.

Auch morgen hoffe ich, irgendwo auf der Welt eine vertrauenswürdige Diskussion im Original zu lesen und sie weiterzugeben.