Une application de bureau arrive + une bibliothèque de jeux partagée

D'"un onglet de navigateur" à "une vraie application"

Avant cela, Studio vivait dans un onglet de navigateur, ce qui signifie que son existence dépendait de cet onglet : fermez-le, actualisez-le ou faites planter le navigateur, et tout ce qui se passait allait avec. Le titre du jour était d'en faire une application de bureau native autonome, lui donnant pour la première fois « sa propre fenêtre, son propre processus ». Autour de cela, les autres lignes ont fait de la plate-forme un produit plus mature : plusieurs jeux partageant du contenu, des agents appelant plus directement, le moteur ajoutant de l'audio et un rendu multi-passes, le repo étant allégé. La mise à niveau de « peut s'exécuter dans un navigateur » vers « peut rester ouverte en tant qu'application à long terme » est la transformation dont cette journée mérite le plus qu'on se souvienne.

Une application de bureau : fermez la fenêtre avant, les agents ne meurent pas

Aujourd'hui, la coque complète d'une application de bureau est apparue : Studio peut s'ouvrir pour la première fois en tant que fenêtre de bureau native, et pas seulement en tant qu'onglet de navigateur. Il était livré avec un processus de maintien en vie (maintenir les services d'arrière-plan en vie au-delà de la fenêtre), une gestion des fenêtres et une résolution correcte de la racine des actifs lors de l'empaquetage de la version de bureau. Cela donne enfin à la fonctionnalité précédente « les agents survivent à un navigateur fermé » une véritable entrée de bureau - qui se trouvait autrefois à l'intérieur du navigateur, et maintenant, avec une fenêtre native, vous pouvez la garder ouverte comme une véritable application à long terme : travaillez manuellement avec les agents, fermez l'interface frontale et ils continuent de fonctionner en arrière-plan ; ouvrez la fenêtre lorsque vous souhaitez vérifier la progression. Un formulaire qui peut à lui seul servir d'« application » constitue le passage clé du « projet de démonstration » à « l'outil de tous les jours ».

Plusieurs jeux partagent une bibliothèque

Plusieurs jeux peuvent désormais partager une même bibliothèque de jeux : placez les ressources et les composants communs dans une bibliothèque partagée, et chaque jeu possède son propre « index » pour les référencer – pas besoin de copier des éléments dans chaque jeu. Pour un créateur cultivant plusieurs œuvres sur le long terme, cela signifie qu’une série, ou plusieurs prototypes, peuvent réutiliser proprement les mêmes ressources plutôt que de disperser des copies partout. Une optimisation réfléchie est venue avec cela : pendant le développement, un changement d'actif dans un jeu ne réanalyse que les ressources du "jeu sur lequel vous travaillez actuellement", et non l'ensemble de l'espace de travail à partir de zéro - avec de nombreux jeux, c'est la différence entre "prend effet instantanément" et "attendez un moment à chaque fois". Le partage et la nouvelle analyse locale font de "une seule personne gérant de nombreux jeux" à la fois efficace et rapide.

Les agents appellent les outils hôtes par liste blanche, directement dans le chat

Ce jour-là, nous avons câblé un canal de « liste blanche », depuis les définitions de types jusqu'à l'exécution. Un agent peut déclarer dans son manifeste « quels outils hôtes je suis autorisé à appeler », et un « pont hôte-outil » injecte ces outils déclarés dans sa liste d'outils de conversation ; une ancienne boîte à outils codée en dur a été retirée en cours de route. Concrètement : l'agent responsable de l'histoire a déclaré un ensemble d'outils liés à la narration dans sa liste blanche, de sorte qu'il peut appeler tout un ensemble d'outils narratifs fins directement dans le chat pour organiser l'intrigue, sans passer par un kit séparé. La valeur est « autorisation explicite, invocation directe » : ce que chaque agent peut utiliser est précisé dans son manifeste – sûr et contrôlable, et « équiper un agent des capacités qu'il devrait avoir » est une chose déclarative et maintenable. C'est la base d'un système d'agents qui tend vers « n'importe qui peut configurer, chacun avec sa spécialité ».

Moteur : un pipeline de rendu multi-passes + audio + AA basculable

Le moteur s'est rempli de plusieurs morceaux ce jour-là. L'abstraction du rendu s'est transformée en un pipeline "multi-passes" - de nombreux effets visuels avancés (en particulier le post-traitement) sont essentiellement calculés "en plusieurs étapes, couche sur couche", et avec une structure multi-passes appropriée, ces effets peuvent être construits de manière propre plutôt que entassés. Le moteur a également construit une démo audio, validant "les jeux peuvent faire du son" bout à bout (le système audio avait été intégré plus tôt ; ce jour-là, un échantillon sonore a été obtenu). La physique a corrigé un bug « inactif » : certains objets étaient gelés sur place sans aucune force, et maintenant ils tombent, entrent en collision et se déplacent correctement. Ensemble, ceux-ci renforcent les trois lignes d'expérience du moteur - visuels, sonores, physiques - un cran supplémentaire vers "peut véritablement créer un jeu complet".

Repo slimming : extraire les binaires de la base de code

Le moteur a également effectué une série de « réduction des dépôts » ce jour : en supprimant les actifs binaires volumineux (échantillons de matériaux, images de base, artefacts de construction, etc.) du référentiel de code, en les déplaçant vers un dépôt de ressources dédié ou en les reconstruisant à la demande, et en établissant une vérification d'intégration continue afin que personne ne remette accidentellement des binaires dans la base de code. Invisible pour les utilisateurs, cela améliore véritablement l'expérience de développement de première ligne : un dépôt plus petit se clone plus rapidement, a un historique plus propre et semble plus léger au quotidien. Pour un projet destiné à évoluer à long terme, open source et cloné par davantage de personnes pour démarrer, "seul le code dans la base de code" est une discipline qui mérite d'être conservée - elle affecte directement le temps d'attente d'un nouveau venu (ou une machine CI) et l'espace qu'il prend lors de la première suppression du projet. Se débarrasser rapidement de ce fardeau à long terme est une gentillesse envers tous les futurs collaborateurs.

Ce que signifie cette journée

Le thème du jour est de faire passer la plate-forme d'un "objet exécuté dans un navigateur" à "une application que vous pouvez posséder et utiliser à long terme". Le shell du bureau lui a donné sa propre fenêtre et son propre processus ; la bibliothèque de jeux partagée vous permet d'y cultiver plus d'une œuvre ; le canal d'outils de liste blanche rend le système d'agent plus configurable et contrôlable ; l'audio du moteur ainsi que le rendu multi-passes et l'amincissement du repo renforcent respectivement les extrémités « peut construire » et « fonctionne sur le long terme ». Ces changements aux orientations différentes témoignent d'une marque de maturité : il ne s'agit plus seulement d'un projet démontrant que « la conversation peut faire des jeux », mais d'un outil qu'on installerait sur son ordinateur, qu'on ouvrirait quotidiennement et qu'on confierait sur le long terme. Dès qu’il peut constituer une « application » à part entière, l’identité du produit change.