Système d'actifs du moteur v1 + peaufinage du chat en profondeur

Quatre titres en une journée : le panorama du jour

Ce fut la journée la plus dense jusqu'à présent, s'étendant de minuit au lendemain matin avec quatre pistes exécutées en même temps : l'atterrissage du moteur, fonctionnalité après fonctionnalité, et correction dans le cadre d'une boucle fermée stricte en sept étapes, le panneau de discussion entrant dans un état stable "jamais terminé", la sécurité du backend et l'interface se contractant avec des tests un par un, plus un refactor de clôture qui a retiré le rechargement à chaud de l'interface de lui-même. Réaliser autant de choses en une journée sans chaos se résumait à deux choses : chaque piste avait des limites et des critères d'acceptation clairs, et plus un changement était proche des fondations, plus il devait être vérifiable. Ci-dessous, il est divisé par thème, mais n'oubliez pas qu'ils ont été regroupés en une seule journée.

Engine Asset System v1 : référencement du contenu du jeu par handle

La livraison la plus importante du moteur à ce jour a été la première version d'un système d'actifs. Avant cela, le « contenu du jeu » comme les modèles, les textures et les scènes n'avait pas de manière unifiée d'être géré ; le système d'actifs leur a donné une identité formelle : chaque actif est un objet structuré référencé via un « handle » léger plutôt que de transmettre d'énormes données brutes. Une poignée est comme un numéro d'appel de bibliothèque : tenez-la et vous pouvez récupérer le livre, sans avoir à le transporter tout entier. Un exemple de scène de salle a été construit pour valider la chaîne. L'intérêt : le contenu du jeu peut désormais être référencé, partagé et réutilisé de manière structurée, avec un seul point d'entrée pour charger les modèles, les textures et les scènes. C'est le véritable point de départ de chaque fonctionnalité ultérieure « importer un modèle, placer des éléments dans une scène ».

Un benchmark de parité des pixels : la qualité du rendu ne peut pas régresser tranquillement

Ce qu'un moteur de rendu interne craint le plus, ce n'est pas une seule mauvaise image, mais « s'aggrave discrètement sans que personne ne s'en aperçoive » : changez une chose et certaines images diffèrent de la référence de quelques pixels, invisibles à l'œil mais s'éloignant avec le temps. Cette journée a posé un critère de « parité de pixels » : comparez les images rendues par le moteur à une référence pixel par pixel, et dès que la différence dépasse un seuil, l'intégration continue passe au rouge et empêche la modification de fusionner dans le tronc. Il transforme "le rendu est-il correct" de quelque chose observé à la main et au toucher en une porte automatique et objective qui s'exécute à chaque validation. Pour un moteur qui fait évoluer sa qualité d'image à long terme, cette porte est la condition préalable à une qualité stable : grâce à elle, vous pouvez modifier le rendu avec audace et sans crainte.

Vérification visuelle du bac à sable : laissez l'agent "voir" si l'image est correcte

Le fait qu'une IA édite des jeux se heurte automatiquement à un problème inévitable : après avoir modifié les choses, comment sait-elle que l'image est réellement correcte ? Vérifier uniquement si le code erroné conduit facilement à "le code n'a pas planté mais l'écran est noir" tout en croyant qu'il a réussi. Ce jour-là, un mécanisme de vérification visuelle a été construit dans le bac à sable, séparant délibérément deux rôles : « produire l'image » et « vérifier l'image » : un côté exécute le jeu et capture les images, l'autre juge les images capturées. La séparation des rôles rend la vérification plus fiable — pas de piège d'autocertification « Je modifie, je capture d'écran, je déclare que tout va bien ». Cette étape est essentielle pour que l'agent passe de « peut écrire du code » à « est responsable de sa production » : il ne se contente plus de jeter du code par-dessus le mur, mais peut boucler la boucle et regarder « à quoi ressemble réellement la chose que j'ai créée ».

Rendu instancié + nombreux objets : un jeu de blocs comme pierre de touche

Cette journée a également permis de mettre en valeur la capacité multi-objets du moteur avec une démo de mini-jeu « falling-block clear ». De tels jeux comportent de nombreux blocs identiques à l'écran à la fois, et l'émission d'une commande de tirage distincte pour chacun s'accumule rapidement. Pour cela, le moteur a ajouté le « dessin instancié » : une seule soumission dessine un grand lot du même objet, amortissant le coût répété. Le chemin de rendu de plusieurs objets a été épuré, de sorte que « de nombreuses entités apparaissant ensemble » fonctionnent rapidement et de manière stable. Valider avec un mini-jeu véritablement jouable plutôt qu'un test abstrait est en soi une discipline : faire en sorte qu'un vrai jeu se déroule sans problème est bien plus convaincant que de passer un extrait isolé.

~100 pass chat-polish : coût, durée, plusieurs fournisseurs

Le panneau de discussion est entré aujourd'hui dans un état d'équilibre "jamais terminé", avec plus d'une centaine de petites itérations axées sur quelques choses pratiques. Premièrement : affichez le coût et la durée réels de chaque tour, avec un format de montant adaptatif (centimes, dix sous, dollars chacun avec la bonne précision) afin que vous puissiez voir d'un coup d'œil ce que cela coûte. Deux : un sélecteur commutable pour « quel backend de codage utiliser » : vous pouvez épingler une conversation sur une seule, le choix est mémorisé, se synchronise entre les onglets, prend en charge la sélection du clavier haut/bas et vous avertit lorsque celle que vous avez choisie n'est pas disponible. Troisièmement : une gestion réfléchie de l'état anxiogène "le modèle réfléchit silencieusement pendant un long moment" - affichant les secondes écoulées, suggérant un passage au-delà d'un seuil et une note d'espace réservé pour "terminé mais pas de sortie visible". Chaque passe touchait une chose, était auto-testée et enregistrait une note. Cette piste mérite une centaine de passages car c'est la surface que l'utilisateur regarde le plus longtemps chaque jour : quelle que soit sa capacité, si elle est lue laborieusement et semble incertaine, il n'y a pas de confiance.

Sécurité du backend et renforcement des contrats : listes blanches, défense de traversée, nombreux tests

Étant donné que l'agent lit et écrit réellement des fichiers sur votre machine, le backend doit rendre "il ne peut toucher que ce qu'il devrait" hermétique. Cette journée a mis en place un grand nombre de défenses et de tests autour de la sécurité des fichiers et des chemins : limiter les chemins accessibles avec une liste blanche, ajouter une défense contre la portée excessive de la "traversée de répertoire", refuser d'écraser un répertoire existant lors de l'écriture d'un fichier et supprimer le chemin d'accès personnel de l'utilisateur dans les réponses sortantes (afin que les chemins réels de votre machine ne fuient pas). Pendant ce temps, les contrats d'interface du backend ont été définis test par test : quelle entrée doit renvoyer quoi, comment les cas extrêmes sont traités, le tout protégé par des tests, et le nombre de tests unitaires a franchi une étape ce jour-là. Rien de tout cela n'est une « nouvelle fonctionnalité visible », mais c'est elle qui décide si vous osez laisser une IA d'édition de fichiers entrer dans votre propre projet : ce n'est qu'avec des limites claires, un comportement prévisible et des régressions détectées par les tests que vous pourrez avoir une réelle tranquillité d'esprit.

Un refactor de clôture : rendre le rechargement à chaud de l'interface indépendant

Au petit matin, la journée s'est terminée par une refactorisation structurelle : rendre le mécanisme de rechargement à chaud de l'interface indépendant et remettre chaque partie à sa place en cours de route : les données de jeu de l'utilisateur ont été déplacées vers le propre répertoire de l'instance, la source du moteur a été extraite vers un emplacement de construction unifié, la configuration de l'environnement a été transférée à la racine du dépôt et la disposition des répertoires imbriqués, sujette aux pièges, a été redressée. Un tel refactor ne montre presque aucun changement du côté de l'utilisateur, mais il rend l'expérience « modifier le code, l'interface se recharge instantanément à chaud » plus propre et moins sujette aux interférences croisées. Plus les fondations sont claires, plus vite vous construisez plus tard – le faire à la fin de la journée est précisément dû au fait qu'après l'arrivée de tant de nouvelles choses, l'arbre entier avait besoin d'une consolidation pour se réaligner.

Ce que signifie cette journée

Si les jours précédents ont prouvé que « la conversation peut construire quelque chose de réalisable », cette journée a jeté les bases de « peut-on le faire de manière fiable, à long terme ». Le système d'actifs permet de gérer le contenu de manière structurelle ; le test de parité des pixels et la vérification visuelle du bac à sable donnent un jugement objectif sur « l'image est-elle correcte » ; la sécurité et les tests du backend rendent « laisser l'IA agir » digne de confiance ; le vernis du chat donne envie aux gens de l'utiliser quotidiennement ; et le refactor final garde tout propre en termes d'ingénierie. Ensemble, ils révèlent une position : avancer rapidement, tout en laissant à chaque étape une trace solide qui peut être vérifiée, régressée et rétrospectée. C'est exactement le modèle que ce journal veut laisser pour le développement futur : la vitesse et la rigueur ne sont pas un choix, mais deux choses réalisables dans la même journée.