Dossier

Architecture client-serveur de Dayz Standalone

architecture client serveur dayz standalone
Artwork de Stanley Vay

Bonjour les survivants, si nous sommes tous d’accord pour dire que le développement du jeu est long, la plupart d’entre nous ne connaissons pas les rouages internes qui amène un jeu d’un simple concept à un produit fini. Beaucoup d’étapes doivent être réfléchies en avance pour ne pas se retrouver bloqué comme il a été le cas avec le moteur de rendu du jeu qui a dû être réécrit pour atteindre les objectifs initiaux. Aujourd’hui un survivant de Dayz a voulu prendre la parole pour nous expliquer comment fonctionne l’architecture client-serveur dans le jeu, je vous laisse donc en compagnie de Draowyr que vous pouvez retrouver sur Twitter ou sur sa nouvelle chaîne Youtube.

 

Il est tant pour moi (Draowyr) d’aller au-delà que la publication de « Récap’ de la Semaine » ou d’une « tribune » où ma parole concernant DayZ est libérée. Nous allons aborder dans cet article l’approche des développeurs de DayZ Standalone concernant l’architecture client-serveur adopté pour le jeu.

 

Qu’est-ce que c’est, l’architecture client-serveur ?

Je vais expliquer ça, le plus simplement possible.  À propos du « client », il s’agit ni plus ni moins du PC du joueur qui émet et reçoit des informations dès que celui-ci est connecté sur un serveur quelconque.

Le « serveur » lui est en charge de recueillir toutes les informations émises par les joueurs, transmettre des informations aux joueurs et gérer une multitude de calculs annexes. Par exemple, le navmesh permettant aux intelligences artificielles de suivre un parcours en prenant en compte l’environnement (Les différents objets, les maisons – dont les intérieurs – et autres).

En 2013, il a fallu faire des choix afin d’améliorer l’architecture client-serveur hérité d’Arma 2. Un exemple très concret, celui du calcul des entités (Joueurs, zombies etc) :

Sur Arma 2, l’approche était de s’occuper de l’ensemble des entités (Bots, joueurs etc) sur la machine cliente. Le serveur transmettait au « client » la position de l’ensemble des entités présentes sur la carte, sans prendre en compte le fait que le « client » pourrait être très loin d’une entité quelconque en provoquant ainsi des calculs superflues. Il était donc nécessaire d’avoir un CPU capable de traiter des données sans nuire à l’expérience de jeu. Et, cela ne suffisait pas du fait de la vieillesse du moteur de rendu.

Désormais, l’approche est différente sur DayZ Standalone. Je parle du « network bubble » (Bulle  réseau) de Standalone avec davantage de détails plus bas dans cet article.

« Généralement un serveur est nettement plus performant qu’une machine cliente » – moi-même

 

En 2013, les serveurs de DayZ Standalone n’étaient pas en mesure de supporter le 64-bits. Le support du 64-bits permet aux serveurs de gagner en performance ; le support du multicœur dans le futur permettra d’augmenter les capacités de calculs côté serveur. Le support du 64-bits côté serveur permet d’améliorer les choses à conditions que les différents modules qui composent le serveur soient optimisés pour procéder aux calculs rapidement et efficacement.

Le 64-bits permet aux serveurs : d’aller au-delà des limites en triplant le nombre de spawns, que ce soit de zombies, d’objets ou d’animaux et d’augmenter les capacités d’utilisation possible de la mémoire RAM, qui ne sera plus bridée par l’usage du 32-bits. Dans les grandes lignes, un serveur tournant en 32-bits ne permet pas d’exploiter la RAM au-delà de 3,2 GB.

Il est probablement possible d’éviter de subir les conséquences de cette limite en effectuant des optimisations, mais l’approche des développeurs de DayZ Standalone concernant l’architecture client-serveur ne permet pas d’ignorer éternellement l’absence d’un support du 64-bits. Cette absence fut comblée en 2014 et permet aujourd’hui d’ajouter des nouvelles choses au sein de DayZ sans crainte d’être victime d’éventuelles limitations côté serveur à cause du 32-bits.

Le support du multicœur côté serveur n’est pas encore implanté, cela a probablement pour effet d’impacter de nombreux calculs et cela se ressent sur les serveurs à forte population de joueurs.

Nous allons voir ci-dessous une liste non-exhaustive des calculs effectués côté serveur.

 

Les calculs côté serveur

LES JOUEURS

 joueur DAYZ STANDALONE ARCHITECTURE CLIENT-SERVEUR

 

Le serveur s’occupe de nombreux calculs concernant les joueurs. Dès lors qu’un joueur entre sur un serveur de jeu, il est nécessaire de récupérer des données, ces données sont récupérées côté serveur en faisant appel aux serveurs de la Hive qui stockent les données des différents joueurs : l’inventaire du joueur, les états (Faim, soif, vie, santé etc), sa position sur la map, etc. Ces informations sont ensuite transmises au joueur.

Quand un événement concernant le joueur survient (ex. Ramasser / déposer un item ou état d’un item qui change) le serveur doit transmettre ces données aux serveurs gérant la Hive (Publique). Cela permet au joueur de changer de serveur sans perdre son personnage tant que le serveur en question communique avec la Hive sur lequel son inventaire est enregistré.

Si la Hive (Publique) tombe, le serveur ne parvient pas à communiquer avec celle-ci pour lui transmettre et récupérer les différentes données du joueur. C’est déjà arrivé par le passé (Décembre 2014) que les serveurs gérant ces données fassent l’objet d’attaque par Déni de service (DdoS) ayant pour conséquence les problématiques décrites ci-dessus.

Toutefois, il est possible de contrer la problématique des attaques en prenant des mesures afin de lutter au mieux contre ça, acquérir le matériel nécessaire afin de détecter et de mitiger une attaque par Déni de Service est relativement coûteux, cela reste faisable à l’échelle de Bohemia et des capacités financières du studio. Il est également possible de dupliquer les données entre plusieurs serveurs pour assurer une redondance en cas de panne ou d’attaque, cela reste beaucoup moins coûteux.

Le serveur s’occupe également des actions (Boire, manger, ouvrir / fermer une porte), c’est pour cela qu’il arrive parfois que l’enclenchement d’une action met du temps à se mettre en œuvre. Cela peut être lié soit à un problème de connexion côté client, soit à une surcharge côté serveur.

Pour répondre à cette problématique, les développeurs ont prévus de gérer les actions côté client dans la future version 0.63, cela fera disparaître le délai de latence car le client n’aura pas besoin de communiquer au serveur les actions qu’il souhaite entreprendre.  Le serveur pourra interrompre une action en cas de prédiction défectueuse, par exemple : deux joueurs prennent un élément en même temps ou un joueur effectue une action illégitime (Tricherie).

 

LES ZOMBIES

Le serveur s’occupe de nombreux calculs concernant les zombies, notamment comme mentionné précédemment, celui-ci gère le « navmesh » et le « pathfinding » de ceux-ci. Ces technologies permettent à l’IA de prendre des décisions sur la trajectoire à adopter : En prenant en compte les objets dans l’environnement, y compris à l’intérieur des bâtiments.

Le navmesh : il permet au pathfinding de choisir une trajectoire en prenant en compte les contraintes liées à l’environnement tel que les murs, les maisons, etc. (ndlr c’est un quadrillage de toute la zone de jeu)

Le pathfinding : Cela signifie en Français « Trouver son chemin ». Il permet ainsi à une entité quelconque d’adopter une trajectoire optimisée en contournant les objets présents dans l’environnement ou en sautant par-dessus dans le cas des clôtures, murets, etc.

Le navmesh consomme – d’après les chiffres communiqués par les développeurs – environ 600 mb de RAM maximum. Cela peut être très vite problématique en cas de limitations techniques lié au 32-bits ; ce qui n’est désormais plus le cas.

pathfing architecture reseau client serveur dayz standalone
En guise d’exemple, voici le comportement du pathfinding (en extérieur)

Point A : Le rond en dessous du personnage présent sur la route – Point B : Le rond derrière le mur.

Nous pouvons voir en rouge, la trajectoire de l’IA souhaitant se déplacer du point A vers le point B. Le « navmesh » permet ainsi au « pathfinding » de sélectionner un chemin en prenant en compte les contraintes de l’environnement.

Si vous voulez en savoir plus sur le navmesh et le pathfinding, n’hésitez pas à lire le sujet de D1D1 intitulé : « Pathfinding des Zombies »

 

LE LOOT

LOOT DAYZ STANDALONE ARCHITECTURE CLIENT-SERVEUR

 

Contrairement au comportement classique de DayZ Mod, le loot n’est pas généré en fonction de la progression du joueur sur la map – avec un tas de conditions pour faire réapparaître le loot dans le but d’éviter les abus notamment dans les zones proposant du loot « militaire » –.

Dès lors qu’un serveur sur Hive dites « publique » souhaite générer du loot pour la première fois, le serveur s’aligne sur la valeur nominale fixée par les développeurs, celle-ci permet de faire apparaître un nombre acceptable d’un item quelconque lors du premier démarrage.

Il existe un élément essentiel : L’économie centrale. Il s’agit d’un système contrôlant les loots sur l’ensemble des serveurs de DayZ, cela permet notamment aux membres de l’équipe de modifier les valeurs en temps réel pour ajuster le loot et cela sans effectuer de maintenance contraignante.

Les items ont également une durée de vie maximale (de quelques heures à plusieurs semaines, voire au-delà), cela permet au serveur de nettoyer ceux-ci dès que la valeur est dépassée.

  • La réapparition et le nettoyage des items ont lieu toutes les 5 secondes côté serveur.
  • Le nombre d’items oscilles entre 19 000 – 25 000 avec une valeur maximale de 45 000.

 

LE « NETWORK BUBBLE » (« La Bulle réseau »)

Dans les jeux de moindre envergure, le serveur envoie des informations sur l’ensemble des entités (Joueurs, etc) présent sur le serveur au « client » pour que celui-ci puisse effectuer un traitement de ces données dans le but – par exemple – d’afficher les joueurs qui sont assez proches.

Le comportement était identique sur Arma 2 et cela avait tendance à tirer vers le bas les performances côté « client », cela a un effet de dégradation de l’expérience de jeu (sur certains serveurs). La présence d’entités en sur-nombre telle que des bots tire vers le bas les performances  côté « client », même si ceux-ci sont loin de la position du joueur.

En bref, ce n’était pas un fonctionnement à renouveler pour DayZ Standalone, c’est pour cela que l’approche des développeurs a changé dans le but de permettre une optimisation côté serveur du « network bubble ».

Désormais : Le serveur n’a plus besoin d’envoyer les informations sur les différentes entités (Dans le cas de DayZ, cela pourrait être : Un joueur, un loup etc) à l’ensemble des joueurs présent sur celui-ci. Cette approche permet aux joueurs présents à Chernogorsk de traiter les données des joueurs présents uniquement dans leurs secteurs (1 km autour d’eux). Ainsi, il n’est plus nécessaire d’effectuer des calculs superflues côté « client ».

Cela pourrait paraître totalement anodin, mais cette approche m’a permis de jouer sur des serveurs remplis avec une machine déplorable, un Dual-Core @ 2,00 Ghz, 2 Go de ram et avec une carte graphique de 512 Mo de Vram. Sur Arma 2, c’était purement et simplement impossible d’atteindre 20-30 FPS sur un serveur rempli.

L’arrivée du Standalone de DayZ a changé la donne et ainsi, cela m’a permis de jouer sur des serveurs remplis sans craindre de voir mon processeur « suffoquer » à cause de l’approche des développeurs d’Arma 2 concernant le « network bubble ».

 

L’EXPLOITATION DE L’ARCHITECTURE CLIENT-SERVEUR

Quand un joueur transmet des informations à un serveur, ces informations peuvent subir des modifications par des logiciels tiers. L’anti-cheat de DayZ, en l’occurrence Battleye, est en mesure de détecter ce genre de manoeuvres douteuses.

Il est possible de détecter un changement douteux transmis au serveur à conditions de connaître le fonctionnement et le comportement normal d’un système quelconque (comme la balistique). C’est ça qui rend assez complexe la lutte contre les logiciels permettant aux joueurs de tricher. Si ce n’était que des variables avec une valeur maximale, la lutte aurait été très aisée.

Par exemple : Jean-François, 34 ans est un grand amoureux du modding sur GTA San Andreas et administre un serveur. Il souhaite réaliser un système de vie plus poussé à la manière de DayZ Mod. Ainsi, il réalise ses scripts et fixe la valeur maximale à 25000, puis il met à jour son serveur en publiant son nouveau système. Quelques semaines après la mise à jour, il découvre que son système est exploité, en effet, certains joueurs peuvent modifier et cela très simplement en transmettant de fausses informations. Il râle (forcément) et cherche une solution permettant de détecter les joueurs ayant un niveau de vie au-delà de la valeur maximale. Celui-ci décide de réaliser un script très simple, côté serveur par mesure de sécurité, permettant de détecter les joueurs ayant un niveau de vie nettement supérieur pour les bannir.

Méthode efficace.. Sauf que, l’approche n’est pas aussi simple, de nombreux systèmes sont d’une complexité extrême et l’anti-cheat doit travailler en occupant le minimum de ressources côté client et côté serveur.

La tricherie est un business extrêmement rentable. Il est arrivé que les développeurs de DayZ reçoivent des menaces. (En savoir plus)

 

 

Note : Je n’ai pas la science infuse ; N’hésitez donc pas à publier un commentaire en cas d’informations inexactes au sein de l’article.

L’article n’est pas complet et je m’en excuse ! Il est très dur d’entrer dans les détails en ayant pour seul source les déclarations des développeurs de DayZ.

N’hésitez pas à me poser des questions dans les commentaires, j’essaierai de répondre si cela ne me dépasse pas trop intellectuellement. Car, je suis avant tout un être humain extrêmement stupide.

Je vous remercie de m’avoir lu,

Une rédaction de Draowyr

Laisser un commentaire