L'architecture de construction et d'exécution prend forme

De « peut dessiner un cadre » à « l’architecture prend forme »

Si le premier jour a répondu « un pixel peut-il être dessiné correctement dans le navigateur », cette journée répond à la question suivante : d'où vient l'image. Ce qui bouge réellement dans un jeu est un modèle de monde appelé ECS (Entité-Composant-Système) : chaque personnage, accessoire et caméra est une « entité », et leur position, leur apparence et leur comportement sont déterminés par des « composants » et des « systèmes ». Avec un rendu mais pas de modèle mondial, le moteur n'est qu'un outil de dessin ; avec un modèle mondial mais pas de rendu, le monde reste invisible. Le fil conducteur de cette journée consiste à relier ces deux moitiés et, parallèlement, à mettre en place l'architecture globale de construction et d'exécution, le shell frontal et plusieurs fonctionnalités fondamentales de l'agent - de sorte que chaque maillon de la chaîne « générer un jeu par conversation » commence à prendre forme.

Le pont ECS↔render : connecter le monde à l’écran

L'étape la plus cruciale de cette journée a été la production d'une première version fonctionnelle du pont entre le monde ECS et le moteur de rendu. Ce qu'il résout semble simple, mais est tout à fait fondamental : il existe une "entité" dans le monde qui transporte des composants tels que la position, l'orientation, le maillage et le matériau - comment le moteur de rendu sait-il où sur l'écran et sous quelle forme la dessiner ? Le pont est ce canal de traduction : chaque image convertit l'état du modèle mondial en commandes de dessin que le moteur de rendu comprend. Grâce à lui, placer un objet en mouvement dans le monde le fait véritablement apparaître et se déplacer à l'écran, sans écrire à la main aucun code de dessin. C'est le tournant où le moteur passe de « deux sous-systèmes indépendants » à « un tout qui tourne » ; chaque expérience ultérieure consistant à « placer un objet et il apparaît à l'écran » remonte au pont connecté ce jour-là.

Un benchmark à double implémentation : un critère de performance

Sur les chemins critiques d'un moteur, il existe souvent plusieurs façons de mettre en œuvre quelque chose, chacune avec sa propre vitesse et ses propres compromis. Cette journée a permis de construire une sonde de type « benchmark à double implémentation » : faire la même chose de deux manières différentes et mesurer côte à côte leur coût réel. La valeur n'est pas celle qui a remporté une seule course, mais cette performance ne repose plus sur des conjectures : toute intuition selon laquelle « l'écrire de cette façon pourrait être plus rapide » peut être mesurée sur place avec le même critère, évitant ainsi une décision astucieuse qui est en réalité plus lente. Pour un moteur destiné à évoluer à long terme et à fonctionner sur toutes sortes d'appareils, établir d'abord « comment comparer les performances de manière objective » revient à assigner un arbitre à chaque optimisation future, si rapide et si lente a des preuves derrière elles.

Le shell frontal Studio est né

Un événement marquant s'est également produit ce jour-là : le shell frontal de Studio a reçu sa première forme approximative. Jusque-là, toutes les capacités résidaient du côté du moteur et de la ligne de commande ; mais ce à quoi l'utilisateur final est réellement confronté, c'est une interface Web qu'il peut ouvrir, discuter et regarder l'image de droite. Le shell initial mis en place aujourd'hui est le "point de départ squelettique" du panneau de discussion, de la fenêtre d'aperçu et des divers ateliers à venir. C'est vide pour l'instant, mais l'importance est que le produit commence à converger d'un « tas de capacités » vers « une forme utilisable ». D'un côté, une base de moteur toujours plus solide, de l'autre, une interface qui commence à prendre forme. Au cours des semaines à venir, les deux s'ancreront dans le Studio que vous voyez.

L'agent développe un système de commande : un brouillon + /contexte

L'agent de chat a fait un pas "de la simple conversation aux commandes" ce jour-là : un projet de conception pour un système de commande a été publié, et les spécifications de la commande /context ont été définies en premier. Un système de commandes donne à « collaborer avec l'IA » un ensemble de raccourcis prévisibles et réutilisables : au lieu de décrire une action fréquente dans une phrase détournée à chaque fois, une commande la déclenche avec précision. /context, la première commande à être spécifiée, aborde exactement ce qui compte le plus dans les longues sessions : "quel contexte contient actuellement le modèle". Définir d'abord la forme du système de commande et sa première commande signifie que les commandes ultérieures peuvent évoluer à partir du même standard, plutôt que chacune étant écrite à sa manière et s'opposant.

Un compactage automatique plus intelligent : par outil, par espace libre

Au fil de longs allers-retours avec l’IA, le contexte accumulé s’allonge de plus en plus, ralentissant les réponses et augmentant les coûts ; mais un compactage grossier jette des informations utiles. Cette journée a ajouté deux éléments d'intelligence au compactage du contexte : premièrement, traitez-le "par outil" : les résultats des différents outils importent différemment, vous pouvez donc décider par outil ce qu'il faut couper et quoi conserver au lieu d'une taille unique ; deuxièmement, déclenchez-le "par un espace vide" - effectuez le compactage dans les fenêtres lorsque vous n'attendez pas de résultat, en masquant le coût aux moments que vous ne remarquerez pas plutôt que lorsque vous souhaitez le plus une réponse rapide. Ensemble, ils permettent aux longues séances de mincir tout en vous dérangeant le moins possible. Cette comptabilité minutieuse de « comment gérer le contexte du modèle » est exactement le moment où cette plate-forme traite les choses comme une véritable ingénierie dès le départ.

Robustesse de l'outillage et du terminal : récupération, clés, bus d'événements

Cette journée a également permis de peaufiner un lot de détails qui rendent l'utilisation quotidienne moins sujette aux dérapages. Les deux modes de l'outil de récupération Web sont devenus plus stables : les messages d'erreur du mode profond sont plus spécifiques et plus faciles à diagnostiquer, tandis que le mode direct n'a pas le droit d'installer des composants supplémentaires par lui-même, ce qui rend son comportement plus contrôlable. Le mouvement du curseur dans le terminal (début/fin de ligne) a été déplacé vers un routage plus clair des touches, de sorte que la mise au point et les frappes s'alignent plus précisément. Le bus d'événements a corrigé une boucle auto-amplifiée dans laquelle l'erreur d'un observateur déclenchait de nouvelles erreurs qui se sont propagées sur elles-mêmes - une fois que cela se produit, les journaux explosent instantanément, il est donc important de les couper à la source. Aucune de ces fonctionnalités n’est spectaculaire ; c'est le travail de découper "cela ne semble pas difficile à utiliser" petit à petit.

Installation et démarrage plus faciles

Puisque l’objectif est de « s’exécuter localement en quelques minutes », le chemin d’installation et de démarrage ne peut pas être cahoteux. Cette journée a réorganisé le flux de démarrage en modules, l'a rendu compatible avec une version plus récente du gestionnaire de packages, a ajouté "l'installation automatique comme solution de secours lorsque le moteur d'exécution est manquant" et a aligné le script de nettoyage sur les mêmes conventions. Pour une plate-forme qui souhaite que plus de personnes – y compris des développeurs non professionnels – se lancent, plus le chemin est fluide « du clonage à la visualisation de l'image », plus la barre est basse. Baver cette route tôt évite à tous ceux qui voudront plus tard tenter une série de tracas potentiellement rebutants.