Présenté par Paul Reindell et Ben Beauséjour, cette conférence sur le serveur meshing permet de faire un point sur les avancées de cette technologie essentielle au développement de Star Citizen. Elle permet d'optimiser la communication entre les différents clients et les serveurs du jeu.
L'absence de chargement entre les zones dans Star Citizen rend la conservation des données de l'ensemble de l'univers particulièrement difficile. La plupart des autres jeux multijoueurs résout ce problème par un système d'instances statiques.
L'idée du serveur meshing est de diviser l'univers sur différents serveurs et ainsi faire un système d'instances dynamiques.
Introduction
Les données dans l'univers
Pour commencer, il faut tout d'abord comprendre comment est organisé l'univers. Les objets sont hiérarchisés. Stanton contient des planètes dans lesquelles se trouvent des lunes dans lesquelles se trouvent des avant-postes et ainsi de suite jusqu'au mug et stylo posés sur le bureau d'une colonie.
Cette cascade de groupes d'objets est appelé "Object container entities" et ensemble ils regroupent toutes les entités/assets de l'univers.
"OCS" et "Identity Bind Culling"
Il est impossible pour un client de charger tous les entités de l'univers lors de la connexion. La demande en mémoire et CPU serait trop importante et rendrait impossible la communication en temps réel avec le client du joueur.
Par conséquent, la première étape est de charger uniquement les "objets containers entities" proches du joueur et lorsqu'il perd le visuel, l'entité se décharge et retourne à son état dormant. Cela permet d'optimiser les performances. Ce système s'appelle l'identity bind culling, en relation avec l'OCS "object container streaming".
Cependant Star Citizen est un jeu multijoueur, par conséquent de nombreux joueurs arpentent le système Stanton en simultané, et il n'est pas improbable que suffisamment de joueurs soient présents et repartis dans l'univers pour au final finir par générer l'ensemble des entités malgré cette optimisation.
Par conséquent ce système a ses limites.
Server Meshing
Pour continuer à améliorer les performances, l'équipe a eu une nouvelle idée, plus complexe mais nettement plus intéressante au niveau des performances : le "server meshing".
Actuellement, il existe des serveurs uniques de jeu avec un maximum de 50 clients. Chaque serveur est unique avec ses propres données.
Le "server meshing" a pour objectif de diviser un même univers en de nombreux serveurs différents. Pour cela, l'équipe a introduit de nouveaux outils.
Replication Layer et Server nodes
Le principe du server meshing est de réorganiser cette structure avec une interface intermédiaire appelée "Replication Layer" entre les différents serveurs et les clients. Cette interface contrôle les IA et simule le monde grâce aux différents servers nodes et, inversement, prend les infos des interactions avec les clients et les transmet au serveur. Mais ce n'est pas son unique fonction, comme nous le verrons par la suite.
L'Entity Graph
"L'Entity Graph" représente une banque de mémoire à l'instant T de toutes les entités dans l’univers : leur position, orientation, état ...
Il récupère, en permanence, les informations de l'univers. Pour cela il est organisé à partir des "object container entities" comme expliqué précédemment, cela permet de conserver les liens entre les objets.
Par exemple : si votre Ursa est dans la soute du constellation. L'OC du véhicule avec ses sous-entités (composants/equipements) se retrouvent attachés à l'OC du vaisseau constellation.
C'est en résumé une énorme base de donnée en temps réel et dynamique.
Certaines entités sont statiques comme les stations spatiales et d'autres sont variables. Ce sont ces dernières qui s'attachent à différents OC en fonction des interactions des joueurs et des IA dans l'univers.
Shard
Enfin, le dernier élément à identifier est le shard qui est une instance contenant un entity graph dédié, un replication layer et des server nodes.
En première itération, les shards seront statiques et spécifiques à des zones de l'univers.
En pratique ça donne quoi ?
Sur un exemple simple, le fonctionnement d'un shard est le suivant :
Un joueur monte dans le Constellation avec un Ursa rover, le client soumet l'information au replication layer qui va alors transmettre l'information à l'entity graph qui va ajouter l'Ursa rover à l'object container entity du Constellation. Si le client se déconnecte puis se reconnecte, le replication layer va récupérer l'information dans l'entity graph et ainsi le joueur va retrouver son Ursa dans la soute de son constellation.
Il existe plusieurs shards. Quand il rejoint le jeu, le joueur est affecté à un shard qui lui est adapté. Un shard aura une experience vécue qui sera différente d'un autre. Ainsi deux joueurs qui sont dans l'univers peuvent trés bien trouver le même PNJ à deux endroits différents, l'un l'observe au bar de Lorville et l'autre devant l'hopital Maria Pure of Heart. Pour que deux joueurs puissent jouer ensemble ils doivent rejoindre le même shard.
Pour ne pas perdre d'objet entre deux shard, il existe le global inventory.
Global inventory
Le "global inventory" représente l'ensemble des objets qui ne sont pas présent physiquement dans l'univers.
Par exemple quand on fait apparaitre un vaisseau, il sort du "global inventory" pour apparaitre physiquement en jeu. A l'inverse lorsqu'on le range il retourne dans le "global inventory".
De manière générale, toute objet n'ayant plus de lien avec personne dans un shard est renvoyé vers le "global inventory".
Conclusion
Cette nouvelle organisation du réseau apporte de nombreux avantages.
- Si un server node plante, le client pourra temporairement s'appuyer sur le replication layer le temps qu'un autre serveur node prenne le relais. Actuellement, le client crashe complétement.
- La gestion dynamique des entités à travers les shards permet d'améliorer nettement les performances.
De nombreux challenges restent encore à résoudre pour l'équipe.
- maintenir la communication entre les outils de quantum et quasar avec les différents shards.
- gestion du chat global entre les shards.
- interactions des missions utilisant plusieurs shards.
Cette conférence nous apporte encore un peu plus de détails sur le "server meshing" et nous pouvons constater l'avancement au fur et à mesure que le développement progresse. Il est à noter qu'il est rare dans le domaine des jeux vidéo en ligne de partager autant sur son architecture réseau. Ces compétences et outils sont particulièrement compétitifs dans le domaine.
