À l'occasion de la sortie de Star Citizen Alpha 4.10, Chris Roberts a publié une nouvelle Letter from the Chairman faisant le point sur plusieurs aspects du développement du jeu.
Au-delà du retour du Siège d'Orison et des nouveautés directement visibles en jeu, cette mise à jour marque surtout une nouvelle étape dans l'évolution de l'infrastructure serveur de Star Citizen. Avec l'arrivée des instances de zones et de rencontres, Cloud Imperium Games commence à exploiter ce qu'il qualifie désormais de Quasi Dynamic Server Meshing, une technologie intermédiaire entre le Server Meshing statique actuel et le Dynamic Server Meshing visé à terme.
Une fréquentation en hausse en 2026
Chris Roberts commence par revenir sur la fréquentation du Persistent Universe.
Star Citizen a atteint cette année un pic de 35 890 joueurs connectés simultanément, et ce en dehors d'une période de Free Fly.
Sur le premier semestre 2026, CIG constate également une progression de 7 % du nombre moyen de joueurs quotidiens et de 11 % du nombre de joueurs actifs mensuels par rapport à l'année précédente.
Une augmentation de la fréquentation qui rend d'autant plus importante la capacité de l'infrastructure à répartir efficacement les joueurs et la charge entre les différents serveurs.
L'Alpha 4.10 introduit les instances dans le Persistent Universe
Avec l'Alpha 4.10, CIG introduit les Area and Encounter Instances, notamment utilisées pour la nouvelle version du Siège d'Orison.
Le concept d'instance n'est pas totalement nouveau dans Star Citizen. Les hangars personnels reposent déjà sur un principe similaire, permettant à plusieurs joueurs d'utiliser virtuellement le même emplacement sans se retrouver physiquement dans le même espace.
La technologie mise en place avec la 4.10 va cependant beaucoup plus loin.
CIG peut désormais créer à la demande des zones instanciées disposant de leur propre contenu et de leurs propres joueurs, tout en restant connectées au Persistent Universe.
Dans le cas du Siège d'Orison, plusieurs groupes peuvent ainsi participer simultanément à l'événement dans différentes instances, sans qu'ils aient besoin d'être regroupés sur un seul et même serveur.
Du Static au Quasi Dynamic Server Meshing
Depuis l'Alpha 4.0, Star Citizen utilise le Static Server Meshing.
Dans cette architecture, différentes parties de l'univers sont attribuées à des serveurs spécifiques selon une répartition prédéfinie. Cette avancée a permis de répartir la simulation du Persistent Universe entre plusieurs serveurs, mais elle conserve une importante limitation.
Si une grande quantité de joueurs se rassemble dans une même zone, le serveur chargé de cette zone doit supporter seul cette augmentation de charge.
C'est précisément sur ce point que la technologie introduite avec les instances de la 4.10 devient particulièrement intéressante.
L'infrastructure est désormais capable de démarrer de nouveaux serveurs à la demande afin d'héberger les instances nécessaires, puis de les arrêter lorsqu'ils ne sont plus utiles.
CIG désigne actuellement cette architecture sous le nom de : Quasi Dynamic Server Meshing, ou QDSM.
Pourquoi seulement « Quasi Dynamic » ?
Le système n'est pas encore le Dynamic Server Meshing complet imaginé par CIG.
À terme, l'objectif du Dynamic Server Meshing est de permettre à l'infrastructure de modifier dynamiquement la répartition du Persistent Universe entre les serveurs selon la position et la concentration des joueurs.
Une zone particulièrement fréquentée pourrait ainsi bénéficier de davantage de ressources serveur, tandis que les zones désertées en nécessiteraient moins.
Avec le QDSM de la 4.10, les territoires principaux du Persistent Universe restent encore attribués de manière statique.
En revanche, l'infrastructure peut désormais ajouter et supprimer dynamiquement des serveurs pour gérer les instances.
Pour Chris Roberts, il s'agit du premier véritable cas d'utilisation du Dynamic Server Meshing dans Star Citizen.
Le Siège d'Orison comme terrain d'expérimentation
Le nouveau Siège d'Orison joue donc un rôle beaucoup plus important qu'un simple retour de l'événement dynamique.
Il sert de terrain d'expérimentation grandeur nature à cette nouvelle architecture.
CIG explique avoir rencontré de nombreuses difficultés lors du développement et des tests de cette technologie, notamment pour obtenir un fonctionnement suffisamment performant lorsque de nombreuses instances sont créées simultanément.
Les différents tests réalisés avant le passage en LIVE auraient finalement permis d'atteindre les performances recherchées.
La technologie pourra désormais évoluer et être utilisée dans d'autres situations.
Une étape supplémentaire vers Star Citizen 1.0
Le Quasi Dynamic Server Meshing ne constitue donc pas l'aboutissement du Server Meshing, mais plutôt une nouvelle étape dans sa construction.
CIG dispose désormais de plusieurs briques essentielles : le Persistent Entity Streaming, la Replication Layer, le Static Server Meshing et maintenant une infrastructure capable de démarrer et d'arrêter certains serveurs en fonction des besoins.
La prochaine évolution consistera à appliquer cette logique directement aux différentes zones du Persistent Universe.
C'est à ce moment-là que le véritable Dynamic Server Meshing pourra commencer à répartir dynamiquement les ressources selon l'activité des joueurs.
StarEngine continue également d'évoluer
Chris Roberts profite de sa lettre pour revenir sur un autre sujet régulièrement discuté : StarEngine.
Si le moteur utilisé aujourd'hui par Star Citizen trouve effectivement ses origines dans CryEngine 3, CIG rappelle que le studio a cessé d'intégrer les mises à jour de CryEngine dès octobre 2015.
Depuis, une grande partie des composants ont été remplacés, modifiés ou entièrement développés en interne.
Cela concerne notamment le rendu, la physique, l'audio, les animations, les interfaces, les systèmes réseau, la réplication ou encore les différents outils nécessaires au développement.
Le passage par Lumberyard était quant à lui principalement lié à l'utilisation d'Amazon Web Services, CryEngine et Lumberyard partageant à cette époque une base technologique commune.
Depuis 2020, CIG dispose également d'une licence perpétuelle sur la branche de CryEngine utilisée comme fondation de StarEngine.
Plus de 100 ingénieurs travaillent sur les technologies de CIG
Cette évolution permanente du moteur et de l'infrastructure mobilise une équipe conséquente.
Le Core Tech Group compte aujourd'hui 146 personnes, dont 106 ingénieurs.
Ces équipes travaillent notamment sur StarEngine, les outils de développement ainsi que les technologies backend nécessaires à Star Citizen et Squadron 42.
Des investissements techniques que Chris Roberts estime indispensables pour parvenir à construire un univers persistant à l'échelle recherchée par CIG.
Vers un retour à davantage de transparence
Cette Letter from the Chairman est également l'occasion pour Chris Roberts de reconnaître que CIG s'est progressivement éloigné de l'un des principes historiques du projet : le développement ouvert.
Ces deux dernières années, les coulisses du développement et les difficultés rencontrées par les équipes ont été moins souvent présentées à la communauté.
CIG souhaite désormais revenir vers davantage de transparence.
La récente présentation des coulisses du développement de l'Alpha 4.10 et du Siège d'Orison doit ainsi constituer une première étape vers ce retour à une communication montrant aussi bien les réussites que les difficultés rencontrées par les développeurs.
Une nouvelle brique pour l'avenir du Persistent Universe
Avec l'Alpha 4.10, Star Citizen ne dispose donc pas encore du Dynamic Server Meshing complet.
Mais pour la première fois, une partie de son infrastructure est capable d'adapter dynamiquement le nombre de serveurs utilisés en fonction des besoins générés par les instances.
Le Quasi Dynamic Server Meshing représente ainsi une étape intermédiaire supplémentaire entre l'architecture actuelle et celle imaginée pour l'avenir du Persistent Universe.
Après le Persistent Entity Streaming, la Replication Layer et le Static Server Meshing, une nouvelle pièce du puzzle vient donc de prendre place.
Reste désormais à voir comment CIG fera évoluer cette technologie pour passer de la gestion dynamique des instances à celle de l'ensemble du 'verse.