Un agent peut terminer un jeu qui compile parfaitement et affiche un personnage coincé sous le sol.

Godogen part précisément de ce problème. Le projet d’Alex Ermolaev est une collection de skills et d’outils qui permet à Claude Code ou Codex de construire un jeu complet pour Godot, Bevy ou Babylon.js à partir d’une description.

Le pipeline construit le projet, génère les assets, lance le moteur et doit ensuite prouver le résultat à partir du jeu en fonctionnement, pas seulement à partir du code ou d’un exit code vert. Selon le moteur et le mode d’exécution, cette preuve peut être une URL jouable ou une courte vidéo enregistrée.

Ce dernier détail change beaucoup la nature du workflow. Dans un jeu, la compilation ne prouve presque rien sur la qualité visible de la scène.

Le résultat attendu est une preuve visuelle

Le README actuel résume sa règle par « proof over claims ». L’agent doit juger le jeu en fonctionnement et corriger ce qui ne tient pas visuellement ou dans l’interaction. Pour une exécution sans surveillance, le projet demande une courte preuve enregistrée plutôt qu’une simple affirmation que le build a réussi.

Ça révèle l’unité de validation choisie par le projet : ce que le moteur a réellement produit.

Le code qui compile n’est qu’une étape intermédiaire.

Le dépôt essaie de rester volontairement mince

Le README actuel explique aussi que le repo publié ne cherche plus à embarquer une énorme recette pour chaque moteur. Il conserve surtout un manifest runtime, un guide moteur court et le skill de génération d’assets.

L’idée est de laisser l’agent reconstruire le scaffold et la boucle de preuve à partir de ces règles plutôt que de maintenir une montagne de templates spécifiques. Godot, Bevy et Babylon.js restent des cibles différentes, mais la logique de travail commune reste compacte.

C’est un bon rappel qu’un système agentique n’est pas seulement un modèle. C’est aussi une architecture documentaire : quelle information est disponible, quand elle entre en contexte et sous quelle forme.

Les assets viennent de plusieurs générateurs

Le pipeline ne demande pas à un seul modèle de tout fabriquer.

Le README associe Gemini à certaines références et personnages, Grok aux textures et objets simples, puis Tripo3D à la conversion d’images vers des modèles 3D. Les sprites animés peuvent passer par de la génération vidéo avec détection de boucle.

Ça implique plusieurs clés API et une stack plus lourde qu’un simple skill Claude Code. Godogen exige aussi les toolchains du moteur choisi, Python, différents outils système et, selon la cible, Chromium ou un GPU pour accélérer le rendu et la capture.

Le projet est open source sous licence MIT, mais une génération complète n’est donc pas une expérience entièrement locale ou gratuite.

Il fabrique désormais trois types de jeux

Le dépôt source sait publier un repo cible pour trois moteurs.

Godot produit des projets C#/.NET avec scène, scripts et organisation d’assets. Bevy produit du Rust avec scènes définies en code et documentation locale. Babylon.js produit des projets TypeScript/Vite, avec hot reload et capture WebGL2 dans Chrome ou Chromium.

Le choix de Claude Code ou Codex intervient ensuite au moment de publier les skills dans le projet cible. Le même corpus source est rendu dans la structure attendue par l’agent sélectionné.

C’est une petite idée d’architecture intéressante : ne pas maintenir trois variantes du workflow pour trois agents. Garder une source commune et adapter le packaging à la fin.

Le jeu devient un test multimodal

Godogen reste un projet jeune. Les démos du dépôt ne remplacent pas un benchmark indépendant de qualité des jeux produits. Une génération qui fonctionne sur une machine et un prompt ne garantit rien sur la robustesse générale du système.

Mais sa boucle de validation est transférable bien au-delà du jeu vidéo.

Un agent qui fabrique une interface devrait regarder l’interface. Un agent qui modifie un graphique devrait rendre le graphique. Un agent qui prépare un PDF devrait ouvrir le PDF. Un agent qui contrôle un objet devrait recevoir un signal du monde physique.

Plus le travail possède une sortie perceptible, moins un test uniquement symbolique suffit.

Godogen l’exprime de manière presque brutale : tant que l’agent n’a pas regardé la frame, il ne sait pas vraiment ce qu’il a fabriqué.