Star Citizen Live - Tech Talk: Alpha 4.8 w/ Benoit and Jens

Jared souligne à plusieurs reprises que les équipes de développement de Cloud Imperium Games sont frustrées de l'état du jeu, car le personnel est impliqué et est de qualité mais les résultats ne sont pas linéaires : il y a des hauts et des bas, et le patch Alpha 4.8 ne répond pas aux critères attendus.

Les développeurs ont un plan d'action pour que le patch 4.9 soit plus solide et résolve une bonne partie des problèmes.

Jens rappelle que toute solution qui serait facile à implémenter le serait rapidement. A contrario, il n'est pas simple de corriger les bugs sévères rencontrés à court terme.

Après une série de patchs qui ont amélioré l’expérience de jeu et la stabilité, la version Alpha 4.8 est vécue par les joueurs comme un retour en arrière, avec de nombreux crashes. Conscientes du problème, les équipes techniques de Star Citizen sont sur la brèche depuis plusieurs semaines.

Un des premiers problèmes rencontrés est lié à un changement sur le vaisseau Idris qui n’aurait pas dû être déployé sur les serveurs Live. Ainsi, tous les Idris qui avaient été rangés (via le terminal ASOP) et qui étaient rappelés provoquaient le crash du serveur concerné. Les développeurs ont dû intervenir manuellement pour corriger les données de ces vaisseaux.

Ce problème a mis en lumière que les garde-fous (Guard rails) ne sont plus adaptés à la taille du projet et au rythme des sorties de patchs. Ils doivent donc revoir les processus et intégrer davantage d’automatisation. Le projet est tout simplement devenu trop grand pour être contrôlé par l'humain. D'où l'idée d'une future validation machine.

Après une année de mises à jour centrées sur le contenu, les développeurs ont apporté des changements majeurs à des services fondamentaux (comme les systèmes qui gèrent les possessions et la persistance), ce qui a généré des bugs sur des parties du jeu qui étaient stabilisées depuis de nombreux patchs. Pour information : le nouveau système de possession permet de décorréler ce que possède le joueur de la mécanique des patchs. Ainsi, les objets, vaisseaux et personnalisations que le joueur a dans son inventaire peuvent être conservés d’un patch à l’autre.

En fait, les développeurs reconnaissent que la transition depuis un moteur de jeu, conçu pour des FPS avec moins d’une centaine de joueurs, vers un MMO avec des milliers de joueurs, est toujours en cours. Cela signifie d’adapter les services d'arrière-plan, l’architecture réseau, et tous les mécanismes de contrôle et de supervision.

Benoit énumère une partie des systèmes qui doivent passer d'une gestion par les serveurs de jeu vers un fonctionnement dans des services d'arrière-plan, notamment pour être compatible avec le server meshing :

• Le système de mission.
• Le système de transports en commun.
• Le système d'inventaire.

Les compétences nécessaires pour développer les services d'arrière-plan ne sont pas les mêmes que celles mobilisées pour coder les gameplays. Il faut savoir mobiliser les services du Cloud, gérer les échecs…

Pour illustrer la criticité des services d'arrière-plan, dans le patch Alpha 4.8, il est apparu un problème très rare, qui ne concernait que quelques requêtes parmi les millions qui sont faites en quelques minutes. La conséquence était de bloquer l'inventaire des joueurs pendant 8 minutes. Ce problème a été corrigé mais il illustre la fragilité de certains services d'arrière-plan et l'importance de les rendre résilients aux erreurs.

Les développeurs observent les performances des serveurs de jeu et constatent que certains en présentent des bien en dessous de ce qui est attendu. Or, les clients et les serveurs font certains calculs en parallèle afin de fluidifier l'expérience de jeu : la machine du joueur (le client) tourne plus vite et prédit ce qui va se passer afin que le joueur ait une situation fluide, et le serveur vient confirmer ou corriger à la fin de son propre calcul (ce qui crée un retour en arrière ou un "saut" pour le joueur, ce qu'on appelle du "rubberbanding"). Quand ce dernier est rapide, les correctifs sont souvent mineurs et il n'y a pas de désynchronisation. A l'inverse, si le serveur est lent, le risque de divergence s'amplifie.

Il est important de noter que cette architecture permet de conserver une autorité côté serveur, et donc de limiter les possibilités de triche.

Après investigation de ce problème de désynchronisation, il semblerait qu’il provienne de la multiplication des zones dans le jeu. Les développeurs envisagent une série de mesures pour contrer les chutes de FPS dans les zones saturées d'entités.

Lorsque les joueurs font des activités en jeu, ils laissent derrière eux des vaisseaux à l'abandon et des carcasses. Ces entités participent à la surcharge des zones car les serveurs doivent prendre en compte toutes les entités à chaque cycle.

Les développeurs ont déjà mis en place des mécanismes pour nettoyer les vaisseaux inutilisés. En fonction des situations, ces appareils sont rangés ou effacés. S'il reste des vaisseaux qui ne disparaissent pas, alors c'est probablement qu'il reste un problème de configuration des paramètres du vaisseau.

Quand une zone est surchargée d'entités, le système va chercher quel est le vaisseau à enlever en priorité. Pour l'instant, un vaisseau n'est pas nettoyé s'il reste des joueurs à l'intérieur, et il l'est plus prioritairement si celui-ci est détruit que si il est fonctionnel. L'état "décommissionné" (bricked) n'est pas nettoyé plus vite mais c'est en cours de travail.

Des missions demandant aux joueurs de nettoyer les épaves et les vaisseaux décommissionnés pourraient être mis en place, mais cela ne serait pas résilient à toutes les situations. C'est pourquoi des systèmes de nettoyage automatisés sont nécessaires.

Le comportement des joueurs a un effet sur la performance des serveurs. Ainsi, la "méta", c'est-à-dire la manière la plus commune d'utiliser le jeu, affecte les serveurs. Ceci est vrai pour les changements de gameplays, de systèmes (l'assurance, l'imprint des vaisseaux…) ou encore d'équilibrage (quelle profession est la plus rentable).

Benoit énumère une liste de problèmes qui affectent fortement les performances des serveurs de jeu :

• Le système de navigation des PNJ à la surface des planètes qui consomme trop de ressources.
• Certains générateurs d'entités qui entrent dans une boucle qui fait augmenter le nombre de PNJ de manière incontrôlée.
• Un problème de configuration des zones de jeu, qui s'aggrave avec la quantité et la complexité du contenu.
• Le système de nettoyage des vaisseaux, qui n'enlève pas les écrans type MFD de la mémoire alors qu'ils ne sont plus visibles dans le monde.
• Les incendies dans certains vaisseaux complexes consomment beaucoup de ressources serveurs.

Benoit souligne que les performances du patch Alpha 4.8 sont mauvaises, mais que la stabilité reste excellente une fois les problèmes liés à l'Idris corrigés.

A chaque fois que les joueurs se connectent au jeu, ils sont affectés à un shard, c'est-à-dire un ensemble de serveurs connectés à une même base de données dynamique appelée Hydrid, pour la durée de cette session. C'est une architecture différente des MMO classiques qui privilégient généralement l'affectation du personnage à un shard spécifique de manière permanente. Lorsqu'un joueur arrive sur un shard, ses possessions et son avatar sont extraits de la base de données centralisée (on dit qu'il est unstowed). Quand le joueur se déconnecte, son personnage et ses possessions vont être rangés dans la base de données. Cela prend un peu de temps.

Le terme Shardlock a été inventé par les joueurs quand ils ont l'impression de ne pas pouvoir changer de shard. Cela peut être dû à de l'impatience (quitter pour le menu et revenir très vite, faire un ALT-F4…) ou à des bugs dans d'autres cas. Les développeurs vont mettre en place des outils pour mieux surveiller si des joueurs se retrouvent liés à un shard de manière prolongée.

Entre janvier 2024 et janvier 2026, il y a eu une augmentation de 30.1% du nombre de joueurs actifs quotidiennement.

Entre février 2024 et février 2026, il y a eu une augmentation de 63.8% du nombre de joueurs actifs quotidiennement.

Entre mars 2024 et mars 2026, il y a eu une augmentation de 50.2% du nombre de joueurs actifs quotidiennement.

Entre avril 2024 et avril 2026, il y a eu une augmentation de 59.8% du nombre de joueurs actifs quotidiennement.

Entre mai 2024 et mai 2026, il y a eu une augmentation de 14% du nombre de joueurs actifs quotidiennement.

Entre juin 2024 et juin 2026, il y a eu une augmentation de 55.4% du nombre de joueurs actifs quotidiennement.

Cette augmentation d'environ 50% depuis 2024 semble indiquer que le jeu se porte bien et que la stratégie d'apporter de la stabilité et du contenu porte ses fruits.

Les développeurs réfléchissent à montrer le nombre de joueurs de manière transparente.

Suite aux problèmes rencontrés avec le patch Alpha 4.8, Cloud Imperium Games modifie la manière dont les bugs sont priorisés. L'équipe chargée de l'expérience des joueurs va prendre plus de responsabilités dans ce domaine, ce qui devrait accélérer la correction de problèmes qui affectent les joueurs.

Voici quelques exemples des bugs prioritaires sur lesquels les développeurs travaillent :

• Les hangars, en particulier quand les portes s'ouvrent alors que l'intérieur n'est pas encore chargé ; ou que les portes intérieures s'ouvrent alors que les portes extérieures restent fermées ; ou que deux hangars de joueurs se superposent.
• Les vaisseaux qui se retrouvent superposés quand un joueur appelle un appareil depuis un terminal ASOP extérieur au hangar et que ce dernier a été sauvegardé avec un vaisseau à l'intérieur.
• La perte du hangar dans sa résidence principale.
• Les problèmes de connexion au jeu (par exemple 64006 et 64008) qui peuvent provenir du fait qu'un serveur de jeu est chargé de déterminer la position du joueur en début de chargement, et que si ce serveur tombe, le joueurs se retrouve dans un état d'erreur.
• L'amarrage qui peut ne pas fonctionner avec les colliers d'amarrage des stations.
• Les monte-charges, qui peuvent parfois montrer un inventaire vide, afficher une erreur de surcharge…
• Les voyages quantiques, dont le trajet se réinitialise quand il est sélectionné, qui ne trouvent pas de trajet quand il y a un obstacle, qui font passer du mauvais côté d'un astre. Ou encore quand on revient dans le système d'origine après une traversée réussie d'un point de saut.
• Les problèmes de chargement des inventaires.