Une commande pour lancer l'application de bureau + un éditeur de nœuds rejoint

Simplifier à la fois le « lancement » et le « branchement »

Le fil conducteur de la journée est constitué de deux « simplifiés ». La première consiste à simplifier le « lancement » : auparavant, exécuter l'intégralité du Studio sur le bureau impliquait la mémorisation d'une chaîne de commandes pour démarrer chaque service ; maintenant, une seule commande le fait. L'autre consiste à simplifier le « branchement » : ajouter un nouvel outil à la plate-forme utilisée pour nécessiter une logique de démarrage codée en dur ; il s'agit désormais de "découverte automatique par manifeste" : ajoutez n'importe quel plugin qui suit la convention et il est reconnu et lancé. Avec une série de améliorations de l'expérience de chat et un moteur interne allégé, le travail global de la journée ouvre la voie à la fois à "l'utiliser" et à "l'étendre" - plus facile à lancer pour les gens ordinaires, plus facile à intégrer pour les développeurs.

Une commande pour ouvrir l'application de bureau

Le côté bureau a gagné aujourd'hui un lanceur à une seule commande : une seule commande démarre le mode développement, crée un package, ouvre l'application directement ou arrête tout, avec des documents expliquant les trois façons d'exécuter : le développement de navigateur, le développement de bureau et l'application de bureau packagée, et ce que chacun convient. Auparavant, exécuter l'intégralité du Studio sur le bureau signifiait mémoriser et saisir une chaîne de commandes afin de démarrer chaque service, difficile à récupérer en cas de problème ; maintenant, une ligne fait apparaître tout le côté bureau. En dessous, le démarrage/arrêt a été déplacé vers des « groupes de processus » : un groupe de services démarre ensemble et est proprement nettoyé ensemble à la sortie – résolvant directement un problème de longue date où la fermeture de la fenêtre laissait une pile de « processus zombies » en arrière-plan, retenant silencieusement les ports et la mémoire et enlisant la machine. L'aplatissement de la barre de lancement est une condition préalable pour que davantage de personnes l'installent sur leur propre ordinateur et l'utilisent quotidiennement.

Un éditeur de nœuds rejoint le store, avec des plugins isolés

Ce jour-là, le démarrage du plugin est passé d'un « tas de logique codée en dur » à une « découverte automatique par manifeste » : tout plugin autonome avec une déclaration de manifeste, déposé, est automatiquement reconnu et lancé par le système, sans qu'il soit nécessaire de modifier le code de démarrage du programme principal pour chaque plugin. En utilisant ce mécanisme générique, un éditeur de nœuds visuels complet (apportant un workbench "3D low-poly" et un "générateur de scène") a été joint en un seul plugin. Un problème d'isolation a été résolu en parallèle : chaque plugin a désormais sa propre racine de projet isolée, donc plusieurs ateliers ne partagent plus un même projet et éditent au mauvais endroit par diaphonie ; en développement, les plugins sont rechargés à chaud par défaut, donc une modification d'une ligne prend effet immédiatement. L'importance : il transforme « la manière dont les outils tiers s'intègrent » d'un codage en dur unique à une norme réutilisable, auto-découverte et mutuellement isolée – une étape clé vers un « écosystème de plugins », rendant tout futur outil à la fois propre et plug-and-play.

Un chat plus fluide + un chien de garde de chargement en aperçu

Le panneau de conversation a gagné aujourd'hui un ensemble d'interactions qui facilitent le quotidien : changer de modèle actuel à la volée, relire l'historique par segments (au lieu de faire défiler laborieusement une longue bande), de nouvelles entrées pour les actions courantes dans la barre supérieure et un anneau d'utilisation contextuelle montrant en un coup d'œil le montant du budget restant. L'aperçu a gagné un « chien de garde au chargement initial » : si la première image met du temps à apparaître après le chargement, elle se recharge automatiquement et réessaye jusqu'à ce que l'image soit réellement rendue, plutôt que de vous laisser attendre sur un écran blanc - ce genre de problème "occasionnellement ne se charge pas, nécessite une actualisation manuelle" fatigue le plus votre patience, et son automatisation rend l'expérience beaucoup plus fluide. Le backend a également corrigé quelques blocages de discussion et garanti que les conversations se déroulaient véritablement sur le modèle que vous choisissez. Individuellement petits, ils polissent ensemble la surface la plus haute fréquence de la journée, de « utilisable » à « réactive ».

Un grand allégement de l'ECS : moins de concepts, plus rapide, plus facile à comprendre

Le moteur a effectué aujourd'hui une lourde opération de « mincissement » sur son noyau : le "système de composants d'entité" (ECS) qui décrit un monde de jeu. Il a supprimé ou fusionné plusieurs concepts fastidieux : ne plus avoir besoin d'une étape distincte de « enregistrement des composants », unifier la « transformation locale » et la « transformation du monde » en un seul ensemble qui n'est plus divisé, regrouper la numérotation des composants de chaque monde en un identifiant globalement unifié, supprimer certains caches locaux redondants et supprimer une responsabilité qui n'aurait pas dû être mélangée à l'enregistrement des actifs à gérer séparément. Derrière cela se cache un axiome de conception qui traverse l'ensemble du projet : 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" : moins de concepts, moins d'erreurs pour les humains et l'IA qui le lisent. Cet amincissement est entièrement invisible du côté de l'utilisateur, mais décide pourtant directement si le moteur, à mesure qu'il grandit, peut rester « décomposable, rapide, modifiable ». Réduire continuellement le bruit conceptuel du noyau est le travail interne qui permet à ce moteur d'évoluer sainement à long terme.

Ce que signifie cette journée

Les sujets de la journée semblent chacun avoir leur propre coin, mais à l'intérieur ils partagent un objectif commun : réduire les frictions. Le lanceur à une seule commande a réduit les frictions liées au « lancement », la découverte automatique du manifeste a réduit les frictions liées au « branchement », le programme de surveillance du chat et de prévisualisation a réduit les frictions liées à « l'utilisation quotidienne », et la réduction ECS a réduit les frictions liées à la « lecture et modification du code ». Pour qu'une plate-forme soit utilisée par plus de personnes, étendue par plus d'outils et maintenue à long terme, ce qui compte généralement n'est pas une fonctionnalité éblouissante, mais l'atténuation de ces frictions banales une par une. Moins il y a de frictions, plus la barre est basse et plus il y a de personnes disposées à venir, à rester et à contribuer. Cette journée a fait avancer plusieurs pas d'un coup sur la question simple mais fondamentale de "rendre tout un peu plus fluide".