💬 NLP

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

Cet article présente GameCraft-Bench, un benchmark de 140 tâches basées sur Godot conçu pour évaluer la capacité des agents de codage à générer des jeux complets et jouables de bout en bout, révélant que les modèles frontières actuels peinent considérablement à atteindre l'exhaustivité de l'artefact et la cohérence interactive malgré l'implémentation de mécaniques reconnaissables.

Auteurs originaux : 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

Publié 2026-06-17

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : 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

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous engagiez un robot cuisinier et que vous lui donnieiez la recette d'un dîner complexe à plusieurs services. Vous ne voulez pas seulement que le robot écrive la recette sur une feuille de papier ; vous voulez qu'il cuisine réellement le repas, qu'il le dresse dans l'assiette et qu'il le serve pour que vous puissiez y prendre une bouchée et le goûter.

C'est essentiellement ce dont traite ce document, GameCraft-Bench. C'est un test pour voir si les agents de codage IA peuvent réellement « cuisiner » un jeu vidéo jouable à partir de zéro, plutôt que de simplement écrire le code de celui-ci.

Voici une décomposition des idées principales du document en utilisant des analogies simples :

1. Le problème : « La recette vs le repas »

Par le passé, lorsque nous testions l'IA sur le codage, nous vérifiions principalement si le code semblait correct sur le papier (comme vérifier si les ingrédients de la recette étaient correctement listés). Mais pour les jeux vidéo, regarder le code ne suffit pas. Un jeu doit fonctionner, les graphismes doivent apparaître, et le joueur doit pouvoir déplacer un personnage et voir ce qui se passe.

Les auteurs soutiennent que pour tester véritablement la capacité d'une IA à créer un jeu, nous avons besoin de trois choses :

La vraie cuisine (Ancrage dans le moteur) : L'IA doit travailler dans un véritable moteur de jeu (ils ont utilisé Godot, un outil gratuit très populaire), et non dans une version fictive ou simplifiée. C'est comme demander au chef d'utiliser un vrai fourneau, pas un jouet.
Le repas complet (Complétude de l'artefact) : L'IA ne peut pas simplement vous donner un ingrédient unique (comme un script pour un personnage qui saute). Elle doit livrer le jeu entier, packagé et prêt à être lancé. Sans éléments manquants.
Le test de dégustation (Vérification interactive) : On ne peut pas se contenter de regarder le plat fini ; il faut le manger. Le jeu doit être joué. Le succès de l'IA est jugé en exécutant réellement le jeu, en appuyant sur les touches et en voyant si le monde réagit correctement.

2. Le test : GameCraft-Bench

Les chercheurs ont construit une immense cuisine de test appelée GameCraft-Bench.

Le menu : Ils ont créé 140 défis différents répartis sur 15 types de jeux (comme des jeux de plateforme, des jeux de course, des jeux de stratégie et des jeux d'horreur).
Le processus :
1. On donne à l'IA une description en langage naturel (ex : « Crée un jeu de plateforme en 2D où l'on collecte des pièces et où l'on évite des ennemis »).
2. L'IA construit le jeu dans le moteur Godot.
3. L'IA doit également enregistrer une « trace de démo » — un script vidéo montant exactement comment jouer au jeu pour prouver qu'il fonctionne.
4. Un système informatique « joue » au jeu en utilisant ce script, enregistre la vidéo, puis un juge IA intelligent regarde la vidéo et attribue une note.

3. Les résultats : « Bon pour écrire, mauvais pour cuisiner »

Les résultats sont surprenants et un peu humiliants pour la communauté de l'IA. Même les modèles d'IA les plus intelligents et les plus avancés (comme Opus-4.7 et GPT-5.5) ont eu du mal.

Le score : La meilleure IA n'a obtenu qu'environ 41 % au test. La plupart ont obtenu moins de 40 %.
Ce qu'elles ont bien fait : Les IA étaient plutôt douées pour construire la « boucle de base » (core loop). Si vous demandiez un jeu où un personnage saute, le personnage pouvait généralement sauter. Elles pouvaient construire les parties du moteur.
Là où elles ont échoué : Elles ont eu du mal à assembler le tout pour en faire une expérience complète.
- Contenu manquant : Elles ont souvent créé un jeu trop court ou sans niveaux pour progresser.
- Visuels défectueux : Les graphismes étaient peut-être là, mais ils n'avaient pas de sens (ex : le joueur ne peut pas voir l'ennemi, ou l'interface utilisateur est cassée).
- L'écart de la « démo » : Beaucoup d'IA ont construit un jeu mais ont oublié d'enregistrer la « trace de démo » requise pour prouver qu'il fonctionnait. C'est comme si le chef cuisinait le repas mais oubliait de le dresser dans l'assiette pour le juge.

4. Découvertes clés (Le « Pourquoi »)

Le document a analysé pourquoi les IA ont échoué :

Voir, c'est croire : Les IA qui ont le mieux réussi sont celles qui regardaient l'écran du jeu pendant qu'elles le construisaient. Elles traitaient la sortie visuelle comme un outil de débogage. Si le personnage avait une apparence étrange, elles corrigeaient le code. Les IA qui se contentaient d'écrire du code sans regarder l'écran faisaient plus d'erreurs.
Être occupé n'est pas mieux : Un modèle d'IA (MiMo) a écrit beaucoup de code et exécuté de nombreuses commandes, mais il n'a pas obtenu un score plus élevé. C'était comme un chef qui hache des légumes furieusement sans jamais réellement cuire le plat. Faire plus de travail ne garantit pas un meilleur résultat si l'on manque l'étape finale.
Compétences différentes : Faire fonctionner la mécanique du « saut » (Mécanique) est différent de rendre le jeu esthétique (Art) ou de créer suffisamment de niveaux (Contenu). Une IA peut être bonne dans un domaine mais mauvaise dans les autres. Elles ne sont pas toutes liées entre elles.

5. Conclusion

Le document conclut que, bien que l'IA devienne très douée pour écrire du code, la création de jeux de bout en bout reste un défi massif.

Les IA actuelles peuvent construire des « fragments » de jeux ou des prototypes simples, mais elles ne peuvent pas encore transformer de manière fiable une idée créative humaine en un package de jeu complet, poli et jouable par elles-mêmes. L'écart entre « écrire du code qui semble correct » et « livrer un système qui fonctionne » est encore très large.

En bref : L'IA sait écrire la recette, mais elle apprend encore à cuisiner le repas complet et à le servir au client.

Résumé Technique : GameCraft-Bench

Définition du Problème

L'article traite du défi de la génération de jeux de bout en bout, définie comme le processus par lequel un agent autonome transforme une spécification de jeu en langage naturel ( $s$ ) en un système interactif jouable ( $G$ ) au sein d'un environnement de développement et d'exécution spécifique ( $E$ ). Contrairement aux tâches de codage traditionnelles où le succès est mesuré par la correction du code ou les tests unitaires, la génération de jeux nécessite la production d'un artefact cohérent et lançable qui répond aux entrées du joueur en temps réel.

Les auteurs soutiennent que les méthodes d'évaluation existantes ne parviennent pas à capturer toute la complexité de cette tâche. Les benchmarks actuels se concentrent souvent sur :

Des jeux basés sur le Web qui manquent de la complexité des environnements de moteurs de jeu réels.
Des éditions localisées de projets existants plutôt que sur une construction complète.
Une inspection statique du code ou des assets, ce qui échoue à vérifier le comportement réel du gameplay.

Pour y remédier, l'article formalise la génération de jeux de bout en bout comme une application $(s, E) \mapsto G$ et identifie trois desiderata critiques pour un benchmark valide :

Ancrage sur le moteur (Engine Grounding) : Le développement doit s'effectuer au sein d'un véritable moteur de jeu avec sa documentation native, ses assets et ses contraintes d'exécution.
Complétude de l'artefact : L'agent doit livrer un projet de jeu complet et lançable (incluant métadonnées, scènes, scripts et assets), et non de simples fragments de code ou des prototypes.
Vérification interactive : L'évaluation doit être basée sur l'observation des interactions de gameplay (actions du joueur et réponses du système) plutôt que sur l'analyse statique du code.

Méthodologie : GameCraft-Bench

Les auteurs instaurent ces desiderata dans GameCraft-Bench, un benchmark conçu pour évaluer les agents de codage dans le moteur Godot 4.

1. Suite de Tâches

Échelle : 140 tâches réparties en 15 familles de jeux distinctes (ex: Plateforme, Stratégie, Roguelike, Visual Novel, Tycoon).
Structure de la Tâche : Chaque tâche $\tau = (s, E, \rho)$ $τ = (s, E, ρ)$ consiste en :
- $s$ : Une spécification en langage naturel décrivant le fantasme du joueur, la boucle de gameplay centrale et les mécaniques.
- $E$ : Un environnement basé sur Godot fournissant un espace de travail, une chaîne d'outils et des assets partagés.
- $\rho$ : Une grille d'évaluation cachée utilisée par le vérificateur.

2. Pipeline d'Évaluation

Le benchmark utilise un pipeline en cinq étapes (Figure 5) :

Packaging de la Tâche : L'agent reçoit la spécification et l'environnement.
Génération par l'Agent : L'agent produit un projet Godot complet ( $G$ ) et un ensemble de traces d'interaction rejouables ( $\Pi$ ) contenant des événements clavier/souris cadencés.
Porte de Compilation (Build Gate) : Le vérificateur tente de lancer le projet. Si la compilation échoue ou si les traces sont inanalysables, le score est de zéro.
Relecture (Replay) : Le vérificateur rejoue les traces dans une instance Godot sans interface graphique (headless), enregistrant des vidéos de gameplay et échantillonnant des images (2 FPS).
Notation : Un juge multimodal évalue les preuves de gameplay par rapport à la grille cachée selon quatre catégories :
- Mécaniques Centrales (M) : Règles, transitions d'état et objectifs.
- Profondeur de Contenu (D) : Progression, variété et étendue de l'exécution.
- Visuels Fonctionnels (V) : Lisibilité, feedback et stabilité de l'interface utilisateur.
- Art & Présentation (A) : Cohérence esthétique et sensation d'œuvre "auteurisée".
- Formule du Score Final : $Score = BUILD \times (w_M M + w_D D + w_V V + w_A A)$ , avec des poids privilégiant la Profondeur de Contenu et la Présentation.

3. Sélection du Moteur

Godot a été choisi pour sa nature open-source, sa configuration légère, son workflow 2D natif, ses fichiers de scène textuels et ses capacités d'exécution en ligne de commande/headless, essentiels pour une évaluation automatisée reproductible.

Résultats Clés

Les auteurs ont évalué sept configurations d'agents de codage de pointe (incluant Claude Code, Codex, Kimi Code et Code Buddy) sur l'ensemble du benchmark.

Performance Globale : La génération de jeux de bout en bout reste largement non résolue. L'agent le plus performant (Claude Code avec Opus-4.7) a obtenu un score global de 41,46 %. La plupart des autres agents ont scoré sous la barre des 40 %, certains (comme DeepSeek-V4-Pro) descendant jusqu'à 2,15 %.
Décomposition par Catégorie :
- Mécaniques : Les agents ont été relativement meilleurs ici (ex: Opus-4.7 a obtenu 55,34 %), créant souvent des boucles d'interaction locales reconnaissables.
- Contenu & Présentation : Les scores chutent significativement pour la Profondeur de Contenu et l'Art/Présentation, indiquant que les agents peinent à assembler des mécaniques en systèmes complets, polis et cohérents.
Exécution vs Jouabilité : Bien que de nombreux agents aient atteint des taux de réussite de compilation élevés (lancement du jeu), ils ont fréquemment échoué à fournir des traces de relecture valides ou n'ont pas réussi à réaliser l'intention de gameplay au sein de ces traces, entraînant de faibles scores finaux.

Résultats Diagnostiques

Le Feedback Visuel est Critique : Les agents utilisant l'inspection d'écran rendu (ex: Kimi-K2.6) ont montré de meilleures capacités de débogage, corrigeant des problèmes tels que l'alignement de l'UI ou les mises en page de niveaux défectueuses, invisibles dans le code source seul.
Usage d'Outils $\neq$ Qualité : Un volume élevé d'appels d'outils (particulièrement les commandes shell) n'était pas corrélé à des scores plus élevés. Le succès dépendait de la capacité à boucler entre la compilation, la fourniture de traces de démo et la garantie de la jouabilité.
Factorisation Partielle : La performance dans les mécaniques, le contenu et les visuels n'était que modérément corrélée. Un agent peut produire un jeu mécaniquement fonctionnel qui manque de profondeur de contenu ou de polissage visuel.

Signification et Revendications

L'article affirme que GameCraft-Bench établit un nouveau standard pour l'évaluation des agents logiciels créatifs en déplaçant l'accent de la correction du code vers la correction du système interactif.

Contrat de Benchmark : Il définit un contrat de benchmark exigeant que les agents opèrent dans un vrai moteur, livrent des artefacts complets et soient jugés via l'interaction.
Limitations Actuelles : Les résultats démontrent que les agents de pointe actuels sont capables de générer des "fragments" de logiciels de type jeu, mais ne peuvent pas encore transformer de manière fiable des spécifications en langage naturel en expériences de jeu complètes, cohérentes et visuellement consistantes.
Paradigme d'Évaluation : Ce travail soutient que l'évaluation de systèmes créatifs exécutables nécessite une évaluation ancrée dans l'interaction (jouabilité) qui va au-delà de l'inspection statique du code, du succès de la compilation ou de la seule plausibilité visuelle.

Les auteurs soulignent que bien que le benchmark soit actuellement limité aux jeux Godot 2D et à l'évaluation visuelle (excluant l'audio), il fournit un cadre rigoureux pour diagnostiquer les lacunes spécifiques des agents actuels dans leur capacité à construire des systèmes interactifs complexes.