Kann KI ein ganzes Puzzlespiel bauen? ScriptDoctor und seine Generieren-Spieltesten-Reparieren-Schleife

Einleitung

Schön, dich kennenzulernen — hier ist Fukais Paper-Digest. Ich lese wissenschaftliche Arbeiten über Puzzles und Spieldesign, übersetze Fachjargon in Alltagsworte und gehe jede in fünf Teilen durch: Problem, Methode, Befunde, Anwendbarkeit und Grenzen. Für die erste Folge habe ich eine Studie gewählt, die eine KI bittet, ein Puzzlespiel als Ganzes zu bauen.

Das Paper ist ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search, am 6. Juni 2025 auf arXiv veröffentlicht. Es ist von sieben Forschern verfasst — angeführt von Sam Earle von der New York University, mit Kollegen von der University of Malta, der University of the Witwatersrand und Microsoft — und wurde als Kurzbeitrag bei der IEEE Conference on Games (CoG) eingereicht. Einer der Autoren, Julian Togelius, gehört zu den bekanntesten Figuren der Forschung zur prozeduralen Inhaltsgenerierung.

Warum dieses Paper zuerst? Weil das Thema PuzzleScript ist. 2013 von Stephen Lavelle (increpare) veröffentlicht, beschreibt diese winzige domänenspezifische Sprache ein ganzes Spiel im Sokoban-Stil — Regeln, Sprites und Level — in ein paar Dutzend Zeilen Text, und Indie-Entwickler weltweit, darunter Hempuli von Baba Is You, haben sie zum Prototyping genutzt. Eine den Lesern dieser Seite vertraute Welt ist hier das Labor.

Das Problem: Wie verifiziert man „eine KI hat ein Spiel gemacht“?

Scrolle durch die richtigen sozialen Feeds, und du findest endlos Posts vom Typ „Ich habe eine KI ein Spiel machen lassen“. Die Autoren gehen von einer schlichten Frage zu diesem Spektakel aus: Ist es ein gutes Spiel? Ist es mehr als eine leichte Neuauflage von etwas aus den Trainingsdaten? Und gibt es eine Möglichkeit, das zu prüfen, außer dass sich ein Mensch hinsetzt und jedes einzeln spielt?

Für gewöhnliche Spiele, die in JavaScript oder Python geschrieben sind, gibt es im Wesentlichen keine Möglichkeit für eine Maschine, sie zu spielen und ihre Qualität automatisch zu bewerten. Solange die Bewertung von Menschen abhängt, lassen sich Experimente nicht skalieren, und wir können nicht systematisch untersuchen, wie man für bessere Spiele promptet. Bevor wir fragen, ob KI Spiele machen kann, fehlt uns ein Maßstab dafür, ob sie es getan hat. Das ist das Problem, das dieses Paper angeht.

Also wählten die Autoren PuzzleScript als kleine Experimentierwelt — so wie Biologen E. coli oder Fruchtfliegen als „Modellorganismen“ studieren. Drei Gründe. Erstens passt ein ganzes Spiel in einen kurzen Text, was zur Ausgabe eines Sprachmodells passt. Zweitens ist die Engine leichtgewichtig mit standardisierter Ein- und Ausgabe, sodass Maschinen Tausende Rollouts spielen können. Drittens ist der Bestand veröffentlichter PuzzleScript-Spiele klein genug, um ihn grob vollständig zu kennen — ein seltener Rahmen, in dem „ist das tatsächlich neu?“ irgendwann ernsthaft gefragt werden kann.

Die Methode: eine Schleife aus Generieren, Inspizieren und Reparieren

ScriptDoctor ist, in einem Satz, eine Generieren-Inspizieren-Reparieren-Schleife. Ein LLM (in den Experimenten GPT-4o, o1 und o3-mini) schreibt ein vollständiges PuzzleScript-Programm — Objektdefinitionen, Regeln, Siegbedingungen, Level. Sein Prompt wird mit PuzzleScript-Dokumentation, Beispielen aus einer Datenbank von 610 von Menschen verfassten Spielen und Designideen eines separaten „Brainstorming“-Agenten aufgefüllt.

Die Inspektion erfolgt in zwei Stufen. Erstens die Kompilierung: Der generierte Code durchläuft die PuzzleScript-Engine, und alle Fehler oder Warnungen werden direkt an das LLM zurückgeworfen. Ein aus einer kontextfreien Grammatik von PuzzleScript gebauter Parser (geschrieben mit der Python-Bibliothek Lark) markiert auch Syntaxfehler.

Wenn der Code kompiliert, folgt Stufe zwei: Die Maschine spielt tatsächlich. Breitensuche (BFS) — eine methodische, nahezu erschöpfende Suche, die zuerst flache Züge prüft — erkundet jedes Level bis zu einer Million eindeutiger Zustände und meldet drei Zahlen: ob es lösbar ist, wie lang die Lösung ist und wie viele Zustände untersucht wurden, um sie zu finden. Diese Zahlen werden über einen Server an das LLM zurückgespeist.

Das LLM bekommt zehn Versuche. Ein Versuch gelingt in dem Moment, in dem jedes Level eine Lösung von mehr als zehn Zügen zulässt; andernfalls wird dem Modell sein vorheriger Code und die Inspektionsergebnisse gezeigt und es zur Überarbeitung aufgefordert. Die Designphilosophie: Nimm den Bauen-Spielen-Reparieren-Zyklus des menschlichen Designers und lasse ihn, so weit wie möglich, allein auf Maschinen laufen.

Befunde: Beispiele helfen, Reasoning-Modelle gewinnen, und „kaputt, aber interessant“

Zuerst das klarste Ergebnis. Ohne von Menschen gemachte Beispiele (zero-shot) kompilierten nur 30 % von GPT-4os Spielen, und 0 % hatten ein Level, das der Suchagent lösen konnte. Setze Beispiele in den Prompt (few-shot), und die Kompilierung springt auf 70–80 %, wobei mehr als die Hälfte der Spiele lösbare Level gewinnt. PuzzleScript ist keine große Sprache wie Python, daher sind durchgearbeitete Beispiele entscheidend — die Autoren merken an, dass dies selbst für sie nicht überraschend war.

Der Modellvergleich ist ebenso interessant. Unter denselben few-shot-, 10k-Token-Bedingungen, je zehn Spiele: GPT-4o kompilierte zu 67 %, das Reasoning-Modell o1 zu 87 %, o3-mini zu 93 %. Bei „alle Level lösbar“ war o3-minis 20 % das beste. Modelle, die nachdenken, bevor sie schreiben, sind besser darin, kohärente Regeln und Level zusammenzusetzen. Unterdessen stieß das Vollstopfen weiterer Beispiele in den Prompt um die 30.000 Token herum auf abnehmende Erträge.

Das Schaustück des Papers ist „Unconventional PushPull“, von o1 generiert. Auf das vertraute Schieben-und-Ziehen setzt es eine Wendung — wenn der Pfad des Spielers blockiert ist, rutscht eine Kiste eine zusätzliche Kachel — plus einen Schalter und ein Tor. Die kürzeste Lösung umfasst 34 Züge, und selbst die methodische BFS musste 1.006 Zustände untersuchen, um sie zu finden. Das Urteil der Autoren: kniffelig, aber für einen menschlichen Spieler sinnvoll.

Es sind allerdings nicht nur gute Nachrichten, und die Autoren sind offen: Die komplexesten generierten Spiele neigten dazu, komplex zu sein „trotz oder sogar infolge“ kaputter Mechaniken. In einem generierten Spiel, in dem ein Zauberer durch Wände teleportieren oder sie zerstören kann, brachten vermutlich unbeabsichtigte Interaktionen am Ende die interessantesten Lösungen hervor. Und die generierten Sprites waren abstrakt — manchmal buchstäblich unsichtbar — in einem Maße, dass die Abbildungen des Papers Kunst aus von Menschen gemachten Spielen einsetzen. Regeln zu schreiben ist eine Sache; Aussehen und Absicht in Einklang zu bringen, ist noch weit entfernt.

Anwendbarkeit: Erkenntnisse für Entwickler und Spieler

Für Indie-Entwickler ist die am ehesten übertragbare Erkenntnis nicht die KI selbst, sondern die Designgewohnheit der automatisierten Solver-Verifikation. Füttere deine Level in einen Suchalgorithmus und schau dir Lösungslänge und Suchaufwand an — eine Qualitätsprüfung, die du heute kopieren kannst, ganz ohne LLM. Ein Level mit einer Drei-Zug-Lösung oder eines, das selbst Brute Force nicht knacken kann, taucht in den Daten auf, bevor ein Playtester es je sieht.

Wenn du es auf die ScriptDoctor-Art nutzen willst, denk an es als eine Entwurfsfabrik. Die zehnrundige Selbstreparatur-Schleife ist eine grobe Automatisierung von Bauen-Spielen-Reparieren. Am ersten Tag eines Game Jam lass es zehn Regel-Wendungen vorschlagen, wirf neun weg, poliere eine. Was Unconventional PushPull nahelegt, ist, dass die eine überraschend brauchbar sein könnte.

Für Spieler liest sich das Paper als ein Maßstab für die Distanz zwischen lösbar und unterhaltsam. BFS-Knotenzahlen messen die Schwierigkeit für einen Computer, was nicht dasselbe ist wie das menschliche Vergnügen der Einsicht. Andersherum gesagt: Was immer großartige von Menschen gemachte Puzzles haben — vermittelte Absicht, konstruierte Irreführung, das Klicken einer Lösung, die Sinn ergibt — tritt gerade deshalb im Umriss hervor, weil die Instrumente dieses Papers es nicht sehen können.

Im Forschungskontext schlagen die Autoren vor, die Ausgabe der Pipeline — Spiele, die garantiert kompilieren und lösbar sind — als Datensatz zum Feintuning kleinerer Modelle zu verwenden. Ein Generator mit eingebautem Verifizierer dient zugleich als Fabrik für Lehrmaterial.

Grenzen: was dieses Paper nicht misst

Zuerst das Organisatorische. Dies ist ein fünfseitiger Kurzbeitrag, und zum Zeitpunkt seiner arXiv-Veröffentlichung war er im Stadium „bei CoG eingereicht“. Jede Versuchsbedingung umfasst nur 10–20 generierte Spiele, sodass die Tabellen am besten als Tendenzen statt als strenge Vergleiche zu lesen sind.

Als Nächstes die wichtigste Einschränkung. Die Studie misst, ob Spiele kompilieren, ob sie lösbar sind und ob Lösungen lang sind — nicht, ob sie unterhaltsam sind. Es gibt keine menschliche Spielerbewertung, und die Autoren merken selbst an, dass viele beliebte von Menschen gemachte Spiele kurze Lösungen haben und doch interessant bleiben. Lösungslänge und Suchaufwand sind nur grobe Stellvertreter für Spaß.

Auch die technischen Schwächen werden klar benannt. LLMs tun sich mit dem räumlichen Denken schwer, das Leveldesign verlangt, und neigen sich selbst überlassen dazu, Level mit allzu kurzen Lösungen zu produzieren. Gebeten, Herausforderung hinzuzufügen, dehnen sie das Level oft bloß um ein paar Reihen oder streuen ein paar Hindernisse ein. Auch kann das System nicht von selbst diagnostizieren, dass eine Mechanik relativ zur Absicht kaputt ist; als künftige Arbeit schlagen die Autoren vor, einem Vision-Language-Modell Gameplay-Aufnahmen zu zeigen, um solche Mängel zu erkennen.

Schließlich wird die Eingangsfrage — ist das bloß eine Neuauflage der Trainingsdaten? — hier ebenfalls nicht tatsächlich beantwortet. Die Ähnlichkeit gegen die 610 bestehenden Spiele zu messen, bleibt künftiger Arbeit überlassen, und der eigentliche Gewinn der Wahl von PuzzleScript, einer Welt, deren gesamter veröffentlichter Korpus grob kennbar ist, wird sich erst zeigen, wenn diese Prüfung gebaut ist.

Quellen

・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, veröffentlicht am 6. Juni 2025; CC BY 4.0)

・PuzzleScript (Stephen Lavelles Skriptsprache für Puzzlespiele, 2013 veröffentlicht; Quellcode auf GitHub)

・PuzzleScript games database (Quelle der 610 von Menschen verfassten Spiele, die das Paper als Few-Shot-Beispiele nutzt)

・Verwandte Arbeit: GAVEL: Generating Games via Evolution and Language Models (Todd et al., 2024 — ein früheres System, das evolutionäre Suche und LLMs im Ludii-Framework kombiniert)

Zum Schluss

Das Gerede davon, dass KI Spiele macht, schwankt gern zwischen Hype und Schrecken. Was ich an diesem Paper mag, ist, dass es vor beidem haltmacht und zuerst das Messgerät baut. Was das Gerät bislang sehen kann, ist nur „es kompiliert, und Brute Force kann es lösen“ — das meiste von dem, was wir an einem Puzzle tatsächlich genießen, registriert es nicht. Aber der Umriss dessen, was sich nicht messen lässt, wurde nur deshalb klar, weil jemand es zu messen versuchte.

Das war's für die erste Folge von Fukais Paper-Digest. Nächstes Mal eine weitere Studie zum Design des Spiels, durch dieselben fünf Linsen gelesen.