Coup d'envoi du projet

Pourquoi le premier jour commence par la fondation du rendu

C’est le premier jour du dossier public de la plateforme. Pour une plate-forme où « vous discutez et un jeu apparaît », une chose doit être vraie tout en bas : le navigateur doit restituer la 3D – de manière authentique et stable. Le premier jour ne consistait donc pas à accumuler une interface flashy ; il a mis tous les efforts sur la partie la plus difficile, la base du rendu : créer un pipeline de rendu directement sur la capacité graphique de nouvelle génération (WebGPU) du navigateur en interne, plutôt que d'encapsuler une bibliothèque générale prête à l'emploi. Ce chemin est plus difficile et plus lent au début – de nombreux détails que d’autres ont emballés doivent être parcourus par nous-mêmes, et les pièges comblés un par un. Mais il décide si la qualité de l'image, les performances et les fonctionnalités restent entre nos mains plus tard, au lieu d'être limitées par les compromis d'une bibliothèque en amont. Les livrables d'aujourd'hui sont des faces vraiment différentes d'une grande chose : "éclairer correctement le premier pixel dans un navigateur". Réaliser en premier cette chose la plus sous-estimée et la moins compromise est ce qui donne à chaque rêve ultérieur de « générer des jeux par conversation » une place où se tenir.

Un pipeline de shader fonctionnel : WGSL + une cale de compilation de shader + PBR simplifié

Le cœur du rendu est le shader, le petit programme qui indique au GPU "de quelle couleur chaque pixel doit être". Ce jour-là, tout un pipeline de shaders a été câblé : écrit dans le langage de shader du standard graphique du navigateur (WGSL), associé à une cale de compilation qui transforme la source du shader en un format exécutable par GPU, ainsi qu'une implémentation simplifiée d'ombrage basé sur la physique (PBR). « Physiquement basé » signifie que les matériaux réagissent à la lumière selon des règles du monde réel : le métal ressemble au métal, le plastique au plastique, et non à un papier découpé de couleur. Ce PBR simplifié utilise délibérément une structure de liaison de ressources allégée (seulement trois groupes de liaison) pour rester léger tout en gardant l'image crédible - facile à comprendre et facile à étendre. Le cale de compilation est particulièrement important : WebGPU ne consomme pas directement la source du shader de haut niveau, donc une étape de traduction dans un format de niveau inférieur est nécessaire entre les deux, et sa résolution dans le navigateur est ce qui permet "d'écrire un shader et de voir immédiatement le résultat". Depuis ce jour, le moteur ne se contente plus de teinter des triangles ; il restitue des objets qui sont éclairés et qui ont de la matière - la première étape clé de « peut dessiner » à « dessine correctement » et le bon point de départ pour tous les matériaux et éclairages plus riches à suivre.

La couche du périphérique de rendu reprise de bout en bout

Pour que les shaders s'exécutent, il doit y avoir une « couche de périphérique de rendu » en dessous qui gère tout : demander les ressources GPU, gérer la surface du canevas, organiser les commandes de dessin de chaque image et les soumettre au GPU. Cette journée a complètement pris en charge cette couche du début à la fin, vérifiant toute la chaîne étape par étape - de la configuration initiale à la production stable image après image, une série d'étapes toutes cochées. Les joueurs ne voient jamais cette couche, mais c'est elle qui gère tout le rendu : lorsqu'elle est solide, les jeux au-dessus sont solides ; Lorsqu'il a des trous, même les effets les plus jolis s'éteignent ou s'écrasent de manière aléatoire. De nombreux problèmes de rendu ressemblent à un effet brisé sur la surface, mais la racine est en réalité que cette couche n'est pas résolue. Le rendre échelonné et vérifiable présente également des avantages à long terme : lorsqu'une image future tourne mal, vous pouvez remonter à travers ces étapes pour identifier quel lien s'est rompu, plutôt que de regarder, impuissant, un écran noir. Le rendre robuste ouvre d’abord une voie fiable pour chaque fonctionnalité de rendu à venir.

Le premier obstacle inter-environnement : un correctif du cycle de vie de la mémoire GPU

Exécutant WebGPU dans différents environnements, les tampons de mémoire GPU suivent des règles de cycle de vie strictes pour « quand ils sont utilisables, quand les restituer » ; une fois que le timing est mal aligné, vous obtenez des données sales à moitié lues ou un crash pur et simple. Ce jour-là, le cycle de vie du tampon a été corrigé lors de l'étape de "lecture/écriture mappée", lui faisant suivre les règles de deux environnements assez différents : l'un dans lequel, sans GPU discret, le rendu est simulé uniquement par logiciel, et l'autre dans lequel le navigateur appelle directement les graphiques natifs de la machine. Pour que le même code soit correct sur les deux chemins, chaque allocation et chaque retour de mémoire GPU doivent avoir un timing exactement correct. De tels correctifs n'apportent aucune « nouvelle fonctionnalité visible », mais c'est exactement ce qui décide si le moteur est « un jouet qui fonctionne parfois sur ma machine » ou « une base qui fonctionne également sur une autre machine et un autre environnement ». Une grande partie du coût d'un moteur de rendu interne est consacrée à cette tâche consistant à colmater les incertitudes inter-environnementales, un trou à la fois ; chaque branchement élargit la gamme d'appareils que la plate-forme peut couvrir de manière fiable.

Concurrence sécurisée : un verrou de cycle de vie par agent

L'autre côté de la plateforme, ce sont les agents qui discutent avec vous et font le travail. Dès le départ, cette plateforme envisage « une équipe d'agents travaillant en même temps » : un responsable distribuant les tâches, des sous-agents prenant chacun une part, plutôt que de parler à un assistant à la fois. Mais dès que plusieurs agents s'exécutent simultanément, la classique « condition de concurrence critique » apparaît : deux actions touchent l'état du même agent presque au même instant sans ordre garanti, produisant une corruption intermittente ou des blocages. Cette journée a extrait la gestion du cycle de vie de chaque agent dans un composant dédié de « verrouillage asynchrone » : les opérations sur le même agent (démarrage, arrêt, changement) sont sérialisées via ce verrou dans une file d'attente, garantissant qu'une seule action touche son état à tout moment. Ainsi, gérer plusieurs agents ne signifie plus se marcher sur les autres et les comportements deviennent prévisibles. Pour une plate-forme qui considère la « collaboration multi-agents » comme une promesse fondamentale, ce verrou est un élément clé qui permet au plan d'aboutir réellement au lieu de vivre uniquement dans une démo.

Un terminal plus robuste : le collage ne plante pas + conseils de collaboration

Au-delà de la sécurité de la concurrence, l'agent de chat a obtenu deux correctifs « au quotidien ». Tout d'abord, la saisie du terminal : un ancien bug "la deuxième pâte se fige" a été corrigé, ce qui rend le collage d'un texte d'exigence long sur la ligne de commande plus résilient : collez un bloc entier de configuration ou une spécification longue et il ne se grippera pas. Deuxièmement, la communication de collaboration : l'outil utilisé par les agents pour s'envoyer des messages a été étoffé par des scénarios d'utilisation et des conseils de réponse, de sorte que "qui doit envoyer un message à qui, quand et comment" a une structure, et la communication pendant la collaboration multi-agents cesse d'être ad hoc. Ce sont les détails clés qui ne semblent pas gênants à utiliser : un assistant qui plante lorsque vous collez vos exigences, ou qui se transforme en babillage lors d'une collaboration, ne peut pas faire confiance, aussi intelligent soit-il. Ce n’est qu’en lissant ces aspérités une par une que cela devient quelque chose auquel vous confierez un vrai travail.

Pas de cache gaspillé : les rappels dynamiques ajoutent un nouveau message

Lorsque l'on parle d'un modèle volumineux, le contexte stable initial peut être « mis en cache » pour économiser du temps et de l'argent ; mais réécrire le front à chaque fois invalide ce cache et force un recalcul complet. Cette journée a modifié les « rappels dynamiques » (les informations temporaires qui changent la conversation transmises au modèle) de « réécrire le début » à « ajouter un nouveau message à la fin », préservant ainsi le cache des préfixes. La sensation directe pour vous : des réponses plus rapides et un coût réduit pour les longues conversations. Une telle optimisation semble minime en soi, mais sur une plate-forme construite autour d'une longue collaboration avec l'IA, elle s'ajoute à de réelles différences en termes de fluidité et de dépenses - et plus la conversation se prolonge, plus cet appel précoce est payant. Cela révèle également une position qui traverse l'ensemble du projet : traiter « la façon dont nous parlons au modèle » comme une ingénierie digne d'être véritablement peaufinée, et non comme une invite créée sur un coup de tête.

Ce que signifie cette journée

En regardant les pièces du premier jour ensemble, vous remarquez qu'aucune d'entre elles n'est délibérément une « fonctionnalité à montrer » : pas de jolie page d'accueil, pas de démo flashy. Ils constituent la première pierre angulaire de chacune des quatre lignes directrices : rendu, moteur, concurrence, conversation. Derrière cela se cache un jugement lucide : le fait que "générer un jeu en discutant" fonctionne en fin de compte ne dépend pas de la capacité du premier jour à faire une démonstration d'une astuce, mais de la question de savoir si la base est suffisamment solide : dessinable dans le navigateur, stable dans tous les environnements, agents qui ne se battent pas, longues conversations qui ne brûlent pas d'argent. Couler ces quatre fondations en même temps est ce qui permet à chaque jour ultérieur de s'empiler régulièrement sur elles. C'est également le premier modèle que ce journal des modifications souhaite laisser pour le développement futur : réussir en premier les choses les plus difficiles, les moins glamour et les moins compromises.