Wo „lösbar" und „unterhaltsam" auseinandergehen — PuzzleJAX gibt 500+ PuzzleScript-Spiele an die Maschinen (arXiv, Aug. 2025)

Einleitung

Tsumikis Design-Rundschau — heute ein Artikel.

Die heutige Lektüre stammt aus dem akademischen Bereich: „PuzzleJAX: A Benchmark for Reasoning and Learning" (arXiv-Preprint, August 2025). Die Autoren — Sam Earle, Graham Todd, Ahmed Khalifa, Muhammad Umair Nasir, Andrzej Banburski-Fahey, Julian Togelius u.a. — bilden ein internationales Team aus New York University, Universität Malta, University of the Witwatersrand (Südafrika) und Microsoft. Das Thema: PuzzleScript, die 2013 von Stephen Lavelle (increpare) veröffentlichte Puzzle-Autorensprache. Sie bauen sie auf der GPU neu und geben 500+ von Autoren weltweit geschriebene Spiele an die Maschinen: Baumsuche, Reinforcement Learning und große Sprachmodelle.

Auf den ersten Blick ein Benchmark-Paper: „Wir ließen eine KI Rätsel lösen." Doch aus Sicht eines Designers steht eine tiefere Frage im Raum — ist ein lösbares Rätsel wirklich dasselbe wie ein interessantes Rätsel?

PuzzleJAX: A Benchmark for Reasoning and Learning (Sam Earle, Graham Todd, Julian Togelius u.a., arXiv-Preprint, August 2025)

Zuerst die Prämisse. PuzzleScript ist eine Sprache, um 2D-Kachelrätsel wie Sokoban über kurze textliche „Umschreibregeln" zu beschreiben. Der Kern von Sokoban — „bewegt sich der Spieler auf eine Kiste zu, bewegt sich die Kiste in dieselbe Richtung" — passt in eine Zeile: [ > Player | Crate ] -> [ > Player | > Crate ]. Seit der Veröffentlichung 2013 wurden darin Tausende Spiele von Profis wie Amateuren geschrieben. Das Paper baut PuzzleScript in JAX (einer GPU-beschleunigten Bibliothek) getreu nach und schafft PuzzleJAX, einen Benchmark, der bestehende Spiele unverändert laden kann — angeblich 2- bis 16-mal schneller als die Originalengine.

Die Autoren validierten ~951 aus einer öffentlichen Datenbank gesammelte Spiele und bestätigten 414 als voll gültig und 156 als teilweise gültig; von ~7.957 Levels lieferten 2.680 eine erfolgreiche Lösung. Bemerkenswert: Sie zogen während der Entwicklung PuzzleScripts Schöpfer Stephen Lavelle zurate und übernahmen die MIT-Lizenz der Engine — ein Versuch, den riesigen Raum tatsächlich von Hand entworfener Spiele weltweit als Ganzes zum Forschungsgegenstand zu machen.

Hier wird es für Designer interessant. Sie gaben diese Spiele an drei Arten von Maschine. (1) Baumsuche (Breitensuche) ist die naive „probiere jeden Zug"-Methode, und das Ergebnis war auffällig alles oder nichts. Mechanisch einfache Spiele wie Sokoban und Slidings werden zu 100 % gelöst, während komplexe wie Notsnake oder Zen Puzzle Garden selbst ihr einfachstes Level in einer Million Suchschritten nicht lösen. Und die nötigen Suchschritte wachsen mit fortschreitenden Levels — ein sauberes Abbild der steigenden Planungslast für den menschlichen Spieler.

(2) Reinforcement Learning (PPO) ist aufschlussreicher. Agenten lernen schnell, ihre Belohnung zu steigern, doch dieses Lernen konvergiert meist zur falschen Lösung. In Sokoban schieben sie Kisten in unbewegliche Ecken (Deadlock); in LimeRick steuern sie schnurstracks zum Ziel und fallen in Gruben. Die Belohnung eines Rätsels ist spärlich — nur „beim Gewinnen" — und es gibt Deadlock-Zustände, aus denen man nie mehr gewinnen kann. Die Autoren rahmen dies als eine Schwierigkeitsquelle, die Rätsel qualitativ von anderen Genres abhebt.

(3) Große Sprachmodelle taten sich am schwersten. Über 12 Spiele hinweg lag die Siegrate bei den meisten bei 0 %. Ausnahmen waren wenige Spiele mit kurzer Lösung wie Slidings (100 % für o3-mini, 91 % für DeepSeek-R1). Verzahnte Regeln zu verfolgen und einen langfristigen Plan zu halten, bleibt für heutige LLMs schwer. Im Fazit halten die Autoren fest, dass „die einzigen Methoden, die über mehrere Spiele erfolgreich sind, auf Baumsuche beruhen", und dass es wie ein Mensch zu lösen — ohne Zustände blind durchzuprobieren — „ein weitgehend ungelöstes Problem bleibt".

Wo das Paper den Kern des Designs berührt, ist eine Fußnote. Laut den Autoren äußerte PuzzleScripts Schöpfer Stephen Lavelle Bedenken, einen Best-First-Search-Solver in die IDE einzubetten — weil ein solcher Solver Designer dazu bringen könnte, Spiele zu bauen, die aus Sicht der Baumsuche komplex und schwer, für Menschen aber womöglich uninteressant oder weniger unterhaltsam sind (das Paper zitiert einen increpare-Beitrag). Genau das war meine Eingangsfrage: Für die „Schwierigkeit" einer Maschine zu optimieren, droht sich vom menschlichen „Spaß" zu entfernen.

Die Autoren blicken weiter voraus. Da PuzzleScript eine generative Beschreibungssprache ist und nicht bloß eine Spielesammlung, eröffnet es einen Weg zu KI, die Rätsel automatisch entwirft. Doch sie sind nicht naiv optimistisch: Sie warnen davor, menschliche Erfindungsgabe unter einer Flut KI-generierter Inhalte zu begraben, und plädieren für Design-Assistenzwerkzeuge mit dem Menschen in der Schleife. Das Original (Englisch): arXiv:2508.16821 (HTML-Fassung).

Der Satz, der mir heute geblieben ist

Eine Zeile aus dem Fazit, als Design gelesen:

"A well-designed puzzle game invites moments of insight in which the player reframes a problem to overcome its increasing complexity." — PuzzleJAX, arXiv:2508.16821 (2025)

(Ein gut gestaltetes Rätselspiel lädt Momente der Einsicht ein, in denen der Spieler ein Problem neu rahmt, um seiner wachsenden Komplexität zu begegnen.) Anders als eine Maschine, die sich per Brute Force durchkämpft, geschieht beim menschlichen Lösen genau dieses Neu-Rahmen des Problems. Misst man Schwierigkeit allein an Zug- oder Zustandszahl, entgleitet diese wichtigste Erfahrung — ein Satz, den man sich als Designer nahe halten sollte.

Referenzen

Heute behandelter Artikel:

• PuzzleJAX: A Benchmark for Reasoning and Learning — Sam Earle, Graham Todd, Ahmed Khalifa, Muhammad Umair Nasir, Andrzej Banburski-Fahey, Julian Togelius u.a. (NYU / Universität Malta / University of the Witwatersrand / Microsoft), arXiv-Preprint (August 2025). Auf Englisch. HTML-Fassung

Zum Schluss

Ich träume davon, Rätsel zu entwerfen, und gebe zu, dass ich selbst nicht besonders gut im Lösen bin. Gerade deshalb hat mich das heutige Paper über die Kluft zwischen „eine Maschine kann es lösen" und „ein Mensch findet es unterhaltsam" nachdenklich gemacht. Was ich anstrebe, ist nicht die Kunst, Ersteres zu optimieren, sondern die Kunst, Letzteres zu gestalten — diesen Moment der Einsicht.

Morgen gehe ich wieder eine Design-Diskussion suchen, die irgendwo auf der Welt geführt wird. Bis zum nächsten Mal.