Travail de recherche M1

Les architectures et algorithmes de répartition de charge et de données dans les jeux

Vincent Desfontaines,
desfontaines.vincent@gmail.com
Étudiant master 1 Jeux et Média Intéractifs Numériques
ENJMIN 2015-2017

Abstract :

Depuis le tout début de leur création, les jeux vidéoludiques ont vu s’affronter plusieurs joueurs entre eux. Depuis Pong, où deux tennismen se challengent, jusque World of Warcraft, avec ses millions de joueurs en lignes, l’évolution des jeux orientés multijoueurs a connu une belle évolution. Lors des premières parties de jeu à plusieurs, les concurrents étaient dans la même pièce avec chacun un contrôleur en main, une manette, reliée à a une même machine, une console. L’écran était alors partagé selon le nombre de joueur qui pouvait varier en général de 2 à 4. En parallèle cette évolution, l’internet s’est amélioré, popularisé jusqu’à atteindre aujourd’hui un grand nombre de foyers. Cet accès au monde s’est solidifié et, aujourd’hui, les débits que peuvent atteindre les lignes des particuliers permettent, pour la plupart, l’obtention de la télévision et de films en streaming en haute définition. Grâce à ce nouveau vecteur de communication, les jeux multijoueurs en ont profité pour permettre à des joueurs de partager une partie, en étant chacun sur sa machine devant un écran entièrement dédié à soi. Les jeux de stratégie en temps réel (Real-Time Strategy - RTS) ou les jeux de tirs à la première personne (First Person Shooter – FPS) permettent jusqu’à 16 joueurs de s’affronter via le réseau. Un nouveau type de jeu a émergé depuis, le Massivement Multijoueurs en ligne (Massively Multiplayer Online – MMO), inspiré des jeux de rôle papier, et amenant avec lui tout une problématique d’échanges, entre les joueurs et les serveurs, de partage de données, avec le monde virtuel que les avatars partagent, et le nombre accru de connexions sur une même session. Ce type de jeu a forcé les développeurs de jeux à se pencher sur les structures à mettre en place, pour permettre une expérience agréable et cohérente entre tous ces aventuriers virtuels. Aujourd’hui, ce type de jeu est largement popularisé sur PC, où chacun peut trouver le monde qui lui correspond, mais il s’est aussi ancré dans les jeux sur mobile tel que Clash of Clan ou plus récemment Boom Beach. En tant que joueur, toutes les structures et les algorithmes mis en place sont invisibles, le nombre de joueurs simultané est parfois tellement grands que des artifices ont dû être produit afin de garder le joueur dans cette illusion d’un univers parallèle virtuel.

C’est ce que ce travail de recherche va tenter de mettre à jour. Sans aller profondément dans chaque caractéristique propre à ces échanges de données, c’est une approche macroscopique que nous allons vous proposer.

  1. Abstract
  2. Les différents types de jeux multijoueurs et leurs besoins
    1. Les FPS et les RTS
    2. Les MMO
  3. Les technologies actuellement utilisées
    1. Les protocoles TCP/IP et UDP
    2. Les bases de données
    3. Les types de serveur de jeu
  4. Les utilisations et les limites de ces technologies
    1. Les FPS et les RTS
    2. Les MMO
  5. Quelles améliorations envisageables ?
  6. Conclusion
  7. Références

Les différents types de jeux multijoueurs et leurs besoins

Les échanges de données dans les jeux multijoueurs ne sont pas uniformes. Chaque type de jeu a des besoins particuliers qui sont liés directement au gameplay de ces derniers. De plus, un même type peut avoir des fonctionnements différents dus aux choix faits par les développeurs. Néanmoins ils partagent tous un même besoin, celui de rendre la partie, entre les différents joueurs, cohérente malgré le partage d’informations et le temps de mise à jour de chacun.

Les FPS et les RTS

Les besoins pour les jeux à dynamique forte tel que les jeux de tir, de course, de stratégie en temps réel :
Pour que l’expérience de jeu soit bien rendue en multijoueurs en réseau, chacun des joueurs doit pouvoir recevoir la mise à jour du monde (l’état de la partie à un instant « t ») à une haute fréquence. Le minimum, selon le jeu, étant fixé à 30 mises à jour par seconde (Overwatch à ses débuts) pour aller vers un standard à 60 mises à jour par seconde. Il est à noter que les prochains FPS comme Quake Champions souhaitent tendre vers un ratio de 120 images par seconde, afin de d’orienter le jeu vers la compétition, ce qui soulèvera alors le problème d’atteindre cette performance coté réseau. Ce besoin de mise à jour est dû aux mouvements rapides des joueurs ou à la prise de décision, d’attaque, de déplacement, dans les jeux de stratégie. Les joueurs ont besoin d’être rapidement au courant de chaque mouvement ou décision des adversaires.

Les besoins sont plutôt orientés calculs physiques que volume de données recevoir, traiter et envoyer.

Les MMO

Les besoins pour les jeux type Massivement Multijoueurs En-ligne :
La particularité de ce type est le nombre de joueurs qui partage un même monde. La cohérence de ce monde entre les différents joueurs est cruciale, elle est à l’origine de l’immersion du joueur dans cette réalité virtuelle. En revanche le gameplay est moins dynamique et autorise un nombre beaucoup plus faible de mise à jour par seconde, on retrouve en général un « tickrate » de 10 à 20 mises à jour par seconde. Cela s’explique par la multiplication du nombre de données à envoyer multiplié par le nombre de joueurs qui se partagent ces données. A ce débit de partage de données il faut aussi prévoir le temps que chaque joueur prendra pour traiter les données reçues afin d’être dans la même situation que tous les autres joueurs.

A l’inverse, ici il est question de pouvoir traiter un grand nombre de connexion et de recevoir puis transmettre des données.

retour sommaire

Les technologies actuellement utilisées

Les besoins des jeux en multijoueurs via les réseaux sont différents selon le gameplay du jeu ciblé et des choix des développeurs. En revanche les technologies liées à la transmission des données, liées au jeu vidéo, ne sont pas légion. Au départ deux protocoles, TCP/IP et UDP, différentes structures d’échanges de données et de leur stockage, et enfin, plusieurs façons d’agencer ces outils afin d’en faire des environnements dédiés aux serveurs de jeux vidéo.
Deux grands protocoles sont utilisés pour la transmission de données : le TCP/IP ((Transmission Control Protocol et Internet Protocol) et l’UDP (User Datagram Protocol).

Les protocoles TCP/IP et UDP

La force de TCP/IP est sa fiabilité, on dit que c’est un protocole de type connexion. Une liaison est établie entre deux points, s’identifiant entre émetteur et récepteur. Le protocole gère lui-même la découpe des données en paquets, ils sont ordonnés en émission et en réception. Cette réception est garantie dans le sens, où, tout paquet de données qui n’arriverait pas à destination serait redemandé puis réexpédié vers le destinataire.

L’UDP est quant à lui orienté en temps réel, on privilégie la rapidité à envoyer l’information en s’adressant à une adresse donnée et sans en attendre de réponse en retour. Le récepteur se met à l’écoute des données sur un numéro de port précis et traite ces informations, grâce aux algorithmes développés spécifiquement, selon les besoins de l’application utilisant ce port. L’ordre des paquets n’est pas assuré, c’est-à-dire que l’envoi des paquets 1 - 2 - 3 peut être synonyme de la réception des paquets 2 - 1 - 3 coté récepteur.

Si la fiabilité est une qualité recherchée dans la transmission de données et dans le développement du réseau dans les jeux vidéo, le choix du protocole TPC/IP serait mauvais, dans la grande majorité des cas, pour ce qui est de la partie contrôle de jeu. En exemple il suffit d’imaginer que l’information de tir d’un joueur, contenue dans un paquet, soit perdue. Le récepteur demande alors la retransmission du paquet, l’émetteur lui envoie de-nouveau l’information. Le récepteur peut alors traiter celle-ci mais, entre-temps, d’autres données ont pu être envoyées. Ces données, à cause de du respect de l’ordre des paquets du protocole TCP/IP, ont été mises en attente. Un phénomène de congestion peut se produire, ou bien même, un trop grand nombre d’informations à traiter sur le moment peut empêcher le récepteur de calculer le rendu du monde à temps. Le jeu sera au mieux saccadé et au pire figé.

Le choix du protocole UDP est un standard dans le réseau des jeux vidéo, pour la partie contrôle du jeu. Ainsi chacun envoie les informations en temps réels sans attendre de réponse. Chaque entité traite la réception des données reçues et, si un paquet se serait perdu, la dernière information reçue garde la priorité sans mettre en attente le jeu. Le choix du protocole UDP force le développement de tout le fonctionnement d’envoi, de réception et de traitement des erreurs. Il faut prévoir le découpage des données, leur réassemblage, un système de contrôle d’intégrité et ne pas oublier de sécuriser ces échanges, afin d’amoindrir les tentatives de hack ou de triche.

retour sommaire

Les bases de données

Le stockage des informations liées aux jeux vidéo est à la base même des jeux tel que les MMO mais intervient aussi dans les autres types de jeu multijoueurs. Actuellement, jouer en ligne est synonyme de compte de jeu en ligne, ou chaque joueur s’identifie sous un pseudo et valide la licence de son exemplaire du jeu. De plus, il est commun maintenant de pouvoir consulter les statistiques du joueur (nombre de victime, scores, niveau…) sur un site internet associé. Dans les MMO, la base de données accueille l’ensemble des objets intéractibles avec le joueur, ses possessions, son avatar et une partie des données dynamiques du monde virtuel. Pour stocker, ranger et distribuer efficacement ce volume d’informations, deux grandes familles de gestion de base de données ressortent : Le SQL (Structured Query Language) et le NoSQL (Not Only Structured Query Langage).

Le SQL repose sur une structure relationnelle de tables de données. Ce type de Base est choisi dès lors que l’on a une idée précise du volume de données qui seront stockées. Le SQL est choisi quand la priorité est mise sur l’intégrité des données. Parmi ces types de bases de données utilisées dans l’industrie vidéoludique on note Oracle RDBMS (World of Warcraft), Microsoft SQL Server (Guild Wars) ou encore PostgreSQL pour le système multiplayers de Sony Online. Etant plus utilisé que le NoSQL, cette solution a l’avantage d’avoir un bon nombre de développeurs expérimentés et d’un excellent support de la part des éditeurs.

Concernant le NoSQL, cette technologie est depuis quelques années mise en avant. On vante son dynamisme dans le stockage de données ainsi que sa capacité flexible. Les développeurs choisissant cette technologie, plutôt que le classique SQL, vantent la rapidité de mise en place de la base permettant de commencer directement la production du jeu. Les personnes maitrisant le NoSQL sont plus rares actuellement mais en considérant l’importance que prend cette technologie, notamment dans les jeux par navigateur ou smartphone, il y a fort à parier que ce nombre va augmenter significativement.

Afin de répondre à un grand nombre de joueurs en simultanée, les bases de données sont dupliquées sur plusieurs serveur. En cela, l’aspect de cohérence de l’ensemble peut ne pas être respecté durant le laps de temps que les données soient répliquées.

retour sommaire

Les types de serveur de jeu

Pour les parties multijoueurs en réseau, on distingue encore deux grandes façons de faire.

Tout d’abord est apparu la manière Peer-to-peer. Chaque entité, chaque joueur, a une version du monde du jeu. Si un joueur avance son personnage, il transmet aussitôt, à tous les autres joueurs de la partie, la nouvelle position de son avatar. La méthode Peer-to-peer est dite non autoritaire car il n’y a pas de version du monde du jeu, c’est-à-dire qu’il n’y a pas de centralisation de la partie. Chaque entité est donc garante de ses propres actions et ne peux pas changer l’état des autres actions des autres joueurs. Dans le cadre d’un réseau avec une faible latence, les informations ainsi partagées seraient instantanées et le jeu fonctionnerai correctement. Néanmoins, et comme c’est souvent le cas des parties multijoueurs par internet, une latence existe bel et bien. De ce fait le joueur qui se protégerai derrière un mur, afin d’éviter des tirs de ses adversaires, pourrait tout de même être touché entre le temps où il se met à l’abri et celui où cette information est transmise aux autres joueurs. Chacun ayant une version du jeu différente mais faisant foi localement, de nombreux troubles peuvent venir gâcher l’expérience de jeu.

illustration architecture Peer-to-peer

La seconde méthode pour gérer des parties multijoueurs est la structure dite client-serveur. Le monde du jeu est garanti par l’entité appelé serveur qui communique avec tous les joueurs de la session. De leur côté, les joueurs envoient (dans la théorie) leur inputs (avancer, sauter, tirer…) au serveur et reçoivent de ce dernier le dernier état du monde. Ce type de structure repose principalement sur la puissance du serveur et la capacité d’échange du réseau. Si en principe chaque joueur pourrait n’être qu’un terminal sans grandes ressources de calcul, dans la réalité on procède un habile partage des tâches à accomplir. Cela a pour but d’alléger les besoins en ressources des serveurs en permettant, par exemple, au client de calculer l’animation à jouer mais, en revanche, pas l’autorité pour déclarer un adversaire mort. Les MMO fonctionnent sur ce modèle pour des raisons liées à la grandeur du monde virtuel, ce sujet est développé dans la suite de cette recherche.

illustration architecture Client-Serveur

Selon le système retenu par les développeurs, le multijoueurs d’un jeu sera soit en Peer-to-peer, soit Client-Serveur. Dans le second cas, la production d’une architecture serveur est nécessaire, elle peut être simple, et gérer une session de jeu, ou plus complexe, et contrôler les connexions, répartir les joueurs, les charges de données etc… La structure de ces serveurs repose sur un ensemble de serveurs, avec parfois une fonction différente pour chacun, et sur des algorithmes fonctionnant à deux niveaux.

Le premier est celui formé par les liaisons entre les différents serveurs, par exemple les algorithmes qui vont recueillir la connexion d’un joueur et rediriger cette connexion vers un serveur qui gère les parties en cours, puis qui redirigeront les données de la partie vers les bases de données. Le second niveau est celui situé dans les serveurs eux-mêmes, par exemple les algorithmes de la boucle de jeu, de chargement de données en temps réel, de vérification de connexion. Pour ce qui est de la répartition de charge et des transferts de données, les algorithmes sont répartis sur les deux niveaux.

retour sommaire

Les utilisations et les limites de ces technologies

En considérant deux grandes catégories de types de jeu, il est possible de constituer deux façons d’utiliser les structures et outils vus dans les précédents paragraphes. Tout d’abord les jeux FPS et RTS puis les MMO.

Les FPS et les RTS

Dans les FPS et RTS, on peut aussi faire un parallèle avec les autres types tel que jeux de course ou sportifs en ligne, le monde dans lequel évoluent les joueurs étant restreint. Une carte comme dans Overwatch ou dans un Total War n’a pas besoin d’être hébergé par plusieurs serveurs. Les données du jeu sont statiques et ne sont pas appelées à être modifiées profondément par le gameplay. De ce fait, les échanges de données seront surtout des informations liées à l’action du joueur (sur ses mouvements, principalement, ainsi que ses actions). Considérant que les jeux actuels sont produits selon le model Client-Serveur, c’est au serveur de contrôler et de calculer le rendu du monde selon les informations qu’il reçoit des joueurs.

Cette notion de rendu est importante car elle assure le bon fonctionnement de la partie. En effet les serveurs sont calibrés pour calculer un rendu de manière régulière : on appelle cela le tickrate. Cette fréquence de rafraichissement est propre au serveur et aussi au jeu. Pour avoir quelques exemples Left 4 Dead 2 à un tickrate de 33, Counter Strike de 66 et plus récemment Counter Strike Global Offensive à 128. Étant une fréquence, on en déduit un intervalle de temps entre chaque calcul : 1 seconde divisée par 33 donne un rendu toutes les 30 millisecondes. Cette mesure est cruciale pour estimer la puissance minimale que doit avoir le serveur. Considérant que l’information envoyée par le client (le joueur) mette un temps te pour arriver (et autant pour revenir), le rafraichissement du monde chez le client prendra alors 2te + tcalcul du server. Ce temps total détermine alors la fluidité de la réalité de l’état du monde pour le joueur, empêchant les phénomènes de téléportations ou de course dans le mur.

La charge de travail se situe alors au niveau du CPU et de la mémoire vive de ces serveurs. Un autre facteur à considérer sur ce genre de jeu est le nombre de joueurs simultanés possible lors d’une partie. Ce nombre est déjà connu car il est prévu dans le design des parties multijoueurs du jeu. Ainsi dans un FPS comme Battlefield 2, le nombre de joueurs maximum par serveur est de 64 joueurs, en RTS on verra un maximum en général de 8 joueurs. Connaissant les limites maximums que ces serveurs devront affronter, il est alors possible de prévoir un serveur assez puissant (en CPU, mémoire vive) qui permettrait de calculer le rendu du monde ainsi que les calculs physiques associés.

Pour les transmissions de données, comme expliqué précédemment, le protocole UDP est à choisir. On évite alors les problèmes liés à la congestion des paquets et les ralentissements du jeu qui peuvent en découler. Il faut alors prévoir un serveur d’identification, en général un login et mot de passe, afin de donner une identité à une adresse IP (représentant un joueur souhaitant rejoindre une partie). Grâce à ce serveur on place un système de session qui correspond à la totalité du temps entre le moment où le joueur s’identifie et celui où il quitte le multijoueurs et se déconnecte. Le serveur sait alors à qui s’adresser pour envoyer les informations de la partie et peut aussi faire le lien entre une entité de la partie et les informations provenant d’un client. L’UDP étant un mode où l’émetteur envoie vers un destinataire sans en attendre de retour cela correspond parfaitement au besoin de fonctionnement en temps réel attendu pour ces genres de jeux.

Les jeux assimilés aux genres étudiés précédemment (FPS, RTS, etc…) demande une haute fréquence de réception et d’envoi d’information ainsi qu’une performance de calcul en temps réel. Avec les connexion haut débit que nous connaissons, l’échange de données sera réalisé sans difficulté, les débits sont rarement remis en cause. Néanmoins un problème de latence peut apparaitre selon la situation du joueur vis-à-vis de son fournisseur internet. Cette latence est le temps que met l’information du serveur vers le joueur (ou l’inverse), elle est impactée par la longueur du parcours que doivent parcourir les données. Aussi appelé « lag » en anglais, elle peut être calculée en faisant un ping (le temps que met un paquet pour partir puis revenir à sa source) que l’on divise par deux. Enfin il reste un dernier critère de qualité d’une connexion internet : la gigue. Cette donnée est la variation de la latence, elle représente un niveau de stabilité dans la vitesse des échanges client-serveur. Une gigue faible est nécessaire pour les échanges de données en temps réel. Une des causes d’une gigue élevée est l’irrégularité dans la réception des informations : un ensemble de paquets est reçu puis pendant quelques temps plus rien. Cette situation occasionne, dans les jeux multijoueurs, des moments fluides puis un simili de perte de connexion et, en une fraction de seconde, la partie se met à jour de l’équivalent de plusieurs secondes de jeu.

Les besoins parfaits pour le type de jeu FPS, RTS et assimilés sont les suivants :

Les capacités de calculs sont au cœur du bon déroulement des serveur de jeu à gameplay dynamique. À la vue du nombre de joueurs fini des parties, on peut dire que la gestion de charge propre à la boucle de jeu n’est pas problématique. Voyons ce qui en est pour les jeux massivement multijoueurs en ligne.

retour sommaire

Les MMO

Les MMO (RPG, FPS) ont des gameplays moins dynamiques que les types de jeux vus précédemment, il n’y est pas question de réaction à la demi-seconde près. Le challenge et la réussite de ces jeux reposent sur une bonne gestion des réseaux et des connexions, très nombreuses, des joueurs. Si le modèle Peer-to-peer peut être fonctionnel pour les jeux de type RTS, ici il n’est pas enviable que chaque joueur envoie à tous les autres joueurs ses informations, le tout en traitant toutes les informations reçues par ces autres joueurs. Parallèlement à ce besoin de qualité dans les échanges, les mondes virtuels hébergés sur les serveurs sont vastes. Dans Eve Online, ce sont près de 7 000 systèmes solaires qui composent le monde, chacun comportant des ceintures d’astéroïdes, des planètes, des stations d’arrimages etc… Dès lors il est aisé d’apercevoir l’importance de la gestion de charge quand on sait que des centaines de milliers de joueurs évoluent dans cet univers. A titre d’exemple, le dimanche 28 juillet 2013, deux alliances se sont affrontées dans un système avec au total 4 070 joueurs, dont environ 2 900 en simultanés. Dans ce genre de jeu, le tickrate des serveurs est beaucoup plus bas que pour les FPS. On avoisine entre 10 et 20 tickrates par seconde selon les jeux

Différentes structures de serveur sont mises en place afin de gérer ces charges de joueurs :

Le "zoning concept" :
Le zoning concept est une façon de partager le monde du jeu en plusieurs zones, et d’attribuer à chaque zone un serveur. Les entités des joueurs sont paramétrées avec une zone d’intérêt, équivalent d’une sphère (ou d’un disque en 2D), délimitant les entités proches du joueur qui doivent être chargées à sa disposition. Pour passer d’une zone à une autre, les serveurs concernés communiquent entre eux les données relatives au joueur. Un serveur de management doit faire les intermédiaires afin de mettre en relation les différents serveurs de ces changements. Enfin pour le joueur, seul les entités proches de lui sont chargées, il faut alors qu’un algorithme détecte ces entités (entrantes et sortantes) afin de demander puis traiter les données nécessaires.
Concernant les limites de cette structure on peut facilement imaginer que si un grand nombre de joueurs se rassemble dans une même zone, le serveur visé ne sera plus en mesure de traiter les calculs et les envois de données dans un temps correct. De plus il faut calibrer le découpage des zones pour que la mémoire du serveur ne soit pas saturée. Encore une fois, la taille du monde fait que même en augmentant les capacités mémoire d’un serveur, on ne pourra pas tout faire tenir dans le même serveur.

Le concept de réplication :
Le concept de réplication vise à mettre en place des serveurs similaires, qui contiennent la même portion du même monde, et de partager les joueurs selon ces serveurs. Si dans un monde il y a une zone Château, il peut y avoir alors 3 serveurs contenant chacun la même instance de la zone Château mais ayant chacun leur liste de joueurs. L’avantage de ce système est le partage des ressources de calculs et des connexions de joueurs. Contrairement au zoning, si des joueurs se rassemblent dans la même zone, alors les serveurs pourront répondre à cette forte affluence grâce au partage. Néanmoins on y relève aussi des inconvénients. Tout d’abord du point de vue du jeu, les zones sont dites instanciées et cela casse l’illusion d’un monde virtuel complet. Deux joueurs souhaitant jouer ensemble devront s’efforcer de se retrouver dans la même instance. Du point de vue matériel cette structure est embêtante car il y aura forcément une limite au nombre de serveurs configurés pour une même zone, et donc une limite de performances liées encore une fois au nombre de joueurs. De plus, si 3 serveurs sont dédiés à la zone Château alors qu’en général un seul suffit à contenir tous les joueurs présents, cela occasionne des ressources supplémentaires inutiles et coûteuses.

Le concept d’instanciation :
Le concept d’instanciation peut être vu comme un mélange des deux types précédents. Un serveur gère une zone et ses joueurs, si le nombre de joueurs devient trop grand alors le serveur est répliqué sur un autre serveur et les joueurs qui arrivent sont envoyés sur ce second serveur. C’est une gestion dynamique de la charge des serveurs. Il subsiste cependant le problème de séparation de l’univers à la vue des joueurs, cela casse en partie l’illusion de monde parallèle.

De ces différentes façons de prévoir les serveurs des MMO, découlent un besoin de détection et de réorientations de la charge des serveurs. Ces mécanismes sont liés à des algorithmes agissant sur les deux niveaux, que l’on a vu auparavant, le premier se situe « entre » les serveurs et le second « dans » les serveurs. L’architecture peut être représentée selon le schéma suivant :

illustration architecture d'un serveur MMO

Le client communique avec un serveur, lui-même relié à une base de données et surtout, relié aux autres serveurs du jeu. Chaque serveur est indépendant dans son fonctionnement lorsque qu’il gère une zone du MMO et communique avec les autres serveurs par le biais du Controller. Ce dernier est la clé de voûte de la structure du réseau du jeu. La base de données permet d’enregistrer les données persistantes telle que le niveau du joueur, un emplacement de construction d’un bâtiment, etc… Concernant les éléments non persistants comme l’invocation temporaire d’un démon, le serveur dispose de sa propre mémoire.

Lors d’une surcharge de joueurs, c’est le serveur qui le détecte grâce à un algorithme qui veillera : soit à ce que le nombre prévu ne soit pas atteint, soit que les ressources mémoire et CPU du serveur reste dans un niveau correct. À partir du moment où cet algorithme détecte le cas de surcharge, le serveur prévient le Controller « central ». Ce dernier doit alors lancer un serveur équivalent de la zone et mettre en relation les deux serveurs. Le serveur 1 ayant retour de cette ouverture du serveur 2, il peut maintenant envoyer les joueurs afin de retourner sous son statut de charge correct.

retour sommaire

Quelles améliorations envisageables ?

Cette recherche s’est avérée plutôt difficile car les studios sont avares d’informations quand il s’agit de leur technologie. Si pour les jeux type FPS on arrive à s’imaginer que les développeurs réseau sont internes au studio, il en est tout autre pour celui des MMO. A ce niveau, on suppose un niveau d’expertise qui laisse penser que le pipeline n’est qu’en partie supporté en interne.

Néanmoins après toutes ces lectures, en recoupant les sites internet réalisés par des professionnels, les forums et les infos des blog développement, on arrive à saisir la problématique principale de la gestion de la charge dans les jeux massivement multijoueurs. Il s’agit de fournir à un nombre de joueurs, potentiellement énorme, un service fiable, offrant l’illusion d’un monde virtuel immense et cohérent, avec des ressources matérielles finies. Entrant en ligne de compte, le budget alloué à ce parc matériel est limité, on ne peut pas aller à la surcharge de serveur si leur utilité est anecdotique.

Considérant une moyenne prévue du maximum de joueurs quotidien à un même instant. L’idéal serait que les ressources serveurs soient utilisées à un taux compris entre 90% et 95%. Cela laisse une marge en case de connexion plus haute que d’habitude et l’avantage de bien utiliser le budget dédié à cette partie du jeu. Pour réussir ce challenge, les serveurs doivent être malléables et suivre les populations du monde virtuel. Pour expliquer cette idée, l’illustration par l’exemple est idéale.

Soit un monde découpé en 5 zones et pouvant accueillir en moyenne, chaque jour, un maximum de 1 000 joueurs en simultané. On dispose alors de plusieurs types de serveur :

On peut imaginer un système tel que celui-ci :

illustration proposition de structure

Les clients se connectent au serveur gérant les sessions, après authentification celui-ci envoie les données de connexion du joueur au Serveur de Connexion. Ce serveur charge les dernières données de localisation puis décide sur quel serveur de jeu envoyer le nouveau joueur. Dans le cas où cette zone n’est pas instanciée (comme la zone 4 ou 5), alors le SdM devra demander à un SdJ de faire une place pour cette zone afin d’y accueillir le joueur. Un SdJ pouvant faire tourner une zone complète pour lui seul, le SdJ 4 pourrait accueillir la zone 5 et délaisser les calculs de la zone 2 du monde au SdJ 3. Enfin pour les zones non utilisées par les joueurs, les évènements et entités dynamiques du jeu seraient hébergés dans le SdD. Ce dernier est prêt à transmettre ses informations à n’importe quel SdJ qui lui demanderait et, en cas de forte affluence ou de panne, de jouer le rôle de serveur tampon.

Avec cette proposition de structure, les transferts de données et les charges de calculs du jeu seraient partagées entre les serveurs en optimisant toutes les ressources disponibles. Néanmoins il faut qu’une zone du monde soit absolument supportée par un serveur référent qui délègue une partie de ses calculs et des transferts de données à un autre serveur, dans la lignée du concept de réplication. A ce besoin s’ajoute celui du traitement des connexions qui doit pouvoir être réalisé conjointement par l’ensemble des serveurs pour un montant dépassant le maximum de joueurs possible au même moment.

retour sommaire

Conclusion

Ce travail de recherche ne m’a pas emmené dans les profondeurs techniques auxquelles je m’attendais, dans des algorithmes réseaux et de gestion de charges. Au fil de mes recherches c’est une approche macroscopique qui semble régner sur les sites et au final je trouve cela logique : c’est de là que vient la difficulté de répartition de charges. Ecrire un serveur qui enregistre des connexions et les distribue n’est pas le problème (pour les professionnels du genre). Détecté une surcharge, échanger entre un client et un serveur, cela n’est pas un challenge non plus pour eux. En revanche, avoir une structure matérielle qui communique, réagit et s’adapte au nombre de joueurs évoluant dans un monde virtuel immense, là est le problème. Souvent on multiplie les ressources serveurs en ajoutant d’autres serveurs. Dans Eve Online, lors des gros combats, le temps du jeu (In-Game) est ralenti (artifice gameplay : dilatation du temps dans l’espace) ce qui laisse le temps aux structures serveur en place de calculer les rendus. Ce qui ressort de l’escalade des ressources c’est qu’elles sont rarement utilisées pleinement. Hors deux informations peuvent servir à calibrer les besoins de la structure : la taille du monde à héberger et le nombre de joueurs potentiel. Le tout est d’avoir une architecture logicielle réseau qui sache utiliser au mieux les ressources à sa disposition. Enfin pour finir, il faut être conscient que l’optimal n’est pas le parfait, impossible à atteindre dans les MMO car la population des serveurs évolue selon l’heure de la journée. Calibrer des serveurs pour un maximum de connexion à 18h00 engendrera des ressources inutilisées à 06h00 du matin.

retour sommaire

Références

  1. Gafferongames, site tenu par un programmeur professionnel spécialisé dans le réseau
  2. GameDevelopment et son système d'échanges entre programmeurs
  3. Dynamic Load Management for MMOGs in Distribued Environments, thèse de Herbet Jordan
  4. Un bref historique de l'Internet
  5. Site internet Gros pixels et son article sur le jeu en ligne
  6. http://www.shamusyoung.com/ et son article sur les problèmes de populations dans les MMO
  7. Stack Overflow - sujet sur les bases de données des MMO
  8. Sitepoint - SQL vs NoSQL
  9. quora.com - sujet questionnant le NoSQL
  10. Building a Peer-to-Peer Multiplayer Networked Game
  11. Wikibooks - concernant le modèle Client-Serveur et Peer-to->Peer
  12. Article rapportant la Grande Bataille dans Eve Online
  13. Tutoriel de programmation UDP
retour sommaire