La théorie sur les différents type de jeux multijoueurs

Il existe plusieurs types de multijoueur. On va ensemble de faire le tour des différentes solutions pour créer un jeu multijoueur. On essayera de comprendre la vision de l’administrateur et des joueurs étant des clients pour notre serveur. Existant énormément de possibilités pour faire un jeu multijoueur, on va parcourir dans cet article les solutions les plus utilisées.

On ne parlera pas ici de la partie à proprement parlé techniques, aussi appelés couches basses socket, tcp/ip… On va expliquer les différentes architectures qu’un jeu peut utiliser pour faire un jeu multijoueur temps réel.

Les différents types de serveurs

Ce qui impacte le plus le joueur au final c’est de savoir comment est administré votre serveur. Si votre jeu est en réseau local, hébergement dédié, … S’il pourra héberger chez lui le serveur entre amis. Ou au contraire s’il faudra se connecter à un serveur distant qu’il pourra choisir ou non.

1. Serveur intégré
   • C’est une solution courante même si de moins en moins dans les jeux AAA. C’est quand vous « hébergez » une partie multijoueur, que vos amis vous rejoignent, et go.
   • Ainsi on ne fait que lancer le jeu sans se poser de question, à ceci prêt qu’il faut avoir la même version du jeu pour pouvoir jouer à plusieurs. (Ce qu’y n’est plus un problème avec des plateformes comme Steam)
   • Le nombre de joueur est souvent très limité, on voit rarement de jeu ainsi avec plus de 8 joueurs simultanément.
   • Par exemple CS (CSS, CS:GO, …), Minecraft, …
2. Réseau local
   • Cette solution est une sous catégorie du serveur intégré, en ne limitant les joueurs qu’au personne présente chez vous. Donc non disponible via internet. On en trouve de moins en moins. Mais ils permettaient d’avoir une très faible latence entre les joueurs. Pour les plus vieux, des programmes comme Hamachi avait existé à cause de ce mode. En simulant un réseau local entre les participants.
   • De la même manière que le serveur intégré, il faut avoir la même version pour que tout le monde puisse jouer ensemble.
   • Le nombre de joueur est souvent très limité aussi.
   • La plus part des jeux où vous deviez rejoindre une ip, par exemple Age of empire. Pour des jeux actuels, il faut regarder du côté des jeux indé, mais même là il y en a de moins en moins.
3. Hébergement dédié
   • L’hébergement dédié est souvent quand vous avez le choix de plusieurs serveurs à rejoindre mais que vous pouvez vous connecter qu’en tant que joueur, vous n’avez aucun droit de modération. Dans ce cas seul celui qui a accès au serveur, potentiellement uniquement les créateurs du jeu. Il permet d’avoir la main sur l’équilibrage, les mises à jours, …
   • Côté serveur, il faut bien sûr le faire tourner, puis lorsqu’on lance le jeu, on peut choisir le serveur à rejoindre.
   • Pouvant avoir de meilleur serveur, on peut espérer viser les 200 joueurs pour certains jeux.
   • Guns of icarus online, GTA5, Arma, …
4. Hébergement local
   • C’est une sous catégorie de l’hébergement dédié, à ceci près, que vous pouvez héberger le serveur chez vous. Celui qui héberge étant un joueur, il a tout les pouvoirs sur son monde. Permettant souvent la création de mode, de modération, …
   • Il faut dans un premier temps lancer le serveur chez soi, puis de la même manière que l’hébergement dédié on aura le choix du serveur à rejoindre.
   • La plus part du temps on aura un serveur un peu moins puissant, mais on peut espérer avoir entre 10 et 50 joueurs.
   • Minecraft, Space engineers, …
5. MMO
   • Ici on cherche à avoir le plus de joueurs simultanément dans la même instance de jeu.
   • Lorsqu’on veut rejoindre une partie, le jeu nous trouve souvent automatiquement un serveur adapté pour ce qu’on souhaite.
   • L’avantage du cloud est que la puissance de calcul pourra suivre, et on peut espérer atteindre des milliers ou des centaines de milliers de joueurs.
   • WOW, T4C, Guild wars, Rocket League,  Overwatch, …

A noté que sur beaucoup de jeu, possède les deux modes serveur intégré et hébergement dédié au choix. Exemple de Counter-Strike, vous pouvez lancer ou héberger une partie privé/public, en local ou internet. Donc à la fois avoir un jeu avec un hébergement dédié ou avec un serveur intégré.

On a plusieurs type de réseau pour l’utilisateur final. Selon chaque solution on a plus ou moins de liberté pour le joueur, le créateur du jeu ou l’hébergeur. Connaissant la vision de chacun selon où vous placez votre gestion, on a plusieurs architectures.

Les architectures réseau

Client-Serveur

 

En client/serveur, chaque fois qu’un client voudra faire la moindre action ayant des répercutions (bouger, frapper, envoyer un message, …) il doit envoyer la requête au serveur. C’est alors le serveur qui s’occupe de valider ou non, et de propager l’action et ses conséquences à l’ensemble des clients.

A noter que le serveur peut être un client et non pas un serveur dédié

 

 

• Avantages
  • Possible de corriger des problèmes sur le serveur sans avoir à toucher aux clients et vise-versa.
  • Niveau sécurité, les données sont centralisés. La sécurité peut donc protéger des données utilisé uniquement côté serveur.
  • La centralisation des données sur un serveur permet une administration beaucoup plus simple.
  • Il existe de nombreux framework ou moteur qui vous propose des solutions rapides à mettre en place.
• Désavantages
  • En cas de blocage réseau, un client peut ne plus pouvoir contacter le serveur et être considéré comme déconnecté.
  • Le serveur doit garder autant de lignes ouvertes qu’il n’y a de clients pouvant surcharger.

Peer-To-Peer (ou pair à pair en français)

 

En p2p, il n’y a pas de serveur. Chaque client effectuant une action ayant des répercutions sur les autres, il va propager l’information aux autres, qui se mettront à jour en fonction.

 

 

 

• Avantages
  • La résistance à un blocage réseau est robuste. Si un client ne peut contacter un autre client, il peut transmettre les infos indirectement.
  • Il existe de nombreux framework ou moteur qui vous propose des solutions rapides à mettre en place.
  • On peut gérer un grand nombre de clents simultanément connectés.
• Désavantages
  • Niveau sécurité des données, il peut être « facile » de récupérer les données des autres utilisateurs qui se balade dans la ram.
  • Pour l’administration des données, il faut prévenir l’ensemble des clients possibles pour qu’ils s’actualisent.

 

Hybrid

Il existe plusieurs version hybrides, mais la plus simple étant que chaque client propage ses actions aux autres ainsi qu’au serveur.

Le serveur étant utilisé comme arbitre et va répondre à chaque joueur si l’action est validé ou non.

 

Il serait difficile de comparer les avantages des inconvénients d’un mode hybride, puisqu’il en existe énormément. On peut imaginer que le serveur ne soit là que pour permettre de télécharger les ressources (cartes, images, personnage, …), pour valider ou transmettre les informations, pour sauvegarder uniquement, pour faire des calculs complexe afin de décharger les clients…

 

Interpolation des données et lags

Quelque soit votre solution réseau, vous aurez forcément une latence.

 

Cet exemple vous montre ce qu’y se passe avec 2 clients.

Quand le client A bouge, sur son écran c’est instantané, mais côté du 2nd client, il ne voit le déplacement qu’une fois avoir reçu l’information.

Ça peut paraitre bête à expliquer mais c’est là la plus grosse difficulté quand on travail sur un jeu en réseau.

 

Cette latence n’est pas uniforme, en partant sur un jeu qui communique 20 fois par seconde, pour avoir suffisamment d’actualisation pour que le mouvement soit fluide (c’est le tick rate), on aura donc une information en moyenne toutes les 50ms. Cependant il est possible de recevoir l’information en retard ou jamais. Dans les deux cas on devra utiliser une interpolation des données pour faire sans. L’idée est relativement simple de la même manière que votre jeu va prendre en compte le temps entre chaque image, on prendre en compte le temps entre les différents appels réseaux.

La courbe vous montre le point rouge qui n’a jamais été reçu, en imaginant que c’était le déplacement d’un autre client, sur votre écran vous ne l’auriez pas vu faire le mouvement exacte, mais une petite approximation.

Après il faut se rassurer, s’il y a suffisamment de trafic réseau, comme je notais plus haut 20 appels par seconde, ces désagréments seront alors à peine perceptibles, on peut donc se permettre ces approximations.

Physics

On parlait un peu plus tôt de serveur qui joue le rôle d’arbitre et qu’il y a un décalage entre la position qu’on voit des autres clients et celle qu’on peut voir chez nous. Si on prend le cas d’une collision, les positions étant différentes, chaque client calculerait un rebond ou autre autre effet de la collision différent selon les données qu’ils ont.

C’est pourquoi il est très compliqué de gérer des problèmes physiques en p2p, mais beaucoup plus envisageable avec un serveur jouant le rôle parti objectif sur les données.

En mode client/serveur, il existe deux types. Ceux qui vont servir d’arbitre et donc peuvent gérer la physique, et ceux qui gère uniquement la partie logique, validant si une action est possible mais serveur principalement à transmettre les actions aux autres clients.

Il reste possible de faire le travail en p2p cependant dans le cas de la collision, 2 voitures qui se percutent, n’ayant pas les mêmes données qui aura raison ? Sachant que les deux avançaient vers l’autre. On peut se dire qu’on prend aléatoirement le client A ou le client B, ça peut aussi être un client C qui va jouer le rôle d’arbitre… ou encore on prend les résultats de A et de B et partage les informations de sorte à faire la moyenne des deux. On peut pousser à l’extrême chez l’un il y a une collision et l’autre l’a évité de justesse, il serait alors injuste pour lui que la collision se produise. Je pousse le raisonnement dans les cas les plus extrême parce que Murphy nous l’a montré, si un problème doit survenir… il arrivera forcément à un moment. Je peux vous l’assurer.

Prédiction des actions

Vous souvenez vous d’un jeu multijoueur, où les personnages se téléporte alors qu’il cherche simplement à se déplacer ?

C’est l’effet de la latence entre les différents clients, le temps que l’action est traité et envoyé jusqu’à vous. Pour éviter cela on tente de prédire les actions des autres clients. Il y a bien des cas qu’on ne pourra pas prédire mais dans le cas d’une action continue comme un déplacement. On peut simuler que le client continue d’avancer tant qu’on a pas eut d’ordre différent. Bien sûr ce n’est pas suffisant si le client ne répond plus. Pour un autre client, il continuera à courir aussi longtemps qu’on n’aura pas considéré qu’il est partit.

Cette partie est sûrement la plus compliqué.

 

 

Source:

Game Server Architecture Patterns

What every programmer needs to know about game networking

Building a Peer-to-Peer Multiplayer Networked Game

Source Multiplayer Networking