Anatomie d'un moteur de jeu IA : ce que contient réellement le prompt

Par Mariana Muntean, CEO de Cinevva

La remarque que les inconnus font le plus souvent à propos de Cinevva, c'est qu'il ne s'agit que d'une surcouche d'IA. Ils arrivent sur la page d'accueil, voient une unique zone de saisie affichant « Décrivez votre jeu », puis décident qu'ils ont compris le produit. Ils ont compris la porte d'entrée. Le produit, c'est tout ce que vous ne voyez pas lorsque vous saisissez cette phrase, plus, depuis cette semaine, un monde ouvert dans lequel vos joueurs entrent pour découvrir votre jeu.

Derrière cette zone de saisie se trouvent un moteur de jeu complet, un orchestrateur doté de 26 outils typés, une flotte de modèles génératifs, une recherche de ressources agrégée auprès de onze fournisseurs, une iframe de jeu en direct que l'agent peut lire et modifier, ainsi qu'une vitrine où ce même agent publie votre jeu terminé sous la forme d'un reel de gameplay à faire défiler. Rien de tout cela n'est exotique. Ce n'est que de la plomberie. Le travail intéressant a consisté à décider quoi connecter à quoi.

Cet article passe en revue toute la machine, de haut en bas. C'est l'explication que nous donnons aux investisseurs techniques et celle que nous donnons aux développeurs qui envisagent de contribuer. Ils cherchent la même réponse.

1. Le prompt est l'interface, pas le système

La première décision de conception a été de tout masquer jusqu'à ce que l'utilisateur soit réellement investi. La page d'accueil n'a qu'une seule mission : transformer une phrase en projet. Nous avons séparé l'expérience en un espace public — le prompt, les sélections et le fil de la vitrine — et un espace créateur — l'IDE, les outils de ressources et le processus de publication — afin que les personnes qui veulent simplement jouer n'aient pas à voir le cockpit.

C'est pourquoi le texte indicatif alterne entre des exemples comme « Créez un jeu de serpent avec des graphismes néon » et « Jeu de tir sur des zombies en vue du dessus ». Ce ne sont pas des tutoriels. Ce sont des autorisations à se lancer. L'utilisateur comprend qu'une « idée de jeu d'arcade bizarre » est une entrée parfaitement valide.

Dès que vous envoyez votre demande, trois choses se produisent. Le système crée un nouveau projet de jeu doté d'un identifiant stable. Il initialise une arborescence de fichiers vide (index.html, game.js, style.css, assets/, GDD.md). Puis il transmet votre phrase à l'orchestrateur avec une fenêtre de contexte de projet pointant vers ces fichiers vides. À partir de là, vous parlez à un agent qui peut agir.

2. Derrière la zone de saisie, un IDE complet dans le navigateur

L'espace de création est un IDE à trois panneaux qui fonctionne entièrement dans le navigateur. L'arborescence des fichiers se trouve à gauche, l'éditeur de code au centre, l'iframe du jeu en direct à droite, et une zone de chat longe le bas de l'écran. Nous avons choisi cette disposition délibérément. Les personnes qui écrivent déjà du code la reconnaissent immédiatement. Celles qui n'en écrivent pas peuvent ignorer le panneau central et communiquer uniquement par le chat.

L'arborescence des fichiers n'est pas une métaphore. Chaque projet est réellement un petit site statique composé de fichiers HTML, JS et CSS, d'images générées, de modèles GLB et de fichiers audio, servis directement depuis R2 par l'intermédiaire d'un Cloudflare Worker. Il n'y a aucune étape de compilation. Et la raison est importante. Cela signifie que l'agent peut lire et modifier les fichiers que vous publieriez réellement, et que le même artefact fonctionne dans l'iframe, sur un téléphone encapsulé avec Capacitor, sur Steam avec Tauri et dans Discord en tant qu'Embedded Activity. Un seul système de fichiers, six cibles de distribution.

Chaque jeu que nous générons doit exposer deux fonctions sur window. getGameState() renvoie un objet simple décrivant le jeu en cours — position du joueur, score, vies, ennemis et minuteurs. setGameState(patch) applique une mise à jour partielle au jeu en direct. Cette minuscule API constitue le contrat qui permet à l'agent d'inspecter et de modifier un jeu en cours sans le recharger. Nous reviendrons sur son importance dans la section 6.

3. L'orchestrateur, là où réside le véritable moteur

Ce que les gens ne voient pas lorsqu'ils qualifient Cinevva de « surcouche d'IA », c'est que l'IA n'écrit pas tant du code qu'elle ne dirige un petit orchestre. L'orchestrateur est une boucle d'appel d'outils exécutée avec un modèle de pointe, dotée d'un prompt système d'environ mille lignes et d'une interface typée comprenant 26 fonctions. Les définitions des outils constituent le moteur. Le modèle en est le chef d'orchestre.

Les 26 outils se répartissent en cinq familles. Les outils de système de fichiers (list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files) permettent à l'agent de traiter votre jeu comme n'importe quelle autre base de code. Les outils de projet (create_new_game, list_games, open_game, ask_user, game_ready) gèrent le cycle de vie d'un projet et sa restitution à l'utilisateur. Les outils génératifs (generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles) font appel à des modèles spécialisés que nous présenterons ensuite. Les outils de connaissances (search_fonts, list_library_docs, search_library_docs, list_generations) fournissent à l'agent des sources de vérité fiables et indexées plutôt que des API inventées. Enfin, les outils d'exécution (read_console_logs, execute_js) permettent à l'agent de voir et de manipuler le jeu en direct.

Un premier échange typique ressemble à ceci. L'utilisateur saisit « Créez un jeu de tir spatial néon ». Le modèle émet un appel à write_files avec un fichier GDD.md décrivant la conception, puis appelle de nouveau write_files avec index.html, game.js et style.css. Il appelle generate_music avec prompt="synthwave space shooter, 120 BPM, driving bassline", ce qui lance une tâche auprès d'ElevenLabs Music et renvoie une URL MP3 dans R2. Il appelle generate_skybox avec un style du modèle 3 de Blockade Labs pour le champ d'étoiles. Il appelle game_ready(title, message) pour faire basculer l'iframe vers la nouvelle version, puis read_console_logs afin de confirmer que le jeu a démarré sans erreur. S'il détecte une trace de pile, il revient à edit_files et corrige le problème avant même que l'utilisateur ne le signale.

La propriété intéressante de cette architecture est que le prompt système et les schémas des outils sont les seuls éléments propres au produit. Remplacez le modèle et tout continue de fonctionner. Au cours de l'année écoulée, nous avons migré entre trois modèles de pointe sans modifier l'interface, car cette interface nous appartient.

4. Le volet ressources : une distribution entre plusieurs modèles

L'agent ne génère lui-même ni images, ni musique, ni sons, ni objets 3D. Il fait appel à des spécialistes. Le volet ressources de Cinevva distribue les tâches entre les meilleurs modèles spécialisés, reliés de façon à ce que la sortie de l'un constitue une entrée valide pour le suivant.

Pour les images et les sprites, generate_image appelle Flux Pro 1.1 avec une largeur et une hauteur toujours multiples de 32, ainsi qu'un format de sortie qui passe au PNG lorsque le prompt demande de la transparence. Pour les morceaux complets, l'agent appelle ElevenLabs Music avec un prompt stylistique et une durée en secondes. Pour les effets ponctuels, ElevenLabs SFX produit en cinq à quinze secondes un extrait à partir d'un texte comme « tir de pistolet laser, blaster de science-fiction ». Pour les environnements à 360 degrés, generate_skybox appelle Blockade Labs avec l'un des quelque quatre-vingt-dix styles disponibles, en utilisant par défaut Digital Painting du modèle 3. Pour les personnages 3D, rig_model envoie un GLB à Tripo afin de lui ajouter une armature et un rig de créature bipède, quadrupède, hexapode, octopode, serpentine ou aquatique, puis apply_animation exécute l'une des quinze animations prédéfinies — attente, marche, course, saut, escalade, plongeon, coup tranchant, tir, blessure, chute, rotation, ainsi que les marches propres aux créatures non bipèdes.

Chacune de ces opérations est une tâche, et non un appel synchrone. Elles prennent de quelques secondes à plusieurs minutes. L'orchestrateur les lance, renvoie immédiatement un jobId, puis un canal séparé transmet le résultat dans la conversation lorsque la ressource est prête. Cela change complètement l'expérience. L'agent peut continuer à développer la logique du jeu pendant qu'un modèle 3D finit d'être riggé en arrière-plan. L'utilisateur n'a jamais à attendre qu'une unique opération critique se termine.

Tous les artefacts arrivent au même endroit : R2, derrière cdn.cinevva.com, et sont accessibles au moyen de simples URL. Ainsi, l'appel write_files suivant de l'agent peut simplement intégrer <audio src="https://cdn.cinevva.com/audio/abc.mp3">, et le jeu fonctionne immédiatement. Aucun SDK, aucun bundler de ressources, aucun manifeste.

5. Recherche de ressources auprès de onze fournisseurs

La génération est idéale lorsque vous avez besoin de quelque chose de précis. La recherche est plus rapide lorsque la ressource existe déjà. La Bibliothèque de ressources est un moteur de recherche fédéré couvrant onze fournisseurs de ressources gratuites ou sous licence, dont les résultats sont réunis dans un seul fil classé.

Le registre des fournisseurs se trouve dans le worker et exécute chaque requête en parallèle auprès de PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, de la collection 3D du Smithsonian, de TurboSquid, de Synty et de Jamendo. Chaque fournisseur implémente une interface commune (search, getMetadata, isBrowsable, getSupportedTypes), de sorte que l'ajout d'un nouveau fournisseur ne nécessite qu'un seul fichier TypeScript. La couche d'agrégation gère la pagination par curseur entre des fournisseurs utilisant des systèmes de pagination différents, déduplique les licences, normalise les types de ressources dans une taxonomie commune — modèle, texture, audio, HDRI, sprite — et associe chaque ressource à sa licence afin que l'agent ne choisisse jamais un élément qu'il ne peut pas redistribuer.

Lorsque ChatGPT a recommandé cet outil le trimestre dernier comme l'un des meilleurs moteurs gratuits de recherche de ressources pour les créateurs de jeux, nous sommes allés lire la recommandation. Elle visait juste sur l'essentiel. L'intérêt n'est pas de proposer une barre de recherche couvrant une seule bibliothèque. L'intérêt est qu'un développeur indépendant recherchant une « texture de mur en pierre » obtient côte à côte des résultats de PolyHaven et d'AmbientCG, une version stylisée de Kenney et une option de photogrammétrie du Smithsonian, le tout avec une seule requête et des métadonnées de licence cohérentes. L'agent peut interroger le même endpoint et choisir des ressources de la même manière qu'un humain.

C'est la partie du moteur dont l'importance est souvent sous-estimée. La plupart des démos de création de jeux par IA génèrent tout de zéro et produisent un rendu uniforme, brillant et légèrement étrange. Les jeux intéressants sur Cinevva associent des ressources générées à de véritables photogrammétries CC0 du Smithsonian et à un arbre low poly fabriqué à la main par Quaternius. L'orchestrateur peut réaliser ce mélange en un seul échange.

6. L'agent joue au jeu

C'est la partie qui surprend le plus les ingénieurs lorsque nous la leur présentons. L'agent ne se contente pas d'écrire du code dans des fichiers. Il exécute le jeu dans une iframe isolée, lit sa console, prend des captures d'écran séparant l'interface utilisateur de la scène 3D et exécute du JavaScript dans l'environnement en direct afin d'inspecter ou de modifier son état. read_console_logs renvoie les cinquante dernières lignes de console.log, console.warn, console.error ainsi que les exceptions non interceptées provenant de l’iframe. Après chaque appel à game_ready, le prompt système oblige l’agent à appeler read_console_logs et à corriger toutes les erreurs avant de rendre le projet à l’utilisateur. Cette règle à elle seule élimine la plupart des échecs du type « l’IA a dit que c’était terminé, mais l’écran est noir » que rencontrent les autres outils.

execute_js est l’outil le plus puissant. Il exécute du JavaScript arbitraire dans la portée globale du jeu. Comme chaque jeu doit implémenter getGameState et setGameState, l’agent peut exécuter JSON.stringify(getGameState()) pour lire l’intégralité de l’état du jeu en cours d’exécution, puis setGameState({player: {x: 500, y: 100}}) pour téléporter le joueur, setGameState({lives: 99}) pour lui accorder l’invincibilité ou setGameState({level: 3}) pour passer directement à la suite. Il peut également inspecter des couches plus basses, par exemple avec scene.children.map(c => c.type) pour examiner le graphe de scène Three.js ou document.querySelectorAll('canvas').length pour confirmer que le moteur de rendu a bien été monté.

Vous comprenez pourquoi c’est important. Lorsqu’un utilisateur dit « le joueur reste coincé dans le mur au niveau deux », l’agent n’a pas besoin de deviner. Il ouvre le niveau deux, exécute getGameState(), examine les données de collision, applique un correctif avec execute_js pour le tester, puis seulement ensuite écrit la correction sur le disque. Il débogue comme vous déboguez. Nous considérons l’iframe comme un pair, pas comme une cible.

7. La documentation des bibliothèques, cette ennuyeuse source de vérité

Nous indexons la documentation officielle des bibliothèques réellement utilisées par les jeux (Three.js, Tone.js, Cannon, et une liste qui ne cesse de s’allonger) dans un référentiel JSON structuré et interrogeable. L’agent se tourne vers search_library_docs("threejs", "Mesh") avant de se tourner vers le web ouvert. C’est plus rapide, versionné, et cela n’hallucine jamais une méthode renommée deux versions mineures plus tôt.

Ce n’est pas très spectaculaire. Mais c’est ce qui distingue une IA qui produit du code fonctionnel d’une IA qui produit du code convaincant en apparence, mais qui plante à la quarantième ligne. Une grande partie de la qualité visible des jeux créés avec Cinevva découle de cette seule décision.

8. De jouable à découvrable : les reels et la vitrine

Un jeu auquel personne ne joue reste un loisir privé. Le problème non résolu le plus difficile du développement indépendant n’est plus la création des jeux. C’est leur distribution. Le moteur ne s’arrête donc pas à « jouable ». Il s’arrête à « devant les joueurs ».

Chaque projet sur Cinevva possède une URL de partage stable, comme play.cinevva.com/{game-id}, qui ouvre la dernière version du jeu dans une iframe en pleine page, avec une petite surcouche pour les mentions J’aime et les partages. Lorsque l’agent appelle game_ready, il ne se contente pas d’activer l’aperçu dans l’environnement de développement. Il propose également de publier une vidéo de gameplay de 15 secondes dans la vitrine Cinevva. Le reel est un véritable enregistrement d’une partie, capturé directement depuis l’iframe (nous fournissons un petit script d’enregistrement que l’agent injecte dans l’environnement d’exécution du jeu). Ce que le spectateur voit défiler est donc du vrai gameplay, et non un montage promotionnel.

Cela transforme la boucle de travail du développeur. L’ancienne boucle consistait à coder, compiler, empaqueter, téléverser, rédiger une page Steam, lutter contre un algorithme, puis surveiller un compteur de listes de souhaits. La nouvelle boucle consiste à saisir une phrase, regarder l’agent construire le jeu, appuyer sur Publier, puis voir son jeu apparaître dans le même flux vertical que tous les autres. La découverte se fait dans le même produit que la création, à la même URL et avec le même compte.

Pour les membres de la communauté des développeurs, c’est la partie à examiner de près. La distribution a toujours été le fossé défensif que les moteurs de jeu n’intégraient pas. Unity fournit un éditeur, puis vous publiez le jeu sur Steam. Unreal fournit un éditeur, puis vous publiez sur l’Epic Store. Cinevva fournit les deux moitiés. Le moteur et la vitrine communiquent par l’intermédiaire du même orchestrateur qui a construit le jeu.

9. Les jeux les plus performants : le cercle vertueux de la découverte

Le flux de reels constitue une moitié du cercle vertueux. Le classement des jeux les plus performants constitue l’autre. Il classe les jeux selon les tendances, les nouveautés et les meilleurs résultats de tous les temps, en pondérant le taux de complétion (le joueur a-t-il terminé une session ?) plutôt que le nombre brut de clics. Le taux de complétion est plus difficile à manipuler que le nombre d’installations. Un jeu qui retient l’attention pendant soixante secondes surpasse un jeu que l’on ouvre puis ferme aussitôt.

Chaque signal alimente le tour suivant de l’orchestrateur. Lorsque l’agent dit « ajoutons un bonus », il ne puise pas dans une bibliothèque de modèles figée. Il s’appuie sur un modèle qui a observé quelles mécaniques retiennent réellement les joueurs sur Cinevva ce mois-ci. Le cercle vertueux n’est pas simplement un classement au bas de la page. C’est le signal d’entraînement de l’ensemble du moteur.

Pour les investisseurs, c’est là que réside notre avantage défensif fondé sur les données. Nous n’avons pas seulement des jeux générés. Nous avons des jeux générés accompagnés de véritables métriques d’engagement au niveau des sessions, reliées aux prompts qui les ont produits, aux choix d’assets effectués par l’agent et aux joueurs qui les ont aimés. Chaque boucle renforce la suivante.

10. Le moteur devient un jeu

Voici la partie que je laisse entrevoir sur les réseaux sociaux depuis des mois. Tout ce qui est décrit dans les sections 1 à 9 concerne un système qui construit des jeux. Ce qui est plus difficile à décrire, tant qu’on ne l’a pas vu, c’est ce qui se produit lorsque le système lui-même devient un lieu.

Créer un jeu reste un travail difficile, même avec tout ce que nous avons développé. Si vous n’avez encore jamais créé de jeu, vous vous retrouvez soudain responsable de l’intrigue, des personnages, du monde, des mécaniques, de qui fait quoi et quand, du comportement de la lumière, de la superposition des effets spéciaux, de la musique, des effets sonores et des mouvements de caméra. C’est beaucoup. Et en plus de tout cela, vous voulez que le résultat vous ressemble, pas qu’il ait l’air d’un modèle recraché par l’outil de quelqu’un d’autre. Le prompt et l’orchestrateur prennent en charge l’essentiel du travail mécanique. Ce qu’ils ne peuvent pas faire seuls, c’est offrir à votre création terminée une scène où se présenter sous le regard des autres.

Nous avons donc construit cette scène. Pendant la majeure partie de cette année, Oleg et l’équipe du moteur ont publié leurs travaux dans une série en 14 parties consacrée à l’intégration d’un monde ouvert dans le navigateur. Un terrain sculpté que l’on peut creuser en temps réel. Des biomes qui se couvrent automatiquement de roche ou d’herbe selon la pente et l’altitude. 80 000 brins d’herbe qui se courbent dans le vent sur un terrain généré par calcul. Un personnage qui marche, sprinte, saute et plane à la fois sur un terrain à carte de hauteurs et sur un terrain volumétrique, au cours d’une même étape. Rien de tout cela n’était une démonstration technique conçue pour elle-même. C’était le socle de ce qui suit.

Aujourd’hui, le monde ouvert est accessible dans une première version. Vous choisissez un avatar et vous y entrez. Vos jeux publiés apparaissent autour de vous sous forme d’espaces à visiter, comme ils apparaissent aujourd’hui dans les reels de la vitrine et dans le classement des jeux les plus performants, à ceci près que vous vous y rendez à pied au lieu de les faire défiler d’un geste. Vous pouvez entrer dans le jeu d’un inconnu depuis le monde sans quitter ce monde. Vous pouvez vous tenir à côté de la personne qui a créé ce à quoi vous venez de jouer et lui dire ce que vous ajouteriez ensuite. Vous pouvez sculpter un morceau de terrain avec quelqu’un que vous venez de rencontrer et en faire le point de départ d’un nouveau projet. La découverte cesse d’être un flux. Elle devient une promenade.

Notre moteur a toujours été un moteur de jeu au sens technique. Aujourd’hui, il le devient aussi au sens littéral. Ce qui construit votre jeu est désormais un jeu en soi. Le même orchestrateur que dans la section 3, les mêmes garde-fous pour les assets que dans la section 4, le même contrat getGameState que dans la section 6, les mêmes reels que dans la section 8 et le même classement que dans la section 9 s’assemblent tous pour former ce lieu unique dans lequel vos joueurs peuvent évoluer. La frontière entre créer et jouer a toujours été artificielle. Elle a maintenant disparu.

Ce que nous pensons avoir bien fait

La première chose que nous avons bien faite a été de considérer le prompt comme un moyen d’interaction avec l’interface plutôt que comme un produit. Le produit, c’est l’orchestrateur, la palette d’outils, les garde-fous pour les assets et la vitrine. Le prompt est le moyen le moins coûteux possible de faire entrer un utilisateur dans le système.

La deuxième a été d’imposer un système de fichiers plat, natif du navigateur et sans étape de compilation. C’est ce qui permet à un jeu Cinevva d’être publié sur mobile, ordinateur, Steam et Discord à partir d’une seule source de vérité. C’est aussi ce qui permet à l’agent de lire ce qu’il a écrit.

La troisième a été le contrat selon lequel chaque jeu généré implémente getGameState et setGameState. Cette seule ligne dans le prompt système est ce qui donne à l’agent l’allure d’un collaborateur plutôt que d’un générateur de code. L’agent peut jouer, et un système capable de jouer peut déboguer.

La quatrième a été d’intégrer la vitrine à la même boucle que le moteur. Nous ne gagnerons pas uniquement grâce à la qualité brute du modèle. Avoir deux mois d’avance sur un générateur à poids ouverts ne constitue pas un avantage défendable. Nous gagnons lorsque le même agent qui construit votre jeu le publie également, mesure ses performances et apprend de la façon dont des inconnus y ont joué.

Si vous voulez voir toute la machine en mouvement, le prompt de la page d’accueil reste la porte d’entrée. Saisissez une phrase. Regardez ce qui se passe derrière. Puis revenez ici et dites-nous quelle partie du moteur nous devrions présenter ensuite.