
Server Meshing
Timeline 2025
Les voyages quantiques sont en train d’être adaptés au server meshing.
La refonte des services sociaux d'arrière-plan est terminée. Il s’agissait notamment de les transposer à la technologie gRPC et de les préparer pour le server meshing.
L’objectif actuel pour le patch 4.0 avec le “Server Meshing” et Pyro est l’été 2024. Des tests seront effectués sur les “Tech Preview Channels” :
L’interdiction quantique a été adaptée au “server meshing”.
Des progrès solides ont été réalisés en vue du “server meshing” dynamique.
L’interdiction quantique est en train d’être adaptée au contexte du “server meshing”. La fonctionnalité ne sera pas changée.
L’équipe travaille sur le “server meshing” dynamique, en particulier sur la séparation des serveurs de jeu de la gestion des territoires. L’objectif est de redistribuer la charge serveur en fonction du nombre d’entités et de joueurs.
Des changements sont apportés aux entités afin de les préparer au server meshing dynamique.
Pendant les quatre derniers mois, le focus a été de terminer l’adaptation des technologies et fonctionnalités au server meshing. Quelques exemples :
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.
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.
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.
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.
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.
Les travaux nécessaires pour adapter pleinement au server meshing les composants de l’intelligence artificielle sont en phase de planification.
Dans le cadre du server meshing, plusieurs services d'arrière-plan essentiels ont été finalisés, comme ceux pour les missions, les scénarios et le social.
Le nouveau système de missions a reçu des changements critiques dans le cadre de son adaptation au server meshing. Ceux-ci doivent permettre la continuité des missions lors du franchissement d’une frontière entre serveurs ou encore lors de récupération après un crash de serveur.
Refonte du système de mission Refonte du système de mission pour le rendre compatible avec le Server Meshing, permettant ainsi de faciliter la création et la maintenance des missions.
Server Meshing V1 L'implémentation initiale du Server Meshing permettra d'avoir plusieurs serveurs par shard afin d'améliorer la répartition de la charge et de faciliter la navigation entre deux systèmes planétaires.
Les complications sont les mêmes que pour la coupe des arbres. Il faut prendre en compte le server meshing, la persistance, etc, cela fait beaucoup d'informations. Il faut différentier les arbres notables (près des camps et points d'intérêt) et essayer d'être plus générique (par exemple définition par zone), dans le cas de zones plus denses ou moins fréquentées. Il n'y a aucune garantie aujourd'hui, mais ils étudient les possibilités.
L’équipe continue de travailler sur le server meshing, en particulier sur la synchronisation de Subsumption entre les serveurs de jeu. Ainsi, les personnages non joueurs peuvent continuer leur comportement en cours lorsqu’ils changent de serveur.
Les changements nécessaires au système social dans le cadre de l’adaptation au server meshing sont en phase de tests internes.
Après évaluation du support requis pour le Server Meshing, Pyro et la stabilité générale de la 4.0, nous avons décidé de retirer temporairement plusieurs livrables de cette mise à jour afin de libérer les ressources d’ingénierie nécessaires à la préparation de son lancement. Ceci inclut le gameplay d’ingénierie, le support de vie, les incendies et les extincteurs, le chargement/déchargement et la refonte du système de transport. Nous sommes conscients que beaucoup d'entre vous attendaient avec impatience ces fonctionnalités, en particulier le gameplay d’ingénierie, mais soyez assurés que nous sommes déterminés à les réintégrer dès que possible.
Le patch Alpha 4.0 est un patch technique, dans le sens où il apporte des changements fondamentaux dans les technologies du jeu avec le “server meshing”.
Avec l’arrivée du server meshing, le nombre de joueurs par shard (c’est-à-dire qui peuvent se rencontrer lors d’une session de jeu) va drastiquement augmenter. Dans ces conditions, le nombre de lieux actuellement présents dans le ‘Verse ne seront pas suffisants et créer des lieux à la main nécessiteraient trop de ressources.
L’équipe se prépare au déploiement du server meshing dans l’univers persistant. Ceci consiste en une série de Tech-Preview pour augmenter le nombre de joueurs par serveur.
L’équipe s’est concentrée sur le server meshing, pour améliorer le passage d’informations entre serveurs.
La refonte du système de missions se poursuit, ce qui inclut 1700 enregistrements de missions rien que pour Stanton. L’objectif est d’adapter les missions au contexte de server meshing tout en simplifiant le travail des développeurs, sans changement pour les joueurs.
Le système de transit est en cours de refonte complète dans le cadre du server meshing.
La vitesse des cycles du serveur (server framerate) a un effet direct sur la simulation de la physique et le comportement des personnages non joueurs. C’est une information que les joueurs peuvent voir en jeu et en sentir les effets. Les développeurs cherchent constamment à améliorer la vitesse du cycle, grâce à des optimisations et en répartissant la charge grâce au server meshing.
Le service d’échange d’UEC entre joueurs fonctionne désormais dans un environnement de server meshing.
Les développeurs espèrent qu’avec le server meshing activé, le patch Alpha 4.0 aura un cycle serveur plus rapide et offrira en conséquence une meilleure expérience de combat contre les personnages non joueurs.
Le système d’échange d’UEC entre joueurs est en train d’être adapté au server meshing.
Les travaux se poursuivent sur la vision et le déplacement des personnages non joueurs dans le cadre du server meshing. Ceci leur permettra de passer d’un serveur à un autre sans perte de contexte.
Dans d’autres cas, des données redondantes étaient envoyées à la couche de réplication, provoquant des problèmes de performance. Il y a donc des actions dans toutes les équipes pour convertir les fonctionnalités existantes à cette nouvelle architecture. L’équipe chargée du server meshing a mis en place des outils pour monitorer les performances de la couche de réplication et des serveurs de jeu, pour guider les autres équipes dans leurs efforts.
La première étape a été l’introduction de la couche de réplication (replication layer) dans le patch 3.18. L’un des bénéfices de cette technologie est la capacité à récupérer après un crash de serveur. Le premier enseignement de ce test a été que la technologie fonctionne globalement très bien, que les principes sont bons. La couche de réplication fonctionnelle offre des bases solides pour un développement plus rapide du reste du server meshing.
Le développement du server meshing s’est fait en plusieurs étapes, chacune testant une partie du système. Les backers ont beaucoup de créativité pour tester les limites du système. Ainsi, chacune des phases de test (appelées Tech Preview) a révélé des problèmes et axes d’amélioration.
De nouveaux tests sont nécessaires en prévision du patch Alpha 4.0 qui verra plusieurs systèmes découpés en de multiples territoires gérés par plusieurs serveurs de jeu. A partir de ce point, les efforts porteront sur le server meshing dynamique, qui devra équilibrer la charge des serveurs de jeu.
Une fois la couche de réplication fonctionnelle, les développeurs ont conduit un test avec deux serveurs de jeu connectés à la même couche de réplication, ce qui correspond à un premier essai de server meshing. Encore une fois, ce test s’est bien mieux déroulé que ce à quoi s’attendaient les développeurs. Le seul bémol pour eux, c’est que le point de saut a dû être descopé de l’expérimentation à la dernière minute. Un autre test avec un point de saut fonctionnel entre Stanton et Pyro a donc été organisé, et les développeurs ont pu constater le bon fonctionnement de la transition entre les deux systèmes.
Les développeurs se sont aussi rendus compte que certaines parties du code n’étaient pas adaptées au server meshing, notamment car des bugs sont apparus du fait de la capacité à récupérer après un crash. L’un des scénarios les plus critiques se produit quand un serveur de jeu envoie des données erronées dans la couche de réplication avant de crasher, provoquant un crash systématique de tous les serveurs de jeu qui essaient de prendre le relai.
Un système de région pour les entités a commencé son développement. Il s’agit de gérer la durée de vie des entités générées procédurallement, fonctionnalité indispensable pour les entités persistence, le rétablissement après un crash et le server meshing.
Des investigations sont en cours pour améliorer la syntchronisation des données de l’intelligence artificielle entre les serveurs et les clients dans le cadre du server meshing.
Les travaux se poursuivent pour l’implémentation de la première version du server meshing.
Les voyages quantiques sont en train d’être adaptés au server meshing.
La refonte du système de mission, nécessaire pour l’adaptation au server meshing, est en phase de planification.
Les travaux nécessaires pour adapter le système d’inventaire au server meshing ont été définis.
L’équipe a commencé à travailler sur des fonctionnalités candidates pour le patch 4.0, comme la refonte des systèmes de mission et de marqueurs, ou encore le commerce dans le cadre du server meshing.
Server Meshing V1 L’implémentation initiale du Server Meshing permettra d’avoir plusieurs serveurs par shard afin d’améliorer la répartition de la charge et de faciliter la navigation entre deux systèmes planétaires.
Refonte du système de transport Refonte du système de transport utilisé pour les trams et les ascenseurs afin de le rendre compatible avec le Server Meshing et de le rendre plus robuste.
Refonte du système de mission Refonte du système de mission pour le rendre compatible avec le Server Meshing, permettant ainsi de faciliter la création et la maintenance des missions.
Mise à jour de la couche de réplication Au cours du cycle de patchs de la 3.23, la couche de réplication sera séparée des serveurs du jeu pour devenir un service autonome. À court terme, cela permettra une meilleure récupération des serveurs en cas de crash. Il s’agit également d’une étape cruciale vers le Server Meshing.
La refonte des services sociaux d'arrière-plan est terminée. Il s’agissait notamment de les transposer à la technologie gRPC et de les préparer pour le server meshing.
Les travaux ont débuté sur la technologie Planet Tech v5. L’équipe est en train de déterminer comment le partitionnement spatial va fonctionner avec le server meshing et la récupération en cas de crash. Le concept de planètes par défaut (default planets) a été introduit pour faciliter les tests internes.
Les services d’arrière-plan liés aux fonctions sociales ont été remaniés, notamment pour le portage vers gRPC et l’adaptation au server meshing.
Avec l’alpha 3.18, notre première mise à jour majeure de 2023, l’équipe a livré le Persistent Entity Streaming (PES), la technologie fondamentale requise pour le Server Meshing (SM). Comme mentionné dans la dernière lettre, le PES est la plus difficile des technologies requises pour le SM et celle qui a nécessité le plus d’ingénierie, de sorte que surmonter les défis de cette mise à jour l’année dernière était essentiel. Le lancement de l’alpha 3.18 a été beaucoup plus délicat que prévu, et nous avons découvert des problèmes avec notre base de données backend qui n’étaient visibles qu’à l’échelle d’une version live, contrairement aux serveurs de test PTU. Par ailleurs, nous avons découvert de nombreux petits problèmes liés à un univers vraiment persistant ; alors qu’il est extraordinaire de tomber sur une épave provenant d’un combat entre joueurs ayant eu lieu il y a une semaine, il est moins agréable d’essayer de se poser dans un hangar où les trois derniers vaisseaux se sont écrasés et ont laissé des débris autour, bloquant votre plateforme d’atterrissage. Nous avons progressivement résolu ces problèmes et bien d’autres encore, mais ce fut une période difficile tant pour les développeurs que pour la communauté. Ces obstacles ont non seulement mis à l’épreuve nos compétences et notre détermination, mais ils ont également démontré notre résilience à mesure que nous les surmontions.
En 2024, notre projet de Server Meshing atteint son apogée après des années de travail acharné. Nous nous rapprochons de la vision initiale que nous nous étions fixée.
L’autre grande étape de 2023 a été l’accueil de l’équipe de Turbulent au sein de la famille CIG. Partenaires depuis fin 2012, Turbulent a été en charge d’une grande partie de notre infrastructure réseau et a grandement contribué à notre croissance et à notre succès. Cette acquisition nous permet de rationaliser nos efforts et nous donne officiellement une présence significative à Montréal, au Canada, une pépinière de talents dans le domaine du jeu vidéo. Dans le cadre de cette acquisition, nous avons accueilli deux cadres supérieurs clés : Benoit Beausejour, le directeur technique de Turbulent, qui devient maintenant le directeur technique de Cloud Imperium et le chef de notre groupe de technologie fondamentale (Core Technology Group ou CTG). Vous connaissez déjà Benoit avec à ses présentations sur le Server Meshing lors des deux dernières CitizenCon. Le second cadre à rejoindre nos rangs est Marc Beaudet, auparavant PDG de Turbulent, et qui devient notre vice-président senior en charge des opérations et du bien-être du millier de personnes travaillant sur Star Citizen et Squadron 42, réparties entre nos cinq bureaux d’Austin (Texas), Los Angeles (Californie), Manchester (Angleterre), Francfort (Allemagne), et désormais Montréal (Canada).
Vous étiez là pour l’emblématique retournement de casque et la première ouverture des portes du hangar dans l’alpha 0.8. Ensemble, nous avons commencé à explorer la vaste étendue de l’Univers persistant dans l’alpha 2.0, et vous étiez présents lors du premier atterrissage planétaire dans l’alpha 3.0. Bientôt, nous quitterons le système Stanton pour nous aventurer dans les étendues désertiques et sans foi ni loi du système Pyro dans l’alpha 4.0 grâce au Server Meshing. Et au-delà, la 1.0 de Star Citizen se profile à l’horizon ! Jamais l’avenir n’a été aussi radieux !
En ce qui concerne Star Citizen, les équipes se préparent à livrer le Server Meshing et à élargir l’univers vers de multiples systèmes stellaires.
Vous vous demandez peut-être pourquoi je vous raconte cette histoire : eh bien, un peu avant la date historique du 10 avril, nous avons organisé notre propre célébration du Jour du premier saut sur le canal de test Tech Preview ce week-end ! Pour tester nos progrès en matière de Server Meshing et de Replication Layer (couche de réplication), nous avons ouvert nos premières portes de saut fonctionnelles et permis à des joueurs de tester le voyage entre deux systèmes pour la première fois de notre histoire ! Les joueurs ont pu voyager entre Stanton et Pyro via des trous de ver, chaque système se chargeant et se déchargeant de façon fluide. Pour ceux que cela intéresse, le “Nick Croshaw” de notre ‘verse est un membre Evocati appelé “MrTrash” qui, selon nous, a été le premier de la communauté à réussir ce saut ! Pendant le test, il est intéressant de souligner que nous avons également atteint 350 joueurs dans une seule shard (par exemple, une couche de réplication avec deux serveurs connectés), établissant ainsi un nouveau record de joueurs présents dans une seule instance dans Star Citizen !
Une refonte du système de mission en prévision du server meshing est en cours de réalisation.
Pour l'adaptation au server meshing, un soutien a été apporté pour les voyages quantiques et les marqueurs lors des transitions vers un autre système stellaire.
Des progrès ont été réalisés sur le “server meshing” et la résilience aux crashs.
Le système de transports en commun a été adapté au “server meshing”, et pour prendre en compte la récupération aux crashs lorsqu’un personnage est dans un transport.
L’objectif actuel pour le patch 4.0 avec le “Server Meshing” et Pyro est l’été 2024. Des tests seront effectués sur les “Tech Preview Channels” :
Les fonctionnalités suivantes sont visées pour le premier semestre 2024, car elles ne dépendent pas de l’implémentation du server meshing :
Bien que nous prévoyions d’utiliser le canal de prévisualisation pour la séparation de la couche de réplication, le Server Meshing et d’autres technologies fondamentales, celles-ci ne feront pas partie du lancement initial.
Ce playtest inclura-t-il la séparation de la couche de réplication ou le Server Meshing ?
C’est là qu’intervient le canal de prévisualisation, un nouvel environnement dans lequel nous déployons et testons de nouvelles technologies fondamentales dans un environnement isolé afin de protéger la fiabilité et la jouabilité du service Live. Les technologies fondatrices à venir, telles que la séparation de la couche de réplication et la récupération en cas de crash, seront d’abord déployées sur ce canal. Ces technologies seront testées et renforcées sur ce canal avant d’être transférées sur le PTU pour une migration vers le service Live. À l’avenir, lorsque nous serons prêts à livrer le Server Meshing, vous pouvez vous attendre à ce qu’il passe d’abord par le canal de prévisualisation pour que ses effets soient observés et testés avant qu’il ne passe au PTU. Toute nouvelle technologie sur le canal doit être validée, évaluée et, en fin de compte, éprouvée avant une sortie sur les serveurs Live.
Mise à jour de la couche de réplication (NOUVEAU) Au cours du cycle de patchs 3.21, la couche de réplication sera séparée des serveurs du jeu pour devenir un service autonome. À court terme, cela permettra une meilleure récupération des serveurs en cas de crash. Il s’agit également d’une étape cruciale vers le Server Meshing.
En bref, il s’agit de la prochaine étape du test des composants du Server Meshing après le déploiement du Persistent Entity Streaming en début d’année. Pour l’instant, les serveurs du jeu ne géreront que le système Stanton, de sorte que vous ne constaterez pas beaucoup de changements dans votre expérience in-game, mais il s’agit d’une étape cruciale pour avancer vers l’alpha 4.0 et au-delà.
Pour plus d’informations sur la couche de réplication, le Persistent Entity Streaming, le Server Meshing et la façon dont tout cela affectera l’avenir de Star Citizen, veuillez consulter notre panel de la CitizenCon 2021 : CitizenCon 2951 : Server Meshing et l’état de la persistance.
Le premier projet à intégrer ce nouveau canal d’aperçu technologique est la couche de réplication (Replication Layer), une composante réseau essentielle de l’infrastructure du Server Meshing. Dans cette mise à jour, la réplication du réseau du jeu et son état sont séparés des serveurs du jeu et constituent un service à part entière. Les clients sont connectés à ce nouveau service et les serveurs du jeu eux-mêmes deviennent des clients ayant autorité sur la couche de réplication. Avec la réplication déplacée hors des serveurs du jeu, l’équipe espère commencer à tester la récupération en cas de crash serveur sans déconnecter les clients du jeu de l’état de l’univers sur une instance donnée.
En bref, il s’agit de la prochaine étape du test des composants du Server Meshing après le déploiement du Persistent Entity Streaming en début d’année. Pour l’instant, les serveurs du jeu ne géreront que le système Stanton, de sorte que vous ne constaterez pas beaucoup de changements dans votre expérience in-game, mais il s’agit d’une étape cruciale pour avancer vers l’alpha 4.0 et au-delà.
Notre objectif est de mettre le Server Meshing statique et Pyro entre les mains des joueurs au quatrième trimestre 2023. Cet objectif est assorti d’une réserve importante : il est difficile d’estimer et de planifier avec précision des travaux d’ingénierie compliqués qui impliquent un paradigme totalement nouveau et nécessitent une multitude de nouveaux services backend. Il est difficile d’estimer et de planifier la technologie avec précision, car les questions et les problèmes qui peuvent surgir en cours de route sont difficiles à prévoir quand personne n’a mis en œuvre ce système auparavant, et les plans survivent rarement au contact avec les utilisateurs, surtout à grande échelle. Cela s’est avéré vrai pour le PES, car ce n’est un secret pour personne que nous espérions avoir l’alpha 3.18 et la sortie du PES sur les serveurs Live pour la fin de l’année, et pas seulement sur le PTU. Les retards dans la finalisation de la 3.18 et du PES ont un impact sur la capacité de l’équipe à entamer la prochaine étape, et nous avons encore des inconnues sur la façon dont le PES se comportera après des mois de forte charge, et vous pouvez constater la quantité de déchets spatiaux que les gens peuvent laisser autour !
Ensuite, nous continuerons à “consolider” le PES, en améliorant certains aspects et en ajoutant des fonctions supplémentaires de qualité de vie, notamment la possibilité de choisir le shard PES que vous souhaitez rejoindre. Le matchmaking actuel entre les serveurs du jeu et le shard PES essaie de vous faire correspondre au dernier shard dans lequel vous étiez lorsque vous vous reconnectez ou récupérez après un crash, mais si ce shard est plein, il vous place dans un autre. À court terme, avant que le Server Meshing ne rende cela moins nécessaire, nous voulons aussi donner aux joueurs le choix d’attendre dans une file d’attente pour leur shard préféré si celui-ci est plein.
Une fois que cela sera fait, nous pourrons faire communiquer plusieurs serveurs du jeu avec la RL (tout comme plusieurs clients communiquent actuellement avec la RL), ce qui permettra à Star Citizen d’avoir plusieurs serveurs simulant l’état de l’univers, ce que nous appelons le Server Meshing (SM).
Nous allons commencer par le Server Meshing statique, où différents serveurs sont affectés à la simulation de différentes zones d’entités dans un système stellaire. Les zones d’entités, parfois appelées grilles locales, sont des zones de simulation distinctes ; l’intérieur d’un vaisseau spatial est une zone différente de l’espace autour duquel le vaisseau vole. Une planète est une zone différente de la zone du système stellaire dans laquelle se trouvent toutes les planètes et les lunes, et une zone d’atterrissage peut également être une zone différente, imbriquée dans la zone de la planète, imbriquée dans la zone du système stellaire.
Dans un premier temps, les serveurs seront liés à des zones fixes, mais nous passerons rapidement au Server Meshing dynamique V1, où nous affecterons dynamiquement les serveurs aux zones d’entités, en fonction de la charge du jeu et de la simulation. Il s’agira d’une utilisation beaucoup plus efficace des serveurs dans le cloud, car vous n’avez besoin de serveurs que là où se trouvent les joueurs, alors qu’avec le Meshing statique, vous avez des serveurs affectés à des zones, même si aucun joueur ne s’y trouve.
La V2 du Server Meshing dynamique ira encore plus loin dans l’affectation dynamique des serveurs en subdivisant les zones d’entités en “îlots de simulation” (il s’agit d’organiser les objets dynamiques d’une zone/grille locale en différents groupes, en fonction des objets qui peuvent interagir/entrer en collision les uns avec les autres), ce qui permettra de répartir ces îlots entre les serveurs afin d’équilibrer la charge de la simulation.
Ceci est très important pour le Server Meshing, car l’état de l’univers doit être totalement découplé de celui du serveur. Cela rendra également Star Citizen beaucoup plus résistant aux crashs du côté client, car un crash de serveur n’entraînera plus l’arrêt de la RL, ce qui signifie que les clients peuvent rester connectés pendant qu’un nouveau serveur prend le relais là où le précédent s’est arrêté. La vision que chaque client a de l’univers qui l’entoure sera un peu plus fluide et moins décalée, car la mise à jour et le rafraîchissement de l’état des objets par le client ne seront plus liés à la fréquence du serveur du jeu. Cela signifie que les joueurs verront les changements d’état des autres clients et des serveurs du jeu au moment où ils se produisent, à la vitesse à laquelle les différents clients et serveurs les transmettent.
Comme vous le savez, le PES et les technologies ultérieures (Server Meshing) vont changer les fondations de Star Citizen pour toujours et permettre de faire un pas de géant pour concrétiser la vision de ce que notre univers partagé est censé être. Il n’est pas surprenant que nous ayons une cadence anormale cette année et nous sommes reconnaissants pour votre soutien à l’heure où nous franchissons ces étapes majeures.
De plus, il y aura une alpha 3.19 à la fin du quatrième trimestre, avec une méthodologie de test similaire à celle de la 3.18 pour la sortie initiale du Server Meshing, du système Pyro et plus encore dans l’alpha 4.0. Par conséquent, vous verrez que la colonne 3.19 a été mise à jour pour une sortie au quatrième trimestre 2022.
Il nous reste notre troisième grande initiative technique, le Server Meshing.
Le développement n’a pas été sans heurts ; nous avons dû modifier nos plans sur la façon dont nous allions faire persister l’état de l’univers lorsque nous avons réalisé que la base de données relationnelle en backend que nous avions prévu d’utiliser avec une foule de services, que nous avions collectivement baptisée “iCache”, ne serait probablement pas en mesure d’avoir une faible latence à l’échelle nécessaire pour le nombre de joueurs simultanés que nous devrons prendre en charge à l’avenir. Nous sommes passés à l’utilisation d’une base de données orientée graphe au début de l’année 2021, en adoptant une approche différente des services et du cache, que nous avons décrite dans une présentation virtuelle lors de la CitizenCon de l’année dernière. L’architecture actuelle utilise ce que nous appelons la couche de réplication, qui est un cache de données évolutif qui suit l’état de tous les objets dynamiques de l’univers, fonctionne dans le cloud et communique avec la base de données orientée graphe basée dans le cloud, que nous appelons Entity Graph. Cette dernière est l’autorité suprême sur l’état de tous les objets dynamiques de notre univers. La couche de réplication, qui est un service distinct et qui, dans sa forme finale, aura plusieurs nœuds de travail en fonction du nombre de joueurs simultanés, nous permet de suivre et de communiquer l’état de l’univers en temps réel, et sépare la simulation de l’état. Ceci est particulièrement important pour l’évolutivité car les clients n’ont pas besoin d’attendre qu’un serveur simule pour voir l’état changer autour d’eux, car les clients et les serveurs communiquent leurs résultats à la couche de réplication, qui sont ensuite répercutés à tous les clients. Comme le service de la couche de réplication n’a pas besoin de simuler, il peut communiquer les changements d’état aux clients à une fréquence fixe et n’est pas lié au temps de simulation, ce qui devrait conduire à une meilleure expérience pour les joueurs. Pour que le PES fonctionne, l’Entity Graph et la couche de réplication doivent être fonctionnels. En termes d’ingénierie, cela a été le plus grand défi technique et a nécessité une refonte fondamentale de la façon dont le jeu gère l’autorité et le changement d’état des entités. En outre, toute une série de nouveaux services en ligne étaient nécessaires pour prendre en charge la couche de réplication et l’Entity Graph. Pour supporter le PES, nous avons dû créer 12 nouveaux services. Pour le Server Meshing, seuls 4 services supplémentaires sont actuellement prévus, vous pouvez donc voir à quel point la technologie du SM est présente dans le PES. Dans ce cadre, nous sommes passés à gRPC qui est un protocole de communication en ligne, open-source et évolutif, sponsorisé par Google. L’aspect positif de l’utilisation d’une telle technologie est qu’elle est conçue pour évoluer (imaginez le nombre d’utilisateurs simultanés que Google doit gérer) et qu’il existe de nombreux outils et codes tiers disponibles, comparé à la création d’un protocole interne personnalisé.
Tout cela signifie que le fonctionnement du Persistent Entity Streaming nécessiterait l’essentiel de la technologie dont nous avons besoin pour rendre le Server Meshing viable. J’ai le plaisir d’annoncer qu’après 16 mois de travail acharné de la part de 18 ingénieurs, de 3 membres dédiés de l’assurance qualité et de 4 producteurs répartis entre CIG et Turbulent (qui gèrent la base de données en backend dans le cloud et ses services connexes), l’équipe a pu faire la démonstration du fonctionnement du Persistent Entity Streaming la semaine dernière lors de notre réunion interne hebdomadaire de mise à jour de l’univers persistant.
En attendant, ceux qui suivent de près notre développement et qui nous aident à tester nos technologies les plus importantes pourront mettre la main sur le streaming persistant et le Server Meshing cette année, car nous les testerons respectivement dans la 3.18 et la 4.0 en PTU pendant l’été et l’hiver. Parfois, l’attente peut être la plus difficile lorsque nous sommes près de la ligne d’arrivée, mais cette année, je suis très excité à l’idée de partager nos plans de sortie pour nos technologiques clés, et je sais que beaucoup d’entre vous sont impatients de sauter sur les serveurs PTU et de commencer à tester plus tard cette année.
Cette année, nous nous trouvons sur un chemin similaire avec trois énormes initiatives technologiques qui vont fondamentalement changer l’expérience et l’immersion dans Star Citizen. La première de ces initiatives est ce que nous appelons le Persistent Entity Streaming (PES), qui est la technologie fondamentale permettant le Server Meshing (SM). Le PES est la partie la plus difficile du travail nécessaire au SM et celle qui a nécessité le plus d’ingénierie. Elle change fondamentalement la façon dont nous enregistrons l’état dans l’univers et offre un niveau de persistance que l’on ne voit pas dans d’autres jeux, qu’il s’agisse de MMO ou même d’expériences solo. Jusqu’à présent, toute la persistance dans le jeu était liée à l’inventaire du joueur ; les vaisseaux que vous possédez ou les objets que vous tenez physiquement ou dans les inventaires virtuels des objets que vous possédez. Si vous avez physiquement attaché un objet à l’intérieur de votre véhicule, par exemple un fusil à un râtelier, lorsque vous vous déconnectez ou que vous rangez le véhicule, celui-ci se souviendra de tous les objets attachés et de tout ce qui se trouve dans l’inventaire virtuel du véhicule. En revanche, si vous déposez ou placez un objet en vrac, même à l’intérieur d’un vaisseau qui vous appartient, il ne sera associé à aucun inventaire du joueur. Ainsi, lorsque vous vous déconnectez (ou si le serveur plante), l’objet ne sera pas présent lors de la connexion ou de la reconnexion. Avec le PES, nous enregistrons l’état de chaque objet dynamique dans le jeu, qu’il soit “possédé” ou tenu par un joueur. Cela signifie que vous pouvez laisser tomber une arme ou un MedPen dans une zone forestière sur microTech et revenir plusieurs jours plus tard après vous être déconnecté pour trouver l’arme ou l’injecteur médical toujours là (en supposant qu’un autre joueur ne les ait pas pris !).
Notre objectif actuel est de présenter le Server Meshing et la 4.0 en avant-première technique aux testeurs Evocati sur les serveurs PTU à la fin du quatrième trimestre de cette année, permettant ainsi à nos joueurs les plus fervents de nous aider à commencer à tester le Server Meshing afin que nous puissions l’affiner et le peaufiner pour la sortie. Mais ceci est fortement conditionné par la facilité et l’efficacité du déploiement du Persistent Entity Streaming, donc soyez avertis qu’il y a de fortes chances que cette présentation soit reportée au premier trimestre de l’année prochaine. Une fois que le Server Meshing aura commencé à être testé en situation réelle avec des milliers de joueurs dans le PTU, nous aurons une meilleure idée du temps de préparation nécessaire avant qu’il puisse faire son chemin vers la sortie LIVE. Nous visons la fin du premier trimestre 2023, mais une fois de plus, nous ne pourrons pas le savoir avec certitude tant qu’il n’aura pas été testé.
Avec la version 4.0, nous aurons notre deuxième système stellaire, Pyro, et nous commencerons à ajouter de plus en plus de contenu, de gameplay et de finition pour atteindre la bêta. Pour nous tous à CIG, le Server Meshing et la 4.0 représentent le prochain grand pas vers le peuplement du ‘verse avec le contenu et de gameplay qui feront de Star Citizen l’univers riche et vivant qui dépasse la promesse que nous avons faite il y a de nombreuses années.
Cette année est importante pour nous tous sur Star Citizen : Vous pouvez vous attendre à voir l’Invictus Launch Week se dérouler dans les nuages de Crusader, la promesse du Persistent Entity Streaming faire son chemin dans le ‘verse, ainsi que de grandes fonctionnalités qui changent le jeu comme le recyclage, le cargo physicalisé, la chasse à la prime v2, de nouveaux événements et missions, des améliorations à Jumptown, des vaisseaux que je sais que vous attendez, comme le Corsair, le Vulture et le Hull C, ainsi que des améliorations de la qualité de vie et de l’accueil des nouveaux joueurs pour rendre Star Citizen encore plus jouable et accueillant qu’il ne l’est aujourd’hui. Sans parler de Pyro et du Server Meshing, que nous nous efforçons de vous faire tester d’ici la fin de l’année, en fonction de la difficulté à stabiliser le Persistent Entity Streaming. Nous pensons que vous préférez tous jouer à ce nouveau contenu plutôt que d’en entendre parler. Nous allons donc utiliser notre temps cette année pour nous concentrer sur le développement et vous fournir la technologie, les fonctionnalités et le contenu que vous attendez.
Comme vous l’avez peut-être deviné, nous aborderons le Server Meshing de la même manière que le déploiement du Persistent Entity Streaming. L’alpha 4.0 sera une nouvelle ère pour Star Citizen. Elle signifiera que notre dernière brique technologique – le Server Meshing – aura été livrée. La première implémentation sera ce que nous appelons le Server Meshing statique (SSM), où chaque serveur se voit attribuer une zone définie à simuler, mais dès que le SSM sera stable, nous passerons au Server Meshing dynamique avec les mises à jour suivantes, ce qui permettra une bien meilleure évolutivité puisque les serveurs ne seront pas liés à un emplacement, mais seront distribués en fonction de la charge, ce qui permettra d’obtenir de bien meilleures performances de simulation dans n’importe quelle région de l’univers.
Avec cette technologie en place, le Server Meshing devient possible, car la couche de réplication/l’Entity Graph est l’état de l’univers dans lequel les clients et les serveurs écrivent et lisent. Parce que nous avons découplé l’état de la simulation, cela nous permet d’avoir de nombreux nœuds de serveur communiquant tous avec la couche de réplication, responsable de la simulation de zones ciblées dans l’univers, ce qui nous permet d’augmenter notre capacité à simuler l’univers dans son ensemble, car un serveur n’est plus responsable de chaque entité non-joueur, quel que soit son emplacement ou son nombre. Cela signifie qu’au lieu d’un serveur qui tombe à cinq fps à cause de la charge de la simulation, nous pouvons en lancer un autre, puis un autre encore pour la répartir et maintenir un tickrate de mises à jour élevé. C’est le but ultime du Server Meshing dynamique et c’est ce vers quoi nous tendons.
Une différence par rapport à l’année dernière est qu’il n’y aura pas de démo de gameplay en tête d’affiche de l’événement, car cela priverait nos équipes de développement de ressources précieuses, qui travaillent dur pour mettre à votre disposition le streaming persistant, Gen 12/Vulkan et le Server Meshing, sans oublier le contenu et le gameplay qui se sont avérés si efficaces pour attirer de nouveaux joueurs ainsi que fidéliser les anciens et nouveaux utilisateurs.
Le plus gros gain de performance se fera côté serveurs. À l’heure actuelle, notre performance serveur est assez limitée par le grand nombre d’entités que nous devons simuler sur un seul serveur. Cela occasionne un framerate bas et une dégradation de l’état des serveurs, forçant le client à subir du lag réseau/du “rubber banding” et d’autres soucis de désynchronisation. Une fois que nous aurons au minimum le Server Meshing statique, nous nous attendons à avoir un framerate serveur considérablement plus élevé, occasionnant de surcroît moins de problèmes.
Le “tick rate” du serveur a l’effet le plus important et est lié au nombre d’emplacements qu’un serveur du jeu simule. Le Server Meshing devrait y contribuer en réduisant le nombre d’emplacements que chaque serveur du jeu doit simuler. Moins d’emplacements signifie un nombre moyen d’entités par serveur beaucoup plus faible et les économies réalisées peuvent être réinvesties pour augmenter le nombre de joueurs par serveur.
Donc ne vous attendez pas à voir le nombre de joueurs augmenter beaucoup avec la première version. Cela évite les problèmes tels qu’un seul nœud de serveur qui est déjà plein avant même que les joueurs ne s’y rendent puisque nous limiterons le nombre maximum de joueurs par shard en nous basant sur le pire scénario. Une fois que nous aurons mis en place ce système, nous examinerons les performances et les aspects économiques et verrons jusqu’où nous pourrons aller. Mais pour rendre de futures extensions économiquement viables, nous devrons chercher à rendre le Server Meshing dynamique aussi tôt que possible.
Nous utilisons toujours certains de nos anciens services persistants, adéquats tels qu’ils ont été conçus mais connus pour avoir des problèmes de performance et d’évolutivité en fonction de nos exigences. Il peut en résulter de longues attentes lors de la récupération des données persistantes des services afin de savoir quoi faire apparaître, comme faire apparaître un vaisseau à partir d’un terminal ASOP, examiner un inventaire, changer l’équipement du joueur, etc. Puisque le streaming persistant complet et le Server Meshing vont tous deux augmenter considérablement la quantité de données que nous devons faire persister, nous savions que nous devions faire quelque chose à ce sujet. C’est pourquoi Benoît de Turbulent et son équipe ont complètement réinventé la façon dont nous allons faire persister les données sous la forme d’EntityGraph, qui est un service hautement évolutif construit au-dessus d’une base de données qui l’est tout autant et qui est optimisée pour exactement le type d’opérations de données que nous effectuons. En plus de cela, nous développons également la couche de réplication, qui agit comme un cache en mémoire hautement évolutif de l’état actuel de toutes les entités d’un shard, éliminant ainsi la nécessité de la majorité des requêtes que nous avons envoyées aux services persistants existants. Eh oui, il va y avoir des services hautement évolutifs du début à la fin !
Le ping du client est influencé par la distance qui le sépare du serveur. Nous constatons que de nombreux joueurs choisissent de jouer sur des régions situées sur des continents complètement différents. Une partie de notre code du jeu donne encore l’autorité au client, ce qui signifie que les joueurs ayant un ping élevé peuvent nuire à l’expérience de jeu de tous les autres. Il n’y a pas grand-chose que nous puissions faire à ce sujet à court terme, mais c’est un point que nous voulons améliorer une fois le Server Meshing opérationnel.
Notre objectif actuel est de publier le streaming persistant et la première version de la couche de réplication idéalement entre le premier et le deuxième trimestre de l’année prochaine (ndt : ce Q&R a été publié en novembre 2021). Nous poursuivrons ensuite avec la première version d’un Server Meshing statique, sauf complications techniques imprévues, entre le troisième et le quatrième trimestre de l’année prochaine.
Lors de la CitizenCon 2951, nous avons plongé dans les technologies innovantes que sont le Server Meshing et le streaming persistant, avec Paul Reindell (directeur de l’ingénierie, technologie en ligne) et Benoît Beauséjour (directeur de la technologie chez Turbulent). Après le panel, nous avons constaté que de nombreuses personnes avaient des questions à poser à nos panélistes, et nous voulons nous assurer qu’elles reçoivent une réponse. Nous vous invitons à lire la suite de notre entretien avec Paul, Benoît, Roger Godfrey (producteur principal) et Clive Johnson (programmeur réseau principal).
Avec le Server Meshing dynamique, il est possible que de grands vaisseaux tels que le Javelin aient leur propre serveur dédié pour exécuter la simulation faisant autorité pour ce vaisseau et tout ce qu’il contient. Cependant, nous essayons d’éviter d’avoir des règles inflexibles sur la façon dont les entités sont assignées aux ressources de traitement, donc ce ne sera pas toujours le cas. C’est une question d’efficacité, tant en termes de vitesse de traitement que de coûts liés aux serveurs. Si nous avions une règle stricte selon laquelle chaque Javelin et tout ce qu’il contient reçoit son propre serveur, cela ne serait pas très rentable lorsqu’un Javelin ne compte qu’une poignée de joueurs. La même règle ne serait pas non plus efficace en termes de vitesse de traitement des serveurs s’il y avait des centaines de joueurs entassés dans le même Javelin, car la règle nous empêcherait de répartir la charge de traitement sur plusieurs serveurs.
Bien que le Server Meshing nous permet de commencer à augmenter le nombre de joueurs qui peuvent jouer ensemble dans Star Citizen, il nous débloquera également la possibilité d’ajouter de nouvelles expériences liées au contenu. Actuellement, nous nous concentrons sur cette exploitation pour ajouter de nouveaux systèmes stellaires. Le Server Meshing est l’une des technologies centrales pour faire fonctionner les points de saut en jeu en permettant aux systèmes stellaires d’apparaître et disparaître de la mémoire sans recourir à un écran de chargement. Les joueurs en seront témoins l’année prochaine quand la première itération du Server Meshing sortira sur les serveurs live à l’occasion de l’introduction du système Pyro.
Au cours de leur présentation lors de la CitizenCon sur le streaming persistant et le Server Meshing, Paul et Benoît ont évoqué la couche de réplication en parlant de service “Hybrid”. Ce service, comme son nom l’indique, est un hybride entre les services “Replicant”, “Atlas”, “Scribe” et “Gateway” que j’ai mentionnés plus haut (mais pas EntityGraph), mais également d’une poignée d’autres services pas encore mentionnés. Nous avons choisi de développer cela en premier avant de séparer les services le composant puisque cela réduit le nombre de pièces amovibles avec lesquelles nous essayons de composer en même temps. Cela nous permet également de nous focaliser sur la mise à l’épreuve de tous les grands concepts plutôt que de simplement nous contenter de faire communiquer ces services entre eux. Dans cette première implémentation, la couche de réplication constituera un seul nœud de serveur “Hybrid”. Si ce dernier crashe, alors la situation sera similaire à ce que les clients subissent actuellement lorsqu’un serveur de jeu dédié crashe. Tous les clients seront renvoyés au menu du jeu avec la tristement célèbre erreur 30k. Une fois que le nœud “Hybrid” remplaçant a démarré, les clients seront en mesure de rejoindre le shard et de reprendre là où ils se sont arrêtés. Avec un peu de chance, nous pourrons l’implémenter de telle façon que le client reçoit une notification à l’écran indiquant que le shard est de nouveau disponible et l’appui d’une simple touche les reconnectera automatiquement dans le shard (comme cela se fait avec la récupération de crash du client).
Bien que nous disposions de la technologie nous permettant de générer dynamiquement des entités sur le serveur, il n’y a toujours qu’un seul serveur qui “possède” toutes les entités simulées. Dans un maillage où plusieurs nœuds de serveur partagent la simulation, nous avions besoin du concept “d’autorité des entités”. Cela signifie qu’une entité donnée n’est plus la propriété d’un seul serveur de jeu dédié, mais qu’il existe plusieurs nœuds de serveur dans le maillage. Donc, un nœud de serveur qui contrôle l’entité, et plusieurs autres nœuds de serveur qui ont une vue client de cette entité. Cette autorité doit également pouvoir être transférée entre les nœuds de serveur. Une bonne partie du temps de développement a été consacrée au concept “d’autorité des entités” et de “transfert d’autorité” au cours du premier semestre 2020. C’est la première fois que l’ensemble de l’entreprise a dû travailler sur le Server Meshing, car une grande partie du code de jeu a dû être modifiée pour fonctionner avec le nouveau concept d’autorité d’entités. À la fin de l’année 2020, la plupart du code (du jeu) a été modifié pour prendre en charge le concept, donc une autre grande étape a été franchie, pourtant il n’y a pas encore de réel maillage.
Maintenant, la version longue. La voie vers le Server Meshing a commencé en 2017/2018 :
En fait, le pire scénario serait que tous les joueurs se décident de s’éparpiller dans tous les lieux assignés à un seul serveur de nœud. De cette façon, le pauvre serveur essaiera de gérer non seulement tous les joueurs mais également tous ses lieux. La solution évidente consiste à augmenter le nombre de serveurs par shard, pour que chaque shard ait à gérer moins de lieux. Cependant, parce qu’il est question de maillage statique et que tout est fixé à l’avance, avoir plus de nœuds de serveur par shard augmente également les coûts de fonctionnement. Mais nous devons bien commencer quelque part, donc l’idée pour la première version du Server Meshing statique est de commencer avec aussi peu de nœuds de serveur que possible tout en nous assurant que la technologie fonctionne. De toute évidence, cela posera problème si nous augmentons le nombre de joueurs par shard en dépassant le seuil actuel des 50 par serveur unique.
L’apparition lente d’entités peut entraîner une latence en retardant l’arrivée des entités sur les clients. Cela peut avoir des effets indésirables, tels que des lieux qui n’apparaissent complètement que quelques minutes après que le voyage quantique soit terminé, la chute à travers les étages après avoir réapparu dans un lieu, des vaisseaux qui mettent longtemps à apparaître sur les terminaux ASOP, la modification de l’équipement du joueur, etc. Les goulots d’étranglement se situent principalement au niveau du serveur. Premièrement, les entités ne sont pas répliquées sur les clients tant qu’elles n’ont pas fini d’apparaître sur le serveur. Deuxièmement, le serveur a une seule file d’attente de “spawn” qu’il doit traiter dans l’ordre. Troisièmement, plus un serveur a besoin de générer un grand nombre de lieux, plus il doit faire de “spawns”. Pour améliorer les choses, nous avons modifié le code de “spawn” du serveur pour utiliser des files d’attente de “spawns” parallèles. Le Server Meshing sera également utile, non seulement en diminuant la charge sur les files d’attente de “spawn” en réduisant le nombre d’emplacements qu’un serveur doit générer, mais aussi parce que la couche de réplication réplique les entités aux clients et aux serveurs simultanément, leur permettant le “spawn” en parallèle.
La plupart des gens, lorsqu’ils parlent de Server Meshing, pensent généralement à l’étape finale de cette technologie, qui consiste à coordonner les serveurs. La vérité est qu’avant cette étape finale, une très longue chaîne d’exigences préalables et de changements technologiques fondamentaux doivent être apportés au moteur du jeu. Dans cette optique, je vais essayer de répondre à cette question en prenant en compte tous les éléments.
Une fois ce premier jalon franchi, la technologie qui nous permet de lier/délier dynamiquement des entités sur le client devait également être activée sur le serveur (car, à terme, les nœuds de serveur du maillage devront faire apparaître/disparaître des entités de manière dynamique). Cette technologie est appelée “Object Container Streaming côté serveur” (S-OCS), et la première version du S-OCS a été publiée fin 2019. Il s’agissait de la deuxième grande étape vers le Server Meshing.
Cependant, ce n’est pas encore un “maillage”. Le travail sur le maillage proprement dit a commencé et il nous faudra une bonne partie de l’année prochaine pour le terminer, et toutes les conditions préalables que j’ai décrites ci-dessus étaient nécessaires pour en arriver à ce point. La première version de cette technologie sera un Server Meshing statique et constitue le prochain grand pas en avant. Cependant, ce ne sera pas non plus la dernière ! Avec le maillage statique, nous disposerons de la première version d’un véritable maillage mais, comme le nom “statique” l’indique, la capacité à faire évoluer ce maillage est très limitée.
Ce nouveau système de matchmaking actuellement en développement en parallèle du Server Meshing nous permet de réunir les joueurs sur des shards en nous basant sur différents paramètres d’entrée. Ceux-ci sont utilisés pour placer des joueurs avec leurs amis, ou bien là où ils ont perdu la plupart de leurs objets dans le monde ouvert. Cependant, ce système nous permet d’utiliser davantage de paramètres avancés, comme la réputation et d’autres statistiques de joueurs cachées que nous relevons.
À mesure que cette technologie s’affinera et que nous nous éloignerons d’un Server Meshing statique pour aller vers un Server Meshing dynamique, les concepteurs pourront s’en servir pour avoir des zones plus grandes et plus intéressantes (comme de plus grandes colonies ou des intérieurs de gros vaisseaux) densément peuplés d’IA et de joueurs. Le Server Meshing pourrait ouvrir la voie à des expériences de gameplays auxquels nos concepteurs n’ont pas encore pensé !
Avec le Server Meshing statique, tout sera fixé à l’avance, y compris le nombre de nœuds de serveur par shard et quel serveur de jeu est responsable de la simulation de tel ou tel lieu. Cela signifie que si tout le monde dans le shard décide de se diriger au même endroit, ils seront au final tous simulés par le même nœud de serveur.
Du côté des FPS du client, le Server Meshing n’a que peu d’impact. Le client n’affiche d’ores et déjà que les entités à portée de vue. Il pourrait y avoir de légères améliorations, puisque nous pourrons étendre la portée d’affichage du client car, actuellement, certains objets ont une portée d’affichage limitée pour certaines fonctionnalités telles que le radar ou les missiles pour qu’ils fonctionnent correctement. Avec le Server Meshing, nous pouvons démultiplier le rayon d’affichage du client et du serveur. Cependant, ces améliorations seront minimes côté client. Toutefois, un meilleur taux de rafraîchissement côté serveur améliorera l’expérience globale dans le sens ou le lag réseau sera considérablement réduit.
Le Server Meshing dynamique sera un peu différent dans la mesure où il réévaluera en permanence la meilleure façon de répartir la simulation, afin de trouver le point idéal pour qu’aucun serveur ne soit surchargé ou sous-utilisé. Au fur et à mesure que les joueurs se déplacent dans le ‘verse, la distribution idéale des ressources de traitement changera. Pour réagir à ces changements, nous devrons être en mesure de transférer l’autorité sur les entités d’un serveur à un autre, ainsi que de mettre en ligne de nouveaux serveurs et de fermer les anciens. Cela nous permettra de déplacer la charge de traitement d’un serveur qui risque d’être surchargé vers un serveur qui est actuellement sous-utilisé. Si aucun des serveurs existants ne dispose d’une capacité de réserve suffisante pour faire face à une augmentation de la charge, nous pouvons simplement louer d’autres serveurs auprès de notre fournisseur de plateformes cloud. Et lorsque la charge de certains serveurs n’est plus suffisante pour les rendre rentables, certains d’entre eux peuvent transférer leurs parties de la simulation sur les autres et nous pouvons fermer ceux dont nous n’avons plus besoin.
Pour que le Server Meshing fonctionne, nous avions d’abord besoin d’une technologie qui nous permette de lier/délier dynamiquement des entités via le système de streaming, car ce n’est pas quelque chose que le moteur prenait en charge à nos débuts. Ainsi, lorsque nous avons publié l’Object Container Streaming côté client (OCS) en 2018, nous avons également réalisé la toute première étape vers le Server Meshing !