💬 NLP

GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?

Dieses Paper führt GameCraft-Bench ein, einen Benchmark aus 140 auf Godot basierenden Aufgaben, der darauf ausgelegt ist, die Fähigkeit von Coding-Agenten zu bewerten, vollständige, spielbare Spiele end-to-end zu generieren, wobei aufgezeigt wird, dass aktuelle Frontier-Modelle trotz der Implementierung erkennbarer Mechaniken erheblich Schwierigkeiten haben, Artefakt-Vollständigkeit und interaktive Kohärenz zu erreichen.

Ursprüngliche Autoren: Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan

Veröffentlicht 2026-06-17

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan Liu, Xin Lai, Chenxin Li, Yiduo Guo, Zhexin Zhang, Xinyuan Wang, Tianyi Bai, Ziniu Li, Benyou Wang

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie stellen einen Roboter-Koch ein und geben ihm ein Rezept für ein komplexes, mehrgängiges Abendessen. Sie wollen nicht nur, dass der Roboter das Rezept auf ein Stück Papier schreibt; Sie wollen, dass er das Essen tatsächlich kocht, anrichtet und serviert, damit Sie einen Bissen nehmen und es probieren können.

Das ist im Wesentlichen das, worum es in diesem Paper, GameCraft-Bench, geht. Es ist ein Test, um zu sehen, ob KI-Coding-Agenten tatsächlich ein spielbares Videospiel von Grund auf „kochen“ können, anstatt nur den Code dafür zu schreiben.

Hier ist eine Aufschlüsselung der Hauptideen des Papers unter Verwendung einfacher Analogien:

1. Das Problem: „Das Rezept vs. Das Essen“

In der Vergangenheit, wenn wir KI beim Programmieren getestet haben, haben wir meistens geprüft, ob der Code auf dem Papier korrekt aussah (wie die Prüfung, ob die Zutaten im Rezept richtig aufgelistet sind). Aber für Videospiele reicht es nicht aus, nur den Code anzusehen. Ein Spiel muss laufen, die Grafik muss erscheinen und der Spieler muss in der Lage sein, eine Figur zu bewegen und zu sehen, was passiert.

Die Autoren argumentieren, dass wir drei Dinge benötigen, um die Fähigkeit einer KI zu testen, ein Spiel zu erstellen:

Die echte Küche (Engine Grounding): Die KI muss in einer echten Game Engine arbeiten (sie verwendeten Godot, ein beliebtes kostenloses Tool), nicht in einer gefälschten oder vereinfachten Version. Es ist, als würde man den Koch bitten, einen echten Herd zu benutzen und keinen Spielzeugherd.
Das vollständige Essen (Artifact Completeness): Die KI darf Ihnen nicht nur eine einzelne Zutat liefern (wie ein Skript für eine springende Figur). Sie muss das ganze, verpackte Spiel liefern, das bereit zum Starten ist. Keine fehlenden Teile.
Der Geschmackstest (Interactive Verification): Man kann das fertige Gericht nicht nur ansehen; man muss es essen. Das Spiel muss gespielt werden. Der Erfolg der KI wird dadurch beurteilt, dass das Spiel tatsächlich ausgeführt wird, Tasten gedrückt werden und man sieht, ob die Welt korrekt reagiert.

2. Der Test: GameCraft-Bench

Die Forscher haben eine riesige Testküche namens GameCraft-Bench gebaut.

Das Menü: Sie erstellten 140 verschiedene Herausforderungen in 15 Arten von Spielen (wie Platformer, Rennspiele, Strategiespiele und Horrorspiele).
Der Prozess:
1. Man gibt der KI eine Beschreibung in natürlicher Sprache (z. B. „Erstelle einen 2D-Platformer, in dem man Münzen sammelt und Gegnern ausweicht“).
2. Die KI baut das Spiel in der Godot-Engine.
3. Die KI muss auch einen „Demo Trace“ aufzeichnen – ein Videoskript, das genau zeigt, wie man das Spiel spielt, um zu beweisen, dass es funktioniert.
4. Ein Computersystem „spielt“ das Spiel unter Verwendung dieses Skripts, zeichnet das Video auf und ein intelligenter KI-Richter schaut sich das Video an, um es zu bewerten.

3. Die Ergebnisse: „Gut im Schreiben, schlecht im Kochen“

Die Ergebnisse waren überraschend und ein wenig demütigend für die KI-Community. Selbst die klügsten, fortschrittlichsten KI-Modelle (wie Opus-4.7 und GPT-5.5) hatten Schwierigkeiten.

Die Punktzahl: Die beste KI erreichte nur etwa 41 % im Test. Die meisten schnitten unter 40 % ab.
Was sie gut konnten: Die KIs waren ganz gut darin, den „Core Loop“ (den Kernkreislauf) zu bauen. Wenn man sie nach einem Spiel fragte, bei dem eine Figur springt, konnte die Figur normalerweise springen. Sie konnten die Teile der Engine bauen.
Wo sie scheiterten: Sie hatten Schwierigkeiten, alles zu einem vollständigen Erlebnis zusammenzufügen.
- Fehlender Inhalt: Sie erstellten oft ein Spiel, das zu kurz war oder keine Level hatte, durch die man voranschreiten konnte.
- Kaputte Visuals: Die Grafik war vielleicht vorhanden, aber sie ergab keinen Sinn (z. B. der Spieler kann den Gegner nicht sehen, oder das UI ist defekt).
- Die „Demo“-Lücke: Viele KIs bauten ein Spiel, vergaßen aber, den erforderlichen „Demo Trace“ aufzuzeichnen, um zu beweisen, dass es funktioniert. Es ist, als würde der Koch das Essen kochen, aber vergessen, es für den Richter anzurichten.

4. Wichtige Entdeckungen (Das „Warum“)

Das Paper untersuchte, warum die KIs scheiterten:

Sehen ist Glauben: Die KIs, die am besten abschnitten, waren diejenigen, die den Spielbildschirm betrachteten, während sie das Spiel bauten. Sie nutzten die visuelle Ausgabe als Debugging-Werkzeug. Wenn die Figur seltsam aussah, korrigierten sie den Code. KIs, die nur Code schrieben, ohne auf den Bildschirm zu schauen, machten mehr Fehler.
Viel beschäftigt ist nicht besser: Ein KI-Modell (MiMo) schrieb viel Code und führte viele Befehle aus, erreichte aber keine höhere Punktzahl. Es war, als würde ein Koch Gemüse hektisch hacken, aber das Gericht nie tatsächlich kochen. Mehr Arbeit zu leisten garantiert kein besseres Ergebnis, wenn man den letzten Schritt verpasst.
Unterschiedliche Fähigkeiten: Den „Sprung“-Mechanismus zum Laufen zu bringen (Mechanik), ist etwas anderes, als das Spiel schön aussehen zu lassen (Art/Grafik) oder genügend Level bereitzustellen (Content). Eine KI kann in einem Bereich gut sein, aber in einem anderen schlecht. Diese Fähigkeiten sind nicht alle miteinander verknüpft.

5. Das Fazit

Das Paper kommt zu dem Schluss, dass KI zwar sehr gut im Schreiben von Code wird, die End-to-End-Spieleentwicklung jedoch immer noch eine massive Herausforderung darstellt.

Aktuelle KIs können „Fragmente“ von Spielen oder einfache Prototypen bauen, aber sie können noch nicht zuverlässig eine kreative Idee eines Menschen nehmen und daraus ein poliertes, spielbares, vollständiges Spielpaket erstellen. Die Lücke zwischen „Code schreiben, der richtig aussieht“ und „ein System liefern, das funktioniert“, ist immer noch sehr groß.

Kurz gesagt: Die KI kann das Rezept schreiben, aber sie lernt noch, wie man das vollständige Essen kocht und es dem Kunden serviert.

Technisches Resümee: GameCraft-Bench

Problemdefinition

Die Arbeit befasst sich mit der Herausforderung der End-to-End-Spielegenerierung, definiert als der Prozess, bei dem ein autonomer Agent eine natürliche Sprachspezifikation ( $s$ ) in ein spielbares interaktives System ( $G$ ) innerhalb einer spezifischen Entwicklungs- und Laufzeitumgebung ( $E$ ) transformiert. Im Gegensatz zu traditionellen Programmieraufgaben, bei denen der Erfolg anhand der Code-Korrektheit oder Unit-Tests gemessen wird, erfordert die Spielegenerierung die Erstellung eines kohärenten, startfähigen Artefakts, das in Echtzeit auf Spielereingaben reagiert.

Die Autoren argumentieren, dass bestehende Evaluierungsmethoden nicht in der Lage sind, die volle Komplexität dieser Aufgabe zu erfassen. Aktuelle Benchmarks konzentrieren sich oft auf:

Webbasierte Spiele, denen es an der Komplexität echter Engine-Umgebungen mangelt.
Lokalisierte Edits an bestehenden Projekten anstatt einer vollständigen Konstruktion.
Statische Inspektion von Code oder Assets, was die tatsächliche Gameplay-Verhaltensweise nicht verifiziert.

Um dies zu adressieren, formalisiert die Arbeit die End-to-End-Spielegenerierung als Abbildung $(s, E) \mapsto G$ und identifiziert drei kritische Desiderata für einen validen Benchmark:

Engine-Verankerung (Engine Grounding): Die Entwicklung muss innerhalb einer echten Game Engine mit deren nativer Dokumentation, Assets und Laufzeitbeschränkungen erfolgen.
Artefakt-Vollständigkeit (Artifact Completeness): Der Agent muss ein vollständiges, startfähiges Spielprojekt liefern (einschließlich Metadaten, Szenen, Skripten und Assets), nicht nur partielle Codes oder Prototypen.
Interaktive Verifizierung (Interactive Verification): Die Evaluierung muss auf beobachteten Gameplay-Interaktionen (Spieleraktionen und Systemreaktionen) basieren, anstatt auf statischer Code-Analyse.

Methodik: GameCraft-Bench

Die Autoren implementieren diese Desiderata in GameCraft-Bench, einem Benchmark zur Evaluierung von Coding-Agenten in der Godot 4 Engine.

1. Aufgaben-Suite

Skalierung: 140 Aufgaben in 15 verschiedenen Spielfamilien (z. B. Platformer, Strategie, Roguelike, Visual Novel, Tycoon).
Aufgabenstruktur: Jede Aufgabe $\tau = (s, E, \rho)$ $τ = (s, E, ρ)$ besteht aus:
- $s$ : Eine natürliche Sprachspezifikation, die die Spielerfantasie, den Core-Loop und die Mechaniken beschreibt.
- $E$ : Eine Godot-basierte Umgebung, die einen Workspace, Toolchain und gemeinsame Assets bereitstellt.
- $\rho$ : Ein verborgenes Evaluierungsrubrum, das vom Verifizierer verwendet wird.

2. Evaluierungs-Pipeline

Der Benchmark nutzt eine fünfstufige Pipeline (Abbildung 5):

Aufgaben-Verpackung (Task Packaging): Die Agenten erhalten die Spezifikation und die Umgebung.
Agenten-Generierung (Agent Generation): Der Agent produziert ein vollständiges Godot-Projekt ( $G$ ) und eine Menge an wiederholbaren Interaktions-Traces ( $\Pi$ ), die zeitgestempelte Tastatur-/Mausevents enthalten.
Build-Gate: Der Verifizierer versucht, das Projekt zu starten. Wenn der Build fehlschlägt oder die Traces nicht parsbbar sind, ist der Score Null.
Replay: Der Verifizierer spielt die Traces in einer Headless-Godot-Instanz ab, zeichnet Gameplay-Videos auf und sampelt Frames (2 FPS).
Scoring: Ein multimodaler Judge bewertet die Gameplay-Evidenz anhand des verborgenen Rubrums in vier Kategorien:
- Kernmechaniken (M): Regeln, Zustandsübergänge und Ziele.
- Inhaltliche Tiefe (D): Progression, Varietät und Umfang zur Laufzeit.
- Funktionale Visualität (V): Lesbarkeit, Feedback und UI-Stabilität.
- Kunst & Präsentation (A): Ästhetische Kohärenz und ein "autorisierter" (authored) Feel.
- Finale Score-Formel: $Score = BUILD \times (w_M M + w_D D + w_V V + w_A A)$ , wobei Gewichte die inhaltliche Tiefe und Präsentation priorisieren.

3. Engine-Auswahl

Godot wurde aufgrund seiner Open-Source-Natur, des leichtgewichtigen Setups, des nativen 2D-Workflows sowie der textbasierten Szenendateien und der Command-Line-/Headless-Ausführbarkeit ausgewählt, welche für eine reproduzierbare automatisierte Evaluierung essenziell sind.

Kernergebnisse

Die Autoren evaluierten sieben Frontier-Coding-Agent-Konfigurationen (einschließlich Claude Code, Codex, Kimi Code und Code Buddy) auf dem vollständigen Benchmark.

Gesamtleistung: Die End-to-End-Spielegenerierung bleibt weitgehend ungelöst. Der stärkste Agent (Claude Code mit Opus-4.7) erreichte einen Gesamtwert von 41,46 %. Die meisten anderen Agenten scoreten unter 40 %, wobei einige (z. B. DeepSeek-V4-Pro) lediglich 2,15 % erreichten.
Kategorien-Aufschlüsselung:
- Mechaniken: Agenten schnitten hier relativ besser ab (z. B. Opus-4.7 mit 55,34 %) und erzeugten oft erkennbare lokale Interaktionsschleifen.
- Inhalt & Präsentation: Die Scores sanken signifikant bei der inhaltlichen Tiefe sowie bei Kunst/Präsentation, was darauf hindeutet, dass Agenten Schwierigkeiten haben, Mechaniken zu vollständigen, polierten und kohärenten Systemen zusammenzufügen.
Ausführung vs. Spielbarkeit: Während viele Agenten hohe "Build Pass Rates" (Starten des Spiels) erzielten, scheiterten sie häufig daran, gültige Replay-Traces bereitzustellen oder die intendierte Gameplay-Logik innerhalb der Traces zu realisieren, was zu niedrigen Endscores führte.

Diagnostische Erkenntnisse

Visuelles Feedback ist entscheidend: Agenten, die gerenderte Bildschirm-Inspektionen nutzten (z. B. Kimi-K2.6), zeigten bessere Debugging-Fähigkeiten und korrigierten Probleme wie falsch ausgerichtete UIs oder fehlerhafte Level-Layouts, die im reinen Quellcode unsichtbar waren.
Tool-Nutzung $\neq$ Qualität: Hohe Volumina an Tool-Aufrufen (insbesondere Shell-Befehle) korrelierten nicht mit höheren Scores. Der Erfolg hing davon ab, den Kreislauf zwischen Build, Bereitstellung von Demo-Traces und Sicherstellung der Spielbarkeit zu schließen.
Partielle Faktorisierung: Die Leistung in Mechanik, Inhalt und Visualität war nur moderat korreliert. Ein Agent konnte ein mechanisch funktionales Spiel produzieren, dem es jedoch an inhaltlicher Tiefe oder visueller Politur mangelte.

Bedeutung und Ansprüche

Die Arbeit behauptet, dass GameCraft-Bench einen neuen Standard für die Evaluierung kreativer Software-Agenten setzt, indem sie den Fokus von der Code-Korrektheit auf die interaktive System-Korrektheit verschiebt.

Benchmark-Kontrakt: Sie definiert einen Benchmark-Kontrakt, der verlangt, dass Agenten in einer echten Engine operieren, vollständige Artefakte liefern und über Interaktion bewertet werden.
Aktuelle Limitationen: Die Ergebnisse zeigen, dass aktuelle Frontier-Agenten zwar in der Lage sind, "Fragmente" spielähnlicher Software zu generieren, aber noch nicht zuverlässig natürliche Sprachspezifikationen in vollständig spielbare, kohärente und visuell konsistente Spielerlebnisse transformieren können.
Evaluierungs-Paradigma: Die Arbeit argumentet, dass die Evaluierung ausführbarer kreativer Systeme eine interaktions-gegrundete Bewertung (Spielbarkeit) erfordert, die über statische Code-Inspektion, Build-Erfolg oder rein visuelle Plausibilität hinausgeht.

Die Autoren betonen, dass der Benchmark derzeit auf 2D-Godot-Spiele und visuelle Evaluierung (unter Ausschluss von Audio) beschränkt ist, aber einen rigorosen Rahmen bietet, um die spezifischen Lücken aktueller Agenten bei der Konstruktion komplexer interaktiver Systeme zu diagnostizieren.