Inside Star Citizen: Dev Diary - Server Meshing

Pour les développeurs de Star Citizen, peu d’entreprises ont la volonté d’investir dans des technologies aussi risquées sur le temps long. C’est une chance unique pour eux comme pour les joueurs de pouvoir être à l’avant-garde de la technologie.

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.

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.

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.

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.

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.

Après avoir vérifié qu’il était possible de connecter deux serveurs de jeu à une même couche de réplication et de passer de l’un à l’autre, les développeurs sont passés au test suivant : la division d’un même système sur plusieurs serveurs de jeu. Ils ont donc réparti Stanton en différents nombres de territoires, avec des nombres maximums de joueurs différents, jusqu’à six serveurs et 800 joueurs. Plusieurs bugs sont apparus à la frontière entre serveurs et les joueurs ont été encore une fois très engagés et créatifs, ce qui a donné beaucoup de matière à traiter pour les développeurs.

Le patch 3.23 inclut la couche de réplication et la récupération suite à un crash, et le fonctionnement est conforme aux attentes.

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.