Pourquoi créer un moteur natif d'IA
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.