Alpha 4.10 est disponible sur l'environnement LIVE depuis le 26 août. Siege of Orison y sert de première application à grande échelle d'une nouvelle couche d'instancing intégrée au Persistent Universe.

Lorsqu'un groupe entre dans la mission, Star Citizen peut charger à la demande une zone et son contenu dans une instance séparée. Cette instance reste reliée au monde partagé, mais son exécution est isolée de celle des autres groupes.

Le serveur est alloué en fonction de la demande

La partie intéressante se trouve derrière l'instance elle-même. Chris Roberts explique que le système surveille la charge serveur. Lorsqu'un seuil défini est atteint, des serveurs supplémentaires peuvent être lancés pour absorber de nouvelles instances.

Lorsque ces ressources ne sont plus nécessaires, elles peuvent être retirées.

CIG décrit cette capacité comme son premier cas de serveurs créés et arrêtés dynamiquement en fonction de la charge. Ce n'est donc pas uniquement un système de copies de donjon : il comprend une couche d'orchestration autour de ces copies.

Pourquoi CIG n'appelle pas encore ça Dynamic Server Meshing

Le server meshing dynamique visé à terme doit pouvoir répartir des portions du Persistent Universe entre différentes ressources serveur suivant l'activité. Une zone très chargée pourrait ainsi recevoir davantage de capacité sans nécessiter une architecture fixe définie à l'avance.

Alpha 4.10 ne fait pas encore cela à l'échelle générale du monde.

Le QDSM applique plutôt cette logique à des espaces instanciés. Le serveur ne redécoupe pas Stanton ou Pyro autour de la foule présente dans une ville ; il ajoute des ressources pour gérer des copies supplémentaires d'une activité lorsque des groupes les demandent.

Siege of Orison sert de banc d'essai

La mission accueille des groupes de quatre joueurs maximum. C'est un contexte beaucoup plus contrôlable qu'une zone ouverte contenant des dizaines de vaisseaux, des inventaires persistants, des IA et des joueurs en déplacement permanent.

Ce périmètre limité permet aussi de tester la chaîne complète : demande de l'instance, chargement des données, attribution à un serveur, connexion avec le Persistent Universe puis libération des ressources une fois l'activité terminée.

Le rapport mensuel d'août indique que les équipes ont continué à travailler sur cette technologie après la sortie de 4.10, notamment autour des contenus utilisant déjà les instances.

CIG change aussi la manière dont il trie ses bugs

La semaine de sortie de 4.10 s'est accompagnée d'une communication distincte sur l'expérience LIVE. CIG explique désormais regrouper certains problèmes non plus seulement bug par bug, mais par systèmes dont les joueurs dépendent régulièrement.

Les catégories citées comprennent notamment l'IA, l'inventaire, les hangars et terminaux ASOP, les ascenseurs de fret, le voyage quantique, les erreurs de connexion, le ravitaillement et la perte de vaisseaux.

Deux fois par semaine, QA, Production, Player Experience et Community doivent examiner ces problèmes à partir d'un « Impact Score » combinant notamment fréquence des signalements, nombre de joueurs affectés, ancienneté et gravité.

L'architecture avance, les bugs n'ont évidemment pas signé l'armistice

La liste officielle des problèmes connus d'Alpha 4.10 restait encore fournie début septembre, avec notamment des erreurs de connexion et différents défauts d'interaction. La présence du nouveau système ne signifie donc pas que le problème historique de stabilité de Star Citizen est réglé.

Ce que 4.10 démontre est plus limité : CIG possède désormais en production une infrastructure capable d'allouer dynamiquement des serveurs pour certaines instances du Persistent Universe.

Le passage de cette démonstration à un vrai Dynamic Server Meshing généralisé reste une autre étape.