Star Citizen Live SPECIAL EDITION: A More Stable Universe

Traditionnellement, le début d’année est l’occasion de prendre en compte les enseignements des années précédentes et de planifier les travaux pour l’année à venir.

Cette année, Cloud Imperium Games va changer drastiquement de stratégie, en privilégiant le contenu, la performance et la stabilité au détriment des nouvelles fonctionnalités.

En effet, ces dernières seront travaillées plus lentement en arrière-plan, avec moins de ressources humaines.

Les développeurs vont traquer davantage de métriques pour évaluer la stabilité perçue par les joueurs. Ils vont vérifier que les joueurs peuvent bien se connecter rapidement, que les interactions dans le jeu fonctionnent de manière fiable. Ils vont ainsi corriger les problèmes et mettre en place des systèmes de résilience qui permettent de remettre le système en l’état après un problème.

Améliorer les performances du jeu nécessite de travailler à la fois sur le client, le serveur de jeu et la couche de réplication (ou hybride). Cela signifie entre autres avoir des cycles plus courts, économiser de la mémoire et réduire la latence réseau.

La correction des bugs va être mieux répartie au sein des équipes, avec une implication des développeurs de tous les niveaux d’expérience. Ceci permettra d’éviter la lassitude et d’en faire un objectif partagé.

Pour 2025, les développeurs prévoient un rythme plus ou moins mensuel pour les patchs de contenu, avec davantage de narration. Par le passé, Cloud Imperium Games a déjà voulu faire des patchs mensuels et n’a pas réussi à tenir le rythme.

Les développeurs sont conscients que l’absence de nouvelles fonctionnalités peut affecter l’attractivité du jeu, mais ils semblent y avoir consensus parmi eux qu’il faut changer de méthode.

Moins de développeurs seront alloués à la création de nouvelles fonctionnalités, pour pouvoir les mobiliser pour la correction de bugs et à l’implémentation de nouveaux contenus.

Cloud Imperium Games va également viser une plus grande qualité pour la sortie des patchs.

Jusqu’à présent, les correctifs étaient apportés par des développeurs juniors avec le soutien des plus expérimentés. Désormais, les développeurs seniors vont participer à la correction des bugs.

L’un des enjeux de l’équipe de développement est de concevoir des systèmes qui sont adaptés à la vision du jeu à long terme, afin de ne pas devoir les reprendre plusieurs fois. Ainsi, si un système présente des problèmes et devra un jour être retravaillé, alors ils vont évaluer, dès lors, s'il faut le reconcevoir maintenant.

Cloud Imperium Games souhaite plus de flexibilité dans l’affectation des ressources entre Squadron 42 et l’univers persistant. Ainsi, même si les équipes ont des personnes clés qui resteront concentrées sur leur tâche, une partie d’entre elles pourront changer rapidement en fonction des besoins.

Star Citizen Live et Inside Star Citizen vont continuer à être produits, et seront diffusés le jeudi, en évitant de trop révéler le contenu narratif. Une nouvelle émission dédiée au vaisseau va être ajoutée.

Le patch Alpha 4.0 est l’une des mises à jour les plus importantes pour les fondations du jeu. Les développeurs avaient besoin d’avoir plus de joueurs sur le patch que les serveurs de test pouvaient en attirer. C’est pourquoi, même s’il n’était pas totalement prêt pour les vacances de fin d’année, le choix a été fait de le mettre entre les mains des joueurs dans une version preview. Le patch Alpha 3.24 est resté accessible en tant que plan de secours au cas où l’expérience sur la nouvelle version aurait été mauvaise.

La coexistence des patch Alpha 3.24 et Alpha 4.0 a permis de pouvoir réaliser des comparaisons sur la charge des serveurs.

Lorsque le patch Alpha 4.0 est sorti sur les serveurs de test, les développeurs ont été surpris par le fait que les fonctionnalités qui tournaient sur l’architecture du patch Alpha 3.24 n’avaient pas les mêmes performances.

Pendant les quatre derniers mois, le focus a été de terminer l’adaptation des technologies et fonctionnalités au server meshing. Quelques exemples :

Le rayon de streaming, qui détermine les objets qui doivent être envoyés aux machines des joueurs était trop important, ce qui causait une charge importante sur la couche de réplication et une charge réseau excessive. Les développeurs ont dû adapter ce mécanisme.

Le nombre de joueurs par shard a dû être configuré. Ainsi, les développeurs ont tablé sur un maximum de 500 à 600 joueurs par shard. Ceci correspond à un compromis entre la performance des serveurs et le nombre d’entrées de hangars disponibles dans les différents lieux.

Le déplacement instantané d’une entité (sorte de téléportation), qui est utilisé quand un joueur réapparaît après être mort, a dû être adapté au contexte de server meshing. L’enjeu est de pouvoir transférer l’entité d’un serveur à un autre au sein d’un même shard.

En attendant le server meshing dynamique, la version statique nécessite une configuration des zones de responsabilités des serveurs au sein d’un shard. Actuellement, les développeurs allouent cinq serveurs à chaque système (Stanton et Pyro), avec un serveur pour l’espace et les points de saut, et un serveur pour chaque planète.

Les développeurs espéraient que le server meshing allait améliorer les performances, et ça n’a pas été le cas car ils n’ont pas assez poussé l’optimisation de ces dernières. Cloud Imperium Games a donc mis en place une organisation pour pouvoir améliorer le code sous la forme d’opérations “coup de poing” et amener les traitements des serveurs entre 15 et 20 cycles par seconde.

Le patch Alpha 4.0.1 a permis de résoudre de nombreux problèmes fondamentaux, mais a également apporté des régressions majeures dans l’expérience utilisateur. Ainsi, les fondations sont meilleures mais ce n’est pas encore perceptible par les joueurs.

L’affectation à un shard repose sur un système d’affinité en fonction de la présence de membres de groupe, d’amis, ou d’un passage précédent sur ce shard.

Désaffecter un personnage d’un shard pour qu’il puisse accéder à un autre prend actuellement plusieurs minutes, et les développeurs n’ont pas encore trouvé de solution pour accélérer ce processus.

Les développeurs réfléchissent à mettre en place un créneau de maintenance régulière.

Quand un personnage charge le jeu, toutes les entités mises en mémoire doivent avoir un serveur qui a autorité sur elles. Il est possible pour le système Pyro, qu'une entité indispensable soit placée sur un serveur devant être rebooté, conduisant à de longs temps d’attente.

Quand les joueurs rencontrent des problèmes, ils trouvent ou essaient des solutions de contournement, comme quitter le jeu, tenter de changer de shard, lancer l’Arena Commander avant de revenir à l’univers persistant… Ces comportements ont permis de mettre en lumière des problèmes d’accès concurrents aux données, qui n’étaient pas apparus dans les phases de tests.

Les joueurs ne sont pas bloqués dans un shard mais leur personnage ne peut être chargé que dans un seul à la fois. Ainsi, si ce dernier est chargé dans un shard et que ce dernier n’est pas accessible, alors le personnage sera bloqué temporairement le temps que le shard se rétablisse et le libère.

Le système de transit (ou de transports en commun) date et est composé de nombreux sous-systèmes (stations, panneaux d’affichages, rames…) Dans un jeu classique, toutes les entités du système de transit seraient chargées en mémoire de manière permanente. Dans Star Citizen, le système est déchargé quand personne n’est à proximité, afin d’économiser des ressources. Tout cela doit être adapté à un contexte de server meshing. Les développeurs ont donc deux équipes sur le sujet : une qui travaille sur le futur système qui sera plus stable et résilient, et l’autre qui apporte des correctifs au système actuel pour qu’il soit jouable.

Les hangars sont instanciés. Ils sont chargés quand un joueur appelle l’ascenseur depuis l’intérieur ou quand il demande à pouvoir atterrir depuis l’extérieur. Tous les hangars des joueurs sont instanciés au même endroit, mais chaque joueur ne voit que celui dans lequel il est. Cette architecture en millefeuille représente quelques défis, tant pour la simulation physique que pour l’affichage ou le son.

Les ascenseurs pour vaisseaux présentent plusieurs problèmes. Par exemple, l’ascenseur lui-même est déplacé de manière autoritaire (ce n’est pas une simulation physique) alors que la position et l'attitude du vaisseau posé dessus répondent à une simulation. Ils obéissent donc à des lois différentes. Les développeurs envisagent d’appliquer la même solution pour les deux éléments.

Des objets disparaissent parfois des inventaires. L’une des causes est un problème de configuration des objets. En effet, pour éviter de saturer les serveurs, certains éléments de jeu ont une durée de vie limitée. A la fin de ce minuteur, ils sont retirés du serveur. Des objets pouvant être ramassés par les joueurs ont parfois ce paramètre de durée de vie activé mais c’est une erreur de configuration.

Le système de persistance à long terme (LTP) enregistre certains types d’objets dans un registre quand ils sont rangés, afin de pouvoir recréer la base de données quand un nouveau patch requiert un effacement. Ainsi, les objets qui sont dans le monde ne sont pas enregistrés. De plus, certains objets peuvent être stockés avec d’autres objets à l’intérieur. Enfin, certains objets achetés avec de l’argent réel reposent sur un autre processus. La complexité du système et le nombre d’objets font qu’il existe des problèmes dans certaines situations. Les développeurs souhaitent que la base de données soit plus stable et qu’ils puissent appliquer des transformations aux données qui ont été changées à l’intérieur de celle-ci.

Les vaisseaux ne devraient jamais disparaître quand un joueur est à l’intérieur.

Le patch Alpha 4.0 introduit un changement radical dans la manière dont les missions sont gérées. Avant, une entité invisible était créée sur le serveur de jeu pour piloter chaque mission. Désormais, un système indépendant des serveurs de jeu prend en charge le déroulement de l’ensemble des missions.

Le patch Alpha 4.0 a réduit la variété des missions sans réduire la quantité de problèmes rencontrés. En fait, la création des missions repose toujours sur un ancien système de scripts, qui est obsolète. Cela rend la création de missions compliquée. Les développeurs travaillent sur un nouveau système de création de missions qui devrait permettre d’en créer plus rapidement et avec plus de variété et de qualité.

Il y avait un bug qui conduisait à payer l’intégralité de la récompense d’une mission à l’ensemble des joueurs qui la partageait. Ce bug a été corrigé mais en fait, il répondait à l’objectif des développeurs d’encourager le jeu en groupe.

Le passage au server meshing a engendré de nombreux problèmes liés à la transition entre deux serveurs. Les équipes travaillent à corriger ces régressions.

La prison est un ancien système qui doit être adapté au nouveau système de mission.