Tl; dr:  Maintenir des clusters dans des milliers d'emplacements et demander aux clients de jeu de pinger tous ces emplacements et de faire un retour n'est pas techniquement & financièrement viable une fois que vous atteignez des milliers d'emplacements.

Courte histoire du système de matchmaking

Les jeux multijoueurs ont besoin, eh bien, de plusieurs joueurs pour se dérouler (évidemment)! Comment ces joueurs peuvent se trouver est tout le sens du système de matchmaking. Dans les premiers jours, le matchmaking se faisait en partageant votre IP avec vos amis pour vous connecter les uns aux autres (Bonjour Doom!). Très vite, des serveurs dédiés apparaissent et les jeux vous permettent de choisir parmi une liste de serveurs disponibles, parfois en vous indiquant la latence entre vous et chaque serveur. Au début des années 2000, le premier système de matchmaking qui automatisait la sélection d'un serveur a été créé. À partir de là, le système de matchmaking de nouvelle génération a commencé à incorporer des règles pour regrouper les joueurs en fonction du contexte du jeu. c'est-à-dire que les joueurs joueraient contre d'autres ayant un niveau de personnage similaire, le même type de voitures, etc. 

Il y a un équilibre à trouver entre l'application des règles pour obtenir un match parfait, et le temps que vous aurez à attendre un autre joueur de votre niveau pour jouer. Demandez aux joueurs diamant de League of Legends de Riot qui sont habitués à attendre plus de 15 minutes pour trouver un adversaire de leur niveau. Ce streamer a attendu pendant 5 heures et même après cela, il n’a toujours pas trouvé quelqu’un avec qui jouer. Les retards de matchmaking ne sont pas seulement causés par les règles de politique de jeu (et le manque d'adversaires) mais par le nombre de centres de données qu'il peut exploiter.

Le processus d'aujourd'hui

Le flux typique d'un système de matchmaking est le suivant :

• Cela suppose que le studio utilise un système de matchmaking centralisé. Certains systèmes plus anciens utiliseront un système de matchmaking par centre de données, ce qui rend les choses encore plus compliquées.

• Le client de jeu demandera au système de matchmaking une liste de centres de données disponibles

• Le client de jeu effectuera un ping ICMP basique à chacun d'eux

• Le client de jeu enverra une demande au système de matchmaking pour un nouveau jeu, prenant un "ticket" et faisant un retour sur la latence varient par centre de données

• Le système de matchmaking mettra le ticket dans une file d'attente avec un horodatage.

• À partir de là, diverses règles peuvent être créées par les concepteurs de jeux, mais celles-ci impliqueront généralement de regrouper les joueurs dans une certaine région.

• Une fois regroupés, les joueurs pour un match donné se verront attribuer un serveur de jeu qui est en attente et opérationnel.

• Les joueurs peuvent jouer ensemble

Pourquoi devrions-nous changer?

Chaque système de matchmaking est différent, et il y a d'autres étapes, notamment autour du chiffrement et autres. Mais cette liste représente l'idée générale, et cela fait plus de 15 ans que cela existe. Ce modèle fonctionne bien lorsque vous avez un nombre limité de centres de données. Il y a cependant certaines limitations :

• Vous devez réchauffer (pré-démarrer) des instances, donc vous avez besoin de clusters de serveurs de jeux en fonctionnement dans chaque emplacement (et d'équipes de personnes pour les entretenir). Vous engagez un coût pour un service qui n'est même pas utilisé. Ceux-ci sont appelés "flottes".

• Les clients de jeu doivent initialement pinger chaque centre de données. Cela signifie que la latence est considérée d'un point de vue auto-centré et non pas au niveau du match dans son ensemble. Certains systèmes de matchmaking "ajouteront" de la latence entre les joueurs, mais à ce stade, cela ne fait que prendre en compte la somme des latences au lieu de l'expérience globale & de l'équité.

• Les temps de correspondance augmentent puisque vous devez maintenant ajouter la latence comme règle dans le matchmaking des joueurs plutôt que de vous concentrer sur des mécanismes centrés sur le jeu.

• La décision est prise initialement et, une fois démarrée, ne peut pas être changée. Si un changement dans le réseau survient, rien ne peut être fait pour changer cela.

• Les solutions d'aujourd'hui ne regardent que la latence, rien d'autre. D'autres éléments doivent être pris en compte comme l'heure de la journée, les expériences précédentes, le contexte des joueurs, et bien d'autres.

Lorsque ce modèle a été initialement mis en place, les studios et éditeurs achetaient eux-mêmes le matériel, hébergeaient les machines et le réseau dans un nombre restreint de centres de données centralisés. Environnement simple, centralisé, sous contrôle. Quelques années plus tard, les fournisseurs de cloud ont commencé à offrir une offre similaire mais sans le tracas de gérer l'infrastructure. Ils ont facilité la création d'un centre de données de l'autre côté du globe sans avoir à investir trop. Cela restait fortement centralisé (AWS possède aujourd'hui 22 centres de données sur lesquels vous pouvez déployer dans le monde entier), et offrait une fibre rapide avec de multiples points de présence pour faire entrer rapidement les joueurs dans ces DC centralisés. Quelle que soit la vitesse de ces dorsales, les joueurs doivent toujours se rendre de leur domicile à ces DC en utilisant des réseaux et des fibres. Les fournisseurs de cloud soutiennent qu'ils couvrent les zones métropolitaines avec une latence inférieure à 20 ms en Amérique du Nord, mais dans quelle mesure cela sera vrai alors que les gens s'éloignent des grandes villes en raison de Covid-19 et que le travail à domicile devient la norme. Si ces affirmations étaient vraies, est-ce que le lag serait toujours le problème numéro 1 du point de vue des joueurs?

Edge Computing pour compléter le cloud public

En regardant ce qui arrive, un nouveau type d'infrastructure émerge appelé l'Edge Computing. Au lieu d'utiliser de grandes fermes de serveurs, les fournisseurs construisent des centres de données plus petits, plus proches des utilisateurs. Par exemple, au lieu de construire quelques grands DC aux États-Unis, ils les répartissent dans chaque état. Ce processus s'accélère alors que les fournisseurs de services mobiles considèrent ces nœuds d'edge pour soutenir leur réseau 5G, et commencent à en déployer un à la base de chaque antenne cellulaire.

Cette tendance est observée dans le monde entier, même les clouds publics réalisent que cela pourrait représenter une menace pour leur activité et ont commencé à s'associer avec des opérateurs pour déployer de plus petits DC dans ces réseaux.

Le réseau peut être optimisé, un chemin plus rapide peut être trouvé, mais personne ne peut enfreindre les lois de la physique. Les fibres ne seront jamais plus rapides que (la moitié) de la vitesse de la lumière, et vous n'aurez jamais de fibres entre chaque point de la planète. Cela n'a rien à voir avec la technologie, c'est du bon sens. La solution restante est de se rapprocher des utilisateurs.

Revenons au matchmaking. L'architecture actuelle peut fonctionner pour exploiter quelques dizaines de centres de données, peut-être 50, 60. Mais étant donné qu'il est clair que le marché de l'infrastructure prend un chemin où nous verrons plus de milliers de centres de données répartis dans le monde, comment le modèle actuel va-t-il évoluer? Comment pouvez-vous tirer parti de cette nouvelle capacité?

Que devez-vous faire?

Vous pouvez laisser les choses telles qu'elles sont, "le service d'aujourd'hui est assez bon", "le lag n'est pas une priorité", "mon système de matchmaking prend déjà en compte la latence" ...   La réalité est que si vous n'innovez pas, d'autres le feront. Tirer parti de ce nouvel ensemble de capacités dans une infrastructure évolutive nécessite de nouvelles méthodes et processus. Les systèmes de matchmaking d'aujourd'hui devront être adaptés, bien au-delà de l'ajout de quelques DC. La quantité de nouveaux jeux lancés quotidiennement rend difficile la concurrence entre studios et éditeurs. Le nombre de joueurs pour un jeu donné devient plus petit alors qu’ils se répartissent sur de nombreux autres titres. Vous ne pourrez pas utiliser des milliers d'emplacements en ayant un cluster dans chacun, en comptant sur le code côté client, et en espérant le meilleur. L'ajustement des réseaux a été effectué, et le gain d'aujourd'hui est négligeable par rapport à ce que l'edge computing permet aux studios de faire.

Les infrastructures à venir sont complexes, chaque match de votre jeu est différent, et personne ne contrôle tous les réseaux d'où vos joueurs viendront. Vous avez besoin d'une solution qui puisse s'adapter rapidement en temps réel, apprendre à l'aide de mécanismes d'IA avancés ce qui a fonctionné et ce qui n'a pas fonctionné, et optimiser chaque match comme s'il était sur mesure pour vos joueurs.

Si vous êtes sérieux au sujet de votre jeu et de son avenir, contactez-nous et nous vous aiderons à améliorer l'expérience de vos joueurs.

Contactez-nous à info@edgegap.com et nous nous assurerons que vos joueurs aient la meilleure expérience possible grâce à notre technologie de pointe.