Jacquard et mondes typés pour des jeux créés par IA
The demo is the easy part
The first Jacquard demo is deliberately seductive. An agent opens a browser-native engine, calls a typed tool, creates a scene, sculpts terrain, places objects, wires behaviour, saves the bundle, and hands the world back to a human who can press play. No multi-gigabyte editor. No desktop-engine ceremony. No ritual of installing a native toolchain before the first idea can move.
If that were the whole story, Jacquard would be easy to explain: faster prototypes, cheaper training sims, and small interactive worlds made from plain language. The source material supports some of that shape: Jacquard is a Dweve research project, written as strict TypeScript, and designed to run in a browser tab. The route metadata describes aweb-native game engine where AI agents build complete games through a typed API, with visual editor, physics, and NPC behaviour included.
But a good demo can hide the real problem. Making an agent produce a plausible game scene is not the hard part anymore. The hard part is making the generated world constrained enough to inspect, editable enough for a designer, physical enough to play, behavioural enough to matter, and safe enough that generation does not become a new way to create unreviewable state.
That is the interesting question: can a game engine expose every meaningful operation as a typed surface shared by agents and humans, while preserving replay, authorship, safety, and the texture of design?
Why the question is still open
A normal packaged tool tries to freeze its promise. Here is what it does. Here is the support model. Here is the boundary. Here is the failure mode. Jacquard is more interesting before those sentences become too smooth, because the hard questions are still connected to each other.
The current source describes an agent-first engine, an MCP surface, deterministic replay, Rapier3D in WASM, WebGPU with WebGL2 fallback, glTF 2.0 assets, and a browser-only path. Those are concrete engineering choices. They are also only the beginning of the social contract around AI-authored games.
Games are not documents with collision boxes. A game world is a live arrangement of geometry, timing, physics, inputs, state transitions, player expectation, and authored surprise. If an AI system generates a report, a reader can mark a paragraph wrong. If an AI system generates a game world, the error may appear as a door that cannot be reached, a non-player character that lies about the quest state, a physics impulse that breaks replay, or an editor operation the agent performed but the designer cannot understand later.
The uncomfortable questions are the point. What should an agent be allowed to mutate directly? Which editor affordances must be first-class typed operations? Which generated assets are safe to package? Which behaviours must be inspectable before they run? Which world state belongs in an event log rather than a hidden engine heap? These are not cosmetic backlog items. They are the engine.
The engine is an argument about reach
Most game engines are excellent tools for humans at a desk. That does not make them good substrates for agents. Their power often lives behind menus, panels, engine-specific scripting languages, proprietary asset pipelines, and UI flows that assume a person can visually search for the next control. An agent can learn to click, but clicking through an editor is not the same as having a programmatic contract.
Jacquard prend la position inverse. Si l'éditeur peut le faire, un appel d'outil doit pouvoir le faire. Une fonctionnalité qu'un agent ne peut pas atteindre par le code n'existe pas vraiment pour cette question de recherche. Cette règle semble sévère jusqu'à ce que l'on regarde un agent tenter de construire un monde avec un moteur uniquement graphique. L'agent est forcé à l'approximation : deviner le menu, espérer que le panneau sélectionné est actif, extraire un message d'erreur, puis continuer avec un état qu'il ne peut pas prouver.
La source nomme clairement la friction : fonctionnalités uniquement graphiques, installateurs lourds, DSL spécifiques au moteur, pipelines fermés. Jacquard répond avec un onglet de navigateur, des formats ouverts, des ressources glTF, des mondes sérialisables, des paramètres validés par schéma, des erreurs typées et une surface typée partagée entre l'éditeur visuel et l'agent. C'est pourquoi le moteur n'est pas qu'un moteur. C'est une expérience sur la portée.
La portée n'est pas une commodité. C'est une sécurité. Quand chaque opération est un appel, chaque opération peut être nommée, contrainte, journalisée, rejetée, rejouée et expliquée. Quand une capacité est cachée derrière un menu, l'agent doit faire passer son intention par une surface qui n'a jamais été conçue pour cela. La différence est celle entre un ingénieur qui lit une trace d'API et un humain qui essaie de se souvenir quel panneau était ouvert quand la scène a changé.
Un monde n'est pas une image
La génération d'images par IA a appris aux gens à accepter un étrange marché : demander une image, recevoir une image, pardonner la structure si la surface semble correcte. Les jeux ne peuvent pas survivre à ce marché. Un niveau de jeu n'est pas jugé seulement par ce qu'il ressemble depuis un angle de caméra. Il est jugé par la capacité d'un joueur à s'y déplacer, par la stabilité de la physique, par la résolution des objectifs, par le respect du monde par le comportement des PNJ et par la possibilité de rejouer l'état quand quelque chose tourne mal.
Voilà où les contraintes typées deviennent centrales. Un outil de terrain ne peut pas se contenter de peindre des collines. Il doit savoir où se trouvent les surfaces praticables, comment les pentes interagissent avec les contrôleurs de personnage, comment la végétation et l'éclairage affectent la visibilité, et comment la génération à base de graines reproduira le même résultat plus tard. Un outil de scène ne peut pas se contenter de placer des objets. Il doit créer des entités adressables, attacher des composants, versionner le graphe, et rendre le résultat suffisamment diffable pour être relu.
La palette d'outils Jacquard rend cela visible. La page nomme quinze catégories : scène, entité, composant, asset, matériau, physique, terrain, éclairage, audio, UI, quête, PNJ, build, debug et playtest. Elle nomme aussi des ressources en lecture seule telles que les métadonnées de projet, le graphe de scène, le catalogue d'assets, les métriques de performance et le journal d'erreurs. Ce n'est pas un menu arbitraire. C'est une taxonomie de ce qu'un monde de jeu doit exposer avant qu'un agent puisse être plus qu'un simple enregistreur de macros astucieux.
Le problème de recherche n'est pas de savoir si les quinze catégories peuvent exister. Elles existent déjà comme affirmation de la source. Le problème est de savoir à quel point chacune doit être expressive, sûre et composable avant que les mondes générés cessent d'être des artefacts fragiles et commencent à se comporter comme des systèmes conçus. La réponse ne viendra pas en incitant plus fort. Elle viendra en rendant la représentation plus difficile à mentir.
L'éditeur n'est pas une décoration
Une lecture faible des outils orientés agent traite l'éditeur comme un visualiseur. L'agent crée les choses ; l'humain regarde. C'est le mauvais modèle pour Jacquard. Le texte source est précis : l'éditeur visuel utilise la même API que les agents. C'est un client non privilégié de la même surface. Ce seul fait empêche une scission profonde de se former à l'intérieur du projet.
Si l'agent a une voie privée vers le monde et que l'éditeur en a une autre, l'humain finit par perdre. L'état généré devient techniquement valide mais pratiquement inéditable. Le concepteur peut voir le château, mais ne peut pas découvrir pourquoi le drapeau de quête est attaché à cette entité, pourquoi le terrain a un bloqueur invisible, ou pourquoi l'emploi du temps du PNJ change après la deuxième nuit. Le résultat ressemble à de la productivité et se comporte comme une dette.
Une API partagée signifie que l'éditeur doit offrir des affordances pour les mêmes concepts que l'agent manipule. Il doit montrer le graphe de scène, les composants, les comportements, les ressources, les erreurs et les performances d'une manière qu'un humain peut comprendre. Il doit permettre au concepteur de corriger le monde sans sortir du contrat dont dépend la relecture. L'éditeur fait donc partie de l'instrument de recherche.
C'est une exigence inconfortable car elle ralentit le fantasme. Il est plus facile de laisser l'agent générer un câblage caché et d'espérer ensuite que la démo continue de fonctionner. Jacquard demande que le câblage caché devienne assez visible pour qu'un concepteur puisse en prendre possession. Les jeux construits par IA ne deviennent sérieux que lorsque l'humain peut en hériter sans archéologie forensique.
La physique est là où le charme devient responsabilité
La physique a une manière brutale de transformer la génération vague en échec visible. Une histoire peut tolérer un peu de récit approximatif. Un monde 3D avec des corps, des collisions, du terrain et une entrée joueur ne le peut pas. Si le pas change avec le taux de trames, la relecture dérive. Si le contrôle du personnage dépend d'une impulsion non journalisée, un rapport de bug devient une rumeur. Si la même graine produit des positions de corps différentes sur une autre machine, le monde n'est pas une preuve reproductible.
Jacquard ancre cela avec Rapier3D en WASM et un pas de temps fixe de 60 Hz. Le matériau source décrit une physique déterministe, un aléatoire ensemencé, une saisie enregistrée et une relecture mécanique à partir d'un journal d'événements typé. Même graine, même journal, mêmes images. Un rapport de bug est le journal joint ; rejouez-le et voyez ce que le joueur a vu. C'est une affirmation plus forte qu'un enregistrement d'écran, car elle préserve les causes interactives, pas seulement les pixels.
La question de recherche est de savoir ce qui se passe lorsque la génération entre dans cette boucle. Un agent peut créer un pont, mais le pont doit obéir aux contraintes de masse, de collision, d'accessibilité et de playtest. Il peut faire apparaître un PNJ, mais le PNJ doit naviguer dans un monde dont la géométrie peut changer. Il peut ajuster le terrain, mais les pentes qui en résultent doivent rester jouables. Il peut ajouter un événement scripté, mais cet événement doit être journalisé d'une manière que la relecture puisse intégrer.
La physique n'est donc pas un sous-système au bas de la pile. C'est l'un des juges de la génération. Un monde de jeu généré n'est pas bon parce qu'il semble plausible. Il est bon lorsque le joueur peut l'habiter, lorsque les règles tiennent, et lorsqu'un relecteur ultérieur peut rejouer le même échec au lieu de demander au modèle ce qu'il voulait dire.
Le comportement des PNJ est la couche où le langage s'épuise
Les personnages non joueurs rendent Jacquard plus difficile qu'un éditeur de niveau. Une pièce statique peut être inspectée comme de la géométrie. Un PNJ est un état dans le temps : emploi du temps, objectif, perception, dialogue, graphe social, relation de quête, pathfinding, mémoire et échec. Le matériau source nomme les arbres de comportement, les emplois du temps, les objectifs, la narration comme données, les graphes de conditions et la progression ramifiée. Ces mots sont l'endroit où les jeux construits par IA cessent d'être un jouet.
Le langage est utile pour l'intention. C'est une mauvaise représentation finale pour le comportement. Une invite peut dire qu'un garde doit être méfiant la nuit, serviable envers les villageois, hostile envers les voleurs et indulgent après que le joueur a terminé une tâche. Le moteur a besoin de quelque chose de plus précis : quel capteur détecte le danger, quelle condition change l'attitude, quel drapeau de quête supplante la méfiance, quel emploi du temps déplace le garde et quelle ligne de dialogue est autorisée après la transition d'état.
C'est cette précision qui rend les outils typés pour PNJ importants. Sans eux, l'agent produit des impressions. Avec eux, il doit écrire le comportement dans des structures inspectables. Le concepteur peut alors se demander si le garde est injuste, si la quête peut se bloquer, si le graphe social crée des obligations impossibles, ou si une instruction générée ferait converger chaque PNJ vers la même routine terne.
Le comportement des PNJ rend aussi la sécurité pratique. Une génération non sûre ne se limite pas à un texte offensant ou à un contenu interdit. Cela peut être une boucle de comportement qui piège le joueur, une quête qui ne peut pas aboutir, un graphe social généré qui encode un stéréotype hostile, ou un emploi du temps qui provoque un effondrement des performances. La sécurité autour de la génération doit opérer au niveau des systèmes de jeu, pas seulement au niveau des mots.
La sécurité est un problème de forme
L'histoire de sécurité la plus simple dit que l'agent peut générer ou non un contenu. Jacquard a besoin d'une histoire plus structurelle. La question n'est pas seulement de savoir si un élément généré est autorisé. Il s'agit de savoir si le changement généré correspond au contrat du monde. Est-ce qu'il ne modifie que la portée qui lui a été donnée ? Est-ce qu'il expose ce qu'il a changé ? L'éditeur peut-il l'inspecter ? La relecture peut-elle le reproduire ? Les outils de compilation et de test de jeu peuvent-ils le rejeter avant qu'un humain ne confonde la nouveauté avec l'achèvement ?
La source pointe vers cela à travers des appels typés, la validation de schéma, des ressources en lecture seule, le débogage, les tests de jeu, des bundles portables et des fichiers ouverts. Ce ne sont pas des fonctionnalités de sécurité glamour, mais elles comptent plus qu'un message de refus dramatique. Un appel borné peut être refusé. Une erreur typée peut être réparée. Une ressource en lecture seule peut permettre à un agent d'inspecter sans modifier. Une étape de compilation ne peut empaqueter que ce qui est sérialisable. Un test de jeu déterministe peut révéler que la porte générée ne s'ouvre jamais.
La génération sûre signifie aussi résister à la tentation de cacher l'incertitude. Si l'agent ne peut pas savoir si une énigme est résoluble, le système ne devrait pas la présenter comme résolue. Si un comportement de PNJ dépend d'un état ambigu, l'éditeur devrait rendre cette ambiguïté visible. Si la relecture physique diverge, l'affirmation devrait échouer. Le vocabulaire de l'échec est encore en construction.
Jacquard devrait rendre l'incertitude visible au lieu de la polir en une fausse promesse. Lorsque le contenu généré n'est pas assez contraint, l'éditeur, le journal, le chemin de relecture et les erreurs typées devraient exposer cet écart pendant qu'il est encore assez petit pour être corrigé. Ce n'est pas de la rugosité pour elle-même. C'est ainsi que les mondes générés évitent de devenir une dette de contenu.
Le navigateur change l'économie de l'itération
Jacquard fonctionnant dans un onglet de navigateur peut sembler être une fonctionnalité de distribution, et c'en est une. L'installation zéro réduit le coût d'essayer un monde. WebGPU et WebGL2 donnent au moteur un chemin de rendu pratique. Une salle de classe, un partenaire de recherche ou une session de conception ne doivent pas commencer par une installation native lourde. Mais le navigateur compte pour une raison plus profonde.
Il raccourcit la boucle d'itération. Un agent peut construire, l'éditeur peut inspecter, le joueur peut tester, et le journal peut être rejoué sans déplacer le monde à travers une chaîne d'outils propriétaires. Le même environnement peut exposer un graphe de scène, exécuter la physique, jouer de l'audio, inspecter les performances et empaqueter un bundle portable. Cela ne résout pas la conception de jeu, mais cela élimine beaucoup de cérémonie accidentelle de son étude.
Le navigateur rend aussi les frontières plus claires. Si le monde s'ouvre comme une page web, la limite de ce qui a été exécuté, chargé, modifié et exporté peut être rendue explicite. Si le moteur est du TypeScript strict ciblant ES2022, avec des assets glTF ouverts et des mondes sérialisables, l'artefact peut être lu par plus de personnes que le petit cercle d'un seul moteur de bureau.
Cette ouverture est un avantage pratique. Plus d'yeux peuvent inspecter la représentation. Plus d'agents peuvent être connectés via MCP. Plus d'échecs peuvent être reproduits sous forme de journaux plutôt que racontés comme des anecdotes. Le navigateur ne rend pas le problème facile. Il rend le problème observable.
La pression du prototype le briserait
Il existe un réflexe logiciel familier : quand quelque chose se démontre bien, on le lisse jusqu'à ce qu'il soit prêt à être empaqueté. Jacquard est exactement le genre de système qui punit ce réflexe. Le lisser trop tôt et l'équipe doit prétendre que le contrat de création est réglé avant que les questions difficiles soient résolues. Quel est le contrat de création stable ? Quels comportements générés sont supportables ? Quelles affirmations physiques tiennent sur tous les navigateurs ? Quels concepts d'éditeur sont désormais permanents ? Quels contrôles de sécurité sont obligatoires ?
Un package prématuré devrait prétendre que les réponses sont déjà réglées. Cela réduirait la recherche à ce qui est le plus facile à empaqueter. Le résultat serait un jouet amusant avec une façade soignée et un dos fragile. La promesse intéressante de Jacquard est plus grande : un moteur de jeu où les agents IA et les concepteurs humains partagent la même surface de travail typée, où l'état du monde est inspectable, où la relecture est mécanique, et où la génération est limitée par des systèmes plutôt que par des intuitions.
Cette promesse mérite de la patience car elle touche plusieurs domaines difficiles à la fois. La conception de langages de programmation apparaît dans les schémas d'outils. L'interaction homme-machine apparaît dans l'éditeur. La simulation apparaît dans la physique. L'IA de jeu apparaît dans le comportement des PNJ. La sécurité apparaît dans les frontières autour de la génération. L'infrastructure apparaît dans l'empaquetage, l'exécution dans le navigateur et les formats ouverts. Une implémentation étroite en choisirait un et traiterait les autres comme des cas limites. Jacquard les maintient connectés.
Le but est de garder la revendication précise. Jacquard est une recherche sur la création de jeux contrôlable par agents et native au navigateur. Elle peut être utile pour des expériences et du travail avec des partenaires sans prétendre que chaque contrat de création est définitif. Cette honnêteté fait partie de l'ingénierie.
Ce qui rend la recherche crédible
Les signes ne sont pas des signes marketing. Ce sont des signes techniques et expérientiels. Un monde généré doit être inspectable via l'éditeur sans état caché. Les appels d'outils doivent échouer avec des erreurs typées utiles. La relecture doit reproduire des échecs significatifs. Les comportements des PNJ doivent être lisibles comme des données et débogables comme des systèmes. Les tests de jeu doivent attraper les impossibilités évidentes avant qu'elles ne deviennent des déceptions humaines.
Le moteur doit aussi préserver la paternité. Les jeux construits par IA ont toujours besoin du goût humain. L'agent peut rédiger un monde, mais le concepteur doit pouvoir le façonner sans perdre la trace de sa création. Si l'humain doit recommencer pour reprendre le contrôle, l'agent n'était pas un collaborateur. C'était une source rapide de dette technique.
La sécurité devrait devenir moins théâtrale et plus mécanique. Un changement généré doit porter une portée, une provenance et un état de révision. L'inspection en lecture seule doit être distincte de la mutation. La construction doit refuser ce qui ne peut pas être empaqueté proprement. Le débogage doit montrer d'où vient un comportement. Les tests de jeu doivent être suffisamment scriptables pour rendre les affirmations reproductibles. Ce sont des mots ennuyeux, c'est pourquoi ils comptent.
Quand ces propriétés deviennent ordinaires, Jacquard peut soutenir des promesses plus fortes. Jusque-là, la recherche est l'étiquette honnête. Elle dit à l'équipe et au lecteur que le but n'est pas seulement de faire produire des jeux par l'IA, mais de rendre les mondes de jeux produits par l'IA suffisamment lisibles pour être possédés.
La revendication utile
Jacquard et les mondes typés pour les jeux créés par IA, parce qu'il ne s'agit pas vraiment de jeux qui apparaissent à partir de prompts. Il s'agit de la machinerie requise avant que les jeux issus de prompts ne deviennent des artefacts sérieux : contraintes typées, affordances d'éditeur partagées, physique déterministe, comportement des PNJ inspectable, assets ouverts, bundles portables et sécurité autour de la génération.
L'image utile n'est pas un moteur magique. C'est un atelier où l'agent et le designer touchent aux mêmes outils. L'agent n'obtient pas de porte cachée. L'éditeur n'obtient pas de carte affaiblie. Le système de physique ne devient pas optionnel quand la scène est jolie. Le journal d'événements ne disparaît pas après la démo. Le monde généré reste un monde que quelqu'un peut inspecter, rejouer, modifier et défendre.
C'est un long programme d'ingénierie, pas un slogan. S'il réussit, les surfaces destinées aux utilisateurs seront plus claires parce que les questions difficiles n'ont pas été bâclées. S'il échoue, l'échec apprendra quand même quelque chose sur les conditions dans lesquelles l'IA peut créer en toute sécurité des systèmes interactifs. Les deux issues sont utiles.
Pour l'instant, la chose la plus précise à dire est celle-ci : Jacquard est un moteur de recherche ouvert pour les mondes de jeux créés par IA. Il a le droit d'être excitant. Il est aussi tenu d'être exact. L'avenir des jeux créés par IA ne sera pas gagné par la première scène la plus belle. Il sera gagné par le monde qui a encore du sens après que le joueur, le designer, l'agent et le journal de relecture y soient tous revenus.