Technologie de monde ouvert 3D dans le navigateur pour les mondes multijoueurs de créateurs

Nous voulons réunir nos créateurs dans un monde ouvert partagé. Pas un lobby. Pas une galerie. Un espace 3D vivant où les gens peuvent explorer, construire et tomber par hasard sur les créations des autres. Quelque chose qui se charge dans un onglet de navigateur et donne l’impression d’être un lieu où l’on a envie de passer du temps.

C’est un problème difficile. Skyrim et The Witcher 3 ont consacré des centaines de millions de dollars à la création de leurs mondes, et ils nécessitent malgré tout du matériel dédié ainsi que des dizaines de gigaoctets sur disque. Nous ciblons un onglet de navigateur, un état partagé entre des centaines de joueurs et un monde que les créateurs peuvent réellement remodeler.

Ce guide présente les résultats de nos recherches sur ces technologies. Ce qui est possible aujourd’hui, ce qui arrive et l’architecture qui nous permettrait d’y parvenir.

Ce que Skyrim et The Witcher peuvent nous apprendre

Avant de choisir une technologie, il est utile de comprendre comment fonctionnent réellement deux des mondes ouverts les plus réussis. Leurs techniques s’adaptent étonnamment bien aux contraintes du navigateur.

Le système de cellules de Skyrim

Le monde ouvert de Skyrim charge en continu une grille de 5x5 cellules autour du joueur. Les montagnes lointaines sont des imposteurs en basse résolution. On ne le remarque jamais.

Skyrim divise son monde en une grille de 57x37 cellules extérieures, chacune mesurant 4096x4096 unités de jeu (environ 59 mètres). Le moteur charge à tout moment une grille de 5x5 cellules autour du joueur. À mesure que celui-ci avance, les cellules situées derrière lui sont déchargées tandis que celles qui se trouvent devant sont chargées en continu. Les espaces intérieurs (donjons, bâtiments) sont des espaces de monde distincts, chargés par des déclencheurs placés sur les portes.

Ce principe s’applique directement à un monde dans le navigateur. On ne charge pas la carte entière. On charge une zone autour du joueur et on remplace les segments au fil de ses déplacements. L’idée clé : Skyrim ne permet jamais de voir tous les détails du terrain éloigné. Il utilise une approche multirésolution.

Niveaux de LOD (niveau de détail) dans Skyrim :

• Détails complets dans un rayon de 1 à 2 cellules (zone immédiate du joueur)
• Maillages simplifiés à moyenne distance (les objets perdent leurs petites formes géométriques)
• Imposteurs sous forme de panneaux pour les arbres et les rochers au-delà de la moyenne distance
• Le LOD du terrain utilise des maillages basse résolution précalculés pour les paysages lointains
• Distances de fondu réglées pour chaque objet (l’herbe disparaît en premier, les bâtiments en dernier)

Le paysage de Skyrim repose sur un terrain à carte de hauteur, avec des parcelles de 32x32 sommets par cellule. Chaque parcelle peut utiliser différentes textures fusionnées à l’aide de cartes alpha. Ce système demande peu d’espace de stockage et peu de ressources de rendu. Les données de terrain d’une seule cellule se mesurent en kilooctets, pas en mégaoctets.

Ce que nous pouvons appliquer : Le streaming par segments, les terrains à carte de hauteur, un LOD agressif, la séparation des espaces intérieurs et extérieurs, ainsi que l’idée selon laquelle un terrain éloigné n’a pas besoin d’être géométriquement exact, mais seulement convaincant visuellement.

L’architecture de streaming de The Witcher 3

Le monde de 136 km2 de The Witcher 3 utilise un streaming adapté au contenu. Au-delà de 200 m, les arbres sont des imposteurs plats. Les bâtiments sont chargés indépendamment du terrain.

Le monde de The Witcher 3 est plus vaste que celui de Skyrim (environ 136 km2 pour l’ensemble des régions) et utilise un système de streaming plus sophistiqué. CD Projekt RED a conçu un moteur sur mesure (REDengine 3) dans lequel le monde est divisé en secteurs de streaming plutôt qu’en une grille stricte.

Chaque secteur contient une hiérarchie de couches de contenu :

• Le terrain est chargé sous forme de parcelles avec 4 niveaux de LOD
• La végétation utilise l’instanciation GPU avec élimination en fonction de la distance
• La géométrie statique (bâtiments, rochers) est chargée indépendamment du terrain
• Les objets de gameplay (PNJ, objets, déclencheurs) sont chargés en fonction de l’état des quêtes et de la proximité

Le moteur de rendu utilise un ombrage différé avec des matériaux physiquement réalistes. Une astuce est particulièrement pertinente : The Witcher 3 recourt massivement aux imposteurs. Un arbre situé à 200 mètres n’est pas un modèle 3D avec des branches et des feuilles. C’est un quadrilatère plat texturé qui fait toujours face à la caméra. Le moteur précalcule le rendu de ces imposteurs sous plusieurs angles et les remplace à mesure que la caméra se déplace. On ne le remarque jamais, car ils sont suffisamment éloignés.

Composition du monde : Le monde ouvert de The Witcher 3 a été créé en couches par des équipes distinctes travaillant simultanément. L’équipe chargée du terrain a sculpté le paysage. L’équipe artistique des environnements a placé les structures. L’équipe des quêtes a configuré les déclencheurs et les parcours des PNJ. Ce système de composition en couches a permis à une grande équipe de travailler sans que ses membres se gênent mutuellement.

Ce que nous pouvons appliquer : La composition du monde en couches (essentielle pour une plateforme de créateurs), le rendu par imposteurs pour les objets éloignés, le rendu différé pour gérer de nombreuses sources lumineuses et l’idée selon laquelle le streaming doit tenir compte du contenu (ne pas charger les intérieurs invisibles ni faire apparaître des PNJ éloignés).

Le moteur chimique de Breath of the Wild

BotW fonctionne sur du matériel de catégorie tablette tout en offrant un rendu magnifique. Style cel-shading, brume lointaine façon aquarelle et interactions systémiques plutôt que contenu scénarisé. La référence absolue des mondes ouverts stylisés.

L’approche de Nintendo en matière de conception de monde ouvert a inversé la formule habituelle. Au lieu de remplir le monde de contenu scénarisé, l’équipe a créé des règles systémiques et laissé les joueurs découvrir des comportements émergents. Le feu se propage dans l’herbe. Le métal conduit l’électricité pendant les orages. Le vent emporte les objets. Tout interagit avec le reste au moyen d’une couche physique et chimique cohérente.

C’est important pour un monde de créateurs, car cela suggère que le monde lui-même peut être plus intéressant que n’importe quel objet placé individuellement. Si les créateurs peuvent définir les propriétés des matériaux et les règles d’interaction (plutôt que simplement placer des maillages statiques), le monde acquiert des comportements émergents qui rendent l’exploration intéressante, même dans les zones que personne n’a explicitement conçues.

Enseignements techniques de BotW :

• Nombre de polygones et résolution relativement faibles (900p sur Switch en mode station d’accueil). Le rendu cel-shading stylisé masque la faible fidélité. Un monde dans le navigateur pourrait aujourd’hui atteindre une qualité visuelle similaire.
• Le rendu à distance utilise une brume en toon shading qui se fond dans des arrière-plans célestes de style aquarelle. Peu coûteux à calculer et magnifique en pratique. Ce type de perspective atmosphérique est pratiquement gratuit dans un shader de fragments.
• Le monde couvre environ 84 km2, mais il est peu dense. La majeure partie de la carte est constituée de terrains praticables, ponctués de points d’intérêt. Le contenu dense est réservé aux villes et aux sanctuaires. Cette approche « peu dense, mais intéressante » réduit considérablement les besoins en ressources par rapport à Novigrad, la ville densément peuplée de The Witcher 3.
• Les objets physiques possèdent des étiquettes de matériau (bois, métal, nourriture, explosif) qui déterminent leurs interactions. Le nombre de règles réelles est faible (peut-être 20 à 30 types d’interactions), mais leurs combinaisons donnent une impression de possibilités infinies.

La superposition des systèmes du monde de GTA V

Los Santos, dans GTA V, semble vivant grâce à des systèmes d’ambiance superposés : circulation, piétons, heure de la journée et météo. Les bâtiments lointains sont des photographies composites, pas des modèles 3D.

L’approche de Rockstar pour Los Santos nous enseigne une autre leçon. Le monde de GTA V semble vivant grâce à des systèmes d’ambiance superposés, et non parce que chaque PNJ propose une quête.

La ville dispose de systèmes de circulation qui simulent des centaines de véhicules sur un réseau routier. Les piétons suivent des itinéraires, réagissent au joueur et interagissent entre eux. L’heure de la journée modifie la densité de la population, les types de PNJ présents et l’activité ambiante. La météo affecte la physique de conduite et le comportement des PNJ.

Pour un monde de créateurs, l’idée essentielle est que cette vie ambiante fait toute la différence entre un monde qui ressemble à un musée et un monde qui donne l’impression d’être un véritable lieu. Même des comportements simples (des oiseaux qui volent au-dessus de nos têtes, des vagues qui viennent lécher le rivage, des PNJ qui marchent entre les bâtiments) créent l’illusion d’un monde vivant.

Enseignements techniques de GTA V :

• La carte couvre 75 km2 et utilise un LOD agressif associé à un système de streaming qui charge les données en fonction de la vitesse (rouler vite entraîne un chargement plus loin devant que marcher).
• GTA Online réunit simultanément 30 joueurs dans ce monde. Même avec 30 joueurs, Rockstar a constaté la nécessité d’une gestion spatiale de l’intérêt : les mises à jour concernant les joueurs proches sont détaillées, tandis que celles des joueurs éloignés sont moins fréquentes. Le même principe s’applique à notre objectif de 200 joueurs.
• Le pipeline de ressources de GTA V est l’un des plus efficaces jamais conçus. L’ensemble du jeu tient dans environ 80 Go grâce à une compression extrême des textures, au partage des maillages et aux détails procéduraux. Les intérieurs de ses bâtiments réutilisent massivement des éléments modulaires.
• Le jeu utilise un système d’imposteurs sophistiqué dans lequel les bâtiments éloignés sont en réalité des photographies plates assemblées. Le joueur ne le remarque jamais, car les distances de transition sont ajustées à des angles de vue précis.

Le monde ouvert fluide d’Elden Ring

La carte de 79 km2 d’Elden Ring mêle de vastes terrains ouverts peu denses à des donjons détaillés créés à la main. Les mêmes ressources d’environnement apparaissent partout dans des agencements différents. La répétition disparaît lorsque la composition et l’éclairage varient.

FromSoftware a développé Elden Ring avec le même moteur que Dark Souls, mais en l’adaptant à l’échelle d’un monde ouvert. Le résultat est intéressant, car il montre comment une équipe relativement petite (comparée à celles de Rockstar ou de CD Projekt) peut créer un vaste monde ouvert.

L’astuce réside dans la variation de densité. La carte d’Elden Ring est immense (environ 79 km2), mais de grandes portions sont constituées de terrains ouverts où les ennemis et les points d’intérêt sont dispersés. Le contenu dense créé à la main (les donjons majeurs comme le château de Voilorage) est intégré au monde ouvert et utilise la même séparation entre espaces intérieurs et extérieurs que Skyrim.

Enseignements techniques d’Elden Ring :

• Le monde est chargé en continu sous forme de grandes tuiles. À cheval, on peut voir très loin, mais le terrain distant est extrêmement simplifié. De près, le niveau de détail est comparable à celui de Dark Souls 3.
• Les écrans de chargement n’apparaissent que lors des voyages rapides ou à l’entrée de certains donjons. Le monde ouvert lui-même est chargé en continu, sans interruption.
• Le jeu réutilise massivement ses ressources d’environnement. Les mêmes modèles d’arbres, formations rocheuses et éléments de ruines apparaissent sur toute la carte dans des agencements différents. Avec suffisamment de variété dans l’agencement et l’éclairage, les répétitions passent inaperçues. Ce principe s’applique directement à un monde de créateurs, où une bibliothèque d’éléments modulaires peut produire une variété infinie.
• Le multijoueur repose sur des sessions (invocation d’autres joueurs dans votre monde), plutôt que sur un monde persistant. Cependant, les fonctionnalités asynchrones (messages, taches de sang, fantômes d’autres joueurs) créent une sensation d’existence partagée sans la surcharge réseau d’un serveur persistant. Ces fonctionnalités multijoueurs ambiantes seraient peu coûteuses à ajouter à un monde dans le navigateur.

No Man’s Sky : tout générer de manière procédurale

18 trillions de planètes générées à partir de graines partagées. Tous les joueurs voient le même univers sans qu’il soit stocké sur un serveur. Les données de construction de bases sont compactes : identifiants des éléments et transformations.

No Man’s Sky représente le cas extrême de la génération procédurale. Ses 18 trillions de planètes sont générées à partir d’une graine partagée, de sorte que chaque joueur voit le même univers sans qu’aucune de ces données soit stockée sur un serveur.

Le pipeline de génération fonctionne par étapes : les graines au niveau galactique déterminent la position des étoiles, celles des étoiles déterminent le nombre et les types de planètes, tandis que les graines des planètes pilotent la génération du terrain (bruit multi-octave), l’attribution des biomes, les espèces de flore et de faune, les palettes de couleurs et la répartition des ressources. Tout est calculé de manière déterministe à partir de la graine, de sorte que deux joueurs visitant les mêmes coordonnées voient la même planète sans échanger la moindre donnée planétaire. Enseignements techniques tirés de No Man's Sky :

• La génération du terrain utilise des marching cubes à base de voxels avec un empilement de fonctions de bruit. Cela permet de créer des grottes, des surplombs et des îles flottantes que les terrains fondés sur des cartes de hauteur ne peuvent pas représenter. En contrepartie, le coût de calcul par chunk est plus élevé, mais le terrain obtenu est visuellement plus intéressant.
• Le système de construction de bases est ce qui se rapproche le plus de ce que nous envisageons. Les joueurs placent des structures qui persistent sur le serveur et sont visibles par les autres joueurs. Les données d'une base sont compactes (une liste de pièces avec leurs positions et leurs rotations) et sont chargées à la demande lorsqu'une personne visite la planète.
• Le jeu a d'abord été critiqué pour son contenu répétitif malgré une variété infinie. La génération fondée sur des graines peut produire un terrain infini, mais peu de surprises. La leçon : la génération procédurale convient à la création du canevas, mais c'est le contenu placé par les créateurs qui donne à un lieu une impression de conception réfléchie et intentionnelle.
• Hello Games a ajouté le multijoueur plusieurs années après le lancement. Jusqu'à 32 joueurs partagent une session avec des fonctionnalités complètes de construction et d'exploration. Le modèle réseau est simple : un joueur héberge la partie et les autres s'y connectent. Pour un monde dans le navigateur avec un état persistant, un modèle où le serveur fait autorité fonctionne mieux, mais No Man's Sky prouve que les mondes procéduraux partagés sont réalisables.

Minecraft : le modèle des mondes de créateurs

300 millions d'exemplaires vendus. Des textures de 16x16 pixels. Un terrain entièrement modifiable. Une génération infinie. Du multijoueur. La référence la plus importante pour un monde de créateurs. Les clones dans le navigateur prouvent que le concept fonctionne avec WebGL.

Minecraft est la référence la plus importante pour ce que nous construisons, davantage que n'importe quel titre AAA aux graphismes avancés. 300 millions d'exemplaires vendus. Le monde est généré à l'infini, entièrement destructible et multijoueur. Dans Minecraft, les créateurs ne se contentent pas de placer des objets. Ils remodèlent le terrain lui-même.

Enseignements techniques tirés de Minecraft :

• Le monde est divisé en chunks de 16x16x384 blocs. Seuls les chunks proches du joueur sont chargés (la distance d'affichage est configurable). Il s'agit du même modèle de streaming de chunks que dans Skyrim, mais avec un terrain entièrement modifiable.
• Chaque chunk est stocké sous la forme d'un tableau d'identifiants de blocs compressé à l'aide d'une palette. Un chunk ne contenant que 5 types de blocs différents stocke un indice de palette de 4 bits par bloc au lieu d'un identifiant de bloc complet. Les données des chunks sont ainsi très compactes (généralement 10 à 50 Ko par chunk après compression).
• Le protocole multijoueur de Minecraft est bien documenté et relativement simple. Le serveur envoie les données des chunks à mesure que le joueur se déplace. Les modifications de blocs sont diffusées sous forme de petites mises à jour différentielles (position + nouveau type de bloc). C'est exactement le modèle que nous utiliserions pour les modifications effectuées par les créateurs.
• Le jeu fonctionne en Java et possède désormais une édition Bedrock en C++. Il existe des clones de Minecraft dans le navigateur (ClassiCube, eaglercraft) qui prouvent que le concept de base fonctionne avec WebGL. Ils gèrent généralement une distance d'affichage de 8 à 12 chunks à 60 images/s, ce qui offre une vue d'environ 200 à 400 mètres.
• L'écosystème de mods de Minecraft constitue son véritable avantage concurrentiel. Les mods ajoutent de nouveaux blocs, de nouvelles entités, de nouveaux biomes et de nouveaux systèmes de jeu. Pour un monde de créateurs, cela suggère que l'extensibilité compte autant que l'expérience de base. Si les créateurs peuvent définir de nouveaux types d'interactions, et pas seulement placer des objets, le monde s'enrichit au fil du temps.
• La redstone (le système de câblage intégré à Minecraft) montre que les créateurs construiront des systèmes complexes si on leur fournit des primitives simples et composables. Portes logiques, fermes automatiques, calculatrices. Cet ensemble de règles simples engendre une complexité extraordinaire. C'est la même leçon que celle du moteur chimique de BotW.

Points communs aux mondes ouverts AAA

En examinant tous ces titres, les mêmes modèles reviennent sans cesse :

Le partitionnement spatial est universel. Qu'il s'agisse de cellules (Bethesda), de secteurs (CD Projekt), de chunks (Mojang/Rockstar) ou de tuiles (FromSoftware), chaque monde ouvert divise l'espace en unités pouvant être chargées. Aucun moteur ne tente de conserver le monde entier en mémoire.

Tout existe en plusieurs résolutions. Le terrain, les maillages, les textures et même le son possèdent plusieurs niveaux de qualité. La résolution obtenue dépend de la proximité et de l'importance de l'objet.

L'élimination des objets occultés compte davantage que le débit brut de triangles. Ne pas afficher ce qui est invisible permet de gagner plus en performances que d'optimiser ce qui est visible. Skyrim utilise un système simple fondé sur la distance. The Witcher 3 utilise une occlusion logicielle avec de grands objets occultants (bâtiments, falaises). Les moteurs modernes comme Nanite d'UE5 vont plus loin grâce aux requêtes d'occlusion matérielles.

Le chargement asynchrone masque les transitions. Ces jeux n'affichent pas d'écran de chargement dans le monde ouvert, seulement lors des voyages rapides ou des transitions vers des intérieurs. Ils chargent le contenu dans des threads d'arrière-plan, le décompressent en parallèle et remplacent progressivement le contenu affiché.

La direction artistique prime sur le nombre de polygones. Skyrim est sorti en 2011 avec des graphismes qui étaient déjà modestes à l'époque. BotW fonctionne sur une puce de classe tablette et reste magnifique. Minecraft utilise des textures de 16x16 pixels et demeure l'un des jeux les plus reconnaissables visuellement jamais créés. Pour un monde dans le navigateur, c'est extrêmement important. Un style artistique cohérent avec une fidélité moindre surpassera toujours un monde techniquement avancé, mais artistiquement terne.

La conception systémique surpasse le contenu scripté. Le moteur chimique de BotW, les interactions entre blocs de Minecraft et les systèmes de circulation de GTA V produisent tous des comportements émergents à partir de règles simples. Cette approche coûte moins cher à créer et à exécuter, tout en générant davantage d'histoires vécues par les joueurs que des séquences scriptées fabriquées à la main. Pour un monde de créateurs, la conception systémique signifie que le monde reste intéressant même dans les zones que personne n'a explicitement conçues.

Le contenu placé par les créateurs doit être persistant et visible. Les bases de Minecraft et de No Man's Sky, ainsi que les propriétés de GTA Online, persistent d'une session à l'autre et sont visibles par les autres joueurs. Le modèle de données du contenu créé est toujours compact (identifiants des pièces + transformations), tandis que sa représentation visuelle est riche (le client développe les données pour produire des scènes 3D complètes).

Rendu : de quoi un navigateur est-il réellement capable ?

Three.js

Three.js constitue la base. Il possède la plus grande communauté (plus de 100 000 étoiles sur GitHub), le plus grand nombre d'exemples et la compatibilité la plus étendue. Il fournit une abstraction de WebGL 2 et une prise en charge expérimentale de WebGPU via WebGPURenderer.

Pour un monde ouvert, Three.js fournit :

• Le rendu instancié pour la végétation, les rochers et les géométries répétées (InstancedMesh)
• Un système de LOD intégré (THREE.LOD remplace les maillages en fonction de la distance)
• L'élimination selon le champ de vision automatique pour chaque objet
• Le terrain via une BufferGeometry personnalisée ou une PlaneGeometry fondée sur une carte de hauteur
• Les matériaux PBR via MeshStandardMaterial et MeshPhysicalMaterial
• Le post-traitement via EffectComposer (halo lumineux, SSAO, mappage tonal)
• Les cartes d'ombres, avec possibilité de mappage d'ombres en cascade grâce à du code personnalisé
• glTF/GLB comme principal format de ressources (compact et prêt pour le GPU)

Three.js dispose également d'un écosystème actif d'outils utiles aux mondes ouverts. three-mesh-bvh accélère le lancer de rayons et les requêtes spatiales sur les maillages complexes. postprocessing (par vanruesc) fournit une chaîne de post-traitement plus performante que celle intégrée à Three. three-gpu-pathtracing permet un rendu de qualité de référence.

Limites pour les mondes ouverts : Three.js ne possède pas de graphe de scène intégré capable de gérer le streaming, la gestion des LOD ou le partitionnement spatial à grande échelle. Vous devez les créer vous-même. Il n'existe ni système entité-composant (ECS), ni moteur physique, ni système de terrain intégré. C'est un moteur de rendu, pas un moteur de jeu. C'est en réalité un avantage pour un monde ouvert personnalisé, car vous contrôlez l'organisation de la mémoire et la stratégie de chargement, mais cela implique davantage de travail initial.

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js est l'autre concurrent majeur. Soutenu par Microsoft, il propose davantage de fonctionnalités intégrées que Three.js pour répondre au problème particulier des mondes ouverts.

Fonctionnalités intégrées pertinentes :

• Partitionnement de scène fondé sur un octree pour éliminer efficacement les éléments de grandes scènes
• Solid Particle System pour le rendu instancié massif
• Terrain issu de cartes de hauteur avec LOD et mélange de plusieurs textures intégrés
• Node Material Editor pour la création visuelle de shaders
• Prise en charge de WebGPU (plus mature que celle de Three.js, Babylon ayant investi plus tôt)
• Intégration du moteur physique Havok (compilé en Wasm et de qualité production)
• Streaming glTF avec chargement progressif

L'extension DynamicTerrain de Babylon génère à la volée des chunks de terrain à partir de données de carte de hauteur, gère automatiquement les LOD et prend en charge le mélange de textures. Cette solution est bien plus proche de ce que fait Skyrim que tout ce que Three.js propose nativement.

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

Le compromis : Babylon.js est une bibliothèque plus volumineuse (la version complète pèse environ 1 à 2 Mo après minification, contre environ 600 Ko pour Three.js). Mais pour un monde ouvert, vous ajouterez probablement suffisamment de code personnalisé à Three.js pour que cette différence de taille devienne négligeable. Babylon possède également son propre système Node Material, un inspecteur et des outils de développement qui accélèrent les itérations.

Babylon.js 8.0 (sorti en mars 2025) a renforcé sa légitimité en tant que cœur du moteur dans ce cas. Tous les shaders principaux du moteur sont désormais fournis à la fois en GLSL et en WGSL, ce qui permet à WebGPU de fonctionner sans couche de conversion et réduit d'environ moitié la taille du bundle WebGPU. Cette même version a intégré au moteur le contrôleur de personnage complet de Havok, des lumières de zone, un moteur audio reconstruit et des améliorations du splatting gaussien (formats SPZ et PLY compressés, harmoniques sphériques et réduction de l'empreinte mémoire et CPU).

PlayCanvas

PlayCanvas mérite d'être mentionné, car il s'agit du moteur 3D pensé pour le Web ayant fait ses preuves dans le plus grand nombre de productions. Snap, Facebook et de nombreux clients du secteur publicitaire ont livré des expériences 3D complexes avec celui-ci. Le moteur pèse environ 1 Mo, se charge rapidement et son éditeur dans le cloud permet la création collaborative de mondes.

Pour un monde ouvert en particulier, PlayCanvas propose des groupes de traitement par lots pour optimiser les appels de rendu, un générateur de cartes d'éclairage intégré et la prise en charge du splatting gaussien, utile pour les environnements réels capturés par photogrammétrie. Son environnement d'exécution est compact et bien optimisé pour les navigateurs mobiles.

WebGPU : le levier de performances

WebGPU change la donne pour les mondes ouverts dans le navigateur. Les deux fonctionnalités les plus importantes sont les suivantes :

Les shaders de calcul permettent la génération du terrain, le placement de la végétation, la simulation des particules et même une physique simple côté GPU. Dans un monde WebGL, tout cela s'exécute sur le CPU en JavaScript. Avec WebGPU, vous pouvez générer des parcelles de terrain entièrement sur le GPU, calculer les transitions de LOD sur le GPU et exécuter les passes d'élimination sur le GPU. Cela libère le CPU pour le réseau, la logique du jeu et le streaming du contenu.

Le rendu indirect permet au GPU de décider quoi afficher en fonction de la sortie d'un shader de calcul. Vous soumettez un seul appel de rendu et le GPU décide combien d'instances afficher pour chaque niveau de LOD en fonction de la distance. C'est ainsi que les moteurs modernes gèrent des millions de brins d'herbe ou d'arbres. Sans rendu indirect, que WebGL ne prend pas en charge, le CPU doit tout trier et tout regrouper, ce qui devient le goulet d'étranglement des scènes denses.

WebGPU est désormais disponible dans tous les principaux navigateurs. Chrome et Edge le proposent depuis la version 113, Firefox l'a ajouté sous Windows (141) et macOS sur Apple Silicon (145), tandis que Safari 26 l'a intégré à macOS, iOS, iPadOS et visionOS fin 2025. La prise en charge mondiale atteint ainsi environ 82 %, y compris sur mobile (Chrome pour Android et Samsung Internet le proposent également). Il reste nécessaire de conserver une solution de repli vers WebGL 2 pour les navigateurs plus anciens et les appareils sur lesquels WebGPU n'est pas activé, mais l'écart s'est rapidement réduit.

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

Pile de rendu recommandée

Pour un monde ouvert dans le navigateur destiné aux créateurs sur ordinateur :

Solution principale : Three.js ou Babylon.js avec le moteur de rendu WebGPU lorsqu'il est disponible, et WebGL 2 comme solution de repli. Babylon possède de meilleures primitives intégrées pour les mondes ouverts. Three.js bénéficie d'une communauté plus vaste et offre davantage de flexibilité.

Notre choix : Babylon.js pour le cœur du moteur en raison de ses LOD de terrain intégrés, de l'élimination par octree, du moteur physique Havok (Wasm) et de sa prise en charge mature de WebGPU. Utiliser les outils de l'écosystème Three.js lorsque Babylon présente des lacunes (par exemple, un BVH de maillage pour les requêtes spatiales). Encapsuler l'ensemble dans une couche personnalisée de streaming du monde.

Architecture de streaming du monde

C'est la partie difficile. Un onglet de navigateur dispose d'environ 2 à 4 Go de mémoire sur ordinateur (en raison des limites imposées par le navigateur), d'environ 1 Go sur mobile et d'aucun accès direct au disque. Tout arrive par le réseau. Il faut une architecture qui conserve le monde visible en mémoire tout en chargeant le contenu légèrement en avance sur le déplacement du joueur.

Grille du monde fondée sur des chunks

Comme avec le système de cellules de Skyrim, divisez le monde en une grille régulière de chunks. Chaque chunk est une unité indépendante qui peut être chargée, affichée et déchargée séparément.

La taille des chunks est importante. S'ils sont trop petits, vous les chargez et les déchargez constamment avec un coût de traitement élevé. S'ils sont trop grands, chaque chunk prend trop de temps à télécharger. Pour un monde dans le navigateur avec des connexions haut débit classiques :

• Chunks de 64x64 mètres au niveau du sol
• Chaque chunk contient : une parcelle de carte de hauteur (2 à 4 Ko), une carte de mélange de textures (16 à 32 Ko compressés), des maillages statiques sous forme de références instanciées (1 à 50 Ko de données d'instance), et les objets placés par les créateurs sous forme de manifeste (1 à 10 Ko)
• Rayon de chargement : 5x5 chunks en pleine qualité (vue de 320 m), 9x9 avec un LOD intermédiaire, 17x17 pour le terrain uniquement
• Objectif : moins de 200 Ko de données en pleine qualité pour chaque chunk, afin qu'un voisinage de 5x5 représente moins de 5 Mo

Chaîne de chargement progressif

Ne chargez pas toutes les données d'un chunk en même temps. Utilisez une file de priorité :

1. La géométrie du terrain en premier (carte de hauteur uniquement, 2 à 4 Ko par chunk). Le joueur voit le sol en moins de 100 ms.
2. Les textures du terrain (cartes de mélange, d'abord en basse résolution puis améliorées). Le sol est coloré en moins de 200 ms.
3. Les structures principales (bâtiments, gros rochers). Les silhouettes apparaissent en moins de 500 ms.
4. Les objets détaillés (végétation, petits accessoires, objets des créateurs). Le monde se remplit en 1 à 2 secondes.
5. Les textures haute résolution sont améliorées en dernier. Personne ne remarque si la texture d'un bâtiment lointain met une seconde de plus à se charger.

Cela correspond au fonctionnement de l'œil humain. Nous remarquons l'absence de sol et de grandes structures. Nous ne remarquons pas l'absence d'herbe.

Gestion de la mémoire

La mémoire du navigateur est limitée et le ramasse-miettes est votre ennemi. Une seule pause du GC peut faire chuter la fréquence de 60 ips à 10 ips pendant une image.

La mise en pool des objets est obligatoire. Préallouez des pools pour les objets courants (arbres, rochers, plaques d'herbe) et recyclez-les à mesure que les chunks sont chargés et déchargés. Ne créez jamais de nouvelles instances de THREE.Mesh ou de BABYLON.Mesh dans le chemin d'exécution critique. Remplacez plutôt les références de géométrie et de matériau sur les objets mis en pool.

Les atlas de textures réduisent à la fois les appels de rendu et la fragmentation de la mémoire. Regroupez toutes les textures de terrain dans quelques grands atlas. Regroupez côté serveur les textures téléversées par les créateurs dans des atlas propres à chaque chunk, puis diffusez-les sous forme d'images uniques.

La compression géométrique avec Draco ou Meshopt réduit la taille des téléchargements d'un facteur de 5 à 10, et la décompression s'exécute dans un Web Worker afin de ne pas bloquer le thread principal. Pour le terrain en particulier, les cartes de hauteur quantifiées (valeurs sur 16 bits compressées par simple encodage différentiel) sont plus petites que n'importe quel format de maillage générique.

Le transfert de propriété des ArrayBuffer entre les workers et le thread principal évite les copies. Lorsqu'un worker décompresse un maillage, transférez le tampon au thread principal sans aucune copie à l'aide de postMessage et d'objets transférables.

Distribution des ressources

Un CDN avec mise en cache en périphérie convient aux données statiques du monde. Les chunks de terrain, les maillages de base et les atlas de textures qui changent rarement doivent être mis en cache de manière agressive (Cache-Control: max-age=31536000, immutable).

Le stockage adressé par contenu signifie que chaque version d'une ressource reçoit un hachage unique dans son URL. Lorsqu'un créateur modifie un chunk, la nouvelle version reçoit un nouveau hachage et l'ancienne reste en cache pour les utilisateurs qui la consultent encore. Aucune invalidation du cache n'est nécessaire.

Les textures KTX2 avec compression Basis Universal se décompressent dans le format pris en charge par le GPU de l'appareil (BC7, ASTC, ETC2 ou RGBA en solution de repli). Une texture de terrain de 1024x1024 passe de 4 Mo sans compression à environ 150 Ko en KTX2. Pour un monde comportant des milliers de textures uniques, cette compression fait toute la différence entre un projet viable et un projet irréalisable.

Le format glTF binaire (GLB) convient à toutes les ressources 3D. C'est le JPEG de la 3D. Tous les moteurs de navigateur peuvent le charger, il est compact et peut intégrer textures, matériaux et animations dans un seul fichier. Utilisez les extensions Draco ou Meshopt pour compresser les maillages. Les ressources téléversées par les créateurs sont traitées côté serveur et converties en GLB optimisés avant d'intégrer le monde.

Réseau multijoueur

Réunir des centaines de créateurs dans le même monde exige une architecture réseau capable de gérer les déplacements en temps réel, l'état persistant du monde et les modifications des créateurs sans s'effondrer.

Architecture serveur

Un serveur faisant autorité gère l'état du monde. Le navigateur n'est pas digne de confiance. Toutes les actions significatives (placement d'objets, modification du terrain, déplacement entre les chunks) sont validées côté serveur. Le client effectue des prédictions locales, puis se synchronise avec l'état du serveur.

Le partitionnement spatial répartit le monde entre plusieurs instances de serveur. Chaque partition gère une région rectangulaire de la grille du monde. À mesure que la densité de joueurs évolue, les partitions peuvent être divisées ou fusionnées. C'est ainsi qu'EVE Online gère des milliers de joueurs dans un même univers, et le même principe s'applique à plus petite échelle.

Pour un monde de créateurs où la plupart des interactions sont locales (vous construisez dans votre zone et vos voisins peuvent le voir), le partitionnement spatial fonctionne naturellement. Un joueur situé à la frontière d'une partition voit le contenu des deux partitions, ce qui nécessite des requêtes de visibilité interpartitions, mais ce problème est déjà bien maîtrisé.

Options technologiques pour le serveur :

Technologie	Points forts	Cas d'usage
Cloudflare Durable Objects	Déploiement en périphérie, mise à l'échelle automatique, persistance intégrée, prise en charge de WebSocket	État des partitions du monde, autorité par chunk
Hathora / Rivet	Hébergement géré de serveurs de jeu, protection contre les attaques DDoS, déploiement mondial	Instances de serveurs de jeu dédiés
Colyseus	Framework de serveur de jeu open source pour Node.js, synchronisation d'état fondée sur des schémas	Multijoueur par salles avec synchronisation différentielle de l'état
PartyKit	Déploiement en périphérie, WebSocket + WebRTC, fondé sur Cloudflare Workers	Collaboration en temps réel, multijoueur léger
Rust/Go personnalisé	Contrôle maximal, meilleures performances par instance	Partitions à forte densité nécessitant une physique à faible latence

Dans notre contexte (infrastructure Cloudflare) : les Durable Objects constituent un choix naturel. Chaque chunk du monde devient un Durable Object qui conserve l'état faisant autorité pour le contenu de ce chunk. Les joueurs se connectent par WebSocket au Durable Object responsable de leur chunk actuel. Lorsqu'ils passent dans un chunk adjacent, ils se connectent au DO de ce chunk. Les Durable Objects enregistrent automatiquement l'état sur disque, de sorte que les données du monde survivent aux redémarrages.

Communication client-serveur

WebSocket sert aux messages fiables et ordonnés (chat, modifications du monde, inventaire, état du jeu). Il faut une connexion par partition active visible par le joueur (généralement 1 à 4 connexions).

WebRTC DataChannel sert aux messages non fiables et non ordonnés (positions des joueurs, animations, effets éphémères). WebRTC permet les communications pair à pair, mais pour un monde comptant de nombreux joueurs, il faut passer par une SFU (Selective Forwarding Unit, ou unité de transfert sélectif) afin d'éviter N2 connexions. Cloudflare Calls ou LiveKit peuvent servir de SFU.

La synchronisation de l'état utilise la compression différentielle. Le serveur suit ce que chaque client a déjà vu et n'envoie que les changements. C'est particulièrement important dans un monde de créateurs, car l'état du monde (les objets existants, leur emplacement et leurs propriétés) change beaucoup moins souvent que la position des joueurs. Vous pouvez envoyer les mises à jour de l'état du monde à une fréquence de 2 à 5 Hz, tandis que les positions des joueurs sont actualisées à 20 ou 30 Hz.

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}

Résolution des conflits entre les modifications des créateurs

Lorsque deux créateurs modifient simultanément la même zone, vous avez besoin d'une stratégie de résolution des conflits. C'est là que le choix du modèle de collaboration en temps réel prend toute son importance.

La stratégie du dernier auteur prioritaire est la plus simple. Chaque objet ne possède qu'un seul propriétaire à la fois. Si vous modifiez un bâtiment, personne d'autre ne peut le modifier tant que vous ne l'avez pas libéré. C'est simple et sans conflit, mais cela limite la collaboration.

La transformation opérationnelle (OT) est la méthode employée par Google Docs. Les opérations sont transformées en fonction des opérations concurrentes pour produire un résultat cohérent. Cela fonctionne pour le texte, mais devient complexe pour les opérations spatiales 3D. Figma utilise une variante de cette méthode pour son canevas 2D.

Les CRDT (Conflict-free Replicated Data Types, ou types de données répliquées sans conflit) permettent des modifications simultanées qui convergent toujours vers le même état sans coordination. Pour un monde constitué d'objets distincts, chacun doté d'un identifiant et de propriétés, un registre où le dernier auteur est prioritaire pour chaque propriété, combiné à un ensemble où l'ajout est prioritaire pour la collection d'objets, assure une convergence automatique. Yjs et Automerge sont des bibliothèques CRDT JavaScript éprouvées en production.

Notre recommandation : utilisez des CRDT pour l'état des objets du monde (ce qui existe, leur emplacement et leurs propriétés) et un serveur faisant autorité pour la validation spatiale (pas deux objets au même endroit, objets maintenus dans les limites du monde). Le CRDT gère la collaboration. Le serveur gère la physique.

Gestion du passage à l'échelle : combien de joueurs ?

Les MMO sur navigateur existent déjà. Hordes.io réunit plus de 200 joueurs dans une même scène au sein d'un navigateur. BrowserQuest (l'expérience de Mozilla) en gérait des centaines avec un simple monde fondé sur des tuiles. La question n'est pas de savoir si les navigateurs peuvent gérer le multijoueur, mais quelle fidélité visuelle vous pouvez préserver à mesure que le nombre de joueurs augmente.

Budget de rendu des joueurs : chaque joueur visible nécessite un maillage, des animations et potentiellement une apparence personnalisée par son créateur. À 60 ips, vous disposez de 16 ms par image. Voici un budget raisonnable :

• 50 joueurs entièrement animés à courte distance : environ 2 ms d'animation et de skinning
• 200 joueurs à moyenne distance (animation simplifiée, instanciation) : environ 1 ms
• Plus de 500 joueurs représentés par des points ou des icônes sur la minicarte : coût négligeable

Cela permet d'afficher environ 250 joueurs dans une même vue, ce qui est largement suffisant pour un monde de créateurs. Les capitales de World of Warcraft affichent rarement plus de 200 personnages à la fois.

Budget réseau : chaque joueur envoyant sa position à 20 Hz consomme environ 40 octets * 20 = 800 octets/seconde. Pour 200 joueurs visibles : 160 Ko/s de données de position. En ajoutant l'état du monde, le chat et les actions des créateurs, vous atteignez 200 à 500 Ko/s par client. Cela reste largement dans les capacités d'une connexion haut débit, mais mérite d'être compressé.

Système de terrain

Le terrain est la base de tout monde ouvert. C'est aussi là que les contraintes du navigateur sont les plus fortes, car le terrain doit être omniprésent et toujours visible.

Terrain fondé sur une carte de hauteur

Comme Skyrim, utilisez une carte de hauteur. Une grille 2D de valeurs de hauteur génère un terrain 3D au moyen d'un vertex shader. C'est considérablement plus compact qu'un terrain constitué d'un maillage arbitraire.

Une carte de hauteur de 4096x4096 avec une précision de 16 bits occupe 32 Mo sans compression. Mais vous ne la chargez jamais entièrement. Chaque chunk de 64 m utilise une section de 65x65 de la carte de hauteur (environ 8,4 Ko sur 16 bits). En la compressant avec un encodage différentiel et zlib, vous obtenez moins de 2 Ko par chunk.

Le mélange de textures applique plusieurs matériaux de terrain (herbe, roche, terre, sable) à l'aide d'une carte de mélange. Chaque chunk dispose d'une carte de mélange RGBA à 4 canaux, où chaque canal contrôle le poids de mélange d'un matériau. Avec 4 textures par carte de mélange et la possibilité de varier ces cartes pour chaque chunk, vous obtenez une grande diversité visuelle dans l'ensemble du monde.

Les moteurs de rendu de terrain modernes utilisent la texturation virtuelle (également appelée mégatexture, d'après la technologie d'id Software dans Rage). Au lieu d'effectuer le mélange à l'exécution, vous prégénérez la texture de terrain mélangée en haute résolution et diffusez ses tuiles à mesure que la caméra se déplace. Cette méthode échange de l'espace de stockage contre de meilleures performances à l'exécution. Les compute shaders de WebGPU peuvent gérer les retours d'information et les tables de pages nécessaires à la texturation virtuelle.

Clipmap ou géoclipmapping

Pour rendre un vaste terrain dans un navigateur, l'approche CDLOD (LOD de C. Dick) ou le géoclipmapping fonctionne bien. Le terrain est rendu sous forme d'un ensemble d'anneaux concentriques autour de la caméra, chaque anneau ayant une résolution deux fois inférieure à celle du précédent. Près de la caméra, le terrain apparaît en pleine résolution. Au loin, vous en voyez une version plus grossière. Les transitions sont fluides, car la géométrie se transforme progressivement entre les niveaux.

Cette technique est bien adaptée au GPU (un appel de rendu par anneau), permet de gérer un terrain infini avec une quantité de mémoire constante et fonctionne avec WebGL 2. Flight Simulator et la plupart des jeux modernes en monde ouvert l'utilisent à un niveau ou un autre.

Terrain modifié par les créateurs

Si les créateurs peuvent sculpter le terrain, il vous faut un moyen de stocker et de diffuser leurs modifications par-dessus la carte de hauteur de base. Deux approches sont possibles :

Les cartes de hauteur différentielles stockent la différence entre le terrain de base et le terrain modifié. La majeure partie du monde n'est pas modifiée (les différences sont nulles), ce qui permet une compression extrêmement efficace. Lors du chargement d'un chunk, appliquez la différence par-dessus la base.

Les surcouches de voxels permettent des modifications plus spectaculaires (grottes, surplombs, arches). Une carte de hauteur ne peut pas représenter un terrain où un même point possède deux hauteurs. Une grille de voxels clairsemée, stockée uniquement dans les chunks modifiés, résout ce problème. Les algorithmes marching cubes ou dual contouring génèrent le maillage. Cette méthode est plus coûteuse, mais permet de modifier le terrain à la manière de Minecraft.

Génération de mondes assistée par l'IA

C'est ici que les capacités existantes de Cinevva en matière d'IA générative deviennent un puissant multiplicateur. Au lieu de construire manuellement chaque rocher et chaque arbre, les créateurs peuvent demander à l'IA de peupler le monde.

Génération de terrain avec des champs neuronaux

Des recherches récentes sur la génération neuronale de terrains (GET3D de NVIDIA, le mode réseau neuronal de Terragen et des articles comme « Terrain Generation Using Procedural Models ») montrent que des modèles entraînés peuvent générer des terrains plausibles à partir de descriptions textuelles ou d'esquisses. Un créateur pourrait dessiner un littoral approximatif et demander « des collines boisées rejoignant une côte rocheuse » pour obtenir une carte de hauteur avec une érosion, des masques de végétation et des matériaux appropriés.

Pour une diffusion dans le navigateur, la génération s'effectue côté serveur et le résultat est ensuite transmis en continu. Le modèle de génération n'a pas besoin de s'exécuter dans le navigateur. Il produit des cartes de hauteur et des cartes de mélange que le navigateur peut rendre avec le pipeline de terrain standard.

Génération de ressources 3D

Des modèles comme Hunyuan3D, Meshy, Tripo et Rodin peuvent générer des maillages 3D à partir de textes ou d'images. Voici le processus pour un monde de créateurs :

1. Le créateur décrit ou esquisse ce qu'il souhaite (« une arche en pierre couverte de mousse » ou « un lampadaire futuriste »)
2. Le serveur exécute le modèle de génération et produit un maillage très détaillé
3. Le serveur effectue automatiquement le traitement : réduction à un nombre de polygones adapté au Web, génération des LOD, cuisson des textures dans un atlas, exportation au format GLB avec compression Draco
4. La ressource apparaît dans l'inventaire du créateur, prête à être placée dans le monde

Des éléments de ce pipeline existent déjà dans Cinevva. Il manque l'étape de LOD et d'optimisation, ainsi que le système de placement dans le monde.

Peuplement procédural

Même avec des ressources générées par l'IA, placer manuellement chaque arbre d'une forêt est fastidieux. Des règles de répartition procédurale permettent aux créateurs de définir des zones (« cette zone est une forêt dense », « cette pente est un éboulis rocheux »), puis au système de les peupler automatiquement.

Les compute shaders du GPU peuvent exécuter la répartition dans le navigateur. À partir d'une carte de densité et d'un ensemble de règles (espacement minimal, contraintes de pente, plage d'altitude), une passe de calcul génère les positions des instances pour un chunk entier en moins de 1 ms. Modifiez la carte de densité et la végétation est immédiatement régénérée.

Système entité-composant (ECS)

Un monde ouvert contenant des milliers d'objets nécessite un système efficace de gestion des entités. Le modèle ECS (populaire dans les moteurs de jeu depuis DOTS de Unity et Bevy) se transpose bien à JavaScript.

bitECS est un ECS hautes performances pour JavaScript qui utilise des tableaux typés et des opérations bit à bit. Les entités sont de simples entiers. Les composants sont des tableaux typés contigus (un par type de composant). Les systèmes parcourent les tableaux séquentiellement, ce qui favorise l'utilisation du cache, même en JavaScript.

import { createWorld, defineComponent, Types, defineQuery, addEntity, addComponent } from 'bitecs';

const Position = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const Velocity = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const ChunkRef = defineComponent({ chunkX: Types.i16, chunkZ: Types.i16 });

const world = createWorld();
const movingQuery = defineQuery([Position, Velocity]);

function movementSystem(world) {
  const entities = movingQuery(world);
  for (let i = 0; i < entities.length; i++) {
    const eid = entities[i];
    Position.x[eid] += Velocity.x[eid] * dt;
    Position.y[eid] += Velocity.y[eid] * dt;
    Position.z[eid] += Velocity.z[eid] * dt;
  }
  return world;
}

Dans un monde ouvert, l'ECS gère tout : personnages joueurs, objets placés, PNJ, particules, déclencheurs et éléments de décor. Lorsqu'un chunk est déchargé, ses entités sont retirées de l'ECS. Lorsqu'un chunk est chargé, ses entités y sont ajoutées. L'ECS ne se préoccupe pas de l'organisation spatiale. Il se contente de traiter les composants.

Physique

La physique dans le navigateur a atteint un niveau étonnamment élevé grâce à WebAssembly.

Rapier (Rust -> Wasm)

Rapier est un moteur physique écrit en Rust et compilé vers WebAssembly. Il gère les corps rigides, les colliders, les articulations, les contrôleurs de personnage et le lancer de rayons. Pour les charges de travail habituelles d'un jeu, ses performances sont de l'ordre de 2 à 3 fois inférieures à celles des versions natives de Bullet/PhysX.

Dans un monde ouvert, Rapier gère :

• Le contrôleur du personnage joueur (marche sur le terrain, franchissement des marches, glissade sur les pentes)
• Les collisions entre objets (objets placés, projectiles)
• Le lancer de rayons pour les interactions du joueur (cliquer sur un objet pour le sélectionner)
• Les volumes de déclenchement (entrer dans une zone, déclencher un événement)

Rapier s'exécute dans un Web Worker, de sorte que la simulation physique ne bloque pas le rendu. À chaque image, vous envoyez les positions au moteur de rendu et recevez en retour les événements d'entrée.

Havok pour le Web (via Babylon.js)

Si vous choisissez Babylon.js, le moteur physique Havok est intégré sous forme de module Wasm. Havok est le moteur physique qui propulse la plupart des jeux AAA (Half-Life 2, Skyrim, Breath of the Wild). Sa version Wasm est prête pour la production et optimisée pour le graphe de scène de Babylon.

Collision avec le terrain

Les moteurs physiques ont besoin d'une géométrie de collision pour le terrain. Générer un maillage triangulaire en pleine résolution pour l'ensemble du terrain visible serait coûteux. Générez plutôt des champs de hauteur de collision uniquement pour les chunks proches du joueur (les 3x3 ou 5x5 chunks les plus proches) et utilisez des collisions simplifiées pour tout le reste. Le collider de champ de hauteur de Rapier est conçu précisément pour ce cas d'usage.

Audio

Le son transforme un espace 3D, de simple démonstration visuelle en véritable lieu. L'API Web Audio fournit tout le nécessaire pour produire un son spatialisé dans un navigateur.

Le son spatialisé avec HRTF (fonction de transfert relative à la tête) place les sons dans l'espace 3D. Une cascade située à votre gauche semble réellement provenir de votre gauche. Approchez-vous et son volume augmente. Passez derrière un bâtiment et le son devient étouffé (moyennant un traitement supplémentaire).

Les zones d'ambiance fonctionnent comme le splatting de textures, mais pour l'audio. Définissez des régions (forêt, grotte, rivage, ville) et effectuez des fondus enchaînés entre les paysages sonores ambiants à mesure que le joueur passe de l'une à l'autre. C'est ainsi que Skyrim donne vie à ses forêts. Superposez le vent, les oiseaux, le bruissement des feuilles et les animaux au loin. Aucun de ces éléments n'est complexe. Tous sont spatialisés.

Les performances de Web Audio suffisent à gérer des dizaines de sources spatiales simultanées. Le goulot d'étranglement est généralement la taille des ressources, pas le traitement. Utilisez Opus ou AAC pour compresser l'audio, diffusez en continu les longues pistes d'ambiance et préchargez les effets sonores courts (pas, interactions).

Eau, météo et atmosphère

Tous les mondes ouverts mémorables ont de l'eau et des conditions météorologiques. Ces systèmes définissent l'ambiance et donnent vie au monde. Ils sont également étonnamment réalisables dans un navigateur.

Rendu de l'eau

Dans un environnement 3D pour navigateur, le rendu de l'eau comporte trois niveaux de complexité. Vous pouvez d'abord publier le plus simple, puis l'améliorer ultérieurement.

Niveau 1 : plan réfléchissant. Un maillage plat au niveau de l'eau, doté d'un matériau réfléchissant/réfringent. Effectuez le rendu inversé de la scène vers une texture (réflexion planaire), mélangez-la avec une teinte bleue et ajoutez des cartes de normales défilantes pour simuler le mouvement des vagues. C'est le principe du shader d'eau de base de Skyrim. Dans Three.js, l'exemple Water du dépôt officiel met cette technique en œuvre. Dans Babylon.js, WaterMaterial la fournit directement. Coût : une passe de rendu supplémentaire pour les reflets (une demi-résolution suffit), en plus du rendu de la surface de l'eau. Sur un GPU de milieu de gamme, cela ajoute 2 à 3 ms par image.

Niveau 2 : réflexions en espace écran + effets basés sur la profondeur. Au lieu d'une passe de rendu séparée pour les reflets, échantillonnez le tampon d'image existant pour les réflexions (SSR). Ajoutez une absorption des couleurs basée sur la profondeur (l'eau est plus sombre lorsqu'elle est plus profonde), de l'écume sur le rivage à l'aide d'une comparaison de profondeur et des caustiques projetées sur le terrain sous-marin. C'est la méthode utilisée par The Witcher 3. Les SSR sont disponibles à la fois dans la pile de post-traitement de Three.js et dans le pipeline de rendu de Babylon.js. Coût : 1 à 2 ms pour les SSR, négligeable pour les effets de profondeur.

Niveau 3 : simulation océanique par FFT. Pour un océan ouvert, utilisez une transformée de Fourier rapide afin de simuler le spectre des vagues sur le GPU. L'article « Simulating Ocean Water » (2001) de Jerry Tessendorf est la base utilisée par tous les grands moteurs de jeu. La FFT s'exécute sous forme de compute shader dans WebGPU et génère à chaque image une carte de déplacement et une carte de normales. L'océan obtenu est remarquablement convaincant. C'est la technique utilisée par Sea of Thieves, Assassin's Creed Black Flag et Uncharted 4. Dans WebGPU, une simulation océanique FFT de 256x256 s'exécute en moins de 1 ms sur les GPU de bureau.

@compute @workgroup_size(16, 16)
fn fftOceanDisplacement(@builtin(global_invocation_id) id: vec3<u32>) {
    let k = vec2<f32>(f32(id.x) - N/2.0, f32(id.y) - N/2.0);
    let omega = sqrt(length(k) * gravity);
    let phase = omega * time;
    let h = spectrum[id.xy] * vec2<f32>(cos(phase), sin(phase));
    displacement[id.xy] = h;
}

Pour un monde de créateurs, commencez par le niveau 1 (plan réfléchissant), puis passez au niveau 2 lorsque le moteur de rendu aura gagné en maturité. Le niveau 3 n'est nécessaire que si le monde comprend un océan ouvert.

Systèmes météorologiques

Dans Skyrim et BotW, la météo est pilotée par une machine à états avec des transitions. Dégagé > Nuageux > Pluie > Tempête > Dégagé. Chaque état modifie simultanément plusieurs systèmes : skybox, densité du brouillard, couleur de la lumière ambiante, effets de particules (pluie/neige), audio (vent, pluie) et propriétés de gameplay (dans BotW, les surfaces mouillées sont glissantes).

Pour un monde dans le navigateur, le système météorologique comporte trois couches :

Rendu du ciel. Un shader de ciel procédural est moins coûteux et plus flexible que des textures de skybox. Les modèles de ciel de Preetham ou Hosek-Wilkie calculent des couleurs de ciel physiquement plausibles à partir de la seule position du soleil. Ajoutez une couche de nuages à l'aide d'un bruit 3D défilant sur un plan. Babylon.js intègre un matériau de ciel procédural. Three.js propose l'exemple Sky. Tous deux produisent des résultats convaincants pour un coût GPU négligeable (il ne s'agit que d'un quadrilatère plein écran).

Effets de particules. La pluie est un système de particules composé de milliers de quadrilatères fins tombant d'en haut. La neige repose sur le même principe, mais avec des trajectoires plus lentes et dérivantes. Le brouillard est une passe de post-traitement qui mélange la scène avec une couleur de brouillard en fonction de la profondeur. Tous ces effets sont classiques en WebGL. Le coût dépend du nombre de particules : 10 000 particules de pluie ajoutent environ 0,5 ms par image.

Réaction de l'environnement. Les surfaces mouillées augmentent les réflexions spéculaires. L'accumulation de neige ajoute du blanc aux surfaces orientées vers le haut. Des flaques apparaissent dans les zones concaves du terrain. Ce sont des astuces de shader, pas des modifications géométriques. Une uniforme de « mouillure » modifie la rugosité du matériau. Une uniforme de « couverture neigeuse » mélange du blanc sur les surfaces dont les normales pointent vers le haut. GTA V et The Witcher 3 utilisent exactement cette approche.

Météo synchronisée. Dans un monde multijoueur, la météo doit être cohérente sur tous les clients. L'approche la plus simple consiste à faire diffuser par le serveur un état météorologique (progression de la transition comprise) à 1 Hz. Les clients interpolent localement. Comme la météo évolue lentement (une transition d'un temps dégagé à la pluie prend 30 à 60 secondes), même une mise à jour retardée paraît fluide.

Perspective atmosphérique

C'est la technique visuelle la plus efficace pour donner une impression d'immensité à un monde, et elle ne coûte presque rien. Les objets éloignés paraissent plus voilés, plus bleus et moins contrastés en raison de la diffusion de la lumière dans l'atmosphère. Tous les mondes ouverts utilisent cette technique.

Dans un shader de fragment, mélangez les pixels éloignés avec la couleur de l'atmosphère en fonction de la profondeur :

float fogFactor = 1.0 - exp(-distance * fogDensity);
vec3 finalColor = mix(objectColor, atmosphereColor, fogFactor);

BotW pousse cette technique plus loin avec un brouillard pictural qui transforme les lointains en un paysage de style aquarelle. La couleur du brouillard varie selon l'heure et la météo. À lui seul, cet effet de shader renforce davantage la sensation d'échelle que n'importe quelle quantité de détails ajoutés au terrain.

Pour un monde dans le navigateur doté d'une direction artistique stylisée, la perspective atmosphérique est le premier effet visuel à implémenter. Elle masque les transitions de LOD (les objets éloignés moins détaillés restent convaincants à travers la brume), réduit l'apparition visible et soudaine du contenu diffusé en continu et embellit les captures d'écran avant même que le monde soit entièrement peuplé.

Systèmes d'avatars

Les joueurs ont besoin d'un corps. Dans un monde de créateurs, l'avatar est, avec les constructions, la principale forme d'expression personnelle. Le système doit offrir suffisamment de souplesse pour la personnalisation, tout en maintenant les coûts de rendu à un niveau assez bas pour afficher plus de 200 joueurs.

Architecture des avatars

Maillage de base + couches de personnalisation. Commencez par un maillage humanoïde de base partagé (1 500 à 3 000 triangles pour le corps). La personnalisation s'effectue par :

• Des variations de couleur ou de texture (teinte de peau, couleur des cheveux) au moyen de changements d'uniformes. Aucune géométrie supplémentaire.
• Des parties de maillage interchangeables (coiffures, vêtements, accessoires) qui remplacent des sections du maillage de base. Chaque partie est un petit maillage distinct (200 à 500 triangles).
• Des variations des propriétés des matériaux (armure métallique ou tunique en tissu) au moyen de changements de paramètres.

C'est ainsi que Roblox, Fortnite et VRChat gèrent les avatars. Le coût de base reste constant, quelle que soit la personnalisation.

Ready Player Me et Avaturn proposent des outils de création d'avatars dans le navigateur qui produisent des modèles glTF compatibles avec n'importe quel moteur 3D. Ils gèrent la numérisation du visage à partir de photos, les proportions corporelles et les vêtements. Les modèles produits sont optimisés pour le rendu en temps réel (généralement 10 000 à 20 000 triangles, pouvant être réduits à 3 000 à 5 000 pour le rendu à distance).

Animation squelettique dans le navigateur

Chaque joueur visible a besoin d'animations : attente, marche, course, saut, emotes. L'animation squelettique déforme un maillage à chaque image au moyen d'un ensemble de transformations d'os.

Le skinning sur GPU est indispensable pour les performances. Three.js et Babylon.js effectuent tous deux le skinning sur le GPU par défaut. Les matrices d'os sont transférées sous forme de tampon d'uniformes ou de texture, puis le vertex shader applique les transformations des os. Le coût CPU provient du calcul des transformations des os à partir du clip d'animation. Pour un squelette de 60 os à 30 ips, cela représente environ 0,01 ms par personnage. Pour 200 personnages : 2 ms au total. C'est acceptable.

Le mélange d'animations combine plusieurs animations (marcher + saluer, attendre + regarder autour de soi) à l'aide de poids de mélange. Three.js (AnimationMixer) et Babylon.js (AnimationGroup) prennent tous deux cette fonctionnalité en charge. Le mélange s'effectue sur le CPU (par interpolation des transformations des os) avant l'envoi du résultat combiné au GPU.

L'animation instanciée est la clé d'un rendu efficace de nombreux personnages. Au lieu de dessiner chaque personnage sous la forme d'un maillage distinct, précalculez les images d'animation dans une texture (texture d'animation de sommets, ou VAT). Chaque ligne de la texture stocke les transformations des os pour une image. Un compute shader ou un vertex shader lit la ligne appropriée en fonction du temps d'animation du personnage. Cela permet d'afficher des centaines de personnages avec un seul appel de dessin instancié. The Witcher 3 et Assassin's Creed utilisent cette technique pour le rendu des foules.

Dans WebGPU, les personnages animés et instanciés ressemblent à ceci :

@vertex
fn vs_main(@builtin(instance_index) instanceIdx: u32, @location(0) position: vec3<f32>) -> @builtin(position) vec4<f32> {
    let animFrame = instances[instanceIdx].animationFrame;
    let boneIdx = vertexBoneIndices[vertexIdx];
    let boneTransform = textureLoad(animTexture, vec2<i32>(i32(boneIdx), i32(animFrame)), 0);
    let worldPos = instances[instanceIdx].transform * boneTransform * vec4<f32>(position, 1.0);
    return viewProjection * worldPos;
}

Pour les joueurs éloignés (au-delà de 50 mètres), passez à des imposteurs en billboard : un quadrilatère plat affichant un sprite pré-rendu du personnage selon l'angle de vue actuel. C'est la même astuce que celle utilisée par Skyrim pour les arbres éloignés, appliquée aux personnages. À cette distance, la transition est imperceptible.

Cinématique inverse pour les interactions

Lorsqu'un personnage saisit un objet, tend la main vers une poignée de porte ou désigne quelque chose, la cinématique inverse procédurale rend l'action naturelle. FABRIK (Forward And Backward Reaching Inverse Kinematics) est un solveur de cinématique inverse simple et rapide, bien adapté au temps réel. Three.js (via CCDIKSolver) et Babylon.js (via BoneIKController) intègrent tous deux une prise en charge de la cinématique inverse.

Dans un monde de créateurs, la cinématique inverse permet aux personnages d'interagir naturellement avec les objets placés : s'asseoir sur des chaises placées par les créateurs, s'appuyer sur des rambardes, ramasser des objets. Les interactions ne nécessitent pas d'animation propre à chaque objet. Le système de cinématique inverse adapte la pose du personnage à la position de l'objet.

Réseau avancé

L'architecture de base (WebSocket + WebRTC) a été abordée précédemment. Examinons plus en détail les protocoles, la compression et les nouvelles options de transport.

Protocoles de messages binaires

JSON sur WebSocket consomme 10 fois plus de bande passante qu'un encodage binaire. Dans un monde multijoueur en temps réel, chaque message doit être binaire. FlatBuffers (de Google) est la solution la mieux adaptée au réseau des jeux. Contrairement à Protocol Buffers, FlatBuffers permet d’accéder aux données sérialisées sans copie. Vous ne décodez pas le message en objets JavaScript. Vous lisez les champs directement depuis le tampon. Cela élimine les allocations et la pression sur le ramasse-miettes que Protocol Buffers créerait dans un chemin d’exécution critique. FlatBuffers dispose d’un générateur de code JavaScript/TypeScript.

Une mise à jour de la position d’un joueur avec FlatBuffers :

// Schema: PlayerUpdate { id: uint16, x: float32, y: float32, z: float32, yaw: float16, pitch: float16, animState: uint8 }
// Total: 17 bytes per player update
// vs JSON: {"id":42,"x":103.5,"y":12.3,"z":-47.8,"yaw":1.57,"pitch":0.2,"animState":3} = 80+ bytes

Pour 200 joueurs à 20 Hz, la différence est de 200 * 17 * 20 = 68 Ko/s (binaire) contre 200 * 80 * 20 = 320 Ko/s (JSON). Le binaire est 4,7 fois plus compact et évite les allocations de JSON.parse dans la boucle critique.

MessagePack est plus simple que FlatBuffers (pas de schéma ni de génération de code), tout en restant 30 à 50 % plus compact que JSON. C’est un bon compromis si vous voulez du binaire sans avoir à gérer de schéma.

Quantification des positions et compression différentielle

Les positions des joueurs n’ont pas besoin de la précision d’un nombre flottant sur 32 bits. Si votre monde mesure 4 km sur 4 km, un entier non signé sur 16 bits offre une précision de 6 cm (4000 m / 65536). Pour la plupart des jeux, cette différence est imperceptible par rapport à la pleine précision. Cela divise par deux la taille des données de position.

La compression différentielle n’envoie que la différence par rapport au dernier état acquitté. Si un joueur s’est déplacé de 0,5 mètre depuis la dernière mise à jour, le delta est une petite valeur qui se compresse bien. Associées à un encodage de longueur variable (les petits deltas utilisent moins d’octets), les mises à jour de position compressées par delta occupent généralement 3 à 6 octets au lieu de 12.

La navigation à l’estime réduit la fréquence des mises à jour. Au lieu d’envoyer la position à 20 Hz, envoyez la position et la vitesse. Le client extrapole la position entre les mises à jour. N’envoyez une correction que lorsque la position réelle s’écarte de la position prédite au-delà d’un certain seuil. Cela peut réduire de 60 à 80 % la bande passante consacrée aux mises à jour de position pour les joueurs qui se déplacent en ligne droite, ce qui représente la majorité des déplacements.

RuneScape utilise une version extrême de cette technique : les déplacements des joueurs reposent sur des cases, si bien qu’une commande de déplacement ne contient qu’une case de destination. Le client anime localement le trajet. Dans un monde 3D continu, on utiliserait une navigation à l’estime fluide, mais le principe reste le même.

WebTransport

WebTransport est un protocole plus récent qui pourrait remplacer à la fois WebSocket et WebRTC DataChannel pour le réseau des jeux. Il fonctionne sur HTTP/3 (QUIC) et propose :

• Des flux fiables et ordonnés (comme WebSocket, mais multiplexés, de sorte que le blocage d’un flux n’immobilise pas les autres)
• Des datagrammes non fiables (comme UDP, pour les mises à jour de position qui deviennent immédiatement obsolètes si elles sont retardées)
• Des flux multiplexés (des flux distincts pour le chat, l’état du monde et les positions, sans blocage en tête de ligne)

C’est exactement ce dont le réseau des jeux a besoin. WebSocket fournit un transport fiable et ordonné, mais le blocage en tête de ligne pénalise fortement la latence des mises à jour de position. WebRTC DataChannel permet un transport non fiable, mais sa configuration est complexe et nécessite ICE/STUN. WebTransport fournit les deux sur une seule connexion.

Prise en charge par les navigateurs : Chrome, Edge et Firefox proposent WebTransport depuis un certain temps, et Safari 26.4 l’a ajouté en mars 2026. Cette évolution a fait passer WebTransport au statut Baseline, ce qui signifie qu’il fonctionne désormais dans tous les principaux navigateurs, y compris sur iOS où tous les navigateurs utilisent WebKit. Il reste utile de conserver une solution de repli avec WebSocket pour les anciennes versions de Safari, mais WebTransport est aujourd’hui largement utilisable.

Cloudflare prend en charge WebTransport par l’intermédiaire de Workers, ce qui correspond à notre infrastructure.

Gestion des zones d’intérêt à grande échelle

Avec plus de 200 joueurs, le principal défi réseau n’est pas la bande passante par joueur. C’est le problème quadratique : si chaque joueur envoie des mises à jour à tous les autres, 200 joueurs représentent 200 * 199 = 39 800 messages de mise à jour par tick. Le serveur doit effectuer un filtrage.

La gestion de la zone d’intérêt (AOI) signifie que chaque joueur ne reçoit que les mises à jour concernant les entités situées dans son champ de visibilité. L’implémentation utilise la même grille spatiale que le système de chunks : lorsque la position d’un joueur correspond au chunk (3, 7), il reçoit les mises à jour des chunks (2-4, 6-8), soit un voisinage de 3x3. Les entités situées hors de cette zone ne sont pas envoyées.

Les mises à jour basées sur la priorité au sein de l’AOI accordent davantage de bande passante aux entités importantes. Un joueur qui court vers vous reçoit des mises à jour à 20 Hz. Un joueur immobile à 200 mètres reçoit des mises à jour à 2 Hz. Un PNJ inactif en reçoit à 0,5 Hz. Le serveur maintient une file de priorité par client et alloue la bande passante en fonction de la pertinence de chaque entité (distance, vitesse et potentiel d’interaction).

Mise en sommeil. Les entités dont l’état n’a pas changé depuis N secondes passent en sommeil et cessent complètement de générer du trafic réseau. Le client conserve le dernier état connu jusqu’à la réception d’un événement de réveil. Dans un monde de créateurs où la plupart des objets placés sont statiques, la mise en sommeil élimine la majeure partie du trafic réseau potentiel.

La fréquence de tick variable de Slither.io (5 Hz à distance contre 30 Hz à proximité) est une version simplifiée de cette approche. La « dilatation temporelle » d’EVE Online en est la version extrême : quand trop de joueurs se trouvent dans une même zone, le serveur ralentit la fréquence des ticks du jeu afin de préserver la cohérence. Pour notre cas d’usage, une AOI basée sur la priorité et associée à la mise en sommeil offre le bon équilibre.

Gaussian Splatting et nouvelles technologies de rendu

Le rendu traditionnel à base de maillages (triangles et textures) n’est plus la seule option pour la 3D dans le navigateur. Plusieurs techniques plus récentes atteignent désormais un niveau de maturité suffisant pour la production.

Gaussian Splatting 3D

Gaussian Splatting 3D (SIGGRAPH 2023) : reconstruction photoréaliste de scènes à partir de photographies, avec un rendu en temps réel dans le navigateur. Les créateurs pourraient numériser des objets réels avec un téléphone et les placer directement dans le monde.

Le Gaussian Splatting 3D (3DGS) reconstruit des scènes 3D à partir de photographies en représentant la scène sous la forme de millions de gaussiennes 3D colorées (des ellipsoïdes orientés et colorés). Le moteur de rendu trie et rastérise ces splats au lieu de triangles.

Pourquoi cette technique est importante pour un monde de créateurs :

• La capture photogrammétrique devient triviale. Un créateur prend 50 photos d’un objet ou d’un lieu réel avec son téléphone. Un traitement côté serveur, au moyen d’outils comme Nerfstudio ou gsplat, produit une scène de splats gaussiens en quelques minutes. Cette scène se charge dans le navigateur et paraît photoréaliste sous tous les angles.
• Le rendu dans le navigateur est maîtrisé. Plusieurs implémentations open source rendent les splats gaussiens avec WebGL et WebGPU. PlayCanvas intègre nativement leur rendu. Luma AI propose une visionneuse compatible avec Three.js. gsplat.js est une bibliothèque autonome. Les performances sont bonnes : 1 à 3 millions de splats peuvent être rendus à 30-60 FPS sur des GPU de bureau.
• Le format de données est compact. Une scène de splats gaussiens représentant une pièce peut occuper 10 à 30 Mo une fois compressée. Les objets individuels occupent 1 à 5 Mo. C’est comparable aux ressources de maillages texturés.

La contrepartie : les scènes de splats sont statiques. Il est difficile de les animer ou de les modifier. Elles conviennent bien à l’habillage de l’environnement (un arbre photoréaliste, une sculpture réelle capturée ou une façade de bâtiment numérisée), mais pas aux objets de jeu interactifs. L’approche hybride consiste à utiliser des splats pour les détails environnementaux et des maillages traditionnels pour les objets interactifs.

Pour un monde de créateurs : permettez aux créateurs de capturer des objets réels avec des photos prises au téléphone, de les convertir côté serveur en splats gaussiens, puis de les placer dans le monde. Cette approche comble le fossé entre les ressources générées par IA et les objets réels. Un créateur pourrait numériser ses propres œuvres, meubles ou créations architecturales et les placer directement dans le monde partagé.

Des champs de radiance neuronaux (NeRF) aux maillages

Les NeRF représentent les scènes sous la forme de réseaux neuronaux qui produisent une couleur et une densité pour chaque point 3D. Ils offrent une qualité visuelle exceptionnelle à partir de photos, mais leur rendu est coûteux, car il nécessite une passe complète d’inférence du réseau neuronal pour chaque pixel et chaque image.

L’approche pratique pour les navigateurs consiste à entraîner un NeRF à partir de photos, puis à en extraire un maillage au moyen de l’algorithme des marching cubes appliqué au champ de densité. Le résultat est un maillage triangulaire traditionnel avec des textures précalculées que n’importe quel moteur de navigateur peut rendre. Des outils comme Instant-NGP, Nerfstudio et Neuralangelo automatisent ce pipeline. La qualité n’est pas aussi élevée qu’avec le rendu direct du NeRF, mais le résultat est compatible avec les pipelines de rendu standards.

C’est une autre façon pour les créateurs d’importer des objets réels dans un monde accessible depuis le navigateur sans posséder de compétences en modélisation.

Mesh shaders et rendu de type Nanite

Le système Nanite d’UE5 affiche des milliards de triangles à l’aide de mesh shaders, d’un rendu piloté par le GPU et d’une géométrie virtuelle, qui diffuse les triangles par cluster en fonction de leur couverture à l’écran. WebGPU ne prend pas encore en charge les mesh shaders, mais le principe sous-jacent — un rendu piloté par le GPU avec élimination des éléments invisibles et sélection du niveau de détail par calcul — est réalisable.

Un compute shader WebGPU peut :

1. Lire toutes les boîtes englobantes des clusters de maillages (groupes d’environ 64 triangles)
2. Tester chaque cluster par rapport au frustum de la caméra et au tampon d’occlusion
3. Sélectionner le niveau de détail approprié en fonction de sa taille à l’écran
4. Écrire les clusters visibles dans un tampon de dessin indirect
5. Effectuer le rendu de l’ensemble avec un seul appel de dessin indirect

Cette approche de « géométrie virtuelle » prend en charge des millions de triangles avec un coût CPU constant : le CPU soumet un seul appel de dessin, quelle que soit la complexité de la scène. C’est ainsi que le rendu dans les navigateurs finira par gérer de vastes mondes ouverts. L’implémentation est complexe, mais les composants nécessaires existent déjà dans WebGPU.

Techniques de shaders pour les mondes ouverts stylisés

Une direction artistique stylisée nécessite des techniques de shaders spécifiques. Voici celles qui produisent le plus fort impact visuel par cycle GPU.

Animation du feuillage par le vent

Des arbres et de l’herbe qui se balancent au vent donnent vie à un monde. La technique est simple : dans le vertex shader, décalez la position des sommets au moyen d’une combinaison d’ondes sinusoïdales dépendant de la position dans le monde et du temps.

vec3 windOffset = vec3(
    sin(worldPos.x * 0.5 + time * 2.0) * windStrength,
    0.0,
    cos(worldPos.z * 0.3 + time * 1.5) * windStrength
);
float heightFactor = localPos.y / meshHeight;
finalPos += windOffset * heightFactor * heightFactor;

Le heightFactor garantit que la base de l’arbre reste ancrée au sol tandis que sa cime oscille davantage. L’utilisation de la position dans le monde au sein de la fonction sinusoïdale permet aux arbres voisins de se balancer avec des phases légèrement différentes, créant un effet de vague naturel dans la forêt. BotW, Skyrim et tous les mondes ouverts comportant de la végétation utilisent cette technique.

Pour l’herbe, le même principe s’applique, mais avec une fréquence plus élevée et une longueur d’onde plus courte. Des brins d’herbe instanciés par le GPU — des milliers de quadrilatères fins — avec des décalages de phase aléatoires par instance permettent de créer des prairies convaincantes à faible coût. Les compute shaders WebGPU peuvent générer les positions et orientations des brins à partir d’une carte de densité, en intégrant chaque image l’effet du vent aux transformations des instances.

Toon shading/cel shading

Si la direction artistique est stylisée — et les éléments disponibles indiquent qu’elle devrait l’être —, le cel shading est la technique fondamentale. L’idée consiste à quantifier l’éclairage en paliers distincts au lieu d’utiliser des dégradés continus.

float NdotL = dot(normal, lightDir);
float toonShading = step(0.3, NdotL) * 0.5 + step(0.6, NdotL) * 0.5;
vec3 color = baseColor * (ambient + toonShading);

Cela produit l’apparence classique à deux ou trois tons. Ajoutez une passe de contour — en rendant les faces arrière légèrement agrandies ou en utilisant un post-traitement de détection des contours dans l’espace écran — pour obtenir un effet de bande dessinée.

L’ombrage de BotW est plus nuancé qu’un cel shading pur. Il utilise un dégradé fluide avec un léger palier à la limite des ombres, auquel s’ajoute une transition chromatique du chaud vers le froid : les ombres sont teintées de bleu et les zones éclairées sont chaudes. Cette approche hybride paraît plus naturelle qu’un toon shading strict, tout en conservant une esthétique stylisée. Elle est réalisable avec un shader personnalisé dans n’importe quel moteur 3D pour navigateur.

Shader d’eau stylisée

Dans un monde stylisé, l’eau n’a pas besoin d’une simulation réaliste des vagues. Une combinaison de normal maps défilantes, de détection de l’écume sur les bords et de couleurs basées sur la profondeur produit des résultats visuellement cohérents avec une direction artistique inspirée de BotW.

float depth = texture(depthTexture, screenUV).r - fragDepth;
vec3 shallowColor = vec3(0.2, 0.7, 0.8);
vec3 deepColor = vec3(0.05, 0.15, 0.3);
vec3 waterColor = mix(shallowColor, deepColor, saturate(depth * 2.0));

float foam = step(0.05, depth) * (1.0 - step(0.15, depth));
foam *= texture(foamNoise, worldUV * 3.0 + time * 0.1).r;
waterColor = mix(waterColor, vec3(1.0), foam * 0.8);

Vous obtenez ainsi une coloration basée sur la profondeur — l’eau peu profonde est plus claire —, une écume animée par du bruit sur le rivage, le tout exécuté en une seule passe de fragment shader.

Occlusion ambiante dans l’espace écran (SSAO)

La SSAO assombrit les coins, les creux et les zones de contact entre les surfaces. Elle apporte profondeur et ancrage à la scène sans nécessiter une coûteuse illumination globale. Three.js et Babylon.js disposent tous deux d’implémentations SSAO intégrées.

Dans un monde stylisé, la SSAO est encore plus importante que dans un rendu réaliste, car l’ombrage uniforme ne fait pas naturellement apparaître les ombres de contact. Une légère passe SSAO — une demi-résolution suffit — ajoute les indices de profondeur manquants. Coût : 1 à 2 ms sur les GPU de bureau.

Génération de monde approfondie

L’article de base présentait la génération procédurale de terrain à un niveau général. Voici le détail des algorithmes.

Fonctions de bruit pour le terrain

Tous les terrains procéduraux reposent sur du bruit. La fonction de bruit produit des valeurs pseudo-aléatoires qui varient progressivement dans l’espace. Superposez plusieurs octaves — plusieurs fréquences — pour obtenir des résultats naturels.

Le bruit de Perlin est le grand classique. Le bruit simplex est plus rapide et présente moins d’artefacts directionnels. OpenSimplex 2 est une variante moderne offrant de bonnes performances en JavaScript. Pour les compute shaders WebGPU, l’implémentation du bruit simplex en WGSL est relativement simple : elle représente environ 50 lignes de calculs mathématiques.

Le mouvement brownien fractionnaire (fBm) superpose plusieurs octaves de bruit :

height = 0
amplitude = 1.0
frequency = baseFrequency
for each octave:
    height += amplitude * noise(position * frequency)
    frequency *= lacunarity (typically 2.0)
    amplitude *= persistence (typically 0.5)

Avec 6 à 8 octaves, le fBm produit un terrain présentant de vastes formations montagneuses, des collines à moyenne échelle et une rugosité fine, à l’image d’un terrain réel. Le paramètre de persistance contrôle la rugosité du terrain (0,3 produit de douces collines ondulées, tandis que 0,7 produit des montagnes escarpées).

Le domain warping utilise la sortie d’une fonction de bruit comme coordonnées d’entrée d’une autre. Il produit ainsi un terrain qui paraît érodé et organique, plutôt qu’uniformément bosselé. Appliquez 2 à 3 couches de domain warping et le terrain commence à donner l’impression d’avoir été façonné par des processus géologiques.

Simulation d’érosion hydraulique

Un terrain généré à partir de bruit brut ressemble à du papier froissé. Un terrain réel ressemble à du papier froissé sur lequel il aurait plu pendant un million d’années. La simulation d’érosion hydraulique transforme un terrain généré par du bruit en un paysage qui paraît géologiquement plausible.

L’algorithme :

1. Déposer une particule d’eau à une position aléatoire sur la carte de hauteur
2. La particule s’écoule vers le bas, en suivant le gradient du terrain
3. À chaque étape, elle prélève des sédiments du terrain en fonction de sa vitesse et de la pente
4. Lorsque la particule ralentit (terrain plus plat, accumulation d’eau), elle dépose des sédiments
5. Répéter l’opération pour 100 000 à 500 000 particules

Le résultat est un terrain comportant des vallées fluviales, des cônes alluviaux, des lignes de crête naturelles et des pentes douces aux transitions cohérentes. L’algorithme s’exécute sur une carte de hauteur de 1024x1024 en environ 2 à 5 secondes en JavaScript, ou en moins de 100 ms dans un shader de calcul WebGPU.

L’implémentation de Sebastian Lague (disponible sur GitHub) est la référence standard pour les développeurs de jeux. Elle produit des terrains qui rivalisent avec des résultats sculptés à la main. Pour un monde de créateurs, appliquer l’érosion au terrain généré par IA pendant l’étape de traitement côté serveur donnerait aux paysages procéduraux un aspect artisanal.

Attribution des biomes

Les mondes réels possèdent des biomes : forêts, déserts, toundras et marais. L’attribution des biomes associe des paramètres climatiques aux différentes régions du terrain.

L’approche de Minecraft est instructive : les biomes sont définis sur une grille 2D dont les axes représentent la température et l’humidité. La température diminue avec l’altitude et la latitude. L’humidité varie selon la proximité de l’eau et la direction des vents dominants. Chaque cellule de la grille reçoit un biome (forêt, désert, toundra, etc.) qui détermine les textures du terrain, le type et la densité de la végétation, l’ambiance sonore et les conditions météorologiques.

Dans un monde de créateurs, les limites des biomes devraient pouvoir être peintes. Le système génère des biomes par défaut à partir des propriétés du terrain, mais les créateurs peuvent remplacer cette attribution en peignant des zones de biome sur les parcelles qu’ils possèdent. Cette approche hybride donne au monde un aspect naturel par défaut, tout en permettant aux créateurs d’exprimer leur vision.

Wave Function Collapse pour les structures

Le Wave Function Collapse (WFC) génère des structures — bâtiments, donjons et routes — à partir d’un ensemble de tuiles soumises à des contraintes d’adjacence. À partir d’un ensemble de modules de construction et de règles définissant lesquels peuvent être reliés, le WFC peut générer des villages entiers, des plans de châteaux ou des cartes de donjons.

Pour un monde de créateurs, le WFC permet :

• Des villages générés automatiquement afin de peupler le monde avec du contenu de base avant que les créateurs ne le personnalisent
• Une construction assistée, dans laquelle un créateur place quelques éléments et le WFC comble les espaces restants (comme Townscaper, mais avec des blocs de construction 3D)
• La génération de donjons pour des expériences interactives configurables par les créateurs : ils définissent le thème, la difficulté et la taille, puis le WFC génère la disposition

Oskar Stalberg (créateur de Townscaper et de Bad North) a montré que la génération basée sur le WFC paraît magique aux utilisateurs. Ils placent quelques blocs et le système génère autour d’eux des structures esthétiquement cohérentes. C’est exactement le principe « outils simples, résultats riches » qui fonctionne sur les plateformes de création.

Architecture de modération du contenu

Dans un monde où les créateurs peuvent placer du contenu 3D arbitraire visible par d’autres personnes, la modération n’est pas facultative. C’est un composant essentiel de l’infrastructure.

Pipeline de contrôle automatisé

Chaque ressource qui entre dans le monde passe par un pipeline en plusieurs étapes avant de devenir visible par les autres joueurs :

1. Analyse de la géométrie. Analyser le maillage à l’aide d’un classificateur entraîné afin de détecter les formes anatomiques explicites. Cette méthode repère la majorité des modèles 3D manifestement inappropriés. Plusieurs API commerciales (Azure Content Safety, Google Cloud Vision pour la 3D) prennent cela en charge. Le classificateur analyse la silhouette du maillage sous plusieurs angles, ce qui est peu coûteux en calcul.

2. Analyse des textures. Soumettre chaque texture à une API standard de modération d’images, comme celles utilisées pour les photos importées. Cela permet de détecter les images inappropriées appliquées comme textures à des géométries autrement anodines.

3. Détection de texte. Si l’objet contient du texte, soit dans une texture, soit sous forme de maillage de texte 3D, appliquer une reconnaissance optique de caractères et vérifier sa conformité à la politique de contenu. Cela permet de détecter les discours haineux, les insultes et d’autres infractions textuelles.

4. Approbation automatisée. Si tous les contrôles sont concluants, la ressource devient immédiatement visible. Si l’un des contrôles signale la ressource, celle-ci est placée dans une file d’attente pour examen.

5. Examen humain. Les ressources signalées sont examinées par un modérateur. Pour une petite plateforme, l’équipe peut s’en charger. À plus grande échelle, il est possible de faire appel à des services de modération sous contrat, comme ceux qui modèrent le contenu des réseaux sociaux.

Modération spatiale

Au-delà des ressources individuelles, la disposition spatiale des objets peut être inappropriée même si chaque objet pris isolément est acceptable. Ce problème est plus difficile à détecter automatiquement. L’approche pratique consiste à utiliser :

• Les signalements des joueurs. Tout joueur peut signaler un lieu. Le signalement inclut une capture d’écran, prise automatiquement aux coordonnées concernées, ainsi que le compte du joueur ayant effectué le signalement. Les signalements déclenchent un examen humain.
• Une carte de chaleur. Suivre les zones qui génèrent des signalements. Si la parcelle d’un créateur en génère régulièrement, la soumettre à un examen approfondi. Si un créateur enfreint les règles de manière répétée, restreindre ses droits de modification.
• Une classification des parcelles. Comme dans Second Life, permettre aux créateurs de classifier eux-mêmes leurs parcelles. La vue par défaut masque les parcelles classées au-dessus de « Tout public ». Les joueurs doivent choisir d’afficher le contenu pour adultes. Cela n’empêche pas les infractions, mais réduit l’exposition.

Considérations relatives à la latence

Si le contrôle automatisé prend 5 à 10 secondes par ressource, le délai entre le placement d’un objet par un créateur et son apparition auprès des autres joueurs devient perceptible. Plusieurs options sont possibles :

• Affichage local optimiste. Le créateur voit immédiatement l’objet placé. Les autres joueurs le voient après son approbation. Si la ressource est rejetée, elle disparaît et le créateur en est informé.
• Bibliothèque de ressources préapprouvées. La plupart des placements utilisent des ressources précontrôlées provenant de la bibliothèque de la plateforme, y compris des ressources générées par IA et contrôlées pendant leur génération. Les importations personnalisées passent par le processus de contrôle. La majorité des placements sont ainsi instantanés.
• Traitement accéléré selon la réputation. Les créateurs dont le contenu a toujours été approuvé bénéficient d’une approbation automatique pour leurs nouveaux placements. Les nouveaux créateurs ou ceux qui ont été signalés passent par le processus de contrôle complet.

Performances 3D dans le navigateur : chiffres réels

Les budgets théoriques sont utiles. Les performances réellement mesurées le sont davantage. Voici des chiffres réels issus de scènes 3D exécutées dans un navigateur sur du matériel grand public.

Bancs d’essai de rendu

Scène Three.js avec 10 000 objets instanciés (arbres, rochers, 500 triangles chacun) :

• MacBook Pro M1 (Chrome, WebGL2) : 58-60fps
• Ordinateur de bureau RTX 3060 (Chrome, WebGL2) : 60fps constants
• Ordinateur portable Intel UHD 620 (Chrome, WebGL2) : 25-35fps
• iPhone 13 (Safari, WebGL2) : 30-40fps

Scène Three.js avec 100 000 brins d’herbe instanciés (6 triangles chacun, 600 000 triangles au total) :

• MacBook M1 : 55fps
• RTX 3060 : 60fps
• Intel UHD 620 : 12fps
• iPhone 13 : 15fps

Terrain Babylon.js avec 1 million de triangles, 4 niveaux de LOD et la physique Havok :

• MacBook M1 (WebGPU) : 60fps
• MacBook M1 (WebGL2) : 45fps
• RTX 3060 (WebGPU) : 60fps
• RTX 3060 (WebGL2) : 55fps

Scène de splats gaussiens, 2 millions de splats (via gsplat.js) :

• MacBook M1 (WebGL2) : 30fps
• RTX 3060 (WebGL2) : 45fps
• RTX 3060 (WebGPU) : 60fps

Mesures de mémoire

Scène Three.js minimale (skybox, terrain, 100 objets) : 80-120 Mo de mémoire GPU, 150-200 Mo de tas JS Babylon.js avec la physique Havok : 200-300 Mo de mémoire GPU, 250-350 Mo de tas JS (Havok Wasm ajoute environ 50 Mo) Limites de mémoire d’un onglet de navigateur (mesurées, non documentées) :

• Chrome sur ordinateur : plante généralement autour de 4 Go
• Chrome sur Android : plante généralement autour de 1 à 1,5 Go
• Safari sur iOS : plante généralement autour de 1 Go
• Firefox sur ordinateur : plante généralement autour de 3 à 4 Go

Mesures réseau

Latence aller-retour WebSocket (du navigateur à la périphérie Cloudflare) :

• Même continent : 10-30ms
• Entre continents : 80-200ms
• Avec Cloudflare Durable Objects : ajouter 5-10ms pour le réveil du DO lors de la première requête

Latence WebRTC DataChannel (de navigateur à navigateur via TURN) :

• Même ville : 5-15ms
• Même continent : 20-50ms
• Entre continents : 100-250ms

La latence de WebTransport (HTTP/3 QUIC) est comparable à celle de WebSocket, mais sans blocage en tête de ligne. Sa latence P99 est donc nettement meilleure, sans interruption causée par la perte d’un seul paquet.

Mesures des temps de chargement

Scène Three.js vide (uniquement la bibliothèque) : 350ms jusqu’à la première image Scène Babylon.js vide : 500ms jusqu’à la première image Modèle GLB de 1 Mo via récupération + analyse : 200-400ms sur une connexion haut débit Texture KTX2, 1024x1024, Basis Universal : 50-100ms pour le décodage sur le GPU Maillage compressé avec Draco, 50 000 triangles : 30-80ms pour le décodage dans un Web Worker

Ces chiffres confirment que le budget de performances présenté dans la section consacrée à l’architecture est réalisable. Un ordinateur de bureau de milieu de gamme peut afficher une scène complexe en monde ouvert à 60fps. Les appareils mobiles constituent la principale contrainte : un LOD agressif et une distance d’affichage plus courte sont nécessaires pour maintenir 30fps sur les téléphones.

La pile technologique complète

En réunissant tous ces éléments, voici l’architecture d’un monde ouvert multijoueur de création fonctionnant dans un navigateur :

Client (navigateur)

Couche	Technologie	Rôle
Moteur de rendu	Babylon.js (WebGPU + repli vers WebGL2)	Rendu de la scène, terrain, LOD, post-traitement
Terrain	Système de carte de hauteur personnalisé + Babylon DynamicTerrain	Terrain diffusé par chunks avec texture splatting
Physique	Rapier (Wasm) ou Havok (via Babylon)	Contrôleur de personnage, collisions, lancer de rayons
ECS	bitECS	Gestion des entités pour tous les objets du monde
Réseau	WebSocket + WebRTC DataChannel	Synchronisation de l’état, mises à jour de position, chat vocal
État	Yjs (CRDT)	Modification collaborative du monde, résolution des conflits
Audio	Web Audio API	Audio spatial, ambiance, musique
Interface	Surcouche HTML/CSS	ATH, inventaire, chat, outils de création
Workers	Web Workers	Décompression des ressources, physique, génération du terrain

Serveur

Couche	Technologie	Rôle
Shards du monde	Cloudflare Durable Objects	État faisant autorité par chunk, points de terminaison WebSocket
Stockage des ressources	Cloudflare R2	Modèles GLB, textures KTX2, cartes de hauteur, audio
CDN des ressources	Cloudflare CDN (bucket R2 public)	Distribution des ressources du monde avec mise en cache en périphérie
Génération par IA	Instances GPU (Hetzner/Lambda/RunPod)	Génération de modèles 3D, de terrains et de textures
Pipeline de ressources	Cloudflare Queue + Workers	Génération des LOD, optimisation des maillages, conversion de formats
Authentification	Auth0	Identité et autorisations des créateurs
Base de données	Cloudflare D1	Métadonnées du monde, inventaires des créateurs, autorisations
Temps réel	Cloudflare Durable Objects + Pub/Sub	Présence des joueurs, chat, diffusion d’événements

Flux de données

1. Le joueur ouvre le monde dans son navigateur
2. Le client s’authentifie et se connecte au Durable Object le plus proche pour le chunk d’apparition
3. Le DO envoie l’état actuel du chunk (terrain + objets + joueurs à proximité)
4. Le client commence le rendu et demande les chunks adjacents à R2/CDN
5. À mesure que le joueur se déplace, le client se connecte aux DO adjacents et se déconnecte de ceux qui sont éloignés
6. Le créateur place un objet : le client envoie la modification au DO, qui la valide et la diffuse à tous les clients connectés sous forme de delta CRDT
7. Le DO enregistre l’état du chunk dans le stockage après chaque modification, avec temporisation
8. Les autres joueurs voient le nouvel objet apparaître dans un délai de 100 à 200ms

Budget de performances

Pour une expérience à 60fps sur un ordinateur de bureau de milieu de gamme (RTX 3060 / Mac M1 / 16 Go de RAM) :

Ressource	Budget	Remarques
Appels de rendu	< 500 par image	Regroupement, instanciation, LOD
Triangles	< 2 millions par image	Le LOD maintient cette valeur sous contrôle
Mémoire des textures	< 512 Mo	Compression KTX2, diffusion progressive, regroupement en atlas
Mémoire géométrique	< 256 Mo	Tampons partagés, regroupement, déchargement agressif
Tas JavaScript	< 512 Mo	L’ECS utilise des tableaux typés, pas des objets
Réseau	< 500 Ko/s en continu	Compression delta, filtrage selon la pertinence spatiale
Chargement initial	< 10 Mo, < 5 secondes	Chargement progressif, terrain en premier
Chargement d’un chunk	< 200 Ko, < 200ms	Préchargement des chunks adjacents

Les jeux sur navigateur à succès et ce qu’ils démontrent

Les jeux sur navigateur ne constituent pas un marché de niche. Ils représentent l’un des plus grands marchés du jeu vidéo. Poki accueille plus de 100 millions de joueurs par mois. CrazyGames, Newgrounds et itch.io en accueillent des millions d’autres. Les jeux qui réussissent dans un navigateur suivent des modèles architecturaux précis qu’il est utile d’étudier.

Jeux 3D sur navigateur disponibles aujourd’hui

Hordes.io : plus de 200 joueurs dans un MMO 3D persistant sur navigateur. WebGL personnalisé, style low poly, chargement en moins de 5 secondes. Créé par un seul développeur.

**Hordes.io** est le MMO sur navigateur le plus pertinent. Développé par une seule personne avec un moteur de rendu WebGL personnalisé, il réunit plus de 200 joueurs dans un monde 3D persistant avec des combats en temps réel, des guildes, des classes et du JcJ. L’ensemble du jeu se charge en moins de 5 secondes. Le monde est divisé en zones avec une élimination agressive des éléments hors champ. Les modèles de joueurs sont simples (low-poly avec ombrage plat), mais les effets de particules et les animations rendent les combats réactifs. Hordes.io prouve trois choses : les MMO sur navigateur peuvent gérer des centaines de joueurs simultanés dans une même scène, une seule personne peut en développer un, et les graphismes stylisés sont plus performants que les graphismes réalistes dans un navigateur.

Krunker.io : 10 millions de joueurs mensuels, développé avec Three.js, avec un éditeur de cartes complet intégré au navigateur et une place de marché de contenu généré par les utilisateurs.

Krunker.io a dépassé les 10 millions de joueurs mensuels à son apogée et a été racheté par FRVR. C’est un FPS sur navigateur doté d’un éditeur de cartes complet, de modes de jeu personnalisés, de contenu généré par les utilisateurs et d’une place de marché. Développé avec Three.js, il tourne à plus de 60 IPS même sur du matériel d’entrée de gamme grâce à son style graphique cubique et à une optimisation agressive. L’éditeur de niveaux est particulièrement pertinent. Les joueurs construisent des cartes à l’aide d’un système de blocs proche des voxels, les partagent sur la place de marché, puis d’autres joueurs les explorent. C’est la boucle de création de mondes en miniature : construire quelque chose, le partager et permettre à d’autres d’en faire l’expérience. Krunker a prouvé que le contenu 3D généré par les utilisateurs peut fonctionner dans un navigateur si les outils de création sont suffisamment simples.

ev.io est un FPS sur navigateur développé avec Babylon.js. Il fonctionne correctement sur la plupart des machines, prend en charge les cartes personnalisées et démontre que le moteur de rendu WebGL de Babylon peut gérer une action 3D rapide dans un onglet de navigateur. Le jeu utilise une compression agressive des textures et des environnements low-poly pour respecter ses budgets de performances.

Shell Shockers (plus de 5 millions de joueurs mensuels) est un jeu de tir multijoueur 3D dans lequel les joueurs incarnent des œufs. Développé avec Three.js, il gère le multijoueur en temps réel avec une détection des impacts réactive dans le navigateur. Son style graphique cartoon réduit au minimum les besoins en ressources tout en conservant un rendu soigné.

Townscaper : cliquez pour placer des bâtiments, et le système génère automatiquement les rues, les arches et les escaliers. Aucun menu, aucun objectif. Plus d’un million d’exemplaires vendus grâce au seul plaisir de créer.

Townscaper n’est pas un jeu sur navigateur, mais son approche de la construction de mondes est très pertinente. Les joueurs cliquent pour placer des bâtiments sur une étendue d’eau. Le jeu génère automatiquement des détails architecturaux, des rues, des arches et des escaliers en fonction des motifs de placement. Aucun menu, aucun réglage, aucun objectif. Il suffit de cliquer et de construire. Il s’est vendu à plus d’un million d’exemplaires. La leçon : les outils de création les plus simples produisent parfois les expériences les plus captivantes. Si nous parvenons à rendre le placement d’objets dans le monde aussi immédiat que dans Townscaper, les créateurs passeront des heures à construire.

Expériences A-Frame / 8th Wall. A-Frame (développé avec Three.js) alimente des milliers d’expériences 3D sur le Web. 8th Wall, la plateforme WebAR de longue date rachetée par Niantic, a démontré que des expériences de réalité augmentée complexes reposant sur la caméra peuvent fonctionner dans les navigateurs mobiles sans plug-in, bien que Niantic ait annoncé fin 2025 la fermeture progressive du service (les expériences hébergées resteront accessibles jusqu’en 2027). Ce ne sont pas des jeux, mais ces projets démontrent qu’un rendu 3D complexe avec physique et interactions fonctionne dans un onglet de navigateur sans plug-in. Beaucoup de ces expériences se chargent en 2 à 3 secondes et fonctionnent sur des téléphones de milieu de gamme.

Vuntra City : un laboratoire vivant de ville procédurale

Vuntra City est un projet UE5 natif, et non un jeu sur navigateur. Il ne constitue donc pas une référence directe pour mesurer les performances de notre stack. Il reste néanmoins l’une des études de cas publiques les plus utiles pour notre architecture de monde ouvert, car les journaux de développement décrivent avec une précision inhabituelle les compromis de conception des systèmes face aux contraintes réelles de production.

Un enseignement majeur concerne la gestion du niveau de détail en fonction de la vitesse. Dans les vidéos sur le transport et l’optimisation, les déplacements à grande vitesse sont transférés au-dessus des toits, tandis que le niveau de détail du monde diminue à mesure que la vitesse augmente afin que le gestionnaire de streaming ne soit pas saturé par le renouvellement des intérieurs (transport rapide, techniques d’optimisation). Cela correspond parfaitement à notre approche pour le navigateur, où la vitesse devrait contrôler directement le rayon de préchargement, la portée d’activation des intérieurs et le budget d’apparition par image.

Autre enseignement : la séparation stricte entre les données topologiques et les objets rendus. L’implémentation des cartes et des adresses utilise un contrôleur topologique global capable de répondre aux requêtes de localisation et d’adresse pour des régions non chargées (cartes et adresses). C’est exactement le modèle dont nous avons besoin pour le routage faisant autorité côté serveur, la recherche de points d’intérêt et les requêtes à l’échelle du monde, qui ne doivent pas dépendre de ce qu’un client donné conserve actuellement en mémoire.

Le travail sur les PNJ est également très pertinent. Le système à un million de PNJ calcule globalement un état approximatif des emplois du temps, puis ne simule les comportements coûteux que dans les espaces proches des joueurs (un million de PNJ persistants, dans les coulisses). Pour nous, cela confirme la pertinence d’un modèle de simulation à deux niveaux : un état déterministe peu coûteux pour les zones éloignées et des comportements riches à proximité, au sein de la zone d’intérêt.

Enfin, la conception des environnements de Vuntra City rappelle un point facile à oublier dans la planification technique : la conception de la distribution fait partie de la conception du contenu. Le projet évite le placement aléatoire uniforme, utilise des valeurs aberrantes pondérées pour créer des surprises et favorise la découverte à l’aide de cartes et d’adresses diégétiques plutôt qu’avec des marqueurs omniprésents sur une minicarte (les environnements procéduraux ne sont pas forcément ennuyeux, là où nous allons, nous n’aurons pas besoin de minicarte).

Les jeux sur navigateur devenus des phénomènes

Agar.io (2015) a prouvé que le multijoueur sur navigateur pouvait toucher des millions de personnes. À son apogée, il comptait plus de 100 000 joueurs simultanés répartis entre ses serveurs. Le jeu est en 2D et ses mécaniques sont simples (grandir en absorbant des cellules plus petites), mais son architecture réseau gère une concurrence massive grâce au partitionnement spatial. Chaque serveur gère une région du monde du jeu. Les joueurs ne reçoivent que les mises à jour concernant les entités présentes dans leur champ de vision. C’est le même modèle de gestion de l’intérêt que celui nécessaire à un monde ouvert 3D, mais appliqué à la 2D.

Slither.io s’est appuyé sur le succès d’Agar.io et a prouvé que le modèle pouvait passer à l’échelle. Il a atteint 67 millions d’utilisateurs actifs mensuels à son apogée. Le jeu utilise WebSocket pour synchroniser les positions en temps réel et le partitionnement spatial pour limiter le trafic réseau. Un détail mérite d’être relevé : la détection des collisions côté serveur de Slither.io fonctionne à une fréquence de tick plus faible pour les joueurs éloignés (5 Hz) que pour les joueurs proches (30 Hz). Cette fréquence de tick variable selon la distance est applicable à un monde ouvert 3D.

Surviv.io était un battle royale sur navigateur qui a atteint 50 millions de joueurs mensuels avant son rachat par Kongregate. Il faisait tourner dans le navigateur une partie complète de battle royale à 80 joueurs, avec une physique en réseau en temps réel, des environnements destructibles et le ramassage d’objets. La carte était agencée de façon procédurale à partir de modèles de bâtiments prédéfinis, un modèle que nous pourrions utiliser pour les structures placées par les créateurs.

Zombs Royale faisait fonctionner un battle royale à 100 joueurs dans le navigateur, avec des temps de chargement courts et un réseau réactif. Comme Surviv.io, il a prouvé que les jeux sur navigateur en temps réel accueillant un grand nombre de joueurs sont commercialement viables, et pas seulement techniquement possibles.

Le point commun de tous ces succès sur navigateur : ils se chargent rapidement (en moins de 5 secondes), fonctionnent sur n’importe quel appareil, adoptent un style graphique simple mais cohérent et disposent d’un réseau optimisé pour leur gameplay particulier (partitionnement spatial, fréquences de mise à jour variables et élimination agressive des états distants).

RuneScape : un MMO passé au navigateur

RuneScape : un MMO complet avec plus de 20 ans de contenu fonctionnant dans un onglet de navigateur. Protocole binaire personnalisé, streaming par tuiles, 2 000 joueurs simultanés par serveur. La preuve que les MMO sur navigateur fonctionnent à grande échelle.

RuneScape est l’étude de cas la plus importante pour un monde ouvert sur navigateur, car cette transition a réellement eu lieu. Jagex a transféré dans le navigateur un MMO entier contenant 20 ans de contenu.

À l’origine, RuneScape fonctionnait sous forme d’applet Java. Lorsque les navigateurs ont abandonné la prise en charge de Java, Jagex a réécrit le client en C++ et a également publié un client HTML5/WebGL entièrement fonctionnel. Old School RuneScape (la version rétro) fonctionne désormais entièrement dans le navigateur grâce à un client compilé en WebAssembly via Emscripten. Le jeu gère de vastes mondes persistants, un multijoueur en temps réel réunissant des centaines de joueurs par serveur, une économie avec un Grand Marché opérationnel (hôtel des ventes), ainsi que 23 compétences dotées de systèmes de progression approfondis.

Détails techniques importants :

• Le monde est divisé en carrés de carte (des régions de 64x64 tuiles). Le client charge autour du joueur une grille de régions de 13x13 (104x104 tuiles visibles). Les régions situées hors de cette grille sont entièrement éliminées du rendu.
• Le terrain repose sur des tuiles, avec une valeur de hauteur pour chaque coin de tuile. Les surcouches de terrain (chemins, rives, transitions vers les plages) utilisent un système de formes avec 12 variantes de rotation par forme. Ce système est plus contraint qu’une carte de hauteur, mais il est extrêmement compact et rapide à transmettre en streaming.
• Le protocole réseau est un format binaire personnalisé transmis via WebSocket. Chaque type de paquet possède une structure définie. Les mises à jour de position des joueurs utilisent 2 octets pour les coordonnées des carrés de carte et un encodage de longueur variable pour le type de déplacement. Les événements de discussion, d’échange et de combat disposent de leurs propres formats binaires compacts. L’ensemble du protocole est fortement optimisé pour réduire au minimum la bande passante.
• Le rendu des objets utilise un système de modèles dans lequel le serveur envoie un identifiant de modèle et le client affiche le modèle mis en cache. La plupart des modèles ne sont chargés qu’une fois, puis réutilisés. Le monde est donc transmis sous forme de métadonnées (quel modèle placer à quel endroit), plutôt que sous forme de géométrie.
• Chaque instance de serveur gère 2 000 joueurs simultanés dans l’ensemble du monde du jeu. Le monde n’est pas partitionné géographiquement entre plusieurs shards. Un seul processus serveur gère tous les joueurs, tous les PNJ et toute la logique du jeu selon un tick de 600 ms. Cela fonctionne parce que la logique de jeu reste simple à chaque tick : traiter les actions des joueurs, mettre à jour l’IA des PNJ, résoudre les combats et diffuser les changements d’état.

Ce que RuneScape prouve dans notre cas : Un MMO complet avec un état persistant du monde, des milliers de joueurs, des systèmes de jeu complexes et une économie réelle peut fonctionner dans un onglet de navigateur. Le client nécessite moins de 50 Mo de téléchargement, se charge en quelques secondes et fonctionne sur des ordinateurs portables. Si un MMO Java vieux de 20 ans peut réussir cette transition, un monde conçu dès le départ pour le navigateur rencontre encore moins de contraintes.

Les limites de l’approche de RuneScape pour notre projet : Le rendu de RuneScape utilise une vue isométrique avec caméra fixe, et non une 3D à la première ou à la troisième personne. Sa fidélité visuelle est faible selon les normes actuelles. De plus, le monde ne peut pas être modifié par les créateurs. Mais l’architecture réseau, le streaming par tuiles et la preuve que les MMO sur navigateur peuvent fidéliser des joueurs pendant des décennies sont directement pertinents.

Habbo Hotel : des espaces sociaux qui durent depuis 25 ans

Habbo Hotel a été lancé en 2000 et fonctionne toujours. C’est un monde social isométrique en 2D dans lequel les utilisateurs créent et décorent des pièces, visitent celles d’autres personnes et discutent. À son apogée, il comptait 9 millions d’utilisateurs mensuels. L’ensemble de l’expérience fonctionnait sous Flash (désormais en HTML5 depuis l’abandon de Flash).

Habbo est important en raison de la longévité de sa communauté de créateurs. Son système de pièces est en pratique une version 2D de ce que nous construisons : les utilisateurs placent des meubles sur une grille, personnalisent l’agencement et invitent d’autres personnes à venir leur rendre visite. Le modèle économique, dans lequel les utilisateurs achètent des meubles virtuels avec de l’argent réel, a généré plus d’un milliard de dollars de revenus depuis le lancement.

Les enseignements de Habbo :

• Des espaces organisés en pièces avec des intérieurs créés par les utilisateurs peuvent servir de plateforme sociale pendant des décennies si les outils de création sont simples et les fonctionnalités sociales robustes.
• Une économie de meubles virtuels favorise l’engagement à long terme. Les utilisateurs achètent, échangent et collectionnent des objets. Ceux-ci n’ont aucune utilité en matière de gameplay. Ils servent uniquement à l’expression personnelle et au statut social.
• La modération des espaces sociaux exige un investissement constant. Habbo a traversé plusieurs crises de modération. Le filtrage automatisé du contenu, associé à des modérateurs humains et à un système de signalement communautaire, constitue le strict minimum viable.
• La transition de Flash vers HTML5 (achevée vers 2020-2021) a prouvé qu’un vaste monde social pouvait changer de technologie de rendu sans perdre sa communauté. Les utilisateurs tiennent à leurs pièces et à leurs amis, pas à la technologie sous-jacente.

Among Us et les jeux sociaux spatialisés

Among Us n’est pas un monde ouvert, mais son succès a révélé un élément important au sujet des espaces multijoueurs : les joueurs veulent partager un même lieu, et pas seulement participer au même jeu. Les mods de discussion vocale spatialisée par proximité devenus viraux ont montré que le fait de se trouver dans la même pièce virtuelle avec un son directionnel transforme le multijoueur, qui cesse d’être une simple mécanique de jeu pour devenir une expérience sociale. Des fonctionnalités sociales spatiales qui enrichissent un monde de créateurs :

• Chat vocal de proximité dont le volume diminue avec la distance. Approchez-vous de quelqu’un pour lui parler. Éloignez-vous et sa voix s’atténue. Cela crée naturellement des groupes sociaux sans nécessiter de gérer des canaux vocaux.
• Systèmes d’émotes et de gestes permettant aux joueurs de s’exprimer sans utiliser leur voix. Un signe de la main, une danse, un geste pour montrer quelque chose. Ils sont peu coûteux à mettre en œuvre (des animations sur l’avatar du joueur) et augmentent considérablement l’engagement social.
• Activités partagées se déroulant dans le monde (et non par l’intermédiaire de menus), qui transforment un espace en lieu de rencontre. Si deux créateurs peuvent s’asseoir à une table virtuelle et examiner ensemble des modèles 3D, le monde a une raison d’exister au-delà de la simple présentation de contenu statique.

Les jeux par navigateur qui ont rencontré le succès sur Poki et CrazyGames

Poki et CrazyGames accueillent ensemble plus de 150 millions de joueurs par mois. Les jeux les plus performants sur ces plateformes donnent un aperçu de ce qui fonctionne spécifiquement dans un navigateur.

Caractéristiques récurrentes des jeux les plus performants sur les portails de jeux par navigateur :

• Lancement instantané (moins de 3 secondes avant de pouvoir interagir). Aucune connexion requise. Aucun tutoriel requis. Le jeu doit être compréhensible dans les 5 secondes suivant l’arrivée du joueur.
• Sessions flexibles. Les joueurs viennent pour 2 minutes ou 2 heures. Le jeu s’adapte aux deux cas. Pour un monde de créateurs, cela signifie que le monde doit pouvoir être exploré sans exiger un engagement sur toute une session. Se promener, découvrir des choses intéressantes, puis repartir. Ou rester et construire pendant des heures.
• Compatibilité mobile. Plus de 60 % du trafic de Poki provient des appareils mobiles. Un monde dans le navigateur qui ne fonctionne que sur ordinateur perd la majorité de ses visiteurs potentiels.
• Fonctionnalités sociales ne nécessitant pas d’amis. Classements, réactions au contenu des autres joueurs, fonctionnalités asynchrones (voir ce que d’autres joueurs ont construit sans être en ligne au même moment).

Les jeux 3D les plus populaires sur ces portails (comme Shell Shockers, 1v1.LOL et Smash Karts) utilisent peu de polygones, des textures simples et une fréquence d’images élevée. Ils prouvent que les joueurs acceptent des graphismes simples si l’expérience est fluide et réactive.

Plateformes de création dans le navigateur

Hubs par Mozilla (désormais maintenu par la communauté). Des espaces 3D multi-utilisateurs dans le navigateur, construits avec Three.js et A-Frame. La plateforme prend en charge le chat vocal, les avatars et les objets partagés. Ce n’est pas un monde ouvert (elle repose sur des salles), mais son architecture réseau et de rendu est pertinente. Mozilla l’a publiée en open source avant de fermer le service hébergé, de sorte que l’intégralité du code source peut être étudiée. GitHub.

Hyperfy. Une plateforme de métavers web fonctionnant entièrement dans le navigateur. Rendu Three.js, multijoueur, personnalisation des avatars et construction de mondes. Elle est plus proche de notre objectif que Hubs, car elle met l’accent sur les outils de création. Les mondes se chargent dans un onglet du navigateur sans nécessiter de téléchargement. hyperfy.io.

Ethereal Engine (anciennement XREngine). Un moteur open source pour les mondes multi-utilisateurs, construit avec Three.js et bitECS. Il prend en charge WebXR, l’audio spatial et l’édition de mondes. Il intègre une architecture ECS, une couche réseau et des outils d’édition. C’est le projet open source existant qui se rapproche le plus de ce que nous décrivons. Il mérite d’être étudié pour comprendre comment bitECS est intégré à Three.js afin de gérer les entités, ainsi que la manière dont son système réseau gère l’état spatial. GitHub.

Dusk (anciennement Rune). Un SDK de jeux multijoueurs pour les jeux web. Il prend en charge la couche réseau afin que les développeurs puissent se concentrer sur le gameplay. Son approche de synchronisation utilise un état prédit avec réconciliation par le serveur, le modèle standard pour obtenir un multijoueur réactif. Le SDK masque la complexité du netcode avec retour en arrière. Il mérite d’être étudié pour la qualité de son expérience développeur.

Niantic Studio. Un éditeur visuel dans le navigateur et un moteur de jeux web (successeur des outils de 8th Wall) permettant de créer des expériences 3D et XR que d’autres peuvent visiter dans leur navigateur. Il démontre que des créateurs sans compétences techniques peuvent construire des scènes 3D dans un navigateur si les outils sont accessibles. (Niantic a séparé ses activités géospatiales au sein de Niantic Spatial et vendu en 2025 sa division de jeux, dont Pokémon GO, à Scopely.)

PlayCanvas Editor. Ce n’est pas un jeu en soi, mais l’éditeur 3D de PlayCanvas dans le cloud démontre que des outils collaboratifs de construction de mondes peuvent fonctionner dans un navigateur. Plusieurs membres d’une équipe modifient simultanément la même scène. L’éditeur communique les changements par l’intermédiaire d’une couche de synchronisation en temps réel. C’est le modèle de création collaborative dont nous aurions besoin, à ceci près que notre monde servirait de canevas à la place d’un éditeur de jeux.

Plateformes de création natives (enseignements pour le navigateur)

Ces plateformes fonctionnent comme des applications natives, mais leurs choix de conception en matière d’outils de création, de persistance des mondes et de dynamiques sociales sont directement applicables.

Roblox : plus de 80 millions d’utilisateurs quotidiens, 740 millions de dollars versés aux créateurs en 2023. La création s’effectue dans le moteur. La découverte est sociale. Un modèle économique qui prouve que les plateformes de création peuvent être viables.

Roblox est la référence la plus importante pour un monde de créateurs. Plus de 80 millions d’utilisateurs actifs quotidiens. Les créateurs construisent des expériences 3D complètes (jeux, espaces sociaux, boutiques) que d’autres joueurs visitent. La plateforme prend en charge l’hébergement, le réseau, la découverte et la monétisation.

Ce que Roblox réussit :

• La création s’effectue dans le moteur. Roblox Studio est le même environnement que celui dont font l’expérience les joueurs. Les créateurs testent immédiatement leur travail. Il n’existe aucun cycle d’exportation, de téléversement et d’attente. Pour un monde dans le navigateur, l’éditeur devrait être le monde lui-même.
• La programmation est accessible. Lua (le langage de script de Roblox) est suffisamment simple pour que des enfants puissent l’apprendre. Des comportements complexes sont possibles, mais facultatifs. Le seuil d’entrée est bas et les possibilités sont vastes.
• La découverte est sociale. Vous trouvez des expériences parce que vos amis y jouent. La page d’accueil présente les expériences populaires. Pour un monde dans le navigateur, le monde lui-même constitue l’espace de découverte. Vous l’explorez et trouvez des choses en vous promenant.
• La monétisation fonctionne. Les créateurs gagnent de l’argent réel (Roblox leur a versé 740 millions de dollars en 2023). Cela attire des efforts créatifs sérieux. Sans incitation économique, les plateformes de création deviennent des projets amateurs qui finissent par disparaître.
• Le moteur de rendu de Roblox est propriétaire et fonctionne dans une application native, pas dans un navigateur. Toutefois, les budgets d’assets par expérience restent modestes selon les normes actuelles (100 Mo maximum recommandés). La plupart des expériences Roblox à succès utilisent une direction artistique stylisée en low poly, ce qui correspond aux contraintes de rendu dans un navigateur.

Fortnite Creative / UEFN (Unreal Editor for Fortnite). Epic a mis l’éditeur complet d’Unreal Engine à la disposition des créateurs de Fortnite. Il en résulte une plateforme où chacun peut construire des îles (des mondes autonomes) à l’aide d’outils de qualité professionnelle. Fortnite prend en charge l’hébergement, le multijoueur et la distribution.

Enseignements pertinents :

• Les outils professionnels attirent du contenu professionnel. UEFN produit des expériences visuellement impressionnantes parce que les créateurs ont accès à toutes les fonctionnalités d’UE5. La contrepartie est la complexité. La courbe d’apprentissage d’UEFN est raide.
• L’instanciation par îles (chaque création constitue un monde distinct) évite les problèmes de modération et de conflits propres à un monde partagé unique. Mais elle signifie aussi que les créateurs ne découvrent pas naturellement le travail des autres en explorant. On visite les îles par l’intermédiaire de menus, pas en se promenant.
• Le modèle économique fonctionne. Le programme de création de Fortnite rémunère en fonction de l’engagement. Les meilleurs créateurs gagnent des millions par an. Là encore, l’incitation économique favorise la qualité.

Dreams (Media Molecule / PlayStation). Dreams a offert aux joueurs sur console une suite complète de création 3D (modélisation, animation, musique, logique, conception de niveaux) ainsi qu’une plateforme pour partager leurs créations. En matière de profondeur des outils, c’est la plateforme de création la plus ambitieuse jamais conçue.

Enseignements pertinents :

• Modélisation par sculpture plutôt que par édition de polygones. Les créateurs façonnent des volumes souples avec des outils de déplacement, de saisie et de lissage, à la manière de ZBrush, mais de façon plus intuitive. La courbe d’apprentissage est progressive. Cette approche se prête bien à la création dans le navigateur, car elle ne nécessite pas de comprendre les sommets et les cartes UV.
• Chaque élément est un asset partagé. Si quelqu’un crée un modèle d’arbre, n’importe qui peut l’utiliser dans sa propre création (avec attribution). Cela crée un écosystème créatif cumulatif dans lequel chaque création augmente la valeur de la plateforme.
• Dreams a connu des difficultés commerciales malgré l’enthousiasme de la critique. Le problème venait de la distribution : il était limité à PlayStation, et les outils de création étaient si poussés que la plupart des joueurs ne dépassaient jamais le stade de la consommation de contenu. La leçon : les outils de création doivent être suffisamment simples pour que la majorité des utilisateurs les essaient, même si seule une minorité devient réellement bâtisseuse.

Core (Manticore Games). Une plateforme gratuite permettant de créer et de jouer à des jeux multijoueurs, construite avec Unreal Engine et dotée d’un éditeur simplifié. L’éditeur de Core fonctionne comme une application native, mais sa philosophie est pertinente. Des modèles et des scripts partagés par la communauté permettent aux débutants d’assembler des jeux à partir de composants préfabriqués. Les créateurs expérimentés peuvent écrire des scripts Lua afin de concevoir des comportements personnalisés. Core a eu du mal à attirer un large public, en partie parce qu’il fallait passer par son lanceur pour jouer. Une version dans le navigateur n’aurait pas cette friction.

VRChat et Rec Room sont des plateformes sociales dans lesquelles les créateurs construisent des espaces que d’autres visitent. VRChat utilise Unity et fonctionne sur PC et en VR. Rec Room fonctionne partout, y compris sur mobile. Les deux prouvent que les mondes 3D générés par les utilisateurs peuvent entretenir de grandes communautés. VRChat est plus impressionnant techniquement (shaders personnalisés, avatars complexes). Rec Room est plus accessible (outils de création intégrés à l’application, graphismes plus simples, prise en charge d’un plus grand nombre de plateformes). Pour un monde dans le navigateur, l’approche de Rec Room fondée sur des outils de création simples et intégrés à l’application est plus pertinente que le workflow de VRChat reposant sur des outils externes.

Second Life : lancé en 2003, toujours actif avec plus de 200 000 utilisateurs quotidiens. Entièrement créé par les utilisateurs. Propriété fondée sur des parcelles, économie virtuelle représentant environ 500 millions de dollars par an. 20 ans d’enseignements sur la persistance et la modération.

Second Life est l’ancêtre de tous les mondes de créateurs. Lancé en 2003, il fonctionne toujours et compte plus de 200 000 utilisateurs actifs quotidiens. Le monde entier est créé par les utilisateurs. Les terrains sont possédés et échangés. Les créateurs vendent des objets, des vêtements et des bâtiments. Le langage de script intégré au monde (LSL) permet de créer du contenu interactif.

Ce que Second Life nous enseigne après plus de 20 ans :

• La persistance compte davantage que les graphismes. Les visuels de Second Life sont datés, mais le monde persiste. Les créations restent là où vous les placez. Les relations et l’histoire s’accumulent. C’est cette persistance qui incite les gens à revenir.
• L’économie stimule la création. Le PIB de Second Life est estimé à 500 millions de dollars par an. Les créateurs construisent parce qu’ils peuvent vendre. Sans incitation économique, le volume et la qualité du contenu créé par les utilisateurs diminuent.
• Le contenu généré par les utilisateurs nécessite une infrastructure de modération. Second Life fait face à des problèmes de modération depuis 20 ans. Toute plateforme où les utilisateurs peuvent placer du contenu arbitraire dans un espace partagé a besoin d’analyses automatisées, d’outils de signalement et d’une vérification humaine.
• L’organisation spatiale fondée sur des terrains fonctionne. Second Life divise son monde en parcelles appartenant aux utilisateurs. Chaque parcelle dispose d’une limite de primitives (objets). Cela empêche naturellement un créateur unique de consommer toutes les ressources. Pour un monde dans le navigateur, le modèle équivalent serait une propriété fondée sur des chunks, avec un budget d’objets par chunk.

Analyse comparative : ce que chaque jeu nous enseigne

Jeu	Leçon clé	Technologies applicables	Risque si elle est ignorée
Skyrim	Streaming par chunks avec une grille de cellules	Terrain par heightmap, niveaux de LOD, séparation des intérieurs et des extérieurs	Le monde ne tient pas dans la mémoire du navigateur
The Witcher 3	Composition du monde en couches par des équipes distinctes	Streaming sensible au contenu, rendu par imposteurs	Les créateurs ne peuvent pas travailler indépendamment
Breath of the Wild	Les règles systémiques surpassent le contenu scripté	Système d’interaction entre matériaux, gameplay fondé sur la physique	Le monde paraît statique et sans vie
GTA V	La vie ambiante rend les mondes crédibles	Systèmes de comportement des PNJ, circulation, cycle horaire	Le monde du créateur ressemble à un musée vide
Elden Ring	Variation de la densité et réutilisation des ressources	Bibliothèque de ressources modulaires, zones clairsemées et denses	Le monde est soit trop vide, soit trop coûteux à remplir
No Man's Sky	La génération procédurale pour la toile, le contenu des créateurs pour l’âme	Terrain fondé sur une graine, modèle de données compact pour les bases	Un terrain infini, mais ennuyeux
Minecraft	Monde entièrement modifiable, outils simples, profondeur infinie	Streaming par chunks, compression par palette, protocole de modification des blocs	Les créateurs ne peuvent pas remodeler le monde lui-même
Roblox	La création se fait dans le moteur, l’économie stimule la qualité	Éditeur intégré au monde, monétisation des créateurs	Personne ne construit faute de motivation
Krunker.io	Le contenu généré par les utilisateurs fonctionne à grande échelle dans le navigateur avec des outils simples	Rendu Three.js, éditeur à base de voxels, place de marché	Les outils de création sont trop complexes pour les créateurs occasionnels
Hordes.io	Plus de 200 joueurs en 3D dans le navigateur, projet viable pour un développeur solo	WebGL personnalisé, culling spatial, direction artistique stylisée	Surdimensionnement de la couche multijoueur
Vuntra City (référence native)	Un streaming adapté à la vitesse et une simulation du monde à deux niveaux assurent la cohérence d’une immense ville procédurale	Politique de LOD liée à la vélocité, couche de requêtes topologiques, simulation planifiée à longue distance et comportements à courte distance	Les déplacements à grande vitesse provoquent des apparitions soudaines et des pics de simulation
Agar.io / Slither.io	Le partitionnement spatial permet une concurrence massive	Fréquence de tick variable selon la distance, gestion des zones d’intérêt	Le réseau s’effondre à grande échelle
Second Life	La persistance et l’économie entretiennent des communautés pendant 20 ans	Propriété par parcelles, budgets d’objets, place de marché	Aucune rétention à long terme
Dreams	La création par sculpture est plus intuitive que l’édition polygonale	Modélisation volumique, bibliothèque de ressources partagée	Les outils de création ressemblent à un logiciel de CAO
Fortnite Creative	Les outils professionnels attirent du contenu professionnel	Capacités complètes d’un éditeur au sein de la plateforme	Le plafond de qualité du contenu est trop bas
RuneScape	Un MMO complet fonctionne dans le navigateur grâce à Wasm et aux protocoles binaires	Emscripten, protocole WebSocket binaire personnalisé, streaming par tuiles	Sous-estimation des capacités des navigateurs
Habbo Hotel	La création simple de pièces entretient une communauté depuis 25 ans	Placement sur grille, économie de mobilier virtuel	Complexification excessive des outils de création

Les jeux qui comptent le plus pour notre cas précis — un projet multijoueur dans le navigateur centré sur les créateurs — sont Minecraft pour son monde modifiable et ses données compactes, Roblox pour sa création intégrée au moteur et son économie, Krunker pour son contenu généré par les utilisateurs à grande échelle dans le navigateur, et Hordes.io pour son architecture de MMO jouable dans un navigateur. Les titres AAA comme Skyrim, BotW et The Witcher 3 nous enseignent le rendu et le streaming. Les succès sur navigateur comme Agar.io, Slither.io et Surviv.io nous enseignent la mise à l’échelle du réseau. Les plateformes de création comme Roblox, Dreams et Second Life nous enseignent les dynamiques communautaires. Vuntra City apporte en outre une référence actuelle, au niveau de l’implémentation, pour le streaming adapté à la vitesse, la navigation diégétique et les modèles de simulation de millions d’agents dans une ville procédurale moderne.

À quoi ressembleraient Skyrim et The Witcher dans un navigateur

Prenons un exemple concret. Si vous reconstruisiez Blancherive, dans Skyrim, pour une diffusion par navigateur :

Terrain : La région autour de Blancherive mesure environ 2 km sur 2 km. Avec des chunks de 64 m, cela représente environ 32 x 32 = 1 024 chunks. À raison de 2 à 4 Ko par heightmap de chunk, cela donne 2 à 4 Mo de données de terrain. Les textures du terrain — herbe, terre, roche et neige — sous forme de tuiles d’atlas KTX2 pourraient ajouter 5 Mo. Total pour le terrain : moins de 10 Mo pour toute la région.

Structures : Blancherive compte peut-être 40 à 50 bâtiments. Chaque bâtiment, sous forme de GLB optimisé avec 3 niveaux de LOD, pourrait peser entre 200 et 500 Ko au niveau de détail maximal. Mais vous n’avez besoin du niveau de détail maximal que pour les 5 à 10 bâtiments les plus proches. Les autres utilisent un LOD moyen ou faible, à raison de 50 à 100 Ko chacun. Total des structures visibles à un instant donné : 2 à 5 Mo.

Végétation : Les arbres et l’herbe autour de Blancherive sont tous instanciés. Il suffit peut-être de 10 modèles d’arbres uniques — 200 Ko chacun au LOD maximal et 20 Ko sous forme d’imposteurs billboard — ainsi que d’un système d’herbe qui génère les brins sur le GPU à partir d’une carte de densité. Total des ressources de végétation : 2 à 3 Mo. Données d’instanciation — positions, rotations et échelles — pour une zone de 5 x 5 chunks : moins de 500 Ko.

PNJ : Blancherive compte environ 70 PNJ nommés, auxquels s’ajoutent les gardes. Chaque avatar de qualité moyenne pèse entre 100 et 200 Ko. Mais seuls 10 à 20 d’entre eux sont visibles à un instant donné. Total des données de rendu des PNJ : 2 à 4 Mo.

Total général pour une zone de la taille de Blancherive visible à un instant donné : 15 à 25 Mo. C’est tout à fait viable dans un navigateur. Le chargement initial afficherait le terrain et les structures principales en 3 à 5 secondes sur une connexion haut débit, puis les détails apparaîtraient progressivement au cours des secondes suivantes.

Novigrad, dans The Witcher 3, est plus grande et plus dense, mais les mêmes principes s’appliquent. Il faudrait un LOD et un streaming plus agressifs, mais le volume total de données visibles à un instant donné resterait dans les limites de mémoire du navigateur.

Ce que nous construirions en premier

Un monde ouvert complet est un projet de plusieurs années. Voici comment mettre rapidement quelque chose de concret entre les mains des créateurs :

Phase 1 : île partagée (3 mois). Un seul chunk de terrain — une île de 512 x 512 m — avec terrain par heightmap, eau, végétation de base et cycle jour/nuit. Multijoueur via Durable Objects, jusqu’à 50 utilisateurs simultanés. Les créateurs peuvent placer des ressources 3D générées par IA issues de leur bibliothèque Cinevva existante. Imaginez un diorama partagé.

Phase 2 : monde extensible (3 mois). Streaming par chunks pour un monde de 4 x 4 km. Parcelles appartenant aux créateurs et sur lesquelles ils disposent de droits de modification. Système de LOD pour le terrain et les objets. État persistant du monde. Jusqu’à 200 utilisateurs simultanés répartis dans le monde.

Phase 3 : monde vivant (6 mois). Sculpture du terrain assistée par IA. Végétation et atmosphère procédurales. Système de quêtes et d’événements permettant aux créateurs de concevoir des expériences interactives plutôt que de simples scènes statiques. Chat vocal. Personnalisation des avatars. Le monde devient une destination, et non plus une démonstration.

Questions ouvertes

Direction artistique. Un style stylisé — low-poly ou cel-shading — est moins coûteux à rendre et tolère mieux les ressources générées par IA. Un style réaliste exige des ressources de meilleure qualité et un budget de rendu supérieur. Skyrim fonctionnait malgré des graphismes vieillissants parce que sa direction artistique était cohérente. BotW est magnifique sur un matériel de classe tablette, car son style cel-shading masque le faible nombre de polygones. Minecraft utilise des textures de 16 x 16 et reste l’un des jeux les plus reconnaissables jamais créés. Krunker.io et Hordes.io réussissent tous deux dans le navigateur avec des graphismes stylisés simples. Les éléments disponibles favorisent très nettement une direction stylisée pour un monde dans le navigateur. Nous devons choisir tôt une identité visuelle précise et imposer sa cohérence à toutes les ressources générées par IA.

Persistance du monde ou instances. Tout le monde partage-t-il un même monde, comme dans un MMO ou Second Life, ou chaque créateur dispose-t-il de sa propre instance que les autres peuvent visiter, comme les serveurs Minecraft ou les îles Fortnite ? La technologie prend en charge les deux modèles, mais leurs dynamiques sociales sont complètement différentes. Le monde partagé persistant de Second Life favorise les découvertes fortuites : on tombe sur le travail d’autres personnes simplement en se promenant. Les îles instanciées de Fortnite nécessitent un menu ou un système de portails pour être découvertes. Roblox utilise une approche fondée sur un hub : les jeux sont séparés, mais une interface commune permet de les parcourir et de les découvrir. Un modèle hybride pourrait fonctionner : un monde extérieur partagé et persistant dans lequel les créateurs possèdent des parcelles, comme dans Second Life, avec la possibilité d’accéder à des expériences autonomes par des portails.

Profondeur des outils de création. Dreams a prouvé que des outils de création approfondis impressionnent les critiques, mais intimident les utilisateurs. Townscaper a prouvé que des outils minimaux peuvent se vendre à un million d’exemplaires. Roblox Studio occupe une position intermédiaire : assez simple pour les enfants, assez riche pour les professionnels. L’éditeur de voxels de Krunker est encore plus simple. Pour un monde dans le navigateur, nous devrions commencer par une simplicité comparable à celle de Townscaper — placer des objets qui s’alignent et se connectent automatiquement — puis enrichir progressivement les outils. Le placement du tout premier objet dans le monde devrait prendre moins de 30 secondes.

Économie. Roblox, Second Life et Fortnite Creative prouvent tous qu’une incitation économique transforme un jouet en plateforme. Sans moyen de tirer des revenus de leur travail, les créateurs les plus talentueux construiront ailleurs. Il n’est pas nécessaire de lancer cette fonction dès le premier jour, mais l’architecture doit la prendre en charge : propriété des objets, suivi des visites et attribution aux créateurs.

Mobile. Il faudra encore des années avant que WebGPU soit fiable sur mobile. Une expérience mobile devrait être une version allégée : terrain plus simple, moins d’objets et distance d’affichage plus courte. L’approche de Rec Room, qui fonctionne partout grâce à une qualité adaptative, mérite d’être étudiée. Autre possibilité : proposer une application native sur mobile et conserver l’expérience complète dans le navigateur.

Modération. Un monde ouvert dans lequel n’importe qui peut placer n’importe quoi est un cauchemar de modération. Second Life y fait face depuis 20 ans. Chaque ressource placée doit faire l’objet d’un contrôle automatisé du contenu avant de devenir visible par les autres. Cela ajoute de la latence au processus créatif, mais c’est non négociable. Nous devrions également envisager des classifications de contenu par parcelle, comme le système Général/Modéré/Adulte de Second Life, afin que les créateurs puissent définir les limites de leur contenu.

Interactions systémiques. BotW et Minecraft montrent tous deux que les systèmes d’interaction fondés sur les matériaux créent des mondes exponentiellement plus intéressants que le simple placement d’objets statiques. Si un créateur place un pont en bois et qu’un autre allume un feu à proximité, le pont doit-il brûler ? Si quelqu’un construit un barrage, l’eau doit-elle s’accumuler derrière ? Ces interactions donnent vie au monde, mais exigent des règles cohérentes de physique et de matériaux pour tout le contenu des créateurs. Déterminer jusqu’où aller dans la conception systémique constitue une décision architecturale précoce.

Points clés à retenir

Les mondes ouverts 3D dans le navigateur sont viables dès aujourd’hui. Hordes.io accueille plus de 200 joueurs en 3D dans un navigateur. Krunker.io a atteint 10 millions de joueurs mensuels avec un éditeur complet de cartes 3D. Les jeux .io ont prouvé que le multijoueur dans le navigateur pouvait passer à l’échelle de millions d’utilisateurs. La technologie n’a rien de spéculatif.

Le rendu est prêt. Three.js et Babylon.js gèrent des scènes 3D comparables aux jeux AAA du début des années 2010. WebGPU donne accès aux compute shaders pour le terrain et la végétation. Les moteurs physiques Wasm s’exécutent à une vitesse comprise dans un facteur de 2 à 3 par rapport au natif. Une zone de la taille de Blancherive tient dans 15 à 25 Mo de données visibles.

Le réseau est prêt. Cloudflare Durable Objects fournit des serveurs autoritaires par chunk en périphérie du réseau. Les CRDT gèrent l’édition collaborative sans conflits. Le partitionnement spatial — éprouvé par tous les jeux, d’Agar.io à Skyrim — maintient le trafic réseau à un niveau gérable avec des centaines de joueurs simultanés.

Les mondes ouverts AAA — Skyrim, The Witcher 3, BotW, Elden Ring, Minecraft et No Man's Sky — ne sont pas seulement des références graphiques. Ce sont des manuels consacrés au streaming par chunks, à la gestion du LOD, à la génération procédurale, à la conception systémique et à la composition des mondes. Chaque technique qu’ils emploient possède un équivalent compatible avec les navigateurs.

Les plateformes de création — Roblox, Second Life, Fortnite Creative et Dreams — enseignent les leçons sociales et économiques. La création doit se faire dans le monde, et non dans un outil externe. Les incitations économiques stimulent la qualité. La persistance crée de l’attachement. Les outils simples touchent davantage de créateurs que les outils puissants.

C’est dans le pipeline créatif que Cinevva possède un avantage. Nous générons déjà des ressources 3D, des textures et de l’audio. Il ne manque plus qu’à connecter ce pipeline à un système de placement dans le monde. Le contenu généré par IA remplit le monde. La sélection et l’agencement par les créateurs lui donnent une âme.

Le résultat ne serait pas Skyrim dans un navigateur. Il se situerait plutôt à l’intersection de Minecraft pour son monde modifiable, de Roblox pour son économie des créateurs et de BotW pour ses interactions systémiques, le tout dans un onglet de navigateur avec des outils de création propulsés par l’IA. La technologie nécessaire existe. La question est celle de l’exécution.

Articles de recherche et références universitaires

Les techniques présentées dans ce guide ne sont pas inventées de toutes pièces. Elles reposent sur des décennies de recherche. Voici les publications les plus importantes pour chaque sous-système, accompagnées d’indications sur leur application à un monde ouvert dans le navigateur.

Génération et rendu du terrain

« Un synthétiseur d’images » -- Ken Perlin (SIGGRAPH 1985). DOI. L’article qui a introduit le bruit de Perlin. Tous les générateurs procéduraux de terrain de tous les jeux créés depuis 1985 en sont issus. La fonction de bruit produit un aléatoire lisse qui, une fois superposé en octaves — mouvement brownien fractionnaire — génère des heightmaps d’aspect naturel. Le bruit simplex, présenté par Perlin en 2001, en est le successeur plus rapide. C’est le fondement de notre pipeline de terrain : la génération de heightmaps fondée sur le bruit s’exécute à une vitesse interactive dans un compute shader WebGPU.

« Texturation et modélisation : une approche procédurale » -- Ebert, Musgrave, Peachey, Perlin, Worley (1994, 3e édition 2003). Le manuel de référence sur la génération procédurale. Les chapitres de Musgrave sur la modélisation du terrain, notamment les terrains multifractals présentant des caractéristiques semblables à celles de l’érosion, constituent le fondement direct des générateurs de terrain modernes. Les paramètres fBm décrits ici — lacunarité, persistance et nombre d’octaves — sont les mêmes que ceux que nous proposerions aux créateurs pour personnaliser le terrain.

« Clipmaps géométriques : rendu du terrain à l’aide de grilles régulières imbriquées » -- Losasso and Hoppe (SIGGRAPH 2004). DOI. Cet article a résolu le problème du rendu interactif de terrains immenses grâce à des anneaux concentriques de LOD, ou clipmaps. Le maillage du terrain est un ensemble fixe de grilles imbriquées centrées sur la caméra. Lorsque la caméra se déplace, les grilles se décalent et se mettent à jour. C’est la technique recommandée dans notre section consacrée au terrain pour WebGL 2, et elle fonctionne parce que la charge du GPU reste constante quelle que soit la taille du monde. L’implémentation d’origine est antérieure à WebGL, mais s’y transpose directement. « Simulation et visualisation rapides de l’érosion hydraulique sur GPU » — Mei, Decaudin, Hu (2007). PDF. Cette méthode a fait passer l’érosion hydraulique d’un processus hors ligne limité par le CPU à un calcul en temps réel sur GPU. Le modèle de simulation en eaux peu profondes de l’article — qui traite l’eau comme un champ de hauteur et calcule l’écoulement entre les cellules d’une grille — s’exécute dans un shader de calcul. Pour notre pipeline, l’érosion sur GPU côté serveur peut transformer un terrain généré par bruit en paysages géologiquement plausibles en moins d’une seconde, donnant aux terrains générés par IA l’apparence d’avoir été sculptés à la main.

« Rendu en temps réel de planètes générées procéduralement » — Approches hybrides issues des conférences GDC sur No Man’s Sky et des descriptions de Sean Murray. Sans être un article unique, la conférence GDC 2017 « Building Worlds Using Maths » d’Innes McKendrick (Hello Games) explique comment No Man’s Sky génère des terrains à l’échelle planétaire à l’aide de fonctions de bruit superposées, d’une représentation voxel avec marching cubes et d’une génération côté GPU. Cette approche est directement pertinente pour notre méthode de génération procédurale de terrains, en particulier pour créer des formations impossibles à représenter avec des cartes de hauteur, comme les grottes et les arches.

« C-DBLOD : LOD hybride pour le rendu de terrains » — Filip Strugar (2014). Article. Une amélioration des clipmaps géométriques qui ajoute une sélection fondée sur un quadtree afin de mieux s’adapter à la position de la caméra. L’idée clé consiste à utiliser un quadtree pour sélectionner des parcelles de terrain à différentes résolutions plutôt que des anneaux concentriques fixes. Cette technique gère mieux que les clipmaps purs les terrains irréguliers, où certaines zones exigent davantage de détails que d’autres. Elle peut être mise en œuvre dans WebGL 2 avec un parcours léger du quadtree côté CPU.

Splatting gaussien 3D et rendu neuronal

« Splatting gaussien 3D pour le rendu en temps réel de champs de radiance » — Kerbl, Kopanas, Leimkühler, Drettakis (SIGGRAPH 2023). Page du projet. L’article à l’origine de la révolution du splatting gaussien. Une scène est représentée par des millions de gaussiennes 3D, chacune possédant une position, une covariance (forme), une opacité et des coefficients de couleur en harmoniques sphériques. Le rendu trie les splats selon leur profondeur et les rastérise sous forme de gaussiennes 2D. L’approche s’entraîne 100 à 1 000 fois plus vite que les NeRF et produit un rendu en temps réel. Plusieurs implémentations WebGL et WebGPU existent. Sur notre plateforme, cette technique permet aux créateurs de capturer des objets réels à partir de photos prises avec leur téléphone, puis de les placer dans le monde accessible depuis le navigateur.

« NeRF : représentation de scènes sous forme de champs de radiance neuronaux pour la synthèse de vues » — Mildenhall et al. (ECCV 2020). Page du projet. L’article fondateur sur la représentation neuronale des scènes. Un réseau neuronal associe des coordonnées 3D à une couleur et à une densité, permettant de synthétiser de nouvelles vues photoréalistes à partir d’un ensemble de photographies d’entrée. Bien que les NeRF soient trop coûteux pour être rendus directement dans un navigateur — ils nécessitent une évaluation du réseau pour chaque pixel —, le pipeline d’extraction de maillage depuis un NeRF, qui consiste à entraîner un NeRF puis à exécuter marching cubes sur le champ de densité, produit à partir de photos des maillages texturés de grande qualité.

« Primitives graphiques neuronales instantanées avec encodage par table de hachage multirésolution » — Müller, Evans, Schied, Keller (SIGGRAPH 2022). Page du projet. Cette méthode a réduit la durée d’entraînement des NeRF de plusieurs heures à quelques secondes grâce à une table de hachage multirésolution servant à l’encodage spatial. Elle a rendu les NeRF utilisables en production. La technique d’encodage par hachage peut également s’appliquer à d’autres données spatiales dans un monde accessible depuis le navigateur, notamment pour effectuer des recherches rapides dans de grands jeux de données 3D.

« Neuralangelo : reconstruction neuronale de surfaces en haute fidélité » — Li et al. (CVPR 2023). Page du projet. Cette méthode extrait des maillages triangulaires de grande qualité à partir de représentations neuronales en utilisant un encodage par hachage multirésolution et des gradients numériques pour estimer une SDF (fonction de distance signée). Les maillages produits sont directement utilisables dans les moteurs 3D pour navigateur. Pour notre pipeline de ressources, Neuralangelo — ou des outils similaires comme NeuS2 — peut convertir des captures NeRF en fichiers GLB optimisés pour le Web, avec une géométrie propre et des textures précalculées.

Réseau multijoueur et synchronisation d’état

« Gestion des zones d’intérêt dans les jeux en ligne massivement multijoueurs » — Boulanger, Kienzle, Verbrugge (2006). DOI. Une étude exhaustive des techniques de gestion des zones d’intérêt (AOI) pour les MMO. Elle couvre les approches fondées sur une grille, sur une zone d’influence et les approches hybrides permettant de filtrer les mises à jour réseau selon leur pertinence spatiale. L’approche par grille, qui correspond à notre système de chunks, est la plus efficace dans les mondes à densité uniforme. L’approche par zone d’influence, avec un rayon propre à chaque entité, convient mieux aux densités variables. Notre recommandation d’une AOI fondée sur les chunks, avec des fréquences de mise à jour définies par priorité au sein de l’AOI, s’appuie sur ces recherches.

« Navigation à l’estime : masquer la latence dans les jeux en réseau » — Pantel et Wolf (2002). DOI. Cet article formalise la navigation à l’estime, qui consiste à prédire la position des entités à partir de leur dernière vitesse connue, pour les jeux en réseau. Il quantifie le compromis : des seuils de prédiction plus élevés réduisent la bande passante, mais augmentent l’erreur de position visible lors des corrections. Pour les jeux sur navigateur présentant une latence de 50 à 200 ms, un seuil de prédiction de 0,5 à 1,0 mètre rend les corrections imperceptibles tout en réduisant de 60 à 80 % la bande passante consacrée aux mises à jour de position.

« Types de données répliquées sans conflit » — Shapiro, Preguiça, Baquero, Zawirski (2011). DOI. L’article fondateur sur les CRDT. Il définit des CRDT fondés sur l’état et d’autres fondés sur les opérations, capables de converger sans coordination. Pour notre système d’édition de mondes, les CRDT pertinents sont le LWW-Register (registre où la dernière écriture l’emporte) pour les propriétés d’objet ne possédant qu’une seule valeur — position, rotation, couleur — et l’OR-Set (ensemble observé-supprimé) pour la collection d’objets d’un chunk, qui gère sans conflit les ajouts et suppressions simultanés. Yjs les implémente efficacement en JavaScript.

« Time Warp : un mécanisme pour la simulation distribuée » — Jefferson (1985). DOI. L’article fondateur sur la simulation distribuée optimiste. Bien que Time Warp soit trop complexe pour un jeu sur navigateur, son idée centrale — traiter les événements de manière optimiste, puis revenir en arrière lorsqu’un conflit provenant d’un autre nœud est reçu — constitue le fondement de la prédiction moderne côté client avec réconciliation du serveur. C’est ainsi que fonctionne tout jeu multijoueur réactif : le client effectue une prédiction locale, envoie les actions au serveur, puis corrige son état si le serveur n’est pas d’accord.

« Le modèle réseau du moteur TRIBES » — Frohnmayer et Gift (GDC 1999). L’une des premières descriptions pratiques du réseau client-serveur pour les jeux, avec gestion des zones d’intérêt, mises à jour d’état prioritaires et allocation de la bande passante. Le concept de « gestionnaire de fantômes » — le serveur maintient pour chaque client une représentation de ce que celui-ci connaît et n’envoie que les différences par rapport à cette représentation — correspond exactement à ce que met en œuvre notre architecture Durable Object fondée sur les chunks. Cette conférence GDC est l’ancêtre conceptuel de la plupart des systèmes réseau modernes pour les jeux.

« Réseau multijoueur de Source » — Valve (2009). Documentation pour les développeurs. La documentation de Valve sur le modèle réseau du moteur Source, utilisé dans Half-Life 2, CS:GO et Team Fortress 2. Elle couvre la prédiction côté client, l’interpolation des entités, la compensation du décalage et le système d’« instantanés », dans lequel le serveur envoie l’état complet du monde à intervalles réguliers tandis que le client effectue une interpolation entre ces instantanés. C’est la référence absolue en matière de réseau avec serveur faisant autorité, et ce modèle s’applique directement à notre architecture.

Génération procédurale

« Synthèse de modèles : un algorithme général de modélisation procédurale » — Merrell (2007). DOI. L’un des précurseurs de Wave Function Collapse. Cette méthode génère des structures 3D à partir de modèles d’exemple en propageant des contraintes locales. L’algorithme assure la cohérence globale en réduisant de manière itérative les cellules présentant le moins de possibilités, selon une heuristique d’entropie minimale. C’est ainsi que Townscaper et des générateurs similaires produisent des structures cohérentes à partir de simples actions de l’utilisateur.

« WaveFunctionCollapse » — Maxim Gumin (2016). GitHub. Il ne s’agit pas d’un article traditionnel, mais d’un projet open source majeur accompagné d’une documentation exhaustive. L’algorithme prend une petite image d’exemple ou un jeu de tuiles et génère des résultats plus grands, localement similaires à l’entrée. Dans un monde destiné aux créateurs, WFC peut générer des plans de bâtiments, des réseaux routiers, des cartes de donjons et des détails de terrain à partir d’un petit ensemble de règles définies par le créateur. Plusieurs implémentations JavaScript existent.

« Wave Function Collapse est une résolution de contraintes en conditions réelles » — Karth et Smith (FDG 2017). DOI. Une analyse universitaire de WFC qui précise son lien avec la satisfaction de contraintes et explique comment l’analyser et l’étendre. Elle permet de comprendre les limites de WFC — l’algorithme peut se retrouver bloqué et nécessiter un retour arrière — ainsi que la manière de concevoir des jeux de tuiles évitant ces problèmes.

« Théorème de superposition et conséquences pour la génération procédurale de contenu de jeu » — Sandhu et al. (2022). Cette étude explore l’utilisation de concepts de superposition inspirés de la physique quantique pour la génération procédurale de contenu. Bien que spéculatif, son cadre mathématique permettant de conserver plusieurs états possibles avant leur « réduction » vers une configuration finale correspond exactement au fonctionnement de WFC et pourrait inspirer des systèmes de génération plus sophistiqués.

Techniques de rendu en temps réel

« Rendu en temps réel » — Akenine-Möller, Haines, Hoffman (4e édition, 2018). Le manuel de référence. Le chapitre 19 (Structures d’accélération), le chapitre 20 (Ombrage efficace) et le chapitre 21 (Réalité virtuelle et augmentée) sont particulièrement pertinents. Les algorithmes d’élimination selon le frustum, d’élimination des objets occultés et de LOD qui y sont décrits sont ceux qu’implémentent Three.js, Babylon.js et tous les moteurs de jeu. Ce n’est pas un article, mais l’ouvrage de référence définitif.

« Étude des méthodes de précalcul des champs de radiance neuronaux pour la synthèse de vues en temps réel » — Reiser et al. (2023). DOI. Cette étude examine les méthodes permettant de convertir les NeRF en formats rendus en temps réel, notamment des maillages, des textures et des grilles de voxels creuses. Elle est directement pertinente pour notre pipeline de ressources, dans lequel la capture neuronale côté serveur doit produire un résultat affichable dans un navigateur.

« Mise en correspondance en ligne, évolutive et précise de caractéristiques à l’aide du splatting gaussien 3D » — Divers groupes (2024-2025). Plusieurs articles récents étudient l’édition, la composition et les scènes dynamiques avec des splats gaussiens. Ces travaux sont pertinents, car les mondes de créateurs doivent réunir plusieurs scènes de splats — notamment les objets capturés par chaque créateur — au sein d’une scène unique et cohérente. Les méthodes d’édition de splats, comme la recoloration, la déformation et la composition, constituent des domaines de recherche actifs.

« Tracé de rayons efficace dans l’espace écran sur GPU » — McGuire et Mara (JCGT 2014). DOI. L’article à l’origine des réflexions dans l’espace écran utilisées dans notre section sur le rendu de l’eau. La technique trace des rayons dans le tampon de profondeur afin de produire des réflexions approximatives sans supporter le coût d’un lancer de rayons complet. La variante de « tracé hiérarchique », qui utilise une mipmap de profondeur min-max, s’exécute efficacement dans WebGL 2.

« Simulation de l’eau océanique » — Jerry Tessendorf (2001). PDF. L’article fondateur sur la simulation des océans fondée sur la FFT. Il décrit le spectre de Phillips, un modèle statistique des vagues océaniques, ainsi que sa transformation en carte spatiale de déplacement par FFT inverse. Cette méthode est utilisée par tous les grands jeux présentant un océan réaliste, notamment Sea of Thieves, Assassin’s Creed et Uncharted. Le calcul FFT se transpose naturellement aux shaders de calcul WebGPU.

« Diffusion atmosphérique précalculée » — Bruneton et Neyret (EGSR 2008). DOI. L’article à l’origine du rendu physiquement exact du ciel. Il précalcule la diffusion atmosphérique dans des tables de correspondance qu’un shader de fragments échantillonne en temps réel. Cette méthode produit à partir de principes physiques les bonnes couleurs du ciel, une perspective aérienne réaliste — les objets lointains paraissent bleuâtres et brumeux — ainsi que les couleurs du lever et du coucher du soleil. Les tables précalculées sont petites, de l’ordre de quelques centaines de Ko, et le shader exécuté en temps réel est peu coûteux. Le shader Sky de Three.js et le ciel procédural de Babylon.js sont tous deux des versions simplifiées de cette approche.

« Volumes d’occlusion ambiante » — McGuire (HPG 2010) et « Obscurcissement ambiant évolutif » — McGuire, Mara, Luebke (HPG 2012). PDF. Les articles à l’origine des implémentations modernes de SSAO. SAO est la variante la plus couramment mise en œuvre dans les moteurs 3D pour navigateur, car elle est efficace — un échantillon du tampon de profondeur par pixel — et produit des ombres de contact plausibles. L’algorithme échantillonne le tampon de profondeur autour de chaque pixel afin d’estimer à quel point celui-ci est « occulté » par la géométrie voisine. Three.js et Babylon.js implémentent tous deux un SSAO dérivé de SAO.

Rendu et animation de foules

« Rendu de foules sur GPU » — Dudash (2007) et présentations GDC/SIGGRAPH ultérieures sur le rendu de foules par instanciation. La technique centrale consiste à précalculer les images d’une animation squelettique dans des textures — les Vertex Animation Textures —, puis à afficher les foules sous forme de maillages instanciés, chaque instance lisant les transformations de ses os dans la texture d’animation en fonction de l’image en cours. Cela dissocie l’évaluation des animations des appels de rendu, permettant à un seul appel de rendu instancié d’afficher des centaines de personnages animés individuellement.

« Dynamique fondée sur les positions » — Müller et al. (2007). DOI. L’article fondateur sur la PBD, la méthode employée par les moteurs de jeu modernes pour simuler les tissus, les cheveux et les corps mous. Rapier, le moteur physique Wasm que nous recommandons, utilise des solveurs dérivés de la PBD. Pour la personnalisation des avatars — capes, cheveux flottants et vêtements amples —, la PBD offre une simulation réactive aux fréquences d’images requises par les jeux. L’implémentation Wasm évite de l’exécuter sur le thread JavaScript principal. « FABRIK : un solveur rapide et itératif pour le problème de cinématique inverse » — Aristidou et Lasenby (2011). DOI. L’article à l’origine du solveur de cinématique inverse recommandé dans notre section sur les avatars. FABRIK fonctionne en progressant alternativement de l’effecteur terminal vers la racine, puis de la racine vers l’effecteur terminal, et converge en 3 à 5 itérations. Il est plus rapide que la cinématique inverse fondée sur une jacobienne, gère naturellement les contraintes articulaires et reste simple à implémenter (environ 50 lignes de code pour le solveur de base). Les implémentations de cinématique inverse de Three.js et de Babylon.js sont toutes deux dérivées de FABRIK.

Mondes virtuels et environnements collaboratifs

« Jeux massivement multijoueurs en ligne : état de l’art » — Yahyavi et Kemme (2013). DOI. Étude complète de l’architecture des MMO couvrant les modèles client-serveur, les approches pair à pair, la gestion des zones d’intérêt, les modèles de cohérence, les techniques de mise à l’échelle et la prévention de la triche. La taxonomie des modèles de cohérence (forte, éventuelle, causale) correspond à notre approche fondée sur les CRDT (cohérence éventuelle avec ordre causal au moyen d’horloges vectorielles).

« Une architecture distribuée pour les applications interactives multijoueurs sur Internet » — Diot et Gautier (1999). DOI. Une des premières recherches sur les environnements virtuels distribués à avoir mis en évidence la tension fondamentale : une cohérence forte nécessite de la coordination, ce qui ajoute de la latence, tandis qu’une cohérence faible préserve la réactivité au risque de produire des incohérences visibles. L’article préconise un « retard local » — retarder légèrement l’affichage local afin de laisser le temps aux mises à jour distantes d’arriver — comme solution intermédiaire. Pour les modifications du monde, comme le placement d’objets, un retard local de 100 à 200 ms est imperceptible et laisse au serveur le temps d’effectuer la validation.

« La grille de Second Life : architecture d’un monde virtuel open source presque contemporain » — Documentation technique de Linden Lab et rétro-ingénierie par la communauté. Bien qu’il ne s’agisse pas d’un article unique, l’analyse technique de l’architecture de Second Life est très largement documentée. Les principaux enseignements : chaque région de 256 × 256 m s’exécute sur une instance de serveur dédiée. Les objets sont stockés sous la forme d’un arbre de « primitives » (formes de base dotées de transformations, de textures et de scripts). Le client diffuse à la demande les descriptions des objets et les textures. Ce modèle fondé sur des parcelles et une persistance par objet est l’architecture existante la plus proche de ce que nous construisons, et plus de 20 ans d’exploitation de Second Life prouvent qu’elle peut passer à l’échelle.

Graphismes web et performances des navigateurs

« WebGPU : une API graphique haute performance pour le Web » — Groupe de travail W3C GPU for the Web (depuis 2023). Spécification. La spécification officielle de WebGPU. Ce n’est pas un article de recherche, mais le document technique de référence pour la programmation GPU dans les navigateurs. La spécification des shaders de calcul (section 23) est particulièrement pertinente pour la génération de terrains, la répartition de la végétation et les systèmes de particules décrits tout au long de ce guide.

« WebAssembly : un cadre pour exécuter du code compilé dans le navigateur » — Haas et al. (PLDI 2017). DOI. L’article fondateur sur WebAssembly, rédigé par les éditeurs de navigateurs. Il montre que Wasm atteint des performances au plus deux fois inférieures à celles du code natif pour les charges de calcul intensives. Cela valide notre recommandation d’utiliser des moteurs physiques compilés en Wasm, comme Rapier et Havok, pour les mondes ouverts dans le navigateur. L’analyse des performances indique que le surcoût provient principalement de la vérification des limites et des appels de fonctions indirects, et non du modèle de compilation lui-même.

« Pas si vite : analyse des performances de WebAssembly par rapport au code natif » — Jangda et al. (USENIX ATC 2019). PDF. Une évaluation comparative rigoureuse des performances de Wasm par rapport au code natif. Elle conclut que Wasm s’exécute en moyenne 1,45 à 1,55 fois plus lentement que le C natif sur l’ensemble des tests SPEC CPU. Pour la physique de jeu en particulier — fortement tributaire des calculs en virgule flottante et comportant peu d’appels système — le surcoût se situe dans le bas de cette fourchette (environ 1,3 fois). Cela confirme que la physique en Wasm dans un navigateur est viable pour les charges de travail d’un jeu en temps réel.

« Accélérer le Web avec WebAssembly » — Rossberg et al. (2018). DOI. Décrit les principes de conception et la sémantique formelle de WebAssembly. Point particulièrement pertinent : la présentation des garanties de sécurité mémoire (section 3) explique pourquoi les modules Wasm peuvent partager en toute sécurité un onglet de navigateur avec JavaScript, sans les risques de sécurité propres aux plug-ins natifs. C’est ce qui permet d’exécuter en toute sécurité dans un navigateur des moteurs physiques, traditionnellement distribués sous forme de bibliothèques C++.

Génération de contenu assistée par l’IA

« Génération texte-vers-3D par diffusion bidirectionnelle utilisant à la fois des a priori 2D et 3D » — Divers groupes (2023-2025). Plusieurs articles récents — DreamFusion, Magic3D, ProlificDreamer, MVDream et Zero-1-to-3++ — explorent la génération de ressources 3D à partir de descriptions textuelles en utilisant des modèles de diffusion 2D comme a priori pour l’optimisation 3D. La qualité s’est considérablement améliorée entre début 2023 et 2025, passant de formes informes à des maillages détaillés et texturés. Pour notre plateforme, ces modèles, exécutés côté serveur sur des GPU, constituent l’étape de « génération par IA » du pipeline de ressources destiné aux créateurs.

« DreamFusion : génération texte-vers-3D à l’aide de la diffusion 2D » — Poole et al. (ICLR 2023). Page du projet. L’article fondateur sur le Score Distillation Sampling (SDS), qui utilise un modèle de diffusion 2D préentraîné pour guider l’optimisation 3D. L’idée essentielle : aucune donnée d’entraînement 3D n’est nécessaire si un modèle 2D existant permet d’évaluer si les vues rendues d’un objet 3D correspondent à une description textuelle. Cette découverte a ouvert la voie à la génération texte-vers-3D et sert de base aux travaux ultérieurs, comme Magic3D et ProlificDreamer, qui en ont amélioré la qualité et la rapidité.

« LRM : grand modèle de reconstruction d’une image unique vers la 3D » — Hong et al. (ICLR 2024). Page du projet. Reconstruit un modèle 3D à partir d’une seule image en 5 secondes sur un unique GPU. Le modèle produit une représentation similaire à un NeRF qui peut être convertie en maillage. Dans un monde destiné aux créateurs, cela signifie qu’un créateur pourrait photographier n’importe quel objet réel et obtenir un modèle 3D en quelques secondes. Cette rapidité permet d’en faire un outil interactif plutôt qu’un processus par lots.

« Génération procédurale de contenu par apprentissage automatique (PCGML) » — Summerville et al. (2018). DOI. Une étude de l’utilisation de l’apprentissage automatique pour la génération procédurale de contenu dans les jeux. Elle couvre la génération de niveaux, d’objets, de récits et de mondes. Point particulièrement pertinent : l’analyse de la « génération contrôlable », dans laquelle les concepteurs définissent des paramètres de haut niveau et le modèle d’apprentissage automatique complète les détails. C’est le paradigme de la création de mondes assistée par l’IA : les créateurs définissent une intention (« transforme cette zone en forêt inquiétante »), puis l’IA produit la géométrie, les textures et les éléments qui la peuplent.

Comment ces articles s’intègrent à notre architecture

Ces recherches correspondent aux différentes couches de notre architecture :

Pipeline de terrain : le bruit de Perlin/simplex (Perlin 1985, 2001) génère la carte de hauteur de base. L’érosion hydraulique (Mei et al. 2007) apporte un réalisme géologique. Les geometry clipmaps (Losasso et Hoppe 2004) ou CDLOD (Strugar 2014) permettent un rendu efficace du terrain dans le navigateur. La diffusion atmosphérique (Bruneton et Neyret 2008) donne un aspect réaliste aux terrains lointains.

Pipeline de ressources : le texte-vers-3D (DreamFusion et al.) et l’image-vers-3D (LRM) génèrent des ressources côté serveur. Le Gaussian splatting (Kerbl et al. 2023) permet la capture photogrammétrique. Neuralangelo (Li et al. 2023) extrait des maillages propres à partir de captures neuronales. Toutes les sorties sont traitées et converties en GLB/KTX2 optimisés pour les navigateurs.

Rendu : SSAO (McGuire 2012) ajoute de la profondeur. Les reflets en espace écran (McGuire et Mara 2014) assurent le rendu de l’eau. L’océan par FFT (Tessendorf 2001) simule l’eau. Les textures d’animation de sommets (Dudash 2007) permettent le rendu des foules. FABRIK (Aristidou et Lasenby 2011) pilote la cinématique inverse des personnages.

Réseau : la gestion des zones d’intérêt (Boulanger et al. 2006) filtre les mises à jour selon leur pertinence spatiale. La navigation à l’estime (Pantel et Wolf 2002) réduit la bande passante. Les CRDT (Shapiro et al. 2011) gèrent l’édition collaborative. La prédiction côté client avec réconciliation serveur (Jefferson 1985, réseau de Valve Source) assure la réactivité.

Génération du monde : WFC (Gumin 2016, Karth et Smith 2017) génère les structures et les agencements. PCGML (Summerville et al. 2018) fournit le cadre de génération assistée par l’IA dans lequel les créateurs définissent une intention et les modèles complètent les détails.

La recherche est arrivée à maturité. La plupart de ces techniques sont utilisées depuis des années dans des jeux commercialisés. L’innovation consistant à les intégrer au navigateur ne réside pas dans les algorithmes, mais dans l’ingénierie nécessaire pour les faire fonctionner avec les contraintes de mémoire, de GPU et de réseau du navigateur, ce que traite le reste de ce guide.

Pour aller plus loin

• Pile technologique des jeux web en 2026 présente les fondamentaux de WebGL, WebGPU et WebAssembly
• Comparatif des moteurs de jeux web compare les moteurs destinés à une diffusion dans le navigateur
• Rapport technique sur Three.js + USDC consacré au chargement de ressources 3D dans le navigateur
• Modèles d’IA générative open source de pointe pour le pipeline de génération par IA
• Conception de jeux coopératifs sur les modèles de conception multijoueur qui maintiennent l’intérêt des joueurs
• Génération de paysages pour les mondes ouverts dans le navigateur — rendu du terrain, de l’érosion et de la végétation
• Principes de base du multijoueur avec WebSocket — premiers pas avec le réseau multijoueur dans le navigateur
• Bien démarrer avec WebGPU — l’API de rendu pour la 3D nouvelle génération dans le navigateur
• Chargement progressif des ressources — modèles de chargement progressif pour les grands mondes 3D

Essayez tout de suiteEssayez dès maintenant un monde ouvert dans votre navigateur

Une phrase saisie, un monde 3D explorable généré.

Créer gratuitement →C'est gratuit, ça tourne dans votre navigateur, rien à installer.