ForgeAX est unStudio de jeux personnels natif d'IA. Nous pensons que l’IA redéfinit les obstacles à la création de jeux.
Notre vision est directe :laissez des équipes plus petites, avec l’IA, créer des jeux qui nécessitaient auparavant des jeux beaucoup plus grands.Non pas pour remplacer les créateurs, mais pour confier à l'IA l'ingénierie et la production lourdes entre « l'idée » et le « jeu jouable ».
Où nous sommes
L'étape actuelle esttransformer des idées en jeux jouables avec l'IA: on peut déjà faire des démos jouables de FPS, ARPG, survie et shooter en studio, avec un moteur couvrant le rendu PBR, la physique et l'animation squelettique. Nous continuerons à peaufiner cette étape vers une qualité livrable.
Source ouverte
La couche d'outils ForgeAX est sous licenceLicence Apache 2.0- n'importe qui peut librement créer, utiliser, construire commercialement et redistribuer. Nous voulons que ce soit un projet ouvert que la communauté peut construire ensemble. Voir lepage de licence.
Laissez les petites équipes créer des jeux plus importants.
Dans le studio, vous décrivez le jeu que vous souhaitez à un responsable de l'IA appelé Forge – via le chat, en travaillant directement dans un éditeur visuel et (plus tard) avec des entrées telles que des images et des vidéos. Il planifie, fait appel à des sous-Agents spécialisés en cas de besoin (gameplay, design, art…), puisécrit lui-même le code moteur, en rechargeant à chaud le résultat dans un aperçu du navigateur en direct.
En dessous se trouvent deux fondations internes : unmoteur repensé pour le point de vue de l'IA(pour que l'IA puisse le lire, l'écrire et comprendre ses erreurs), et unboucle de développement qui maintient l'IA à un résultat correct et vérifiable(exigences entrantes, sortie jouable, chaque étape observable et traçable).
Une boucle en sept étapes
À l'intérieur du moteur, chaque fonctionnalité passe par le même pipeline : les exigences sont entrées, un résultat de travail est obtenu, avec un enregistrement lisible à chaque étape :
- Exigences — indiquez ce qu'il faut construire, avec des critères d'acceptation.
- Recherche — historique de l'enquête, contraintes et options.
- Planifier : définissez une stratégie et divisez-la en tâches.
- Implémenter — écrivez du code et des tests.
- Vérifier — contrôles indépendants ; tout rouge bloque la fusion.
- Jugement — un humain prend la décision finale.
- Finaliser — fusionner une fois le processus réussi.
Un orchestrateur et des sous-Agents
Un « orchestrateur » pilote la machine à états, décidant quel sous-Agent envoyer à chaque étape et vérifiant sa sortie ; les sous-Agents sont spécialisés dans leur rôle et dans leur propre contexte. Les humains injectent du jugement sur seulement deux points : énoncer les exigences et examiner les résultats.
Aucun "ça a l'air bien" ne passe à travers
La vérification comporte deux portes IA : l'une analyse statiquement les documents et les API du point de vue d'un utilisateur IA, détectant "promis mais non mis en œuvre" ; l'autre exécute la démo dans un bac à sable isolé, capture des captures d'écran et les revérifie – en se protégeant contre les « tests verts, écran noir ».
Il se stabilise avec le temps
Après chaque fonctionnalité, les frictions rencontrées en cours de route sont capturées sous forme de commentaires qui améliorent le pipeline lui-même. La fonctionnalité suivante utilise automatiquement la version améliorée : le pipeline se nourrit de sa propre sortie et devient plus intelligent.
Le résultat : l'IA ne produit pas du code de « qualité démo », mais des fonctionnalités vérifiées et rejouables qu'un humain peut prendre en charge.
La plupart des API des moteurs de jeu sont écrites pour les humains. Lorsque l’IA devient celle qui écrit le code, le moteur devrait être différent.
L'idée principale de ForgeAX est simple : l'utilisateur décrit un jeu et l'IA écrit le code du moteur. Cela ressemble à "juste un auteur différent", mais en pratique, les moteurs existants ne sont pas compatibles avec l'IA - ils supposent qu'un lecteur lit des documents, devine et remplit le contexte comme le fait un humain.
Notre position est directe : L'IA est le premier utilisateur du moteur. Lorsque « convivial pour l'IA » entre en conflit avec « convivial pour les humains », l'IA gagne. Voici quelques conséquences concrètes.
1 · Une source de vérité, dérivez le reste
Un fait est défini exactement à un seul endroit ; tout le reste en dérive. Les champs de composants, par exemple, sont intégrés dans un schéma : les inspecteurs, les débogueurs et les outils lisent le schéma au lieu de rechercher la source et de deviner. L’IA n’a pas besoin de « se souvenir » des conventions éparpillées partout, car il n’y a qu’un seul endroit où chercher.
2 · Erreurs que l'IA peut comprendre et récupérer
Une erreur n’est pas simplement une phrase humaine que vous « lancez ». Nous utilisons un ensemble fermé de codes d'erreur, chacun contenant des informations structurées « quoi/pourquoi/comment récupérer ». Lorsque l’IA détecte une erreur, elle sait quoi changer ensuite – au lieu de traiter le texte d’exception comme du mysticisme.
3 · Des données structurées au lieu de « regarder l'écran »
La partie la plus difficile d'un bug de rendu est que "cela ne semble pas correct à l'écran". Un humain peut regarder le moniteur ; L’IA ne le peut pas. Ainsi, le moteur peut capturer une trame d'appels de rendu (appels de dessin, liaisons, cibles de rendu, état du pipeline) pour lire hors ligne, rejouer et inspecter l'état complet au Nième tirage. Un problème visuel devient des données que l'IA peut « lire ».
4 · Deux implémentations qui se vérifient
La couche de rendu a deux implémentations backend (WebGPU et wasm) derrière une seule interface. Ils s'affichent côte à côte : dès que l'IA utilise mal l'API d'un moteur, l'autre backend diverge immédiatement, faisant apparaître le problème - bien plus rapidement que d'attendre un examen humain.
Ces conceptions partagent un critère commun : moins un lecteur (humain ou IA) doit avoir de concepts en tête, mieux c'est. Plus l'API est cohérente et indexable localement, plus l'IA réussit souvent - et plus il est facile pour un humain de prendre le relais.
"AI-native" n'est pas un slogan, c'est une longue série de décisions "à refaire pour le point de vue de l'IA". Nous en dévoilerons davantage dans la documentation et les prochains articles.