Pourquoi nous avons créé SimEngine, un moteur de jeu pensé pour l'IA

SimEngine est un nouveau moteur de jeu généraliste en C++20 et Vulkan 1.3, destiné à être publié en open source sous licence MIT OU Apache-2.0. Il existe parce que notre jeu spatial avait besoin de plus d’échelle, de qualité visuelle et de performances mesurables que ce qu’un moteur généraliste nous offrait confortablement. Surtout, c’est un moteur de jeu pensé pour l’IA : ses premiers utilisateurs sont des agents de code. Son interface est donc faite de commandes typées, d’exécutions headless déterministes, de captures et de résultats vérifiables, pas d’un éditeur visuel.

SimEngine est en pré-version : 13 des 56 tâches d’implémentation sont terminées, et on ne peut pas encore publier de jeu avec. Cet article explique pourquoi il existe, ce qu’il fait déjà et ce qu’il coûte. Le moteur livré n’appelle jamais de modèle d’IA : l’IA pilote le développement, pas votre jeu.

Tout est parti d’un jeu spatial

SpaceSim: Pale Blue Dot, notre jeu spatial à l’échelle réelle, a été construit avec Godot. Godot est un moteur formidable : ouvert, léger, avec un format de scène en texte et une communauté que nous aimons. Il nous a menés étonnamment loin.

Mais le jeu que nous voulions vraiment se situe quelque part entre Kerbal Space Program et SpaceEngine. On construit un véhicule sur une base planétaire détaillée, on traverse l’atmosphère, on atteint l’orbite, on rejoint un second corps et on se pose sur un terrain détaillé. Le même univers, le même véhicule et le même état de simulation doivent survivre à tout le voyage, et à une sauvegarde au milieu.

Faire cela avec des visuels de niveau AAA et des performances mesurables oblige à maîtriser ce qu’un moteur généraliste garde, à juste titre, générique : l’imbrication des repères, la précision locale à des millions de kilomètres de l’origine, le streaming du terrain, la façon dont le rendu consomme l’état de la simulation. On peut tordre un moteur autour de ces problèmes, mais à un moment, on se bat contre l’architecture au lieu de construire le jeu.

Cela aurait pu justifier un moteur sur mesure pour un seul jeu. Pas SimEngine, un moteur généraliste que nous comptons publier en open source. C’est la seconde raison qui l’a justifié.

Qui écrit vraiment le code

L’essentiel de notre code est désormais écrit par des agents de code, avec un humain qui dirige, relit et décide. En observant ces agents travailler dans des moteurs traditionnels, un même schéma revient. Les modèles sont compétents, mais les interfaces ont été conçues pour des humains :

• l’état réel d’une scène vit dans un éditeur que l’agent ne voit pas ;
• les fichiers sont binaires, ou truffés de GUID qui rendent les diffs illisibles ;
• « lancer le jeu et vérifier que ça a l’air bien » est une étape humaine ;
• le succès se réduit souvent à « ça compile », ce qui ne prouve pas grand-chose.

La réponse du secteur a été de greffer l’IA sur l’éditeur : assistants, panneaux de chat et, plus récemment, des passerelles MCP vers Unity et Unreal. C’est utile, et cela va s’améliorer. Mais cela branche un agent sur un outil conçu autour d’une souris.

Nous avons posé la question inverse : à quoi ressemblerait un moteur si l’agent en était le premier utilisateur dès le premier jour ? Notre dossier d’architecture le dit sans détour. Si ce qui distingue le moteur, c’est qu’un LLM peut construire et valider un jeu avec, alors la boucle d’itération de l’agent est une décision d’ingénierie de premier plan, soumise à la même exigence de preuve que le backend graphique.

Cela change aussi la notion de performance. Le temps de frame compte toujours, mais pendant le développement, le chiffre qui domine est le coût par changement accepté : combien de temps, combien d’essais et combien d’interventions humaines il faut pour qu’un changement d’agent soit prouvé correct. Le plus souvent, ce coût, c’est la boucle compiler, lancer, valider.

Ce que « pensé pour l’IA » veut dire, et ne veut pas dire

Pour SimEngine, « AI-first » désigne une liste précise de propriétés d’ingénierie :

1. Une interface typée et découvrable. Un agent lance simengine_host --capabilities et reçoit un seul document JSON : versions de schéma, commandes, composants et modules. Les commandes déclarent unités, repères, préconditions et erreurs. Les commandes d’un module désactivé n’existent tout simplement pas.
2. Des exécutions headless déterministes. Un scénario a une graine, un calendrier de ticks, des commandes planifiées et des attentes. Il tourne sans fenêtre et renvoie PASS ou un échec codé avec l’étape fautive, plus une empreinte final_state_sha256 de l’état final.
3. Des yeux. simengine_capture rend la même scène hors écran via Vulkan, en PNG accompagné d’un manifeste : l’agent peut regarder l’image. Quand une image est attendue, une capture absente ou noire est un échec, pas un haussement d’épaules.
4. L’isolation. Les agents travaillent en parallèle dans des worktrees et des dossiers de build séparés. Les candidats sont intégrés un par un, et le moteur stable ne charge jamais un artefact à moitié construit.
5. Des skills fournies. Chaque nouveau projet embarque des skills d’agent pour créer, modifier et diagnostiquer une scène. Ouvrez le dossier dans Claude Code ou Codex et l’agent connaît le workflow.

Voici ce qu’un agent écrit concrètement : une commande planifiée et l’attente qui prouve qu’elle a fonctionné. Unités et repères sont explicites, rien ne dépend d’un état d’éditeur caché.

{ "at_tick": 60, "command": "simengine.entity.set_position", "version": 1,
  "args": { "entity": "ball",
            "position": { "value": [0.25, 1, -1], "unit": "m", "frame": "world" } } }

{ "name": "ball_on_table", "entity": "ball", "quantity": "position",
  "value": { "value": [0.25, 1, -1], "unit": "m", "frame": "world" },
  "tolerance": { "value": 0, "unit": "m" } }

Et tout aussi délibérément, voici ce que cela ne veut pas dire :

• Pas de LLM dans le moteur. Le moteur, les exemples et les tests n’ont jamais besoin d’un compte, d’une clé d’API ou d’un SDK de fournisseur. Aucune frame n’attend un modèle.
• Pas d’enfermement chez un fournisseur. Tout agent capable de lancer une commande et de lire du JSON fonctionne : Claude Code, Codex, Cursor, Copilot, Gemini CLI.
• Pas de gadget « prompt vers jeu ». C’est un moteur natif avec une architecture explicite, pas un générateur dans le navigateur.
• Pas de chiffres magiques. Nous ne prétendons pas que l’API « élimine les hallucinations » ni qu’elle économise une part fixe de tokens. La productivité se mesure par changement accepté, sur un corpus de tâches fixe, face à une référence.

Cinq décisions qui ont façonné le moteur

1. Un backend Vulkan 1.3 direct et fin

Nous avons évalué un framework de rendu multiplateforme existant (The Forge) et l’avons écarté, en notant ce qui nous ferait revoir ce choix. Un backend fin que nous maîtrisons est plus simple à comprendre, à instrumenter et à lire de bout en bout pour un agent. La première scène PBR a été rendue hors écran et vérifiée de façon indépendante sur une RTX 4070 Ti sous Windows.

2. Un petit cœur, des modules optionnels exclus à la compilation

Les dépendances ne vont que vers le bas : application, puis modules, puis cœur. Un module désactivé n’est ni compilé, ni lié, ni enregistré : pas de système dormant, pas de travail surprise au démarrage, pas de commande que l’agent pourrait appeler sans devoir le faire.

3. Généraliste dès le premier jalon

La généralité se teste, elle ne se suppose pas. Le premier exemple est une cour avec une table, des caisses et des tonneaux, construite via le cœur public avec les modules spatiaux désactivés. SpaceSim est l’application de référence exigeante. Ce n’est pas la raison d’être du cœur.

4. Les scénarios font foi

Chaque changement d’un agent peut s’exprimer comme un scénario : entrées avec graine, commandes planifiées, résultats attendus. Deux exécutions donnent la même empreinte : une régression a une signature, et un rapport de bug est un fichier, pas un paragraphe.

5. La preuve avant le « terminé »

La feuille de route est un fichier de données validé. L’outil de suivi rejette les exigences inconnues, les cycles de dépendances et toute tâche déclarée terminée sans preuve. Le travail accepté conserve ses manifestes, ses captures et sa revue indépendante. Comme le dit une exigence : « Compiler avec succès, survivre à un tick ou renvoyer un booléen de succès ne suffit pas à valider. »

Ce que vous y gagnez

• Moins de tokens par changement. Pas d’éditeur ni d’état d’interface à expliquer : un document de capacités, du texte versionné et un index d’API compact. Le contexte sert au jeu plutôt qu’à apprendre le moteur. Nous le mesurons par changement accepté au lieu de promettre un chiffre.
• La vitesse du natif. Du C++20 sur un backend Vulkan 1.3 fin et direct, sans VM ni ramasse-miettes dans le moteur, avec un budget de temps de frame.
• Des agents qui vérifient au lieu de deviner. Découverte, attentes, empreintes et captures remplacent « ça devrait marcher » par « voici la preuve ».
• Des bugs reproductibles. Graine, scénario et identité de build fixent un échec : n’importe qui, humain ou agent, peut le rejouer.
• Tout est lisible en diff. Des schémas texte versionnés avec unités et repères explicites : une revue se lit comme une revue de code.
• Des agents en parallèle, sans risque. Worktrees et builds séparés, intégration un par un, et les preuves périmées sont relancées.
• L’échelle sans bricolage. Des repères hiérarchiques typés et un rendu relatif à la caméra gardent la précision locale, même loin de l’origine.
• Ouvert et sans fournisseur imposé. MIT OU Apache-2.0, aucune dépendance IA à l’exécution, et compatible avec l’agent de votre choix.

Ce que ça coûte, honnêtement

Choisir un moteur sur mesure coûte cher, et prétendre le contraire contredirait tout ce qui précède :

• Pas d’éditeur visuel. C’est voulu. Un inspecteur de diagnostic minimal est prévu, mais si vous pensez en glisser-déposer, SimEngine n’est pas encore pour vous.
• Une seule plateforme. D’abord Windows 11 x64 avec un GPU Vulkan 1.3, plus Linux pour la chaîne headless et la CI.
• Pré-version. Aujourd’hui, il n’y a ni physique prise en charge, ni boucle de jeu, ni entrées, ni audio pour publier un jeu.
• Maîtriser la pile, c’est assumer le travail. L’intégration, les diagnostics, les tests et l’outillage d’assets ne disparaissent pas parce qu’il n’y a pas d’éditeur. Il faut les construire, les prouver et les maintenir.

Si vous devez sortir un jeu cette année, utilisez Unity, Unreal ou Godot. Ils sont excellents : voyez notre comparatif Unity, Unreal, Godot pour savoir où chacun brille. SimEngine est un pari sur l’avenir du développement de jeux, construit au grand jour pour que vous puissiez juger ce pari par vous-même.

Où il en est aujourd’hui

Le premier jalon (fondations réutilisables et points de décision) est en grande partie terminé, et le second (physique, précision spatiale, continuité) est en cours. Concrètement, un agent peut déjà :

• créer un projet à partir de l’exemple first_scene et le vérifier face au build du moteur ;
• ajouter un objet, le déplacer avec une commande planifiée et ajouter une attente sur sa position finale ;
• l’exécuter en headless et obtenir PASS, 3 attentes sur 3 et une nouvelle empreinte d’état ;
• le capturer hors écran avec Vulkan et vous montrer les PNG avant et après ;
• ouvrir la scène dans l’environnement de test Windows pour déplacer la caméra, sélectionner et déplacer des objets, puis exporter ;
• préparer des assets glTF/GLB statiques via un pipeline hors ligne strict et déterministe.

Ce n’est pas encore un jeu. C’est une boucle fermée dans laquelle un agent peut faire un changement et le prouver, et c’est la fondation de tout le reste.

La suite

Viennent ensuite un bac à sable de physique locale (un adaptateur expérimental existe déjà derrière un verrou), puis le terrain planétaire et son streaming, la construction, le vol et la persistance, la qualité visuelle et la stabilité temporelle, des opérations d’agent plus riches avec rechargement contrôlé, et enfin un moteur intégré et distribuable. Le dépôt deviendra public avec ce premier jalon distribuable.

Si vous créez des jeux avec des agents, ou si vous en avez envie, dites-nous ce qui coince pour vous aujourd’hui : c’est exactement autour de ces retours que ce moteur est conçu. Le moteur lui-même est présenté sur la page SimEngine.