Les panneaux de l'éditeur principal arrivent + Prise en charge de Windows

Du « squelette » à la « chair » : l'éditeur commence à remplir

Les deux jours précédents ont mis en place le « squelette » de l'éditeur : le système de panneaux ancrables, les outils de transformation, l'annulation/la restauration. Mais un squelette seul ne peut pas faire le travail ; ce qui permet réellement à quelqu'un de s'asseoir et de créer un jeu, ce sont les panneaux de fonctionnalités accrochés à ce squelette. Le travail d'aujourd'hui consiste exactement à donner corps à ce squelette : remplir, d'un seul coup, les trois panneaux centraux indispensables à tout éditeur de jeu, de sorte que le flux d'édition le plus élémentaire - "voir les objets, sélectionner, modifier les propriétés, extraire les ressources" - s'exécute de bout en bout pour la première fois. Pendant ce temps, le moteur s'est élargi dans deux directions : en ajoutant la base de rendu pour toute la catégorie des cartes de tuiles du gameplay 2D et en corrigeant un lot de problèmes de compatibilité Windows afin que davantage de personnes puissent l'exécuter. Avec un modèle importé réellement connecté à un exemple de jeu et le backend se dégradant gracieusement en cas d'échec, le thème de la journée est clair : remplir le cadre construit au cours des jours précédents, point par point, en quelque chose de véritablement utilisable.

Le trio d'éditeurs de base : Hiérarchie / Inspecteur / Actifs

Ce jour-là, l'éditeur a rempli les trois panneaux les plus essentiels de l'édition de jeux, chacun s'occupant de son propre domaine et aucun n'est superflu. Le panneau Hiérarchie : organiser chaque objet de la scène dans une arborescence par relation parent-enfant, indiquant clairement d'un coup d'œil qui est l'enfant de qui, cliquez pour sélectionner - c'est ici que vous "trouver des choses et saisir la structure" dans une scène. Le panneau Inspecteur : sélectionnez un objet et toutes ses propriétés s'étalent sur la droite : position, rotation, matériau, toutes sortes de paramètres modifiables directement - c'est ici que vous "réglez une chose". Le panneau Actifs : parcourez et extrayez tous les matériaux du projet - modèles, textures, packs de scènes, etc., en faisant glisser ce dont vous avez besoin - c'est ici que vous "récupérez les matériaux". Ensemble, les trois forment le flux principal que chaque développeur de jeux répète des centaines ou des milliers de fois par jour - "voir tous les objets → en sélectionner un → modifier ses paramètres → faire glisser quelque chose depuis les ressources" - enfin terminé dans Studio. Ils forment un « trio » précisément parce que l’essence du montage est une navette sans fin entre « la vue globale, le détail d’un objet unique et la source des matériaux » – ce n’est qu’avec les trois présents que l’éditeur devient vraiment capable de travailler.

Le moteur gagne en rendu de carte de tuiles 2D

Le moteur a jeté aujourd’hui les bases de toute une catégorie de gameplay : le rendu de cartes en tuiles 2D. Les cartes de tuiles sont l'approche classique du jeu 2D : découpez le monde en une grille de cellules carrées, placez une petite image (« une tuile ») dans chaque cellule, et assemblées, elles forment une carte entière : l'herbe, les murs, les rivières et les routes sont tous pavés à partir de ces petits carrés ; Les jeux classiques à défilement latéral, descendant et pixel-art sont presque tous construits dessus. Aujourd'hui, le moteur a intégré les composants de base pour les cartes de tuiles et les couches de tuiles, et peut lire un format de fichier de carte de tuiles commun, ce qui signifie qu'un niveau que vous dessinez dans un outil cartographique dédié peut être lu directement dans le moteur et rendu, sans remplacer chaque cellule à la main. L'importance : cela étend formellement la portée de la plate-forme des scènes auparavant orientées 3D vers le vaste territoire de la 2D - le premier jeu que de nombreux créateurs veulent créer est précisément un jeu en 2D, et ouvrir cette voie ouvre la porte à un grand nombre de créateurs 2D.

Compatibilité Windows : il fonctionne correctement sur plus de machines

Cette journée s'est concentrée sur un lot de problèmes de compatibilité Windows. Le piège le plus courant et le plus insidieux des logiciels multiplateformes ne réside souvent pas dans les fonctionnalités elles-mêmes, mais dans les subtiles différences de convention entre les systèmes : différents systèmes d'exploitation utilisent des fins de ligne de texte différentes, des séparateurs de chemin de fichier différents, un comportement différent pour la correspondance des fichiers génériques - et si l'un d'entre eux n'est pas aligné, le code qui fonctionnait correctement sur un système échoue inexplicablement sur un autre. Cette journée a corrigé, un par un, un ensemble d'échecs causés par ces différences et unifié la convention de fin de ligne de texte afin que tous les fichiers se comportent de manière cohérente sur toutes les plates-formes. Pour les utilisateurs Windows, cela signifie que l'environnement de développement et les tests s'exécutent correctement sur leurs propres machines au lieu de s'accrocher partout aux différences du système d'exploitation. Pour qu'un outil puisse être utilisé par le plus grand nombre de personnes possible, le support multiplateforme est un travail de base incontournable : il n'ajoute aucune nouvelle fonctionnalité, mais décide directement combien de personnes « ne peuvent même pas franchir la porte ». Le renforcement de cette compatibilité élimine le tout premier obstacle pour une base d’utilisateurs plus large.

Câblage "d'un modèle importé" dans un jeu réel + un backend plus robuste

La veille, la fonctionnalité « faites glisser un modèle et il devient une scène » a été ouverte ; cette journée l'a parcouru avec un exemple réel : un modèle de scène complet a été intégré à l'échantillon du jeu de tir comme exemple concret du chemin "importer un modèle → assembler une scène jouable". Une nouvelle fonctionnalité simplement exécutée ne suffit pas : elle nécessite un cas d'utilisation réel pour vérifier qu'elle résiste dans un flux réel de bout en bout, et c'est exactement ce que fait cet exemple. Le backend résiste également mieux aux surprises : lorsqu'un sous-service dépendant n'est pas encore opérationnel, les requêtes associées se dégradent désormais progressivement vers un statut clair "temporairement indisponible" au lieu de générer une pile d'erreurs de serveur génériques qui entraînent toute l'interface vers le bas. Cette « dégradation progressive » est la marque d'un système robuste : la panne d'un composant ne devrait pas paralyser l'ensemble du système ; il devrait clairement indiquer "cette partie n'est pas disponible pour le moment" et laisser le reste continuer. En combinaison avec le précédent canal de téléchargement d'actifs binaires, la chaîne complète d'introduction de matériaux externes et de leur utilisation dans un jeu réel est devenue plus complète aujourd'hui.

Ce que signifie cette journée

Cette journée n’a connu aucune avancée révolutionnaire, mais elle illustre bien le processus d’un produit consistant à « passer du cadre à l’aspect pratique ». L'arrivée du trio d'éditeurs signifie que l'édition visuelle de Studio passe, pour la première fois, du « démontrable » à « vous pouvez réellement vous asseoir et travailler » ; l'ajout de cartes de tuiles 2D a étendu le territoire de la plate-forme de la 3D à la 2D, attirant ainsi un grand nombre de créateurs souhaitant créer des jeux 2D classiques ; et le correctif de compatibilité Windows supprime à l'avance la barrière d'entrée pour davantage d'utilisateurs potentiels. Considérés ensemble, ces trois éléments vont dans la même direction : permettre à plus de personnes, de plus de manières, sur plus d’appareils, d’utiliser véritablement cette plateforme. La maturité d'un outil n'est jamais la naissance d'une fonctionnalité éblouissante, mais ce type de « couverture » et de « convivialité » s'élargissant solidement de jour en jour.