Huit agents VibeGame assemblent un jeu 2D à partir d'un prompt et devancent leurs concurrents sur GameCraft-Bench

Les équipes du laboratoire PRLab de l'Université de Nankin et du S-Lab de l'Université technologique de Nanyang ont publié VibeGame, un framework qui crée un projet de jeu 2D complet à partir d'une description textuelle et d'images de référence facultatives : code, scènes, animation, physique et configuration. En interne, une équipe de huit agents spécialisés travaille sur un projet stocké sous forme de fichiers texte, que l'agent peut lire et modifier sans éditeur graphique. Sur un sous-ensemble de GameCraft-Bench, dans le mode où le système dessine lui-même les graphismes, il a devancé d'autres harnais agentiques utilisant le même modèle de base, y compris GPT-6.1-Sol.

Pourquoi les jeux sont plus difficiles que du code ordinaire

Pour les auteurs, le jeu fait partie des logiciels les plus exigeants. Il doit maintenir un monde interactif en temps réel, conserver un style visuel cohérent et respecter des règles équilibrées. Beaucoup d'erreurs n'apparaissent qu'en jouant : les entrées du joueur, la physique, l'animation et la logique d'interaction se combinent de telle sorte qu'un projet formellement correct se brise en cours de partie.

Selon les auteurs, les approches existantes ne couvrent le problème que partiellement. Les modèles du monde comme Genie génèrent une expérience interactive à partir de vidéos, mais ne fournissent pas de code source modifiable. Les LLM intégrés aux moteurs commerciaux, comme DreamGarden pour Unreal, butent sur un état du projet dispersé entre interfaces graphiques et fichiers binaires. Quant à de nombreux systèmes agentiques, ils ne vérifient le jeu qu'à la fin, ou se contentent de s'assurer qu'il compile et se lance.

Un moteur que les agents savent lire

Les auteurs sont partis du framework web Phaser, dans lequel les projets s'expriment entièrement en texte. Pour éviter que les agents ne sèment le chaos, ils ont ajouté de la structure. Un jeu est un ensemble de scènes, configurées dans des fichiers JSON à vérification de types. Chaque scène est une hiérarchie de nœuds, et chaque nœud regroupe l'apparence, la géométrie de collision, les scripts de comportement et les paramètres. Les nœuds communs sont conservés dans des fichiers distincts. Le schéma détecte les références brisées, par exemple vers un asset manquant, avant même le lancement.

Deuxième propriété : le pilotage image par image. L'agent peut mettre le jeu en pause, l'avancer d'un nombre donné d'images, lire ou modifier la position et la vitesse des nœuds, envoyer une commande sémantique comme « appuyer sur saut » et prendre une capture d'écran. La vérification se fait ainsi au rythme de l'agent, et non en temps réel : image par image, par scripts ou par bots. Troisième propriété : le code source complet et non compressé du moteur est placé dans le répertoire du projet, afin que l'agent consulte les API exactes plutôt qu'une documentation périmée.

Une équipe qui se contredit elle-même

Les rôles sont répartis ainsi : orchestrateur, concepteur, artiste, architecte, programmeur, auditeur, joueur et relecteur. Le concepteur transforme une requête comme « un combat de boss à la Hollow Knight » en document de conception décrivant les mécaniques, la progression et les systèmes numériques. L'artiste produit concept art et assets via des modèles de génération d'images, dont GPT-Image-2, supprime l'arrière-plan et normalise les tailles. Une fois validés par l'utilisateur, le document et le concept servent de socle commun.

Le code passe par une chaîne composée de l'architecte, du programmeur, de l'auditeur et du joueur. L'auditeur vérifie statiquement le résultat avec les outils de cohérence du moteur. Le joueur lance le jeu via l'interface d'exécution (runtime) et utilise un modèle de vision pour évaluer si l'image correspond à l'intention. Une sous-tâche n'est considérée comme terminée qu'après ces deux vérifications. Enfin, un relecteur indépendant évalue le projet sur le comportement du jeu, la complétude visuelle et la cohérence, ainsi que sur la sensation de prise en main. Si un point ne passe pas, il renvoie le projet avec les motifs, et l'orchestrateur les transforme en tâches de correction.

Auto-évolution sans entraînement

Après l'acceptation d'un projet, le système en extrait une expérience réutilisable de trois types : squelettes, modules et contrats d'interaction. Un squelette est un modèle de projet exécutable pour un genre : sans assets, mais avec l'architecture du code, des valeurs déjà réglées et l'enchaînement des scènes. Les nouveaux projets adaptent et revérifient ces éléments au lieu de les copier aveuglément. Ce qui n'est pas vérifié ou qui est propre à un projet reste isolé. Les poids du modèle ne changent pas.

Les ablations montrent que retirer le moteur AI-native ou les relecteurs adverses réduit sensiblement le score global. L'expérience extraite par un modèle plus puissant aide à améliorer le résultat d'un modèle plus faible.

Ce qu'il faut garder en tête

L'évaluation porte sur un sous-ensemble de GameCraft-Bench, selon quatre axes : mécaniques de base, profondeur du contenu, partie visuelle fonctionnelle et présentation artistique. Le résultat est un score pondéré issu de l'annexe de l'article. Le texte disponible ne donne aucune valeur précise, donc l'ampleur de l'avantage sur les concurrents ne peut pas être vérifiée.

La comparaison avec les autres harnais a été menée par les auteurs eux-mêmes. Le framework est limité à la 2D et dépend de Phaser. Pour les développeurs, l'enseignement est pratique : la représentation textuelle du projet, le pilotage image par image du runtime et le rôle de relecteur indépendant sont des techniques transposables à d'autres pipelines agentiques.

Le code et la démo sont publiés sur le site du projet et dans le dépôt GitHub.