Ce qu'il faut réellement pour créer un monde ouvert dans un navigateur

Par Mariana Muntean, CEO de Cinevva

L'équipe de Cinevva vient de publier l'un des journaux d'ingénierie les plus transparents de ces dernières années dans le développement de jeux : une série en 12 parties documentant notre tentative de créer un monde ouvert multijoueur qui s'exécute entièrement dans le navigateur. Aucun téléchargement. Aucune boutique d'applications. Juste une URL.

Le projet s'est étendu sur 24 expériences techniques que nous appelons des « spikes » -- de courts prototypes ciblés, conçus chacun pour répondre à une question risquée. Chaque spike a été publié avec du code source fonctionnel que vous pouvez ouvrir et exécuter dans votre navigateur dès maintenant. La série a été écrite par Oleg Sidorkin, CTO et cofondateur de Cinevva, et ressemble moins à du marketing qu'à un journal de terrain tenu sur la ligne de front de ce que les navigateurs peuvent réellement accomplir en 2026.

Ce qui rend la série intéressante à lire -- même si vous n'envisagez jamais de créer des systèmes de terrain --, c'est la méthode sous-jacente. C'est une étude de cas sur la manière de réduire les risques d'un projet ambitieux avant de s'engager dans des dépenses importantes.

Commencer par la question la plus difficile

La plupart des projets de monde ouvert échouent selon une séquence prévisible. D'abord, vous avez un superbe concept. Puis une jolie scène. Ensuite, vous découvrez que votre budget par image était déjà épuisé avant même que le gameplay n'existe.

Notre équipe a inversé l'ordre. Le premier spike était délibérément rudimentaire : un maillage de terrain de 512 mètres, 500 objets instanciés, un relief généré par bruit procédural, un plan d'eau et du brouillard. Pas d'ombres, pas de passe d'embellissement. La seule question était de savoir si un navigateur pouvait maintenir une fréquence d'images stable pendant que la caméra s'y déplaçait.

C'était possible. Et ce « oui » a établi ce qu'Oleg appelle un « contrat de référence » -- un coût mesuré servant de référence pour une scène minimale, auquel chaque fonctionnalité suivante devait se justifier. Si un nouvel effet était superbe mais faisait exploser le budget par image, il n'était pas retenu. Du moins, pas encore.

Ce type de discipline semble évident. En pratique, il est rare dans les environnements de prototypage rapides où tout le monde s'enthousiasme pour la prochaine avancée visuelle.

Le pari de la physique

La deuxième expérience s'est attaquée à un débat architectural qui divise les développeurs de jeux sur navigateur : la physique doit-elle s'exécuter sur le thread principal, où sa mise en œuvre est plus simple, ou dans un Web Worker, où elle ne peut pas bloquer le rendu ?

Sur le papier, exécuter la physique dans un worker est plus propre. En pratique, la crainte concerne la latence. Chaque événement d'entrée doit franchir deux fois une frontière de communication : une première fois pour atteindre le worker, puis une seconde pour rapporter le résultat. Si cet aller-retour est trop lent, appuyer sur une touche et voir son personnage se déplacer semblera poussif.

L'équipe a intégré le moteur physique Rapier (compilé de Rust vers WebAssembly) dans un worker dédié, mis en place le pipeline de messages, puis effectué des mesures. Le surcoût était négligeable. Les commandes restaient instantanées. Mais nous avons pris soin de préciser que nous avions validé un scénario particulier, et non une règle universelle. Lorsque la charge sur le GPU et la complexité du streaming changeraient par la suite, il faudrait réexaminer ces hypothèses.

Les spikes ennuyeux qui ont sauvé le projet

La troisième partie de la série ne contient aucune capture d'écran. Elle couvre trois expériences peu spectaculaires en apparence, mais lourdes de conséquences pour le produit.

La première visait à déterminer si les Durable Objects de Cloudflare pouvaient gérer la diffusion en temps réel des positions à des fréquences de tick dignes d'un jeu -- autrement dit, le socle du multijoueur. En cas d'échec, toute l'architecture réseau aurait dû être partitionnée très tôt, au lieu de reposer sur la gestion d'une île par une instance unique.

La deuxième validait un profil de qualité mobile : non pas un préréglage pour ordinateur simplement rebaptisé, mais un chemin de rendu explicitement peu coûteux, construit à partir de la même base de terrain. Il s'agissait de savoir si le monde pouvait rester lisible et réactif sous les contraintes des GPU mobiles sans réécrire le moteur de rendu.

La troisième évaluait si les scripts de comportement générés par IA pour les workflows des créateurs seraient suffisamment fiables pour une utilisation en production.

Aucune de ces expériences n'a produit de bande démo. Toutes les trois ont fixé des limites strictes qui ont orienté chaque décision architecturale ultérieure. Oleg écrit que ces « spikes peu spectaculaires ont fait évoluer l'architecture plus rapidement que les spikes visuels ».

Le streaming : là où les beaux projets s'effondrent

On peut dissimuler beaucoup de choses dans une image fixe. On ne peut pas masquer une saccade de 40 millisecondes lorsqu'un joueur franchit la limite d'un chunk en courant.

L'équipe a testé le streaming avant de créer un terrain avancé, en séparant délibérément les problématiques. Le Spike 6 a validé le chargement des chunks voisins avec du contenu simple. Ce n'est qu'après avoir obtenu ce signal clair que le Spike 11 a introduit le streaming de heightmaps compressées avec raffinement progressif -- en chargeant d'abord le terrain à une résolution de 17 échantillons, puis de 33, avant de passer à la grille complète de 65 échantillons.

L'ordre des opérations s'est révélé plus important que prévu. Si nous avions commencé directement avec des chunks de hauteur compressés, chaque saccade aurait été ambiguë. S'agissait-il d'un problème de décodage, d'un blocage lors du téléversement d'une texture ou d'un problème de mise à jour de la géométrie ? Tester d'abord un streaming simple a éliminé toute une catégorie d'incertitudes.

Une leçon pratique s'en est dégagée : il faut mesurer directement les blocages liés aux téléversements, et non les déduire du nombre moyen de FPS. Les moyennes masquent les pics de durée d'image, alors que ce sont précisément ces pics que les joueurs ressentent.

La guerre des budgets visuels

Trois expériences distinctes se sont attaquées séparément aux coûts de rendu, plutôt que de les regrouper. La densité de la végétation et l'animation du vent. Les matériaux de terrain multicouches avec projection triplanaire pour les parois rocheuses. Les shadow maps en cascade sous une charge de terrain réaliste.

Le spike consacré à la végétation a révélé que regrouper les instances en un nombre réduit de maillages avait plus d'impact que de diminuer le nombre de polygones par brin. Celui consacré aux matériaux a montré que la projection triplanaire sur les surfaces verticales justifiait son coût GPU, contrairement à l'ajout d'une cinquième couche de textures splat. Celui consacré aux ombres a établi que trois cascades d'une résolution de 1024 produisaient des ombres de contact acceptables sans dépasser 2 millisecondes de temps GPU.

L'équipe a adopté une règle sans détour : une fonctionnalité ne progresse que si son coût peut être justifié par des mesures du temps de rendu par image. Cette contrainte, instaurée tôt, a considérablement simplifié les décisions architecturales ultérieures concernant le terrain volumétrique et les clipmaps.

Le pivot qui a changé la trajectoire du projet

Avant le Spike 10, notre modèle mental était le suivant : « un monde plus vaste implique davantage de géométrie ». Après le Spike 10, il est devenu : « budget géométrique constant, avec mise à jour d'anneaux centrés sur la caméra ».

Les clipmaps géométriques -- des anneaux concentriques de terrain centrés sur la caméra, chacun étant progressivement moins détaillé -- permettaient de maintenir un nombre de triangles à peu près constant, quelle que soit la distance d'affichage. L'astuce pratique résidait dans le géomorphing aux limites des anneaux : fusionner progressivement les hauteurs des sommets dans le shader afin que le passage d'un niveau de résolution à l'autre reste invisible en mouvement.

Une leçon subtile est venue de la méthodologie de test. Les clipmaps paraissent correctes sur les captures d'écran. Leurs artefacts ne se révèlent que lors de déplacements prolongés de la caméra à travers les limites des anneaux. L'équipe a passé du temps à effectuer des traversées à vitesse constante et à rechercher du bruit temporel. « Les captures d'écran mentaient, écrit Oleg. Le mouvement disait la vérité. »

Passer sous terre

Les heightmaps ne peuvent pas représenter des grottes. Elles stockent une seule valeur d'élévation par point d'une grille. Dès que l'on veut des tunnels, des surplombs ou des parois rocheuses sculptées, il faut un terrain volumétrique.

Le Spike 12 a implémenté les marching cubes sur le GPU au moyen de compute shaders WebGPU, afin d'extraire des maillages triangulaires d'un champ de distance signé en 3D. Quatre chunks de 64³ s'exécutaient simultanément, avec des mises à jour du maillage à chaque image à partir de modifications animées du SDF. Le compute shader gérait l'ensemble du processus -- évaluation du champ, classification des cellules et émission des sommets -- sans aucune relecture par le CPU.

Le véritable défi n'était pas de faire fonctionner le système. Il fallait le faire fonctionner aux côtés de tout le reste. L'intégration au graphe de scène de Three.js, la gestion du cycle de vie des buffers (les buffers WebGPU ne peuvent pas être redimensionnés), la gestion des fences pour éviter de détruire des ressources GPU encore utilisées -- la série consacre deux parties entières à ce que nous appelons le « durcissement progressif », ce processus peu spectaculaire qui consiste à ajouter une capacité à la fois et à vérifier, après chaque ajout, que la couche précédente fonctionne toujours.

Le cauchemar des raccords

La section techniquement la plus éprouvante de la série couvre les parties 9 à 11 et traite de ce qui se produit lorsque des chunks de terrain de résolutions différentes se rejoignent.

Lorsqu'un chunk très détaillé jouxte un chunk moins détaillé, leurs maillages générés indépendamment ne s'alignent pas à la frontière. Il en résulte des fissures visibles, des arêtes qui scintillent et des jonctions en T à travers lesquelles la lumière fuit. L'algorithme Transvoxel résout ce problème grâce à des cellules de transition spéciales qui relient les différences de résolution -- mais son implémentation correcte dans toutes les configurations de chunks, avec un ordre d'enroulement cohérent, une bonne gestion des buffers et des plages de dessin exactes, a nécessité six expériences distinctes.

L'anecdote de débogage la plus mémorable de l'équipe : deux jours passés à traquer un artefact de raccord que nous attribuions à la logique de transition. Le véritable coupable était une donnée obsolète. Le compute shader GPU écrivait N sommets dans un buffer, mais l'appel de dessin était toujours configuré pour afficher N+M sommets provenant de l'image précédente. Ces sommets supplémentaires contenaient des données incohérentes qui produisaient de minces triangles scintillants, semblables à des lames de rasoir. Une seule ligne a suffi à corriger le problème : limiter la plage de dessin au nombre de sommets actifs indiqué par le compteur atomique.

« Les bugs de rendu se font souvent passer pour des bugs de maillage, observe Oleg. La géométrie avait toujours été correcte. »

Du chaos à la gouvernance

Après la bataille des raccords, l'équipe a remplacé le comportement ad hoc des chunks par un système de règles explicite. Une fonction centrale décidait désormais du niveau de LOD de chaque chunk, de son mode de rendu (heightmap ou marching cubes) et des faces nécessitant des cellules de transition. Des anneaux de distance déterminaient le LOD de base. Une contrainte d'adjacence garantissait que deux chunks voisins ne différaient jamais de plus d'un niveau de résolution. Une bitmap des modifications maintenait les chunks volumétriques en mode marching cubes, quelle que soit leur distance, s'ils contenaient des modifications apportées par des créateurs.

Des surcouches de débogage à code couleur -- vert pour les chunks en heightmap, bleu pour les marching cubes, orange pour les faces de transition -- ont transformé « j'ai vu un bug quelque part près de cette crête » en « le bug apparaît à la position (142, 12, -67), en direction du nord-ouest ».

« Les règles n'ont pas réduit la complexité, écrit Oleg. Elles l'ont organisée. »

Le résultat final

Le dernier spike a combiné les anneaux de clipmap, le brouillard de ciel calculé par fragment (en échantillonnant la couleur réelle de la skybox dans la direction de chaque fragment du terrain) et le câblage des modules Three.js dans une démonstration unifiée. Le résultat est un système de terrain qui superpose l'édition volumétrique au premier plan, les chunks de heightmap à moyenne distance et les anneaux de clipmap au loin, sous une couche de règles qui régit le mode, le LOD et les transitions.

La série se termine par des enseignements qu'Oleg dit vouloir appliquer à nouveau dans tout futur projet :

• Commencez par des spikes consacrés aux risques avant de travailler sur les fonctionnalités. Répondez aux questions du type « est-ce seulement faisable ? » avant d'investir dans les pipelines de contenu.
• Figez les bases dont le bon fonctionnement est confirmé avant les grands sauts d'intégration. La journée passée à établir un point de contrôle propre permet d'économiser plusieurs jours consacrés ensuite à isoler des régressions.
• Imposez des règles et de l'observabilité avant les marathons d'optimisation. Des conditions nommées avec des règles de déclenchement l'emportent toujours sur les bugs mystérieux.
• Testez en mouvement, pas avec des captures d'écran. Les sauts visuels, le scintillement et les saccades du streaming se cachent tous dans les images fixes.
• Mesurez le temps par image de chaque fonctionnalité, pas la moyenne des FPS. Les moyennes masquent les pics que les utilisateurs ressentent réellement.
• Publiez les passages chaotiques. Les fausses pistes, la chasse aux fantômes, les deux jours passés à accuser le mauvais système. Ce sont les parties dont les autres peuvent réellement tirer des enseignements.

Pourquoi cela compte au-delà de Cinevva

Cette série est importante pour trois raisons qui dépassent le pipeline de terrain d'une seule entreprise.

Premièrement, elle montre que les compute shaders WebGPU, la physique WebAssembly et les Durable Objects déployés en périphérie ont franchi un cap. En 2026, un monde ouvert multijoueur doté d'un terrain volumétrique, d'une édition en temps réel et d'un LOD en streaming est viable sur le plan architectural dans un onglet de navigateur. Ce n'était pas le cas deux ans auparavant.

Deuxièmement, la méthodologie des spikes -- de petites expériences ciblées répondant chacune à une question risquée au moyen de résultats fonctionnels et mesurables -- fournit un modèle à toute équipe qui tente quelque chose dont la faisabilité reste incertaine. La discipline qui consiste à mesurer avant de s'engager, à établir des références avant d'intégrer et à nommer les cas limites avant d'optimiser s'applique bien au-delà des systèmes de terrain.

Troisièmement, cette transparence radicale est précisément l'objectif. La publication du code source des 24 expériences, y compris les impasses et les détours de débogage ayant duré deux jours, fait de cette série bien plus qu'un blog technique. C'est un carnet d'ingénierie public qui traite le lecteur comme un collègue plutôt que comme un client. La série complète est disponible dans notre guide de la série, avec chaque prototype exploratoire exécutable directement dans le navigateur.

---

Cet article a été initialement publié sur Medium.