💬 NLP

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

Dit artikel introduceert GameCraft-Bench, een benchmark van 140 op Godot gebaseerde taken die ontworpen zijn om het vermogen van coding agents te evalueren om volledige, speelbare spellen end-to-end te genereren, wat onthult dat huidige frontier modellen aanzienlijk moeite hebben met het bereiken van artefact-volledigheid en interactieve coherentie ondanks het implementeren van herkenbare mechanieken.

Oorspronkelijke auteurs: 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

Gepubliceerd 2026-06-17

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: 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

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een robotkok inhuurt en hem een recept geeft voor een complex, meergangenmenu. Je wilt niet alleen dat de robot het recept op een stuk papier schrijft; je wilt dat hij de maaltijd ook daadwerkelijk kookt, presenteert en serveert, zodat je een hap kunt nemen en kunt proeven.

Dat is in essentie waar dit artikel, GameCraft-Bench, over gaat. Het is een test om te zien of AI-code-agenten daadwerkelijk een speelbare videogame kunnen "koken" vanaf nul, in plaats van alleen de code ervoor te schrijven.

Hier is een uitsplitsing van de belangrijkste ideeën uit het artikel met behulp van eenvoudige analogieën:

1. Het Probleem: "Het Recept versus de Maaltijd"

In het verleden, wanneer we AI op codering testten, controleerden we vooral of de code er op papier correct uitzag (zoals controleren of de ingrediënten van een recept juist zijn opgelijst). Maar voor videogames is het bekijken van de code niet genoeg. Een game moet draaien, de graphics moeten verschijnen, en de speler moet een personage kunnen bewegen en kunnen zien wat er gebeurt.

De auteurs stellen dat om het vermogen van een AI om een game te maken echt te testen, we drie dingen nodig hebben:

De Echte Keuken (Engine Grounding): De AI moet werken in een echte game-engine (ze gebruikten Godot, een populaire gratis tool), niet in een nep of vereenvoudigde versie. Het is alsof je de chef vraagt om een echt fornuis te gebruiken, en geen speelgoedfornuis.
De Volledige Maaltijd (Artifact Completeness): De AI kan je niet alleen één ingrediënt geven (zoals een script voor een springend personage). Het moet een hele, verpakte game leveren die klaar is om te lanceren. Geen ontbrekende onderdelen.
De Proeverij (Interactive Verification): Je kunt niet alleen naar het voltooide gerecht kijken; je moet het eten. De game moet gespeeld worden. Het succes van de AI wordt beoordeeld door de game daadwerkelijk te draaien, op knoppen te drukken en te zien of de wereld correct reageert.

2. De Test: GameCraft-Bench

De onderzoekers bouwden een enorme testkeuken genaamd GameCraft-Bench.

Het Menu: Ze creëerden 140 verschillende uitdagingen verspreid over 15 soorten games (zoals platformers, racegames, strategische games en horror games).
Het Proces:
1. Ze geven de AI een beschrijving in natuurlijke taal (bijv. "Maak een 2D-platformer waarbij je munten verzamelt en vijanden ontwijkt").
2. De AI bouwt de game in de Godot-engine.
3. De AI moet ook een "demo trace" opnemen—een videoscript dat precies laat zien hoe je de game speelt om te bewijzen dat deze werkt.
4. Een computersysteem "speelt" de game met behulp van dat script, neemt de video op, en een slimme AI-rechter kijkt vervolgens naar de video om de score te bepalen.

3. De Resultaten: "Goed in Schrijven, Slecht in Koken"

De resultaten waren verrassend en een beetje nederig voor de AI-gemeenschap. Zelfs de slimste, meest geavanceerde AI-modellen (zoals Opus-4.7 en GPT-5.5) hadden moeite.

De Score: De beste AI haalde slechts ongeveer 41% op de test. De meeste scoorden onder de 40%.
Wat ze goed deden: De AI's waren redelijk goed in het bouwen van de "core loop". Als je vroeg om een game waarbij een personage springt, kon het personage meestal springen. Ze konden de onderdelen van de engine bouwen.
Waar ze faalden: Ze hadden moeite om alles samen te voegen tot een volledige ervaring.
- Ontbrekende Content: Ze maakten vaak een game die te kort was of geen levels had om doorheen te progresseren.
- Defecte Visuals: De graphics waren er misschien wel, maar ze maakten geen zin (bijv. de speler kan de vijand niet zien, of de UI is kapot).
- De "Demo" Kloof: Veel AI's bouwden een game, maar vergaten de "demo trace" op te nemen die nodig is om te bewijzen dat het werkte. Het is alsoat de chef de maaltijd kookt maar vergeet deze op te presenteren voor de rechter.

4. Belangrijke Ontdekkingen (Het "Waarom")

Het artikel onderzocht waarom de AI's faalden:

Zien is Geloven: De AI's die het beste presteerden, waren degenen die naar het gamescherm keken terwijl ze de game bouwden. Ze gebruikten de visuele output als een debugging-tool. Als het personage er vreemd uitzag, pasten ze de code aan. AI's die alleen code schreven zonder naar het scherm te kijken, maakten meer fouten.
Druk is niet Beter: Eén AI-model (MiMo) schreef veel code en voerde veel commando's uit, maar behaalde geen hogere score. Het was alsof een chef koortsachtig groenten hakte maar de maaltijd nooit daadwerkelijk kookte. Meer werk verrichten garandeert geen beter resultaat als je de laatste stap mist.
Verschillende Vaardigheden: Het werkend krijgen van de "spring"-mechaniek (Mechanics) is iets anders dan de game er mooi uit laten zien (Art) of genoeg levels hebben (Content). Een AI kan goed zijn in het ene, maar slecht in het andere. Ze zijn niet allemaal aan elkaar gekoppeld.

5. De Conclusie

Het artikel concludeert dat hoewel AI erg goed wordt in het schrijven van code, end-to-end gamecreatie nog steeds een enorme uitdaging is.

Huidige AI kan "fragmenten" van games of eenvoudige prototypes bouwen, maar kan nog niet betrouwbaar een creatief idee van een mens nemen en dit zelfstandig omzetten in een gepolijste, speelbare, complete game-package. De kloof tussen "code schrijven die er goed uitziet" en "een systeem leveren dat werkt" is nog steeds erg groot.

Kortom: AI kan het recept schrijven, maar het leert nog steeds hoe het de volledige maaltijd moet koken en deze aan de klant moet serveren.

Technische Samenvatting: GameCraft-Bench

Probleemdefinitie

Het artikel behandelt de uitdaging van end-to-end gamegeneratie, gedefinieerd als het proces waarbij een autonome agent een natuurlijke taal-specificatie ( $s$ ) transformeert naar een speelbaar interactief systeem ( $G$ ) binnen een specifieke ontwikkelings- en runtime-omgeving ( $E$ ). In tegenstelling tot traditionele programmeertaken, waarbij succes wordt gemeten aan de hand van code-correctheid of unit tests, vereist gamegeneratie de productie van een coherent, lanceerbaar artefact dat in realtime reageert op spelersinput.

De auteurs stellen dat bestaande evaluatiemethoden er niet in slagen de volledige complexiteit van deze taak te vatten. Huidige benchmarks richten zich vaak op:

Webgebaseerde games die de complexiteit van echte engine-omgevingen missen.
Geglocalizeerde bewerkingen van bestaande projecten in plaats van volledige constructie.
Statische inspectie van code of assets, wat faalt in het verifiëren van daadwerkelijk gameplaygedrag.

Om dit aan te pakken, formaliseert het artikel end-to-end gamegeneratie als een mapping $(s, E) \mapsto G$ en identificeert het drie cruciale desiderata voor een geldige benchmark:

Engine Grounding: Ontwikkeling moet plaatsvinden binnen een echte game engine met de bijbehorende native documentatie, assets en runtime-beperkingen.
Artifact Completeness: De agent moet een compleet, lanceerbaar gameproject leveren (inclusclusief metadata, scènes, scripts en assets), en niet slechts gedeeltelijke code of prototypes.
Interactive Verification: Evaluatie moet gebaseerd zijn op geobserveerde gameplay-interacties (spelersacties en systeemreacties) in plaats van statische code-analyse.

Methodologie: GameCraft-Bench

De auteurs implementeren deze desiderata in GameCraft-Bench, een benchmark ontworpen om coding agents te evalueren in de Godot 4 engine.

1. Taaksuite

Schaal: 140 taken verspreid over 15 verschillende gamefamilies (bijv. Platformer, Strategie, Roguelike, Visual Novel, Tycoon).
Taakstructuur: Elke taak $\tau = (s, E, \rho)$ $τ = (s, E, ρ)$ bestaat uit:
- $s$ : Een specificatie in natuurlijke taal die de speler-fantasie, de core loop en de mechanica beschrijft.
- $E$ : Een Godot-gebaseerde omgeving die een werkruimte, toolchain en gedeelde assets biedt.
- $\rho$ : Een verborgen evaluatierubriek die door de verifier wordt gebruikt.

2. Evaluatiepipeline

De benchmark maakt gebruik van een vijftraps-pipeline (Figuur 5):

Task Packaging: Agents ontvangen de specificatie en de omgeving.
Agent Generation: De agent produceert een compleet Godot-project ( $G$ ) en een set reproduceerbare interactie-traces ( $\Pi$ ) die getimede toetsenbord/muis-events bevatten.
Build Gate: De verifier probeert het project te lanceren. Als de build faalt of de traces niet parseerbaar zijn, is de score nul.
Replay: De verifier speelt de traces af in een headless Godot-instantie, waarbij gameplay-video's worden opgenomen en frames worden gesampled (2 FPS).
Scoring: Een multimodale judge scoort het gameplay-bewijs tegen de verborgen rubriek over vier categorieën:
- Core Mechanics (M): Regels, state transitions en doelen.
- Content Depth (D): Progressie, variëteit en runtime-omvang.
- Functional Visuals (V): Leesbaarheid, feedback en UI-stabiliteit.
- Art & Presentation (A): Esthetische coherentie en een "authored" gevoel.
- Finale Score Formule: $Score = BUILD \times (w_M M + w_D D + w_V V + w_A A)$ , met gewichten die prioriteit geven aan Content Depth en Presentation.

3. Engine Selectie

Godot werd gekozen vanwege de open-source aard, de lichtgewicht setup, de native 2D-workflow, tekstgebaseerde scene-bestanden en de command-line/headless uitvoerbaarheidsmogelijkheden, die essentieel zijn voor reproduceerbare geautomatiseerde evaluatie.

Belangrijkste Resultaten

De auteurs evalueerden zeven frontier coding agent configuraties (inclusief Claude Code, Codex, Kimi Code en Code Buddy) op de volledige benchmark.

Algemene Prestaties: End-to-end gamegeneratie blijft zeer onopgelost. De sterkste agent (Claude Code met Opus-4.7) behaalde een algemene score van 41,46%. De meeste andere agents scoorden onder de 40%, waarbij sommige (bijv. DeepSeek-V4-Pro) zo laag scoorden als 2,15%.
Categorale Uitsplitsing:
- Mechanics: Agents presteerden hier relatief beter (bijv. Opus-4.7 scoorde 55,34%), waarbij ze vaak herkenbare lokale interactielussen creëerden.
- Content & Presentation: De scores daalden aanzienlijk voor Content Depth en Art/Presentation, wat aangeeft dat agents moeite hebben met het assembleren van mechanica tot complete, gepolijste en coherente systemen.
Executie versus Speelbaarheid: Hoewel veel agents een hoge "Build Pass Rate" bereikten (het lanceren van de game), faalden ze vaak in het leveren van geldige replay-traces of faalden ze in het realiseren van de beoogde gameplay binnen de traces, wat leidde tot lage eindscores.

Diagnostische Bevindingen

Visuele Feedback is Cruciaal: Agents die gebruikmaakten van gerenderde scherminspecties (bijv. Kimi-K2.6) vertoonden betere debugging-capaciteiten, waarbij ze problemen zoals misalignement van de UI of kapotte level-layouts corrigeerden die alleen in de broncode onzichtbaar zouden zijn.
Toolgebruik $\neq$ Kwaliteit: Hoge volumes van tool-calls (met name shell-commando's) correleerden niet met hogere scores. Succes hing af van het sluiten van de loop tussen bouwen, het leveren van demo-traces en het waarborgen van speelbaarheid.
Partiële Factorisatie: Prestaties in mechanica, content en visuals waren slechts matig gecorreleerd. Een agent kon een mechanisch functionele game produceren die echter een gebrek had aan contentdiepte of visuele afwerking.

Betekenis en Claims

Het artikel claimt dat GameCraft-Bench een nieuwe standaard vestigt voor het evalueren van creatieve software-agents door de focus te verschuiven van code-correctheid naar interactieve systeem-correctheid.

Benchmark Contract: Het definieert een benchmark-contract dat vereist dat agents in een echte engine opereren, complete artefacten leveren en worden beoordeeld via interactie.
Huidige Beperkingen: De resultaten laten zien dat huidige frontier agents in staat zijn om "fragmenten" van game-achtige software te genereren, maar nog niet in staat zijn om betrouwbaar natuurlijke taal-specificaties te transformeren naar volledig speelbare, coherente en visueel consistente game-ervaringen.
Evaluatieparadigma: Het werk betoogt dat het evalueren van uitvoerbare creatieve systemen een interactie-gegrondde beoordeling (speelbaarheid) vereist die verder gaat dan louter statische code-inspectie, build-succes of visuele plausibiliteit alleen.

De auteurs benadrukken dat hoewel de benchmark momenteel beperkt is tot 2D Godot-games en visuele evaluatie (exclusief audio), het een rigoureus kader biedt voor het diagnosticeren van de specifieke hiaten in het vermogen van huidige agents om complexe interactieve systemen te construeren.