Le bus agent entre dans les filtres de l'interface utilisateur + du tableau de bord

Rendre visible la machinerie invisible

Le runtime du plugin et le bus d'événements que le backend a discrètement versé la veille sont eux-mêmes "invisibles" - ils s'exécutent en arrière-plan, imperceptibles pour les utilisateurs. Le thème de cette journée était de connecter cette machinerie invisible à l'interface, la rendant observable et exploitable. Une fois qu'un système commence à avoir une activité interne comme « plusieurs agents communiquant via un bus », le fait de tout cacher en arrière-plan laisse les utilisateurs et les développeurs dans l'anxiété de la boîte noire de « ce qu'il fait réellement ». Le travail de cette journée était donc clair : ouvrir une fenêtre sur le bus, ajouter un filtrage à la liste des tâches, permettre aux gens de vraiment voir ce qui se passe à l'intérieur du système. L'observabilité n'est pas un avantage ; c'est la condition préalable pour qu'un système complexe soit fiable et débogué.

Un bus d'agent visible

Aujourd’hui, les agents de bus d’événements utilisent le câble pour communiquer avec l’interface. Un « voyant d'état de santé du bus » est apparu dans la barre latérale, indiquant le nombre actuel de plugins, afin que vous puissiez savoir en un coup d'œil combien de fonctionnalités sont chargées et si l'état est sain ; et un panneau d'administration de bus dédié a été promu au rang d'entrée de niveau supérieur, où vous pouvez parcourir les types d'événements, naviguer vers le haut/bas à l'aide du clavier, développer n'importe quel enregistrement en place pour ses détails, et même créer un lien profond depuis un enregistrement directement vers la catégorie d'événement correspondante dans la barre latérale. Le point de tout cela : la collaboration multi-agents est devenue « visible » pour la première fois – qui parle à qui, ce qui est transmis, combien d’événements de chaque type – présentée clairement, et non plus une goutte d’activité en arrière-plan que vous ne pouviez que deviner. Pour une plateforme qui fonctionne à long terme grâce à « une équipe d’agents collaborant », cette fenêtre est une étape clé pour transformer la collaboration abstraite en une image concrète qui peut être comprise et dans laquelle intervenir.

Tableau de bord : répartition des statuts, filtrage et recherche

À mesure que de plus en plus de tâches étaient exécutées en même temps, une liste simple ne suffisait plus. Cette journée a ajouté quelques outils pratiques au tableau de bord : la liste des exécutions a gagné une "bande de distribution de statut" en haut, afin que vous puissiez voir en un coup d'œil l'image globale du nombre d'exécutions en cours d'exécution, terminées ou erronées ; et la liste des tâches prend en charge le filtrage par statut et la recherche par titre, vous permettant de localiser rapidement celle qui vous intéresse parmi une grande pile d'historique. Ce sont des fonctionnalités simples, mais lorsque vous gérez réellement des dizaines de tâches à la fois, elles décident si vous « saisissez l'ensemble d'un coup d'œil » ou « pêchez une aiguille dans une longue liste ». Lisser les deux opérations à haute fréquence que sont le tri des problèmes et la révision de l'historique revient, au fond, à respecter le temps de l'utilisateur : à mesure qu'un système se développe, un bon filtrage et une bonne recherche sont la productivité elle-même.

Le moteur peut charger des modèles 3D standards (glTF)

Le moteur a franchi aujourd'hui une étape clé dans son écosystème de contenu : la prise en charge du chargement du format de modèle 3D standard glTF et de son chargement via le système d'actifs a été mise en place la veille. glTF est le format d'échange courant pour le contenu 3D, pris en charge par la plupart des outils de modélisation et des marchés de modèles ; être capable d'ingérer directement du glTF signifie que de grandes quantités de modèles 3D prêts à l'emploi peuvent être importés et utilisés, sans avoir à les refaire à la main. Le connecter au système d'actifs plutôt que de créer une logique de chargement distincte est également important : les modèles importés ont alors naturellement une identité unifiée et un moyen d'être référencés, gérables et réutilisables de manière structurée. Pour les utilisateurs, il s'agit d'une réponse importante à la vraie question de savoir « d'où viennent les ressources nécessaires à la création d'un jeu » : non seulement l'IA peut les générer, mais des modèles standards déjà existants dans le monde peuvent être importés directement.

Le vocabulaire ECS du moteur converge en une seule famille

Le moteur a effectué une "convergence" importante au niveau bas ce jour-là. Auparavant, différentes formes de données dans les composants (chaînes, tableaux de longueur fixe/variable, tampons) avaient chacune leurs propres couches de gestion et d'emballage, dispersées dans leur concept et fatigantes à lire. Ce jour-là, ils ont tous été regroupés sous une seule famille de « ressources gérées » et ont supprimé une pile de code wrapper redondant. Parallèlement, la « création d'une entité » est devenue plus stricte au niveau du type : des contraintes de type plus précises décrivent de quels composants et de quelles données une entité est constituée, à la fois bloquant les erreurs au moment de la compilation et effaçant les anciens correctifs effectués via des « conversions de type forcées » un par un, avec une vérification permanente pour empêcher leur réapparition. Ce travail est entièrement invisible du côté de l'utilisateur, mais il incarne une position d'ingénierie fondamentale : la mesure de la qualité du code n'est pas le nombre de lignes mais "le nombre de concepts que vous devez maîtriser pour comprendre un seul point" - la convergence d'un vocabulaire dispersé en une seule famille allège exactement la charge de tous (y compris l'IA) qui liront plus tard ce code.

Une position de travail : éditer directement + le test local est la porte

Cette journée a également articulé une position de travail dans la culture de l'ingénierie : pour des changements suffisamment clairs, modifiez directement plutôt que d'appliquer un processus lourd à tout ; mais en même temps, la « réussite des tests locaux » a été définie comme un seuil non limité : vous pouvez avancer rapidement, mais vous ne pouvez pas ignorer la vérification. Les deux semblent contradictoires mais sont les deux faces d'une même chose : précisément parce que les tests automatisés constituent le filet de sécurité, l'édition directe ne devient pas une imprudence. Expliquer « quand entreprendre le processus lourd et quand le montage direct est acceptable » est en soi un respect pour l'efficacité : ne pas laisser des choses simples être ralenties par le processus, ni laisser la vitesse devenir une excuse pour perdre le contrôle de la qualité. Ce sens du rythme est le secret invisible pour qu’une équipe à itération rapide reste à la fois rapide et stable à long terme.

Ce que signifie cette journée

Dans l'ensemble, il s'agissait d'une journée visant à « rendre le système transparent pour les gens ». La machinerie interne complexe du backend a été connectée à l'interface, devenant observable et exploitable ; le moteur a ouvert la porte à de vastes modèles standards, les sources de contenu ne sont donc plus limitées ; et le faible niveau a rendu le code lui-même plus lisible et plus fiable grâce à la convergence du vocabulaire. En apparence, la visualisation, le chargement du modèle et la convergence des types sont trois choses sans rapport, mais elles visent un seul objectif : garder ce système toujours plus complexe « compréhensible et digne de confiance » pour les utilisateurs, pour les développeurs et pour l'IA qui lira plus tard le code. Jusqu’où va un système dépend souvent moins du nombre de fonctionnalités qu’il accumule que de sa capacité à rester transparent à mesure qu’il devient complexe – et cette journée était un investissement dans cette transparence.