Les personnages projettent enfin des ombres + un éditeur entièrement autonome

Une journée à fort volume : remplir les détails et définir les règles

Le travail de cette journée a été important, allant du « remplissage des détails » à la « définition des règles ». Le côté remplissage des détails était le travail qui façonnait directement l'apparence et la convivialité d'un produit : créer un personnage projetant une véritable ombre au sol, faire en sorte que les animations se mélangent en douceur, faire en sorte que le moteur ingère des modèles à partir d'outils professionnels et compléter toute la catégorie des cartes de tuiles 2D. L'aspect définition des règles concernait l'infrastructure, inédite mais d'une grande portée : réécriture de l'éditeur dans un module entièrement autonome, intégration de l'ensemble de la base de code avec sa première porte de qualité automatisée et renforcement du déploiement multiplateforme. Le premier améliore « ce qui est construit maintenant » ; ce dernier rend « le processus de construction ultérieure » plus stable. Pour qu’un projet aille loin, il faut avoir les deux mains fortes : peaufiner continuellement l’expérience visible tout en fixant tranquillement, une à une, les règles qui garantissent la santé à long terme. Cette journée a été un cas d’école où les deux progressaient ensemble.

Le personnage jette enfin une ombre : une journée entière de broyage

L'échantillon d'ARPG dark-fantasy de la veille présentait un défaut immédiat : le héros sorcier ne projetait aucune ombre sous ses pieds, la silhouette entière comme une texture flottant dans les airs, sans aucune impression de "se tenir sur le sol". Cette journée s'est déroulée contre cette ombre pendant une journée entière, un processus sinueux : d'abord essayer d'écrire un shader dédié à la projection d'ombre pour le personnage truqué, puis utiliser une géométrie proxy invisible pour projeter l'ombre à sa place, puis revenir à une "fausse ombre" ovale épinglée sous les pieds comme filet de sécurité ; tout en ajustant à plusieurs reprises les paramètres dont la projection d'ombre a besoin - en ajoutant une passe de projection aux matériaux de la scène, en inclinant la lumière directionnelle pour allonger les ombres, en ajustant la précision des ombres en cascade, en réduisant l'intensité de la lumière du ciel pour que le contraste de la lumière directionnelle soit visible, en réglant l'intensité et l'angle du clair de lune. Après tous ces essais, le véritable point crucial a finalement été cerné : le nombre de cascades de l'ombre a dû passer de 4 à 1 pour être lancé de manière fiable - ce qui a en fait fait ressortir un bug de moteur plus profond (le chemin d'ombre directionnel à 4 cascades se comporte mal en mode jeu), organisé dans un rapport détaillé pour l'équipe du moteur. L'atmosphère nocturne était adaptée : un clair de lune tamisé et quelques torches autour du camp, évoquant l'ambiance sombre et fantastique de « éliminer les monstres autour d'un feu la nuit ». Une journée entière de persévérance a produit un effet apparemment minime mais crucial : le personnage a finalement « atterri ».

L'éditeur fonctionne de manière entièrement autonome

L'article autonome de l'éditeur a été réécrit ce jour dans une coque véritablement autonome. Il s'agissait d'un système « autonome » depuis un certain temps, mais cette entrée autonome était toujours liée à l'interface de discussion principale : elle devait fonctionner à l'intérieur de l'interface principale, sans être vraiment indépendante. Aujourd'hui, il a été entièrement séparé et réécrit : il apporte sa propre disposition multi-panneaux ancrable, restitue et organise lui-même les neuf panneaux dont l'éditeur a besoin, sans dépendre du tout de la configuration de l'interface principale. Un script d'amorçage en un clic a été ajouté qui, sur une nouvelle machine, prépare automatiquement les différents artefacts de construction nécessaires à l'exécution - y compris les éléments binaires nécessaires au rendu de bas niveau - afin qu'il soit prêt à être modifié immédiatement. L'importance est de transformer l'éditeur d'une "partie intégrée du Studio principal" en "une application complète que vous pouvez ouvrir et utiliser seule". Il s'agit à la fois d'une réalisation complète de la conception modulaire et d'une ouverture de la voie pour intégrer ultérieurement l'éditeur dans d'autres produits ou le distribuer en tant qu'outil autonome.

L'ensemble de la base de code obtient sa première porte CI

Cette journée a équipé l’ensemble de la base de code de sa première porte de qualité automatisée. Une porte CI (intégration continue) signifie que chaque fois que quelqu'un soumet une modification, le système exécute automatiquement une vérification - cette vérification initiale comporte trois parties : la vérification du type (confirmant les interfaces entre les parties de code alignées), la construction (confirmant que le code se compile réellement) et le test de fumée (une exécution confirmant que la fonctionnalité de base n'a pas été interrompue). Ce n'est que si les trois réussissent que le changement est autorisé dans la ligne principale. Une fois ouverte, la porte a immédiatement fait apparaître plus de vingt incohérences de type qui avaient « dérivé tranquillement » dans quelques sous-projets – elles ne constituaient pas d'erreurs lors d'une utilisation normale mais avaient déjà posé des dangers ; ils ont été nettoyés par lots le même jour. L'importance est considérable : à partir de ce jour, aucun nouveau changement ne peut discrètement entraîner de tels problèmes sur la ligne principale : la machine les arrête automatiquement à la porte. Pour une base de code modifiée à haute fréquence en parallèle par de nombreux agents d'IA, ce « gardien » automatisé est particulièrement crucial : une personne ne peut pas surveiller chaque changement, mais une porte le peut, et elle ne se lasse jamais et ne joue jamais de favoris. Remettre le plancher de la qualité à l'automatisation pour le protéger est exactement la marque d'un projet passant d'une « croissance rapide » à une « croissance durable ».

Formats de modèles professionnels + mélange fluide d'animations

Le moteur a ajouté aujourd’hui deux fonctionnalités solides sur les personnages et les ressources. Premièrement : il ingère formellement les formats de modèle générés directement par les outils de modélisation professionnels. Ce format contient entièrement les paramètres d'animation, de squelette et même de physique, alors que son utilisation préalable nécessitait d'abord une conversion vers un autre format commun au Web, perdant inévitablement des détails ; désormais, le moteur le lit directement, de sorte que les actifs issus des outils professionnels entrent fidèlement dans le jeu. Deuxièmement : cela permet aux actions des personnages de se fondre en douceur : là où passer de « marcher » à « courir » ou « inactif » à « attaquer » était autrefois un montage instantané dur qui semblait nerveux, maintenant plusieurs clips peuvent se mélanger proportionnellement et effectuer une transition en douceur, rendant le mouvement d'un personnage beaucoup plus cohérent et naturel – crucial pour la sensation des jeux d'action. Un outil de dessin et de débogage immédiat a également été ajouté, dessinant des lignes d'assistance et des cadres de délimitation directement sur l'image, ce que vous voyez est ce que vous obtenez pour le diagnostic, bien plus intuitif que de deviner à partir de chiffres. Ensemble, ceux-ci complètent une autre partie de la chaîne d'outils pour "créer un personnage qui bouge et bouge naturellement".

Un système complet de cartes de tuiles 2D débarque dans le moteur

Le moteur a également systématiquement complété et décroché toute la catégorie des cartes en tuiles 2D ce jour-là. Les cartes de tuiles constituent le moyen le plus classique de créer des jeux 2D : elles représentent le monde en une grille de cellules carrées, chacune contenant une petite image, assemblées en un niveau complet. Ce qui a atterri aujourd'hui n'est pas seulement "peut afficher", mais un ensemble complet de mécanismes : actifs de jeu de tuiles, couches de tuiles, extraction et rendu efficaces basés sur des morceaux, retournement horizontal/vertical et gestion des ancres pour les tuiles, sélection et tri corrects des sprites, et une chaîne de validations de données strictes qui échouent rapidement en cas d'erreur. Il était accompagné de démos exécutables et de tests automatisés qui le soutenaient tout au long du processus. Cela pousse la capacité 2D de la plate-forme des bases préliminaires de ces derniers jours au niveau « vous pouvez sérieusement créer un jeu 2D ». Le premier jeu dans l'esprit de nombreux créateurs est précisément un jeu en 2D : un défilement latéral, une vue de haut en bas, un monde de pixel art ; ouvrir la voie à la 2D ouvre solidement la porte à ce grand nombre de créateurs. Avec des bases solides à la fois en 3D et en 2D, la gamme de types de jeux que la plate-forme peut proposer est suffisamment large.

Ce que signifie cette journée

Cette journée, avec une production énorme, a répondu à la fois "est-ce bien fait" et "le chemin est-il stable". Le processus consistant à broyer une journée entière sur une ombre représente le mieux l'attitude de cette équipe : un personnage sans ombre peut sembler un défaut sans conséquence pour beaucoup, mais il décide directement si l'image est crédible - et la résoudre complètement nécessitait de ne pas la contourner mais d'essayer couche par couche, d'exclure couche par couche, jusqu'à trouver le véritable nœud caché au plus profond du moteur et de l'enregistrer honnêtement. Pendant ce temps, l'indépendance totale de l'éditeur, la mise en place du premier portail CI et le renforcement du déploiement multiplateforme fournissent un terrain durable pour ce type de diligence : lorsque le niveau de qualité est protégé par l'automatisation et que les modules peuvent évoluer de manière indépendante, l'équipe est libre de peaufiner chaque ombre. Tirer le meilleur parti de l'expérience immédiate tout en établissant les fondations à long terme - cette journée a permis de réaliser les deux.