Un mode éditeur obtient sa feuille de route + le moteur prépare l'édition visuelle

Définir une direction, poser les bases et soustraire, le tout en une seule journée

Les éléments de la journée semblent dispersés mais tournent autour d'un seul objectif : développer une nouvelle branche "éditeur" pour Studio. Pour le faire grandir, il faut trois choses à la fois. Tout d'abord, « définir une direction » : transformer "l'ajout d'un mode d'édition" d'une discussion orale en un plan de conception formel afin que le travail à venir ait quelque chose à suivre. Deuxièmement, « jeter les bases » — le moteur remplissant, au niveau de la couche inférieure, les capacités dont un éditeur a réellement besoin ; sans eux, l’interface supérieure est un château en l’air. Troisièmement, "soustraire" - faire converger deux noyaux d'exécution historiquement parallèles en un seul, afin que la charge de maintenance ne vous écrase pas avant même que la nouvelle fonctionnalité n'apparaisse. Lorsqu'un projet atteint le seuil de l'ajout d'une fonctionnalité majeure, ce qui est le plus testé n'est pas la vitesse d'écriture du nouveau code, mais la capacité à réfléchir simultanément à la direction, à consolider les fondations et à se débarrasser des bagages - cette journée a fait les trois.

Une feuille de route pour le mode éditeur : du mode lecture seule au mode édition et lecture

Jusqu'à présent, Studio était principalement l'endroit où exécuter et tester un jeu : vous discutez avec l'IA, elle écrit du code et le côté droit exécute le jeu pour vous. Cette journée a officiellement lancé « l'ajout d'un mode d'édition », capturé sous la forme d'un ensemble complet de documents de conception et d'état – comparant les capacités existantes du moteur, notant les spécifications des fonctionnalités du mode d'édition, faisant le point sur le chemin parcouru par la mise en œuvre et proposant une proposition de conception concrète. L'objectif est clair : vous ne vous contentez pas de regarder un jeu se dérouler, mais vous pouvez directement placer des objets, modifier des propriétés et créer des scènes dans une interface visuelle - un véritable montage et jeu, où un changement montre immédiatement son effet juste à côté de vous. L'écrire d'abord sous forme de document, plutôt que de plonger directement dans le code, c'est parce qu'il touche le moteur, l'avant et le temps d'exécution à plusieurs endroits et mérite un plan clair avant l'action ; tout le travail de rédaction des prochains jours suit ce plan. C'est un signe du passage de Studio d'une vue de joueur à une vue de créateur - de "l'IA le construit pour vous et vous jouez", vers "l'IA et vous éditez ensemble et vous pouvez intervenir à tout moment".

La réflexion sur le terrain atterrit : le panneau de propriétés peut se construire tout seul

L'étape clé du moteur ce jour-là a été d'ajouter des « métadonnées de réflexion » aux champs des composants. La réflexion, en termes simples, permet à un programme de « se décrire » : le système n'a plus besoin d'être informé — il peut lire, pour chaque propriété de chaque composant, le nom et le type — celui-ci est un nombre, celui-là est une couleur, celui-là est une bascule. Pourquoi est-ce important ? Parce que le travail le plus lourd dans un éditeur visuel consiste à dessiner un contrôle d'entrée pour chacun des centaines de types de propriétés : un curseur pour les nombres, un sélecteur pour les couleurs, une case à cocher pour les bascules. L'écriture manuscrite de chacun ne termine ni ne suit les changements du moteur. Avec la réflexion de champ, le panneau de propriétés de l'éditeur peut « se construire lui-même à partir des métadonnées » : ajoutez une nouvelle propriété dans le moteur et le contrôle correspondant apparaît automatiquement dans le panneau, sans travail manuel supplémentaire. C’est exactement la condition préalable sous-jacente qui permet à ce modèle d’éditeur d’aboutir véritablement : d’abord rendre les données auto-descriptives, et ensuite seulement l’interface peut être automatisée.

Le pipeline de rendu devient échangeable, donc le style visuel n'est pas verrouillé

Le moteur a également rendu le « pipeline de rendu » échangeable aujourd'hui. Le pipeline de rendu est l'ensemble de la chaîne d'assemblage par laquelle le moteur transforme une scène 3D en chaque image à l'écran - en décidant de la manière dont la lumière tombe, de la manière dont les ombres sont calculées, de la manière dont les post-effets s'empilent. Ce pipeline était codé en dur dans le moteur : vous ne pouviez utiliser que le seul style visuel qu'il donnait. Cette journée a révélé la « couture » du pipeline, de sorte qu'un projet ayant des besoins visuels particuliers peut intégrer son propre flux de rendu et obtenir un aspect distinctif au-delà de celui par défaut du moteur. Plus important encore, la capacité a été validée en « l'utilisant nous-mêmes d'abord » : le propre rendu du moteur a commencé à fonctionner via ce pipeline échangeable, garantissant qu'il n'est pas décoratif mais véritablement utilisable. L'ouverture proactive d'une fonctionnalité de base signifie que le moteur passe d'une boîte noire « à prendre comme donnée » à une plate-forme où « les utilisateurs avancés peuvent personnaliser en profondeur » – ce qui est particulièrement crucial pour les créateurs à la recherche d'une identité visuelle distinctive.

Un manuel d'utilisation du moteur, écrit pour l'IA

La journée a également eu quelque chose de distinctif : rédiger un manuel d’utilisation du moteur spécifiquement pour l’IA. Sur cette plate-forme, la principale force qui écrit le code du jeu est l'agent IA, et non une personne – donc « rendre le moteur utilisable » doit d'abord signifier « le rendre lisible et correctement utilisable par l'IA ». Ce manuel n'est pas de la prose pour les humains mais une spécification d'utilisation structurée pour les agents ainsi qu'un ensemble de compétences opérationnelles directement suivies : comment créer des entités, attacher des composants, utiliser le système d'actifs et la posture correcte pour les tâches courantes, le tout écrit sous une forme qu'un agent peut suivre de manière fiable. Son importance : la "documentation" d'un outil n'est plus une note secondaire pour les humains mais un moyen de production qui détermine directement la qualité de sortie de l'IA - mieux l'IA comprend le moteur, plus les jeux qu'elle écrit pour vous sont corrects et moins sujets aux retouches. Traiter « le manuel de l’IA » comme un citoyen de première classe, rédigé avec sérieux, constitue une différence fondamentale d’état d’esprit entre cette plate-forme native d’IA et un moteur traditionnel.

Deux noyaux d'exécution convergent en un seul

Cette journée a également effectué une lourde « soustraction » : le retrait et l'archivage formels d'un noyau d'exécution autonome historiquement restant, toutes les tâches d'exécution qu'il assurait autrefois étant déjà transférées dans le processus backend unifié. Cette seule coupure a supprimé près de cent cinquante mille lignes de code, ne laissant qu'une coquille vide comme marqueur historique. Pourquoi est-ce bon ? Parce que pendant longtemps, le système avait deux noyaux capables d'exécuter des agents en même temps, donc tout changement devait être synchronisé des deux côtés, et un instant d'inattention rendait leur comportement incohérent – ​​une taxe de maintenance invisible et continue. Une fois regroupés en un seul noyau, tous les flux d'agents, capacités et outils s'enregistrent et s'exécutent en un seul endroit, sans plus de « deux côtés à maintenir alignés ». Supprimer cent cinquante mille lignes tout en rendant le système plus robuste confirme un credo qui traverse l'ensemble du projet : les progrès ne se mesurent pas par les lignes écrites mais par le nombre de choses que vous devez garder à l'esprit pour comprendre et maintenir le système – la complexité que vous pouvez réduire est en soi le résultat le plus précieux.

Le contenu du jeu est déplacé vers les ressources + un correctif pour l'ordre de relecture

Le côté contenu a également franchi une étape par rapport à la ligne principale ce jour-là : les ennemis dans l'exemple de jeu de tir sont passés de "générés un par un dans le code" à des "instances d'actifs de scène". La différence entre ces approches : les ennemis codés en dur dans le code ne peuvent être modifiés que par un programmeur, tandis que les ennemis transformés en actifs structurés sont plus faciles à réutiliser et à configurer, et plus faciles à reconnaître et à placer pour le futur éditeur - c'est donc également un travail de base pour l'édition visuelle, permettant aux "éléments qui seront modifiés" d'exister sous forme d'actif à l'avance. Au-delà de cela, les outils de création de contenu (édition de style nœud, création de scènes, etc.) ont reçu un lot de finitions quotidiennes : des outils de pinceau, un canevas adapté à la vue, une barre d'outils de scène, des correctifs d'importation aller-retour et plus encore, rendant ces ateliers plus fluides à utiliser. Un problème d'ordre de relecture du chat a également été résolu : les messages inter-agents et système s'ajoutent désormais correctement à la fin, de sorte que la relecture d'une partie de l'historique correspond exactement à l'ordre que vous avez vu en direct - pour que la relecture soit fiable, l'ordre doit être précis à la lettre.

Ce que signifie cette journée

Cette journée est l'aspect classique d'un projet « se préparer au pivotement » : avant d'aborder un grand projet, régler d'abord direction, fondation et bagage d'un seul coup. Le plan de l'éditeur indique "où aller", la réflexion du champ du moteur, le pipeline échangeable et le manuel de l'IA ouvrent "une route que vous pouvez réellement parcourir", tandis que la convergence et l'assetisation du noyau éliminent "le vieux bagage qui vous fait trébucher". Il convient de le rappeler : ce jour-là, il n'y avait pas un seul nouveau bouton éblouissant sur lequel un utilisateur pouvait cliquer et jouer avec ce jour-là - sa valeur est toute en dessous, le genre de travail "si vous ne posez pas les fondations aujourd'hui, la tour de demain ne peut pas être construite". Une plate-forme qui évolue sur le long terme dépend précisément de la volonté de faire ce travail de base sérieusement lorsqu'il n'y a pas d'applaudissements instantanés. A partir de ce jour, la nouvelle patte « éditeur » a ses dessins et ses fondations ; ce qui suit le construit, couche par couche.