Skip to content

CAS D'UTILISATION: MULTIJOUEUR

Largement, le multijoueur est un concept simple. Les utilisateurs doivent pouvoir envoyer et recevoir des données d’autres utilisateurs. Appliquer cela au domaine d’expertise du client était assez simple.

Les gens qui font du vélo à l’intérieur, qui font un tour virtuel à vélo, devraient pouvoir en voir d’autres sur la même route qu’eux. Sur une carte GPS, ils devraient également voir d’autres personnes à vélo autour d’eux, pas nécessairement sur la même route qu’eux.

La partie difficile est bien sûr de transmettre les données d’un utilisateur à un autre. Cela devrait également se produire très rapidement pour que tout le monde voie tout le monde sur la position qu’il occupe réellement. Et puis, en plus de cela, tout devrait fonctionner pour des milliers d’utilisateurs faisant la même chose en même temps.

Largement, le multijoueur est un concept simple. Les utilisateurs doivent pouvoir envoyer et recevoir des données d’autres utilisateurs. Appliquer cela au domaine d’expertise du client était assez simple.

Les gens qui font du vélo à l’intérieur, qui font un tour virtuel à vélo, devraient pouvoir en voir d’autres sur la même route qu’eux. Sur une carte GPS, ils devraient également voir d’autres personnes à vélo autour d’eux, pas nécessairement sur la même route qu’eux.

La partie difficile est bien sûr de transmettre les données d’un utilisateur à un autre. Cela devrait également se produire très rapidement pour que tout le monde voie tout le monde sur la position qu’il occupe réellement. Et puis, en plus de cela, tout devrait fonctionner pour des milliers d’utilisateurs faisant la même chose en même temps.

1. Exigences

Il y a quelques limitations à prendre en compte. D’une part, il est impossible d’envoyer des données instantanément sur des distances physiques. De plus, créer quelque chose qui évolue à l’infini prend énormément de temps. Enfin, l’envoi rapide de grandes quantités de données nécessite une connexion Internet robuste.

Puisque nous voulions garder le multijoueur aussi accessible que possible, nous avons dû décider quelles marges étaient acceptables. Nous n’avions ni le temps ni les ressources pour créer le meilleur multijoueur au monde. Nous pourrions cependant en créer un qui puisse répondre aux besoins immédiats et futurs du client.

Pour ça, nous devions définir les exigences que le système multijoueur devait remplir:

  • Les applications doivent envoyer et recevoir deux mises à jour par seconde
  • Le système devrait être capable de prendre en charge 10.000 utilisateurs en même temps, avec la possibilité de se développer au-delà à l’avenir
  • Le coût par utilisateur doit être inférieur à x € par mois

La recherche d'une bonne technologie de réseau

Un multijoueur tient ou tombe avec sa technologie de réseau. Nous ne sommes pas trop fiers d’admettre que les vrais ingénieurs réseau en savent beaucoup plus sur ces choses que nous, donc au lieu d’essayer de créer notre propre technologie réseau pour obtenir des données de A à B, nous avons décidé de voir s’il y avait des produits disponibles qui ont fait exactement cela comme leur objectif principal.

Nous avons dressé une liste complète des technologies possibles et noté quelques caractéristiques clés de chacune (si disponible). Ensuite, nous avons suggéré quelques candidats solides à examiner de plus près. En concertation avec le client, nous avons choisi deux candidats très solides. Sur papier, ils étaient tous les deux aussi bons, mais nous avons quand même dû en choisir un. Nous avons décidé de les tester tous les deux par l’épreuve du feu.

uLink/UnityPark
Photon
SmartFoxServer
AppWarp
Lidgren
KBEngine
Forge
RakNet
Nakama
Colyseus
Badumna
ElectroServer
RedDwarf
NetDog
PikkoServer
Player.IO
SlimNet
Union
Orbit
Gamooga
Azure Gaming – Playfab

 

3. Preuve de concept

Une application a été créée pour afficher les points se déplaçant sur une carte GPS, sur un itinéraire prédéfini. Les données pour ces points seraient envoyées sur le réseau et reviendraient pour le déplacer réellement. Plusieurs applications peuvent être exécutées sur différents PC et elles devraient toutes voir les mêmes points aux mêmes emplacements. De plus, chaque application devrait pouvoir créer plus de points et, à son tour, elles seraient également visibles sur d’autres applications. Cette application a ensuite obtenu deux versions, une pour chaque technologie de réseau, afin que nous puissions voir laquelle fonctionnait le mieux dans un scénario réel.

4. Architecture du serveur

Le client a accepté lorsque nous avons suggéré que nous voulions exécuter cette solution multijoueur dans le cloud. Cela s’accompagnait d’avantages intéressants, tels qu’une meilleure évolutivité et la possibilité pour les utilisateurs de se connecter à un centre de données proche d’eux.

Une «salle» est un ensemble d’utilisateurs qui peuvent se voir. Les utilisateurs ne doivent recevoir que les mises à jour des autres utilisateurs qu’ils peuvent voir. Cela réduit la bande passante au minimum. Un serveur de jeu peut héberger une ou plusieurs de ces salles. Lorsque plus de capacité est nécessaire, nous pouvons simplement ajouter un nouveau serveur de jeu pour gérer l’augmentation de la charge.

Cependant, deux problèmes subsistent. En fonction du moment choisi, les utilisateurs sur la même route pourraient être placés dans des pièces différentes, ne se voyant ainsi pas. Cela découlait du fait que l’application demandait d’abord au serveur si une chambre était disponible. S’il n’y en avait pas, il fallait le créer et le rejoindre. S’il y en avait un, il pourrait simplement le rejoindre.

Cela pourrait amener deux clients à demander une certaine chambre en même temps, avant que l’un ou l’autre ne puisse créer une chambre. Le serveur leur disait à tous les deux qu’une telle salle n’existait pas et ils en créeraient chacun une. Les deux clients créeraient ainsi une salle pour le même itinéraire. Le résultat était qu’ils ne pourraient pas se voir.

Si nous laissons un seul point décider quand créer et quand rejoindre des salles, ce sera toujours cohérent, car il saurait quand il a créé une salle et les problèmes de concurrence pourraient être résolus.

Entrez le serveur de matchmaking…

L’autre problème était que, par défaut, chaque message envoyé par une application était dupliqué et envoyé à tous les autres clients. Bien que cela semble correct, voire logique au début, le problème devient clair lorsque nous appliquons un peu de mathématiques.

n = nombre d’utilisateurs
Quantité de messages envoyés au serveur = n
Quantité de messages envoyés par le serveur = n * (n – 1)

Si nous avons 100 joueurs sur le même itinéraire envoyant 100 messages au serveur, 9900 messages reviennent. Et nous aimerions avoir deux messages par seconde, ce qui signifie 19800 messages par seconde. C’est un peu trop.

Nous avons donc créé une logique personnalisée à exécuter sur le serveur, qui regroupe les mises à jour et n’envoie un message au client qu’à un intervalle défini. Nous sommes même allés plus loin: nous n’envoyons que les données nouvelles à cette application particulière, de sorte qu’aucune donnée inutile ne soit envoyée. Cela réduit considérablement l’utilisation de la bande passante.

 

5. Mise en œuvre dans toutes les applications

Une fois le «comment» déterminé, nous avons créé la configuration et l’implémentation du serveur, en utilisant l’application de preuve de concept pour tester en cours de route. Une fois que nous étions convaincus que tout était opérationnel, il était temps de mettre en œuvre et d’utiliser le nouveau multijoueur dans les applications des utilisateurs finaux. Il y avait plusieurs applications développées et maintenues par différentes équipes. Pour nous assurer qu’ils puissent tous tout mettre en œuvre le plus rapidement possible, nous avons créé une documentation approfondie, telle que:

  • Un aperçu de chaque composant multijoueur et de son fonctionnement à un niveau élevé
  • Un contrat de données décrivant quels messages doivent être envoyés et reçus du multijoueur, jusqu’aux bits et octets
  • Documentation API des serveurs de matchmaking, décrivant quels appels HTTP pourraient être effectués et à quoi ressemblaient les réponses
  • Un diagramme de données de tous les champs utilisés dans le système multijoueur et à quoi ils ont servi

6. Résultat

Ce multijoueur a été rendu public juste avant la saison occupée de notre client en 2019. Il a fonctionné sans interruption et sans aucun problème majeur depuis. Le nouveau multijoueur a conduit à un nombre record d’utilisateurs en ligne, une croissance sans précédent et une fidélisation des abonnés, car les utilisateurs peuvent profiter du vélo ensemble dans le confort de leur propre maison.

Nous serons heureux de répondre à toutes vos questions!