Pax Dei
Inscrivez-vous à l'Alpha
Pax Dei

Aperçu technologique : notre système de construction

Bonjour, Paxiens !

Les magnifiques structures que vous avez construites depuis la première Alpha continuent de nous émerveiller un peu plus chaque jour. Vous, les joueurs, avez su vous approprier le système de construction de façon extraordinaire. Nous avons donc pensé que vous souhaiteriez en savoir un peu plus sur la technologie derrière ce système, d’autant plus qu’elle est probablement l’une des plus sophistiquées de l’histoire du jeu vidéo.

Actuellement, les zones du Domaine les plus prisées comptent environ 400 000 pièces de construction. À raison de 24 Domaines par monde, il y a plusieurs millions de pièces dans chacun d’entre eux. Le taux de construction standard est de 10 000 nouvelles pièces par semaine pour un seul Domaine.

Notre système de réplication

Dans un jeu multijoueur en réseau, le système de réplication permet de s’assurer que l’état du jeu dont disposent les joueurs est cohérent et à jour. En d’autres termes, ce système reçoit les informations envoyées par un joueur et les distribue aux autres joueurs.

La taille des données de construction pour un Domaine est actuellement d’environ 30 Mo. Ça ne paraît pas beaucoup comme ça, n’est-ce pas ? Mais imaginons que l’on ait 100 joueurs ; ce sont maintenant 3 Go de données qui doivent être gérés par le serveur, le client (la machine du joueur) et notre système de réplication.

Un tel volume de données nécessite un traitement très particulier, et ce, à toutes les étapes de la chaîne de production du jeu. Nous pouvons utiliser le système de réplication d’Unreal Engine pour le gameplay, mais pas pour les bâtiments. La réplication des bâtiments repose sur un serveur dorsal de réplication (qui porte donc bien son nom) qui envoie les données de construction de la base de données d’un monde aux clients et aux serveurs.

Lors de la connexion, le client comme le serveur se connectent au serveur de réplication, qui commence par envoyer l’état de la zone. Comme mentionné précédemment, les données initiales pèsent actuellement environ 30 Mo pour les zones les plus étendues. Après la réplication de l’état initial, le client et le serveur reçoivent les nouveaux événements de construction de la part du serveur de réplication. Nous utilisons le flux gRPC comme canal de communication entre les événements de construction et le serveur de réplication. Nous n’entrerons pas dans les détails concernant le gRPC. Pour la faire courte, il garantit que toutes les parties concernées, soit le serveur, le serveur de réplication et les clients, communiquent correctement et se comprennent mutuellement.

In the matrix

Ajouter une pièce de construction : sous le capot

Voici une version simplifiée de ce qui se passe après qu’un joueur s’est servi de son marteau de construction :

  1. Le client envoie une demande de construction au serveur d’Unreal ;

  2. Le serveur vérifie les autorisations pour s’assurer que la demande de construction est autorisée ;

  3. Si le serveur le permet, il envoie ensuite la demande de construction au serveur dorsal ;

  4. Le serveur dorsal effectue ses propres vérifications pour autoriser ou non la demande de construction ;

  5. Une fois autorisée, une pièce de construction est ajoutée à la base de données du monde principal ;

  6. L’événement de construction est envoyé par la base de données à notre serveur dorsal de réplication personnalisé ;

  7. Le serveur de réplication envoie l’événement de construction au serveur et au client ;

  8. Le serveur et tous les clients de la zone (ici, le Domaine) font apparaître la pièce de construction ;

  9. Le serveur vérifie l’intégrité de la structure ;

  10. Le client calcule également l’intégrité afin de l’afficher dans l’interface utilisateur.

Rendre le bâtiment visible de tous

La réplication massive des données est le premier défi auquel nous sommes confrontés. Une fois que le client a reçu les 400 000 pièces du Domaine, le paquet de 30 Mo que nous évoquions précédemment, nous devons les rendre visibles. Votre ordinateur doit les dessiner, et c’est là que réside le deuxième grand défi.

Il est inconcevable d’utiliser un système qui dessine 400 000 pièces les unes après les autres. Nous avions besoin de quelque chose qui puisse s’adapter à nos besoins. Les deux éléments principaux que nous utilisons sont les maillages statiques instanciés (ISM) et les gestionnaires de zone.

Les ISM servent à dessiner des milliers de pièces en un seul signal de dessin au lieu de les dessiner une par une.

Les gestionnaires de zone, les parallélépipèdes que l’on voit dans la vidéo ci-dessous, contrôlent tous les accessoires et les pièces de construction qui se trouvent dans leur zone. Ils se chargent de la création et de la destruction des pièces de construction et des accessoires, des calculs d’intégrité et de bien plus encore, notamment des ISM.

Le gestionnaire examine toutes les pièces de construction standard dans sa zone (pas les stations d’artisanat ni les rangements) et les trie en fonction de l’espace. Il les insère ensuite dans des maillages statiques instanciés personnalisés. La magie peut désormais opérer.

Ceci étant dit, ce n’est pas encore fini. En plus des bâtiments, il faut également dessiner les rangements, les stations d’artisanat et les pièces de décoration, en sachant que la plupart de ces éléments ont leur propre fonctionnalité de gameplay. Tous ces accessoires sont des acteurs standard d’Unreal, mais contrairement aux bâtiments que l’on peut voir d’assez loin, ils n’apparaissent qu’autour du personnage, dans une certaine zone d’affichage.

Dans la vidéo ci-dessous, vous pouvez voir comment les gestionnaires fonctionnent et la façon dont les accessoires apparaissent ou non. Chaque boîte que vous voyez correspond à un gestionnaire. Comme expliqué ci-dessus, chaque gestionnaire contrôle les ISM et l’intégrité de sa zone propre, mais il contrôle également la visibilité des acteurs d’accessoires : stations d’artisanat, rangements et autres éléments de décoration. Selon la position du personnage et la distance d’affichage du client, le gestionnaire activera ou désactivera la visibilité de ses acteurs d’accessoires.

Dans la vidéo, les gestionnaires qui désactivent la visibilité des accessoires sont indiqués en rouge et ceux qui l’activent sont indiqués en cyan. Le violet indique ceux qui sont en attente d’activation et le magenta ceux qui sont en attente de désactivation.

Il existe un autre type d’accessoire qui nécessite un traitement particulier : les sources de lumière. Lorsque votre personnage s’en approche, les lumières fonctionnent grâce à Lumen, le système d’éclairage dynamique et global d’Unreal Engine 5, afin d’améliorer l’immersion du joueur. Cependant, à une certaine distance, les lumières proviennent de projecteurs de lumière plus légers afin d’améliorer les performances du jeu. Certains Domaines disposent de plus de 20 000 sources de lumière que vous pouvez observer simultanément !

Lights in the night

Évidemment, il y a aussi quelques contraintes au niveau du serveur. Un serveur d’Unreal Engine peut supporter 150 à 200 joueurs maximum. Si un nombre plus élevé de joueurs souhaitent être dans le même village, alors nous devons créer des instances de serveur. Voici donc un autre domaine où l’existence de systèmes personnalisés est particulièrement utile. Notre système de réplication permet aux bâtiments d’être visibles sur toutes les instances du serveur en temps réel ! Si un joueur construit quelque chose dans une instance de serveur, tous les autres joueurs se trouvant dans les autres instances du serveur verront le bâtiment changer en temps réel.

Quelques mots pour la fin

L’apparition de tous ces bâtiments autour du joueur sans qu’il y ait de lag est compliquée et s’étale sur plusieurs secondes, voire plusieurs minutes, découpées en plusieurs images. Par ailleurs, comme vous l’avez probablement deviné en lisant les différentes étapes ci-dessus, les calculs d’intégrité représentent un processus très complexe. Nos serveurs diffusent du contenu provenant du monde entier ; le calcul de l’intégrité doit donc être soigneusement configuré pour que tous les paysages soient disponibles avant même qu’ils ne soient affichés. La création d’états physiques pour les pièces doit se faire sans lag, et la recherche de chevauchements entre la physique et les calculs d’intégrité réels doit être effectuée de manière itérative

Vous savez maintenant pourquoi, lorsque vous vous connectez, il arrive souvent que vous voyiez d’abord le paysage, puis les bâtiments, et enfin les accessoires.

Les joueurs de Pax Dei construisent bien plus rapidement que ce que nous avions prévu. L’ensemble du système a déjà fait l’objet de nombreuses optimisations, et nous avons encore de nombreux tours dans notre sac. Le système actuel devrait fonctionner correctement jusqu’à environ 500 000 pièces. Au-delà de ce chiffre, de nouveaux problèmes à résoudre risquent d’apparaître. Toutefois, nous avons une bonne nouvelle à vous annoncer ! Nous prévoyons déjà d’étendre le système à 1 million de pièces par zone.

Mais nous verrons ça plus tard.

En attendant, vous pouvez continuer à construire et suivre les conseils de joueurs qui ont réussi à maîtriser les pièces et l’environnement pour créer de superbes structures !

Pax vobiscum,

L’équipe Mainframe