Le runtime du jeu passe entièrement au moteur interne

Un tournant décisif : désormais, votre jeu tourne sur notre propre moteur

C’est un véritable tournant. Avant cela, ce qui motivait réellement votre jeu dans l'aperçu était encore une approche de rendu à usage général empruntée très tôt pour un démarrage rapide ; et les capacités que l'équipe du moteur avait développées ces jours-ci, bien qu'en croissance constante, n'étaient pas vraiment devenues « le moteur qui fait tourner les jeux ». Ce jour-là, le temps d'exécution a été transféré en gros sur le moteur interne : à partir d'aujourd'hui, chaque jeu avec lequel vous discutez fonctionne véritablement sur notre propre moteur. Son importance n'est pas seulement « d'échanger la base », mais de rassembler pour la première fois les capacités dispersées construites au cours des derniers jours (éclairage physique, ombres, lumière du ciel ambiante, système d'actifs, couches 2D) dans un seul moteur, et non plus chacune séparément. Les éléments ci-dessous tournent autour de ce commutateur ou ont été pilotés par celui-ci.

Pourquoi un moteur maison vaut-il la peine d'être choisi

Remplacer une approche prête à l'emploi et fonctionnelle pour construire un moteur à partir de zéro coûte clairement cher ; alors pourquoi est-ce que ça vaut le coup ? Le cœur est le contrôle. Emprunter une approche générale laisse la qualité de l'image, les performances et les fonctionnalités limitées par les compromis de cette approche, et faire quelque chose pour lequel elle n'a pas été conçue est délicat ; en interne, le rendu est entièrement contrôlable, les problèmes peuvent être retracés jusqu'au bout et de nouvelles fonctionnalités peuvent être créées une seule fois et prendre effet partout, sans contourner les limites de quelqu'un d'autre. Plus important encore, ce moteur est conçu spécifiquement pour les « jeux d'écriture d'IA » : ses interfaces, son système d'actifs et son comportement par défaut peuvent tous être peaufinés pour « permettre à l'IA d'écrire correctement et de réutiliser facilement le code généré », ce qu'aucune approche tierce générale ne peut offrir. Le changement d'aujourd'hui fait passer la base la plus fondamentale du produit de « loué » à « le nôtre ».

Les matériaux bénéficient de shaders personnalisés

En actionnant le moteur, le système matériel s'est également divisé en deux couches : le modèle et l'instance. L’un est un matériau physique standard prêt à l’emploi qui couvre la plupart des objets ordinaires ; l'autre permet à un objet de porter son propre shader personnalisé pour un effet visuel distinctif (lueur, distorsion, pulsation, champs d'énergie) qui n'est plus lié au matériau standard. Pour éviter que « plus de variété » ne « devienne lente », le moteur met en cache un pipeline de rendu par matériau, réutilisant le même matériau et en gardant les différents séparés, à la fois flexibles et efficaces. Une démonstration de « lueur pulsée » a prouvé que le chemin fonctionne de bout en bout. Pour tous ceux qui souhaitent qu’un objet ne ressemble pas aux autres, cela donne la bonne voie : la simplicité du matériau standard, plus la liberté de le personnaliser entièrement en cas de besoin.

Téléchargement de maillage plus strict : mauvaises erreurs de données sur place

Cette journée a également ajouté une vérification d'entrée stricte au chemin de bas niveau de "téléchargement des données de maillage vers le GPU" : si les données de maillage entrantes sont mal formées (par exemple, le nombre de données par sommet ne correspond pas aux attentes), le moteur échoue rapidement sur place plutôt que de l'avaler silencieusement et de vous laisser deviner quand l'image se brisera plus tard d'une manière étrange. Une migration unifiée des formats de données s'est accompagnée, alignant les formats de données de sommet pertinents sur une norme cohérente. Cela ressemble à « simplement ajouter un contrôle », mais cela incarne un principe d’ingénierie important : faire apparaître les erreurs le plus tôt possible et aussi près que possible de l’endroit où elles se produisent réellement, plutôt que de les laisser dériver dans le pipeline vers une bizarrerie difficile à retracer. Pour un moteur qui demandera à l'IA de générer des données de maillage en masse, ce contrôle d'accès « les mauvaises données ne peuvent pas entrer » permet d'économiser d'innombrables heures de débogage ultérieur.

Plus d'agents spécialisés + sélection dans l'outil

La liste de collaboration s'est à nouveau remplie ce jour : plusieurs nouveaux agents avec des spécialités distinctes sont arrivés, vous pouvez donc choisir le bon pour assumer une tâche plutôt que de tout confier à un seul généraliste. La barre supérieure de la fenêtre d'outils comporte un sélecteur d'agent permettant d'attribuer quel agent travaille dans un atelier donné et d'ouvrir ses détails en un clic pour voir dans quoi il est bon. Le backend a également ajouté une création/lecture/mise à jour/suppression unifiée pour les agents avec prise en charge des rôles, rendant ainsi la « gestion de votre équipe IA » elle-même ordonnée. Trouver le bon agent pour le bon travail est la clé de l'efficacité de la collaboration : confier un besoin artistique à un agent spécialisé en art est bien plus fiable qu'à un touche-à-tout. Cette journée a rendu le « choix de la personne » à la fois pratique et fluide.

Ne laissez pas les documents mentir : réconciliation automatique entre documents et code

Cette journée a également soulevé une porte spéciale : vérifier automatiquement si les « documents de conception » et le « code réel » sont toujours alignés. Chaque projet en évolution longue a un problème commun : les documents décrivent l'intention initiale tandis que le code ne cesse de changer, et au fil du temps, les deux divergent discrètement jusqu'à ce que les documents commencent à induire en erreur. Cette porte de réconciliation déclenche une alarme lorsque les emplacements des codes clés référencés par les documents changent, vous obligeant à mettre à jour soit le code, soit le document, sans les laisser se séparer secrètement. Il aborde la « fiabilité des documents », le problème le plus facilement négligé mais qui érode l'efficacité à long terme. Pour une plate-forme qui prend au sérieux "L'IA s'appuie également sur des documents pour comprendre le système", garder les documents honnêtes est en soi une infrastructure de base - car les documents menteurs induisent en erreur les humains et l'IA.

Ce que signifie cette journée

Le poids de cette journée repose presque entièrement sur ce changement d’exécution : changer le moteur qui exécute votre jeu de « loué » à « le nôtre ». Il ne s'agit pas d'une fonctionnalité qui rend instantanément l'image plus jolie, mais d'une décision fondamentale quant à « qui détient l'initiative pour l'avenir » : à partir de maintenant, la qualité de l'image, les performances et l'orientation de l'optimisation de l'IA sont entre nos mains. Grâce à ce changement, les documents sont devenus personnalisables, les mauvaises données ne peuvent pas entrer, l'équipe est plus facile à recruter et les documents ne mentent plus, ce qui rend ce « propre moteur » plus contrôlable et plus fiable. Une plate-forme qui ose, après avoir déjà fonctionné, remplacer ses fondations les plus essentielles par une fondation interne n'est pas après une belle apparence momentanée mais une autonomie durable - et c'est le jugement qui mérite le plus d'être rappelé aujourd'hui.