Une porte de construction pour que l'IA ne puisse pas faire semblant de "terminé"

Faire de « fait » une chose vérifiable

Confier le développement d’un jeu à une IA soulève une question fondamentale et incontournable : comment savoir si son « fait » est vraiment terminé ? Les gens croient instinctivement que "si c'est écrit complet, c'est complet", mais une IA n'est pas toujours fiable : elle peut déclarer le succès juste après avoir modifié le code, seulement pour que vous ouvriez un écran noir. L'axe principal du jour résout ce problème de confiance de manière mécanique : ne plus laisser l'IA « être juge d'elle-même », mais contrôler l'accès par un contrôle objectif et exécuté par une machine. Vus parallèlement au lot d'améliorations du moteur du même jour, les deux sont complémentaires : la porte de construction garantit "ce qu'elle fournit fonctionne réellement", tandis que les améliorations du moteur garantissent que "ce qu'elle peut fournir est plus riche, plus grand et plus beau". L’un est le plancher de qualité, l’autre le plafond de capacité ; faire avancer les deux est ce qui rend la plate-forme à la fois « fiable » et « capable ».

Un build-gate de jeu : pas de "terminé" jusqu'à ce qu'il soit réellement compilé

Les jeux de construction d'IA ici présentaient un défaut qui provoquait des maux de tête : ils déclaraient "complet" après avoir modifié le code, uniquement pour que le navigateur ouvre un écran noir, ou pour que le code ne soit pas compilé du tout - vous pensiez avoir un jeu jouable mais en réalité vous aviez une pile de code qui ne fonctionnerait pas. Ce jour-là, une porte de construction a été installée sur l'ensemble du flux : le backend a ajouté une étape de contrôle en amont de la construction qui compile véritablement le jeu avant que l'IA ne déclare l'achèvement ; et une règle stricte a été intégrée dans la charte de l'IA : elle ne peut être déclarée terminée qu'une fois la construction terminée. Le blocage seul ne suffit pas ; la clé est de laisser l'IA les réparer elle-même : les erreurs de construction spécifiques sont transmises en temps réel là où l'IA peut les voir, renvoyant la cause détaillée au lieu d'un simple "ça a échoué". Ainsi, une boucle complète d'autocorrection a pris forme : créer un jeu → l'IA écrit du code → le backend exécute la construction → un échec génère des erreurs spécifiques → l'IA les corrige → jusqu'à ce qu'il réussisse vraiment. La signification est d'une grande portée : cela transforme le « fait » de l'affirmation subjective d'une IA en un fait objectivement vérifiable – quand il dit « c'est prêt », vous pouvez y faire confiance avec beaucoup plus de confiance.

Modèles multi-matériaux : chaque pièce obtient enfin son propre matériau

Le moteur a ajouté aujourd'hui une fonctionnalité clé pour gérer des modèles complexes : un modèle peut contenir plusieurs « sous-maillages », chacun avec son propre emplacement de matériau. Cela semble abstrait mais le cas d'utilisation est très concret : sur un personnage, l'armure est en métal, les vêtements sont en tissu, le visage est en peau, leur texture, leur réflectivité et leur couleur sont entièrement différentes ; sur une voiture, la carrosserie est peinte, les vitres en verre, les pneus en caoutchouc. Auparavant, un modèle ne pouvait souvent porter qu'un seul matériau dans son ensemble, aplatissant ces différences par pièce et donnant ainsi l'impression qu'il était soit entièrement en plastique, soit entièrement en métal, très déformé. Désormais, le moteur peut diviser un modèle en plusieurs sous-maillages par partie et attribuer à chacun son propre matériau, de sorte que les modèles complexes s'affichent enfin correctement avec "chaque partie son propre matériau". Plusieurs bugs de pontage d’importation de modèles ont été corrigés parallèlement, et tous les exemples de jeux réels ont terminé la migration du format de données pour correspondre. Pour les créateurs, cela signifie que les modèles détaillés importés de l’extérieur peuvent être présentés correctement tels qu’ils sont censés apparaître, plutôt que d’être contraints à un seul matériau uniforme.

Plus de lumières, des scènes plus grandes : surélever le plafond à grande échelle

Le moteur a également soulevé le plafond sur "la taille que peut avoir une scène" dans deux directions ce jour-là. L'un d'entre eux est l'éclairage : le rendu a été déplacé vers une approche "d'éclairage groupé" - son idée principale est de découper l'espace de l'écran en plusieurs petites cellules et, pour chaque cellule, de calculer uniquement les quelques lumières qui l'affectent réellement, de sorte qu'une scène puisse contenir beaucoup plus de sources de lumière qu'auparavant sans écraser les performances. Une ville nocturne, un pâté de maisons rempli de néons et de lampadaires, a précisément besoin de la présence simultanée de nombreuses lumières, et ce pipeline ouvre la voie à de telles scènes. L'autre est la capacité : les tampons de rendu contenant les données d'objet ont été modifiés pour « croître à la demande en doublant » — auparavant, le nombre d'objets d'une scène avait un plafond d'environ un millier, au-delà duquel il dépassait ; désormais, le tampon s'agrandit automatiquement par plusieurs à mesure que les objets grandissent, le plafond est levé et les grandes scènes peuvent en contenir beaucoup plus. Les deux sont des travaux sous le capot que les utilisateurs ne voient pas encore qui décident directement « de l'ampleur de votre ambition » – pas une fonctionnalité de jeu spécifique, mais la condition préalable qui transforme « une scène plus grande » d'impossible en possible.

Une manière plus intuitive d'écrire le point d'entrée d'un jeu

Le moteur a également réorganisé aujourd'hui la façon dont "la création d'une application de jeu" est écrite, en la divisant en trois couches plus intuitives : une pour la caméra et les paramètres d'affichage de base, une pour les options de construction/packaging, une pour la façon dont les ressources sont connectées. Auparavant, ces paramètres de nature différente étaient mélangés et faciles à confondre - en particulier pour l'IA qui en dépend pour écrire du code, plus les paramètres sont compliqués et moins clairement catégorisés, plus le risque d'erreur est élevé. Divisé par responsabilité en trois couches claires, ce que fait chaque couche est évident en un coup d'œil, de sorte que l'IA écrit les jeux de manière plus fluide et moins sujette aux erreurs. Ceci et la « porte de construction » du jour sont en réalité les deux faces d’une même médaille : la porte garde la sortie, bloquant la sortie défectueuse ; rendre l'API plus intuitive réduit le risque d'erreur à l'entrée. Une plate-forme dotée du code d’écriture de l’IA doit à la fois effectuer une vérification après coup et rendre plus difficile l’erreur préalable – ensemble, ils améliorent régulièrement la qualité de sortie. Le modèle de nouveau jeu par défaut a également été mis à niveau, livré immédiatement avec un ciel HDR et un personnage contrôlable, de sorte que chaque nouveau jeu commence à partir d'une ligne de base plus présentable.

L'éditeur affiche la géométrie réelle + une relecture plus stable

L'éditeur s'est rapproché de ce que vous voyez est ce que vous obtenez aujourd'hui : il précharge désormais les fichiers de modèle, de sorte que la vue d'édition affiche directement la géométrie réelle d'un modèle plutôt qu'une zone d'espace réservé temporaire. Cela ressemble à un détail, mais l'impact est réel : lorsque vous placez, alignez et ajustez un objet dans l'éditeur, vous voyez à quoi il ressemble réellement, au lieu d'imaginer ce que deviendra finalement une boîte qui le remplace. Le pipeline d'actifs sous-jacent a également été migré vers le format de pack de scènes natif du moteur, et la vue d'édition comporte également un ciel HDR, alignant davantage l'environnement d'édition sur le runtime final. En cas d'erreur, la superposition sur le canevas développe la cause sous-jacente plus détaillée plutôt qu'un message générique, pour un diagnostic rapide. La rediffusion du chat a également corrigé l'ordre d'entrelacement des cartes multi-agents : lorsque vous examinez une partie de l'historique, les allers-retours entre plusieurs IA sont correctement tissés, correspondant exactement à l'ordre que vous avez vu en direct. Ensemble, ces éléments servent une seule chose : rendre ce que vous voyez dans l'éditeur et en rediffusion aussi proche que possible du réel.

Suivre les progrès de l'équipe

Cette journée a également ajouté des graphiques de visualisation de l'avancement du travail de l'équipe. Alors que de plus en plus de travaux sont menés en parallèle par les agents d’IA, « où en sommes-nous exactement maintenant et combien il en reste » devient une question qui mérite d’être examinée. Les courbes de débit et d'épuisement ajoutées représentent ces informations sous forme de lignes doubles s'accumulant au fil du temps, associées à un panneau de mesures du projet, de sorte que l'équipe voit le rythme global en un coup d'œil : combien de choses ont été accomplies dans ce tronçon, combien sont encore en vol, si la vitesse accélère ou ralentit. Pour un flux de développement fortement dépendant de l'automatisation, cette « visibilité globale » est très importante : même si les gens confient une grande partie de l'exécution concrète à l'IA, ils doivent garder le contrôle de la situation globale, sachant dans quelle direction et à quelle vitesse les choses évoluent. Tracer les progrès est précisément un moyen de prendre du recul par rapport à l’enchevêtrement des détails d’exécution tout en gardant une vue d’ensemble stable.

Ce que signifie cette journée

Les deux axes principaux de la journée répondent ensemble à deux facettes de la proposition fondamentale "comment faire en sorte qu'une IA construise de bons jeux de manière fiable". Le build-gate répond "fiable" : grâce à une vérification objective de la construction et à un retour d'erreur spécifique, il transforme le "fait" de mots vides en un fait qui peut être vérifié et auto-corrigé - la pierre angulaire de la confiance. La série d'améliorations du moteur répond « bonne » : le multi-matériau rend les modèles plus réels, l'éclairage groupé et la capacité accrue rendent les scènes plus grandioses, une entrée plus intuitive permet à l'IA de moins se tromper – l'expansion des capacités. Ce qu'une plateforme de création basée sur l'IA redoute le plus, c'est « qu'elle semble impressionnante, mais elle n'est pas fiable » ; et cette journée a confirmé exactement les deux choses les plus fondamentales à la fois : « fiable » et « bien fait ». Lorsque la machine est à la fois plus performante et plus strictement vérifiée, les gens peuvent lui confier véritablement et en toute confiance « la construction d’un jeu ».