Server Meshing : comment Star Citizen casse le plafond des MMO

Par la rédaction CDDN • Mise à jour : 25 octobre 2025 — Alpha 4.3.2 LIVE

En bref — Le Server Meshing permet à plusieurs serveurs de simuler le même univers (shard) en se partageant les zones (villes, orbites, planètes, stations). La couche de réplication (Replication Layer) maintient l’état des entités et gère la reprise après crash. Résultat : plus de densité, une vraie persistance (PES) et moins de plantages “tout ou rien”.

Pourquoi tout le monde en parle ?

Traditionnellement, un MMO confie un shard à un seul serveur. Or un serveur a des limites (CPU, RAM, réseau). Dans Star Citizen — univers systémique où tout persiste (débris, caisses, vaisseaux, IA, économie) — ce modèle crée des goulots d’étranglement : désynchronisations, IA réduite, fameux 30k.

Le Server Meshing (SM) change l’échelle : plusieurs DGS (Dedicated Game Servers) coopèrent dans le même shard. Chaque DGS prend l’autorité d’une zone. Quand un joueur, un PNJ ou un projectile franchit une frontière de zone, l’autorité bascule vers le serveur voisin. Côté joueur, c’est transparent.

Les briques qui rendent le SM possible

À lire aussi : Star Citizen Genesis : la fabrique de mondes (contexte Planet Tech v5/Genesis).

PES / EntityGraph (3.18)

Persistent Entity Streaming : tous les objets (entités) existent et persistent dans la base d’entités du shard : épaves, tasses, munitions, etc.

Replication Layer (3.24.x →)

Chef d’orchestre entre serveurs et clients : publie l’état des entités, assure le handoff d’autorité entre zones et permet la reprise après crash (Crash Recovery).

Shards

Un shard = un univers cohérent avec son état propre. Les objets « laissés au sol » y restent. L’inventaire « rangé » (stowed) peut être ressorti ailleurs dans le même shard.

(S)OCS & Bind Culling

(Server) Object Container Streaming : charge/décharge ce qui est pertinent ; le bind culling coupe les mises à jour réseau inutiles. Ces optimisations allègent la charge et préparent le maillage.

Statique aujourd’hui, dynamique demain

Server Meshing statique (v1, 4.0 → 4.3) : frontières définies à l’avance (ex. « Ville », « Atmosphère », « Orbital », « Profondeur spatiale »).
Server Meshing dynamique (objectif) : frontières mobiles selon l’affluence ; une zone très peuplée se subdivise en plusieurs serveurs puis se replie ensuite.

Server Meshing (v1 statique) : plusieurs DGS partagent l’autorité d’un même shard. La couche de réplication synchronise l’état et orchestre les handoffs entre zones.

Server meshing Star Citizen : Replication Layer, DGS et handoff d’autorité entre zones — Illustration CDDN — « Server Meshing Dynamique : et la force est avec nous dans ce MMO MASSIIIIF! »

Concrètement, côté joueurs

Plus de densité : davantage de joueurs, d’IA et d’événements dans le même shard (perceptible depuis 4.0 preview, consolidé en 4.1 → 4.3).
Moins de « tout s’arrête » : si un DGS plante, la reprise serveur recrée la zone et reconnecte les clients au remplaçant via le Replication Layer.
Persistance vécue : ce que vous laissez dans le monde reste dans votre shard (PES). Les inventaires et la LTP (persistance long terme) évoluent patch après patch.

Exemple : vous quittez Lorville vers l’orbite. À l’altitude de transition, l’autorité de votre vaisseau passe du DGS « Ville » au DGS « Planète/Orbital ». Vous tirez un missile sur la frontière ? L’entité « missile » est connue des deux DGS et l’autorité bascule au bon moment.

Chronologie utile

2019 — SOCS/OCS : bases du streaming d’objets et de zones.
Mars 2023 (3.18) — PES / EntityGraph LIVE : persistance à l’échelle du shard.
2024 (3.24.x) — Replication Layer scindé & Crash Recovery généralisé.
Déc. 2024 (4.0 preview) — Server Meshing v1 : topologies multi-serveurs, sauts vers Pyro activés.
2025 (4.1 / 4.2 / 4.3) — Itérations de stabilité/perf, LTP et missions « serveur ».
Oct. 2025 (4.3.2 LIVE) — Consolidation des systèmes et nouveaux contenus.

Limites actuelles & points d’attention (4.3.2)

Persistance LTP : cas limites d’items manquants après patchs (en correction continue).
Crash Recovery : selon version, certaines missions peuvent être annulées lors d’une reprise.
Maillage dynamique : encore en chantier ; le v1 statique/hybride reste la base.

Glossaire express

Shard: Instance-univers persistante avec état propre.
DGS: Dedicated Game Server, serveur simulant une zone du shard.
Replication Layer: Service central qui publie l’état, gère l’autorité et la reprise après crash.
PES / EntityGraph: Base d’entités assurant la persistance fine des objets.
(S)OCS: (Server) Object Container Streaming.
Bind Culling: Réduction des mises à jour réseau aux seules entités pertinentes.

FAQ

Combien de joueurs par shard ?

CIG augmente progressivement la population par shard grâce aux topologies multi-serveurs. Le plafond exact varie selon les builds et la charge ; l’objectif est bien au-delà du modèle « 1 serveur = 1 shard ».

Puis-je retrouver mon équipement partout ?

Les objets persistants restent dans votre shard (PES). L’inventaire « rangé » peut être ressorti ailleurs dans ce même shard. Des passerelles contrôlées existent pour certains transferts entre shards (évolutif).

Que se passe-t-il si un serveur plante ?

Le Crash Recovery relance un DGS et restaure l’état via le Replication Layer. Des effets de bord peuvent subsister (missions annulées, etc.) selon la version.