Star Citizen Live | Tech Talk w/ Benoit Beausejour

Du fait de la sortie de Squadron 42 prévue en 2026, la direction de Star Citizen a décidé qu’il était important que les équipes se concentrent sur la jouabilité et la stabilité. En parallèle, l’architecture réseau du jeu a complètement changé, comme le rappelle Benoit :

Depuis 2024, le jeu est passé en version Alpha 4.x, avec un “server meshing” permettant d’avoir plusieurs systèmes stellaires, chacun découpé en plusieurs serveurs.

Les performances serveurs sont en moyenne meilleures (au-dessus de 20 cycles par seconde) même si certaines zones restent plus difficiles.

Les « shards » accueillent plusieurs centaines de joueurs (autour de 600 dans les derniers patchs) et cela va continuer de progresser.

Les crashs de type 30k ont disparu, permettant d’avoir des durées de sessions multipliées par 10.

Cloud Imperium Games a mis en place un système de « Jokers » qui permet de mettre sur pied une équipe ad ’hoc, pilotée par l’assurance qualité (les testeurs), pour prendre en charge les bugs autour d’une fonctionnalité (par exemple le système de transit) ou corriger un problème. Ce dispositif est désormais appelé « Hero Squads » en interne.

Les équipes d’assurance qualité ont désormais la main sur les priorités de tests et l’autorité pour décider si un développement peut passer sur les serveurs « Live » ou non. Ceci a permis de faire face aux très nombreux problèmes de régressions, c’est-à-dire de résurgence de bugs qui avaient été corrigés ou d’apparition de bugs sur des systèmes qui fonctionnaient précédemment.

Une initiative « d’hygiène » a été menée pour réduire les messages qui apparaissent dans les journaux d’exécution (logs en anglais) afin que ceux qui restent soient efficaces pour repérer et corriger les problèmes.

A chaque build, les développeurs calculent un score qui représente une estimation de la stabilité de l’environnement. Il prend en compte, entre autres, le nombre de déconnexions entre les clients et le serveur, la durée de fonctionnement de ce dernier, les crashs du client... Au début, le score était uniquement un nombre mais il n’était pas toujours facile de savoir à quoi cela correspondait, alors ils ont donné des noms aux différents niveaux : optimal, excellent, stable, instable, volatile, accidenté, ou instabilité critique.

Le score de stabilité du patch 3.18 était instabilité critique, celui des patchs 3.23.x était approximativement au niveau instable, alors que celui du patch 4.3.0 était entre optimal et excellent. Ainsi la stabilité perçue par les joueurs a grandement augmentée en un an.

Les développeurs essaient d’atteindre un score équivalent ou supérieur au patch précédent lorsqu’ils décident de mettre une mise à jour entre les mains des joueurs.

En 2025, entre 8 et 9 patchs ont déjà été livrés sur l’univers persistant, alors qu’auparavant c’était plutôt 4 par an. C’est un rythme soutenu qui met sous une pression constante certaines équipes clés. Les directeurs sont en train d’évaluer quel sera le rythme à tenir en 2026.

Auparavant, Cloud Imperium Games avait un environnement de travail principal (Main Stream) sur lequel l’ensemble des équipes déposaient leurs travaux : les outils, les fondamentaux techniques, les gameplays, les assets graphiques… Cette organisation permettait d’intégrer plus rapidement les travaux en cours mais générait de l’instabilité et donc des pertes de temps.

Pour tenir le rythme de 2026, un “stream” de développement appelé “SC patch” a été mis en place. Cet environnement n’a pas fait l’objet de mises à jour techniques majeures (technologies, outils de développements) afin de garantir la meilleure stabilité possible. Ainsi, c’est la séparation des travaux menés par les équipes de contenu de ceux menés par celles qui travaillent sur les technologies et les outils qui a permis cette accélération du rythme des patchs.

La durée des sessions est un indicateur qui est calculé entre la connexion et la déconnexion à une “shard” (c’est-à-dire que rester dans le menu ne compte pas). C’est une mesure importante, complémentaire au nombre de joueurs connectés simultanément. En effet, on peut avoir beaucoup de joueurs connectés mais une faible stabilité tandis qu’une longue durée de session indique généralement une bonne qualité du patch et une envie de jouer au jeu.

Entre les patchs 3.x et ceux actuels, la durée des sessions a plus que doublé. De plus, le système de récupération lors des crashs serveur permet d’avoir une continuité de jeu même si une session est interrompue par un problème, dans une partie des cas.

Les Tech Preview ont pour objectif de tester des fonctionnalités sans perturber le fonctionnement de l’univers de test. Ce système a d’abord été utilisé fin 2024 pour le “server meshing” du patch 4.0. En 2025, il va être mis en œuvre pour tester tous les changements techniques qui ont été apportés à la branche principale de développement (Main Stream) avant de les porter sur celle dédiée aux patchs et au contenu (SC Patch). Elle permettra d’évaluer en particulier des améliorations graphiques, l’implémentation de Vulkan, et d'apporter des nouveaux outils pour les développeurs notamment pour les missions.

Le Tech Preview suivant servira à tester le gameplay d’ingénieur de bord. Les développeurs espèrent qu’il aura lieu avant la fin d’année.

Benoit rappelle que Subsumption est désormais appelé StarScript.

Les joueurs participent moins aux PTU et aux Tech Preview car l’environnement Live est plus stable et a davantage de contenu. Benoit invite d’ailleurs les joueurs à participer aux tests pour rendre les patchs plus robustes.

Jared explique qu’avec le rythme soutenu des patchs en 2025 et la présence d’événement à durée limitée, il y a une situation paradoxale dans laquelle les joueurs participent davantage au jeu, ce qui est un succès pour les développeurs, mais font moins de tests, ce qui pose des problèmes pour les futures mises à jour. Il n’y a pas vraiment de bonne solution pour faire face à ce phénomène, et c’est la raison pour laquelle ils sont en train de réévaluer le rythme des patchs.

Les développeurs de Star Citizen ont décidé d’avoir une approche ciblée pour réparer et relancer les shards. Ainsi, ils supervisent les performances et relancent des “shards” neufs quand il y en a besoin.

Un reboot quotidien des serveurs n’apporterait pas beaucoup de gains car s’il y a des problèmes dans la base de données, ils seraient transférés à nouveau aux serveurs après le redémarrage.

Le server meshing est déployé depuis plus de 8 mois sur les serveurs Live. Pour l’instant, c’est une version statique qui répartit la charge sur plusieurs serveurs en fonction de zones géographiques, appelées des territoires. Plusieurs configurations ont été testées (au minimum une par patch) depuis le début, par exemple pour allouer davantage de ressources aux endroits où des événements se déroulent. Actuellement, il y a 10 serveurs par “shard”.

L’année 2025 a permis à l’équipe de développement de se familiariser avec le server meshing, notamment en adaptant les gameplays à cette architecture et en faisant face à des bugs.

Le composant central du server meshing, qui assure la connectivité entre tous les composants, est appelé "l’Hybride". Pour ce dernier, il n’y a aucune tolérance aux bugs : s’il y a le moindre risque dessus, le patch ne peut pas être sorti. Les performances de l’Hybride sont essentielles pour limiter les problèmes de rubberbanding et de désynchronisation.

Pour aller vers le server meshing dynamique, les développeurs doivent mettre au point un algorithme qui anticipe la charge de chaque serveur en fonction de ce sur quoi il a autorité : les joueurs présents, les personnages non joueurs, les vaisseaux… Benoit explique qu’une salle avec 300 joueurs ne pose aucun problème pour un serveur mais que les intelligences artificielles et les vaisseaux nécessitent davantage de ressources.

Benoit explique les particularités du server meshing de Star Citizen comparé à d’autres projets. Tout d’abord, les fonctions de simulation et de réplication sont séparées, alors qu’habituellement elles sont portées par un même serveur de jeu. La réplication est portée par l’Hybride, qui porte l’état dans lequel se situe “l’univers” et le distribue aux serveurs et aux clients. Ainsi, les serveurs sont connectés à l’Hybride comme les clients le sont, mais la différence est qu’ils ont une autorité sur les entités.

Ensuite, le découpage de l’espace par le server meshing de Star Citizen est une combinaison de volumes 3D et d’un arbre, alors qu’il est généralement en grille dans d’autres jeux.

Les monte-charges sont une des fonctionnalités qui a bénéficié d’une des équipes de choc aussi appelées “Hero Squads”. Benoit pense que celle-ci a été mise en place trop tardivement. Plusieurs problèmes sont cités :

La présence d’un objet au-dessus des monte-charges peut provoquer le blocage de ces derniers. De plus, certains objets arrivent à passer à travers le monte-charge, provoquant un blocage invisible. Certains objets détruits ne sont plus visibles mais empêchent tout de même les monte-charges de fonctionner.

L’ordre de chargement de la console ou de la plateforme du monte-charge peut créer un problème d’appairage entre les deux, rendant le tout non fonctionnel.

L’interface utilisateur peut être désynchronisée, provoquant une différence entre ce qui est affiché et le contenu de la plateforme.

Les enseignements des problèmes liés aux monte-charges est qu’il faut une meilleure gestion des erreurs, des tests approfondis en multijoueurs, et des mécanismes d’auto-réparation des systèmes.

Avec la persistance, il est indispensable d’avoir un système qui nettoie de temps en temps l’univers, afin d’éviter l’accumulation d’objets, de véhicules ou de cadavres.

Ainsi, chaque objet appartient à une catégorie et chaque catégorie possède une limite de densité en fonction du lieu. Ainsi, il ne devrait pas y avoir plus d’un certain nombre d’un type d’objet dans une région donnée.

Chaque type d’objet a également une durée de vie dans le monde.

Tout véhicule qui n’a pas de joueur à l’intérieur est soumis à un minuteur pour le retirer du jeu. De mémoire, Benoit indique que la durée est de deux heures actuellement. A l’avenir, celle-ci devra être variable en fonction de la taille du vaisseau et du lieu.

Lorsque deux entités entrent en intersection trop longtemps, l’une des deux est retirée du jeu.

Beaucoup d’entités apparaissent en cours de jeu, comme les ennemis pour les missions, ou encore les verres lors des animations des barmans. Durant l’année 2025, les développeurs ont dû faire face à de nombreux bugs liés à des apparitions en surnombre, provoquant par exemple des flots incessants d'adversaires. Ces problèmes ont de nombreuses causes différentes.

Un système appelé “Population Management System” va être mis en place pour prendre en charge l’apparition de personnages non joueurs.

A la sortie du patch 4.0, l’interdiction quantique ne fonctionnait plus du fait du server meshing. Ceci est dû au fait que les informations nécessaires pour déterminer les interdictions peuvent être réparties sur deux serveurs. L’une des solutions était de faire porter la fonction par l’Hybride mais les développeurs essaient de garder ce dernier le plus simple possible pour des raisons de stabilité et performance. Ainsi, un nouveau service a été implémenté pour prendre en charge les interdictions quantiques. Ce service reçoit la position des moteurs quantiques et des dispositifs d’interdiction quantique des différents serveurs et les informe s’il y a une interaction entre certains d’entre eux.

En ce qui concerne les balises de détresse pour les joueurs ayant besoin de soins, le passage au server meshing a grandement augmenté le nombre de joueurs, et donc les messages liés au déclenchement des balises. De plus, les balises provenant d’un autre serveur de jeu n’étaient pas visibles.

Un service pour les balises (“Beacons” en anglais) va être mis en place pour permettre de les diffuser dans un environnement de server meshing.

Le système de transit regroupe les transports en commun et les ascenseurs qui permettent de se déplacer dans les villes et les stations. Il s’agit d’une des fonctionnalités qui a bénéficié d’une des équipes dédiées de type “Hero Squads”, avec des développeurs très expérimentés.

L’état actuel du transit est acceptable pour les développeurs même s’il reste quelques bugs.

Le système de transport est le futur du système de transit. Il s’agit d’une refonte complète, qui doit être résiliente aux problèmes actuellement rencontrés. Actuellement, le nouveau système de transport est testé en interne et permet d’établir des liaisons entre des portes fixes à New Babbage. Il reste à implémenter le passage vers des instances. Le système passera en Tech Preview quand il sera prêt.

Le contrôle aérien de Star Citizen a pour mission d’assigner un hangar à un joueur qui veut atterrir ou ouvrir la porte du hangar à celui qui souhaite décoller. C’est donc un système qui est en interface entre le joueur, le monde extérieur, les hangars instanciés, et le système de file d’attente s’il y a plus de joueurs présents dans leurs hangars que de portes disponibles dans le monde extérieur.

Les développeurs ne sont pas satisfaits de l’implémentation actuelle du contrôle aérien car il supervise beaucoup de choses alors que c’est un ancien système qui demande une mise à jour. Le plan d'action issu est de le découper en différents services, par exemple avec un gestionnaire des hangars (“hangar manager”) qui prendra en charge tout ce qui se passe dans ces derniers.

L’un des problèmes les plus embêtants pour les joueurs est la perte d’objets lors des patchs. Le système de persistance à long terme (LTP) a été introduit lors du patch Alpha 3.8 afin d’offrir aux joueurs une solution pour qu’ils puissent conserver leurs objets dans un contexte où les remises à zéro (“Wipes” en anglais) sont nécessaires sur le plan technique. Le LTP était une solution à court terme qui n’était pas conçue pour passer à l’échelle dans le cadre du server meshing.

Les vaisseaux et objets obtenus via un achat dans la boutique en ligne (Pledge store), par le système de parrainage (Referral), d'abonnement (Subscription) ou de concours sur Spectrum sont gérés différemment de ceux obtenus en jeu. Ils sont considérés comme des “droits” (entitlement) et le jeu vérifie régulièrement qu’ils sont bien présents. Les objets obtenus en jeu sont gérés par une autre base de données qui est actuellement moins robuste. Dans un avenir proche, les vaisseaux gagnés en jeu seront plus robustes aux changements de patchs.

Tous les objets qui sont visibles en jeu sont dans un état déstocké, c’est-à-dire qu’ils ont été chargés dans la base de données d’un Shard à partir de celle qui assure la persistance. Quand un vaisseau est réclamé pour la première ou à chaque fois qu’il est rangé via le monte-charge d’un hangar, il est stocké dans l’inventaire local.

Chaque fois qu’une entité est rangée dans l’inventaire local d’un lieu, un enregistrement est créé dans la persistance de longue durée. Si c’est un vaisseau qui contient des objets, alors tous ces derniers qui sont configurés pour la persistance à long terme, seront enregistrés dans le LTP, pour être conservés d’un patch à l’autre. Il y a de nombreux cas aux limites, par exemple lorsqu’un joueur stocke un vaisseau avec à l’intérieur un véhicule d’un autre joueur.

Actuellement, la manière la plus sûre de conserver un vaisseau d’un patch à l’autre est de s’assurer qu’il est stocké (“stowed” en anglais) fonctionnel (“claimed” en anglais) dans un inventaire local d’un lieu.

La raison pour laquelle il n’est pas possible de sauvegarder toute la base de données du jeu entre deux patchs est que la structure des entités change régulièrement. Les développeurs sauvegardent donc des macro entités à travers des droits (“Entitlements” en anglais) et recréent les objets à chaque patch.