Créer un monde ouvert dans le navigateur, partie 3 : les prototypes peu spectaculaires qui nous ont sauvés

Par Oleg Sidorkin, CTO et cofondateur de Cinevva

Vous découvrez la série ? Consultez le guide de la série. Il explique ce qu'est un prototype exploratoire et donne accès à toutes les parties.

Cette partie comporte moins de captures d'écran spectaculaires et davantage de garanties architecturales.

Après les prototypes 1 et 2, nous avons mené trois vérifications de risques qui semblaient modestes, mais dont l'impact sur le produit était majeur.

La première concernait la diffusion à grande échelle avec les Durable Objects. Nous avons testé la distribution des positions entre plusieurs clients à des fréquences de tick comparables à celles d'un jeu, tout en mesurant la distribution de la latence, l'utilisation du processeur par tick et l'intégrité des livraisons. En cas d'échec, nous aurions adopté très tôt une architecture partitionnée plutôt que de confier chaque île à une seule instance.

La deuxième portait sur la validation des contraintes mobiles. Il ne s'agissait pas d'un préréglage pour ordinateur simplement rebaptisé « mobile », mais d'un profil explicitement peu coûteux, dérivé du même terrain de référence.

Ouvrir le profil mobile dans un nouvel onglet ↗ · Voir le code source

Nous avons réduit la densité des segments, le nombre d'objets, la pression liée à la résolution de rendu et la portée du brouillard. La question était simple. Ce monde peut-il rester lisible et réactif malgré les contraintes d'un appareil mobile, sans devoir réécrire tout le moteur de rendu ?

La troisième vérification concernait la fiabilité de la génération de comportements dans les workflows des créateurs. Nous avons évalué le taux de JSON valide, la justesse sémantique par rapport aux primitives attendues et la latence des réponses. En cas d'échec, nous aurions adopté une création de comportements strictement fondée sur des formulaires.

L'enseignement essentiel de ce chapitre est que ces prototypes peu spectaculaires ont fait évoluer l'architecture plus rapidement que les prototypes visuels. Ils ont fixé des limites strictes pour la topologie réseau, les promesses sur mobile et l'expérience utilisateur des outils.

Dans la partie 4, nous revenons au travail visible sur le terrain et testons le comportement du streaming pendant les déplacements, plutôt que de nous limiter à des captures d'écran de chargement statique.

Technologies mentionnées dans ce chapitre

Cloudflare Durable Objects. Instances serverless avec état, déployées en périphérie du réseau et dotées d'une persistance intégrée ainsi que de la prise en charge des WebSockets. Chaque Durable Object conserve l'état de référence d'une partition du monde (ou d'un chunk). Les joueurs se connectent par WebSocket et reçoivent les positions diffusées par les autres joueurs présents dans la même partition. Lorsqu'un joueur se déplace vers un chunk adjacent, il se connecte au Durable Object de ce chunk. Les Durable Objects enregistrent automatiquement l'état sur disque et peuvent évoluer jusqu'à des milliers d'instances simultanées. Consultez la documentation de Cloudflare sur les Durable Objects ainsi que notre guide des technologies 3D dans le navigateur consacré au réseau multijoueur.

Partitionnement spatial. Répartition du monde entre plusieurs instances de serveur selon les régions géographiques. Chaque partition gère une zone rectangulaire de la grille du monde. Lorsque la densité de joueurs évolue, les partitions peuvent se diviser ou fusionner. Les joueurs proches de la limite d'une partition voient le contenu des deux partitions grâce à des requêtes de visibilité interpartitions. C'est ainsi qu'EVE Online gère des milliers de joueurs dans un même univers.

Diffusion WebSocket en éventail. Distribution en temps réel des mises à jour de position depuis un serveur vers de nombreux clients connectés. La bande passante descendante par client augmente de façon linéaire avec le nombre de joueurs visibles :

$$B_{\text{client}}=N_{\text{visible}}\times b_{\text{player}}$$

À des fréquences de tick comparables à celles d'un jeu (20 à 30 Hz), chaque joueur génère environ $b_{\text{player}}\approx 800$ octets de données de position par seconde. Afficher 200 joueurs coûte donc $200\times 800=160$ Ko/s par client. Le coût serveur d'une approche naïve où chacun communique avec tous les autres est encore pire, puisqu'il augmente comme $N^2$. C'est précisément pourquoi le filtrage par pertinence (gestion spatiale des zones d'intérêt) plafonne $N_{\text{visible}}$ avant l'envoi vers chaque connexion, tout en respectant le budget temporel du tick. Consultez notre guide du réseau pour découvrir les compromis entre compression différentielle et fréquence de mise à jour.

Contraintes du rendu sur mobile. Les GPU mobiles offrent un débit 5 à 10 fois inférieur à celui des GPU pour ordinateur, disposent d'une limite de mémoire d'environ 1 Go (contre 2 à 4 Go sur ordinateur) et réduisent leurs performances thermiques lors d'une charge prolongée. Un profil de qualité mobile diminue la densité des segments, le nombre d'objets, la résolution de rendu, la distance d'affichage et la qualité des ombres. L'objectif n'est pas d'atteindre la parité avec les ordinateurs, mais de préserver la lisibilité et la réactivité. Consultez les chiffres de performance réels de la 3D dans le navigateur pour voir de véritables benchmarks GPU.

---

Partie 3 sur 12.
Précédent : Partie 2 — La physique dans un Worker et la crainte de la latence des commandes
Suivant : Partie 4 — Le streaming avant les terrains sophistiqués
Guide de la série : /fr/blog/2026-02-25-open-world-browser-series-guide