Le mode éditeur est réellement utilisable

Le modèle arrive : de « le regarder fonctionner » à « intervenir pour le changer »

Le plan de l'éditeur défini la veille est entré en mise en œuvre et s'est exécuté sans traîner - un bel exemple, sur l'ensemble du projet, de « réfléchissez-y, puis construisez-le immédiatement ». Avant cela, Studio a toujours été un lieu où « vous parlez, l'IA construit, vous regardez » : vous décrivez ce que vous voulez, l'IA écrit du code et le côté droit exécute le jeu ; mais si une chose ne vous plaisait pas, vous ne pouviez que la décrire avec des mots, sans pouvoir la pousser à la main. Ce que cette journée a ajouté est exactement la voie « à la main » : sélectionner, faire glisser, enregistrer — ces actions les plus simples s'appliquent pour la première fois dans Studio. Pendant ce temps, le moteur a complété quatre ou cinq fonctionnalités pour soutenir cette voie, et la chaîne d'outils de contenu a permis aux actifs de circuler plus facilement dans l'éditeur. En une phrase : pour la première fois, l'agence de création est passée de "tout est confié à l'IA" à "l'humain et l'IA peuvent intervenir".

Le mode éditeur arrive : sélectionnez, faites glisser les gadgets, enregistrez automatiquement

Ce jour-là, Studio s'est doté pour la première fois d'un véritable "mode éditeur", construit progressivement en deux couches. Tout d'abord, la « surface d'édition » a été mise en place : l'interface d'édition est rendue en direct par le moteur, donc ce que vous voyez est la véritable apparence du jeu plutôt qu'une approximation dessinée séparément ; Ensuite, le "cerveau d'édition" a été connecté - un bus de commandes enchaîne chacune de vos actions dans des instructions contrôlables, associé à une arborescence de scène à gauche (répertoriant les objets qui existent et qui est l'enfant de qui) et un inspecteur de propriétés à droite (sélectionnez un objet pour voir et modifier ses propriétés), ainsi qu'une synchronisation en direct entre l'éditeur et le moteur. Au toucher : vous pouvez cliquer pour sélectionner des objets dans la fenêtre, utiliser un gadget (cette poignée enroulée autour d'un objet qui vous permet de faire glisser, faire pivoter et redimensionner directement) pour ajuster la position et la pose, et faire glisser les éléments du panneau d'éléments vers la scène. Cette structure « surface + cerveau + synchronisation » est essentielle : elle signifie que l'éditeur n'est pas un panneau codé en dur mais un cadre qui évolue parallèlement aux capacités du moteur, et chaque fonctionnalité d'édition ultérieure se développe par-dessus.

Les scènes deviennent « documentées » : une par jeu, suivi automatique

Cette journée a également établi quelque chose de profond : les scènes sont désormais « pilotées par des documents » : la scène d'un jeu est exprimée comme un document structuré, et ce document est la seule autorité de la scène ; l'éditeur le lit, le moteur l'exécute et la sauvegarde le sauvegarde. Derrière cela, un noyau de scène dédié est devenu la source unique de vérité pour ces scènes documentées. La persistance est venue avec - "une scène par jeu, enregistrée automatiquement, selon le jeu ouvert": quel que soit le jeu que vous ouvrez, c'est le fichier de scène que vous modifiez, et les données ne saignent plus entre les jeux. Pourquoi le « document-driven » est-il si important ? Parce que cela pointe « l'édition humaine » et « l'édition IA » vers la même chose : faites glisser un objet et vous modifiez ce document ; l'IA écrit du code et modifie ce même document ; les deux sont naturellement cohérents plutôt que chacun éditant sa propre copie. Ce jour même le modèle du sample shooter a été modifié pour décrire son arène statique via ce document, validant pour la première fois, avec un jeu réel, que le mécanisme fonctionne.

Faites glisser les personnages et les véhicules + sautez entre les plugins

Du côté de la création de contenu, cette journée a mis en place le chemin du « téléchargement direct » : les personnages, les PNJ et les véhicules terminés dans l'atelier de personnage peuvent être glissés directement pour être utilisés, et la finition d'un PNJ passe automatiquement à l'étape suivante ; plusieurs anciens bugs – ne s’affichant pas sur les surfaces, véhicules atterrissant au mauvais endroit – ont été corrigés en même temps. De plus, les plugins peuvent désormais naviguer les uns vers les autres : un clic dans l'outil de personnage, par exemple, peut transférer le contexte actuel directement dans l'outil d'animation pour continuer, sans rechercher de fenêtres ni reconfirmer de quel personnage il s'agissait. Les quatre modules de l'atelier d'animation ont également été unifiés en un seul langage de conception, avec des couleurs et un espacement soignés, ressemblant à un seul produit plutôt qu'à quatre pièces assemblées. Ensemble, ceux-ci enchaînent le flux "créer un personnage → l'animer → le placer dans la scène" - ce qui signifiait autrefois rebondir sur plusieurs outils - dans une chaîne de montage fluide, dont le point final est exactement cet éditeur qui vient d'être utilisé.

Moteur : anti-aliasing + 9-slice UI art, un look plus raffiné

Les deux pièces du moteur d'aujourd'hui sont toutes deux des raffinements visibles. L'un est l'anticrénelage multi-échantillons : sans lui, les bords et les contours inclinés d'un objet portent une frange de fines marches « irrégulières », particulièrement évidentes sur les diagonales et au loin ; avec lui, les bords sont doucement lissés et l’ensemble de l’image est instantanément plus propre. L'autre est la prise en charge de 9 tranches : un élément fondamental du travail de l'interface utilisateur : l'image d'arrière-plan d'un bouton ou d'un panneau, si elle est entièrement étirée, déforme ses coins arrondis ; l'approche en 9 tranches coupe l'image en neuf morceaux de sorte que les « quatre coins » restent tels quels tandis que seuls les « bords et le milieu » s'étirent selon les besoins, permettant à une image de s'adapter aux boutons et panneaux de n'importe quelle taille sans se déformer. Ni l’un ni l’autre ne change le gameplay, mais ils décident directement si un jeu « a l’air raffiné ». Rendre solides ces capacités d'apparence de base est la condition préalable pour que les créations des utilisateurs soient "présentables" - quelle que soit la qualité du gameplay, une frange de jaggies et un bouton déformé le dévalorisent à première vue.

Moteur : formats d'actifs extensibles + plus d'échecs de chargement silencieux

Le moteur a également apporté deux autres modifications « squelettiques » ce jour-là. Premièrement : l’importation d’actifs est devenue extensible. La connaissance de « quel format, lire comment » était auparavant codée en dur dans le cœur du moteur, de sorte que le moteur ne pouvait utiliser que les quelques formats qu'il connaissait ; Aujourd'hui, cette connaissance a été transformée du noyau en quelque chose d'injectable de l'extérieur, ce qui signifie que des tiers peuvent ensuite enseigner au moteur ses propres formats d'actifs sans toucher au moteur lui-même. Cela transforme le moteur d'un système fermé « ne mange que la ration prescrite » en une plate-forme ouverte et extensible. Deux : un mappage intégré des identifiants de ressources aux descripteurs internes a été ajouté, avec des erreurs plus claires. Auparavant, si un composant n'était pas correctement défini ou si une ressource référencée ne pouvait pas être trouvée, le système échouait souvent silencieusement : la scène semblait chargée, mais un objet manquait inexplicablement et vous n'aviez aucune idée de l'origine du problème ; maintenant, de tels cas sont signalés explicitement. L'extensibilité permet au moteur de « s'ouvrir » et la suppression des erreurs lui permet de « être débogué » – deux garanties pour un contenu toujours plus complexe.

En coulisses : les préférences vous suivent + pas de cache de développement obsolète

Le backend a également réglé deux choses peu glamour mais qui ont façonné l'expérience ce jour-là. Premièrement : les préférences du navigateur ont été conservées sur le serveur, de sorte que les paramètres personnels que vous modifiez dans l'interface ne résident plus uniquement dans un navigateur mais vous suivent, toujours là lorsque vous ouvrez ailleurs. Deuxièmement : un phénomène ennuyeux au moment du développement a été corrigé : la page d'entrée d'un plugin était mise en cache par le navigateur, donc après avoir modifié le code et actualisé, vous verriez toujours l'ancienne version et douteriez qu'elle prenne effet ; ce jour-là, cette page d'entrée a été configurée pour ne pas mettre en cache, garantissant qu'une actualisation affiche la dernière version. Individuellement triviaux, de tels changements déterminent « le degré de confort d'utilisation » : les préférences ne sont pas perdues, le rafraîchissement est frais — apparemment évident, mais pour les réaliser véritablement, il faut choisir un endroit après l'autre. Lisser ces bavures est le devoir quotidien d’un outil passant de « utilisable » à « agréable ».

Ce que signifie cette journée

Cette journée marque un tournant : Studio a commencé à passer d'un « générateur de jeux conversationnels » à une « plateforme de création avec à la fois conversation et édition ». Ce qu'il convient le plus de retenir n'est pas seulement le résultat « l'éditeur fonctionne », mais comment il a atterri : un plan un jour, exécuté le lendemain, et non pas un panneau isolé empilé, mais la base de la « scène pilotée par document », plusieurs capacités sous-jacentes du moteur et le chemin d'entrée des outils de contenu, tous alignés en même temps, de sorte que l'éditeur est né sur une structure qui peut continuer à croître. Pour les utilisateurs, à partir de ce jour, vous pouvez faire générer l'IA pendant que vous vous réglez manuellement, les deux pointant vers la même scène sans se battre. Pour la plate-forme, cette étape a formellement reconnecté la « créativité humaine » à la boucle créative : l’IA vous fait passer de zéro à huit dixièmes, et vous ajoutez vous-même les deux dixièmes restants, les plus personnels.