Ce qui suit est la transcription de la présentation de Michal Buras au Live Service Game Summit (2024.09.10).

Le message à retenir est une meilleure compréhension des différentes technologies de mise en réseau disponibles et les avantages ainsi que les défis des différentes infrastructures de jeux. Plus précisément, le peer to peer en tant que technologie et ses défis, en particulier la migration des hôtes, et comment cela impacte vos ressources de développement.

Présentation - Transcription Complète

Introductions

Bonjour à tous,

Je suis Michal et aujourd'hui je voulais vous montrer le parcours que nous avons suivi pour créer une solution multijoueur parfaite pour Six Days in Fallujah, en particulier notre analyse des solutions peer-to-peer et comment gérer la migration des hôtes. De plus, nous allons parler de l'hébergement de jeux sur serveur dédié.

Le message que vous retiendrez, espérons-le, est une meilleure compréhension des différentes technologies disponibles et les avantages ainsi que les défis des différentes infrastructures de jeux.

En décomposant, nous allons passer en revue le peer to peer en tant que technologie et ses défis, en particulier la migration des hôtes, et comment cela impacte vos ressources de développement.

Ensuite, nous examinerons les différentes options d'infrastructure d'hébergement de serveurs dédiés, y compris les serveurs bare metal, les machines virtuelles de calcul et les instances de conteneurs.

À propos du conférencier

Mais tout d'abord, un peu sur moi, je suis Michal Buras, Responsable Réseautage / Ingénierie en ligne pour Six Days in Fallujah. Le jeu a eu un lancement très réussi et nous continuons à le développer au fil du temps.

Personnellement, je suis dans le développement de jeux depuis six ans, dix ans dans le développement de logiciels. J'ai commencé dans la VR pour l'industrie initialement, mais pas pour les jeux et je voulais faire des jeux. Donc, j'ai rejoint le [Multiplayer Games Group] (MPG), où j'ai fait un travail fascinant sur le réseautage entre autres choses. Et après cela, j'ai travaillé comme généraliste pour Breach Studios, mais je voulais vraiment faire du réseautage, alors j'ai rejoint Highwire Games.

Objectif de la présentation

Pourquoi suis-je ici, n'est-ce pas ?

Après le lancement initial, j'étais chargé avec mon équipe d'ajouter la migration des hôtes à Six Days, car c'est essentiel pour notre expérience et pour que le jeu continue d'être en ligne. Ce que j'ai réalisé, c'est qu'il y avait un manque d'informations et d'analyses [disponibles] entre les différentes technologies, à savoir le peer to peer par rapport à l'hébergement dédié.

De plus, étant curieux, je voulais évaluer si le peer-to-peer [réseautage] était vraiment la solution économique que nous continuons à dire dans le développement de jeux.

Enfin, j'espère que cette exploration aidera à informer les autres et à accroître les connaissances disponibles pour la communauté des développeurs de jeux au sens large.

Réseautage Peer-To-Peer dans les Jeux Multijoueurs - Les Bases

Je réalise que tout le monde dans la salle n'est peut-être pas ingénieur, alors voici un aperçu rapide des bases du peer-to-peer et comment connecter des joueurs sur le réseau.

Le peer to peer, comme on dit, est censé être super simple. Le jeu crée un serveur d'écoute et avec l'IP publique, vous connectez tous les joueurs au serveur. Et malheureusement, la vérité n'est pas aussi simple qu'il y paraît, car votre IP publique n'est pas votre propre IP publique.

Cela signifie que l'adresse IP est partagée. Votre fournisseur Internet regroupe plusieurs utilisateurs sous une seule IP avec un processus appelé traduction d'adresse réseau.

La seule différence est le numéro de port qui vous est temporairement assigné lorsque vous demandez une page web ou une autre ressource. Pour les non-ingénieurs, pensez à l'IP du serveur comme à un immeuble d'appartements. Cependant, comme il y a plusieurs appartements dans chaque bâtiment, chaque fois que vous commandez une pizza, on vous donne un numéro d'appartement unique, et le numéro change au fil du temps.

Et cela cause beaucoup de confusion.

Nous devons trouver un mécanisme pour récupérer le numéro assigné et partager cette information d'une manière ou d'une autre avec les autres joueurs.

Réseautage Peer-To-Peer - Serveurs STUN

Cette solution s'appelle un serveur STUN. Pensez-y comme à un annuaire téléphonique. Si vous voulez que les gens puissent trouver votre entreprise, vous devez mettre à jour l'annuaire avec votre numéro actuel.

Malheureusement, cette solution n'est pas sécurisée, car notre numéro d'appartement pourrait être partagé davantage, et quiconque sur Internet pourrait nous envoyer n'importe quoi. La plupart des fournisseurs de services trouvent cela non sécurisé et bloquent ce type de trafic.

Réseautage Peer-To-Peer - Serveurs de relais

L'alternative, la seule alternative que nous avons, ce sont les serveurs de relais. Votre adresse privée n'est partagée avec personne sauf le serveur qui relaie l'information entre vous et l'autre joueur.

Il y a presque des serveurs sans calcul, mais comme ils nécessitent un certain niveau de puissance de calcul, vous devrez les héberger, ce qui signifie que vous avez besoin d'un fournisseur de services.

Il existe de nombreux services disponibles qui fournissent des solutions de serveur de relais que nous avons évaluées, mais pour cette présentation, je ne parlerai que de trois que je trouve les plus intéressants.

Relais : Epic Online Services - Vue d'ensemble

Tout d'abord, Epic Online Services (EOS) offre des relais gratuits, ce qui signifie zéro coût initial et zéro coût de maintenance.

Cette solution nécessite le moins de développement, elle est multiplateforme, dispose d'un système de lobby, et la seule chose qui vous manque pour un jeu complet est un système de matchmaking.

Cependant, vous n'avez absolument aucun contrôle sur la façon dont ces joueurs sont routés.

Un serveur de relais ajoute un nœud supplémentaire à votre paquet de jeu par lequel il doit passer, ce qui introduit de la latence. Étant donné le nombre limité de relais, un joueur pourrait être routé vers des relais distants en fonction de la disponibilité du moment. Cette latence élevée est inacceptable dans un jeu commercial, car elle conduit à une mauvaise expérience pour le joueur, et par conséquent, à un taux de désabonnement. Cela entraîne directement des joueurs frustrés sur Discord et une perte de revenus.

Relais : Epic Online Services - Vulnérabilités

Epic Online Services peut également être vulnérable.

Ceci est un exemple d'un des titres AAA de Steam. Nous avons ici un groupe de joueurs dans le lobby, et ils peuvent échanger des informations qui sont gérées par WebSocket. Lorsque vous créez un jeu peer-to-peer, vous rassemblez généralement des informations pertinentes sur le joueur hébergeant le jeu, c'est-à-dire sur son PC, n'est-ce pas ?

En utilisant une application simple appelée Fiddler, vous pouvez accéder à cette base d'informations du lobby et exposer toutes les informations privées des autres joueurs en texte clair. Et cette application prend littéralement deux clics à installer et peut être utilisée par un enfant de dix ans. Donc, quelqu'un pourrait à lbasiquement rassembler les données [de votre] base de données, n'est-ce pas ?

Et c'est un énorme risque pour un jeu commercial à assumer. Donc faites attention à ce que vous implémentez en utilisant le système de lobby.

Relais : WebRTC

[Une] solution peer-to-peer alternative que j'ai trouvée intéressante est les relais WebRTC. J'ai découvert cette option d'infrastructure grâce à People Can Fly’s Outriders qui avaient une présentation approfondie d'Unreal il y a quelques années.

En bref, c'est une bonne implémentation car ils réutilisent des serveurs de relais, mais ils ont dû modifier le code Unreal beaucoup pour y faire face. De plus, ils ont dû héberger les relais eux-mêmes. C'est une infrastructure personnalisée que vous devez construire, tester, optimiser et maintenir, ce qui entraîne des coûts mensuels qui auraient pu être dépensés ailleurs.

Cependant, il n'est pas clair s'ils sont vraiment tellement meilleurs en termes de performances que les relais EOS.

Relais : Serveurs Développés en Interne / Autohébergés

Ce qui me amène aux serveurs de relais développés en interne. Et l'un des projets, l'idée était que nous pouvions créer un serveur de relais dans Unreal Engine qui va sérialiser des paquets, peut-être les analyser pour prévenir la tricherie. Et cela n'avait pas de sens au niveau conceptuel à cause de la latence et des coûts computationnels supplémentaires.

Si vous réalisez des calculs, ce n'est plus un serveur de relais. Cela devient une forme de serveur dédié. Donc ma recommandation, si vous souhaitez avoir votre propre technologie de relais, il suffit de prendre un proxy de GitHub, de le modifier pour être configurable en temps d'exécution. Vous n'avez pas besoin d'implémenter une sorte de répétition de paquet, d'ordre, etc., car votre gestionnaire de jeu devrait s'en occuper.

Mais si vous prenez un recul en ce moment et pensez à tout ça. À ce stade, vous ne créez pas un jeu, vous construisez une infrastructure. Brûler de l'argent sur des choses qui n'aident pas votre jeu à croître avec du contenu, une meilleure technologie ou des fonctionnalités.

Quel est le but ?

Migration des Hôtes & Impact sur les Défis des Relais

Maintenant, tous ces services ont un défi fondamental.

Vous avez besoin d'un mécanisme appelé migration d'hôte, parce que si le joueur qui héberge le jeu quitte, tout le monde est déconnecté.

C'est un problème fondamental que vous devez résoudre car cela tue littéralement la session de jeu de bout en bout. Un énorme problème pour tout jeu commercial où le multijoueur est clé.

Nous avions un énorme problème dans Six Days avec des gens qui quittaient simplement le jeu à cause de la difficulté de notre jeu. Vous n'avez qu'une seule chance, un seul tir, n'est-ce pas ? Et ils ne sont peut-être pas conscients d'être un hôte ou peut-être qu'ils ne se soucient pas d'être un hôte. Donc, c'était un arrêt de la fête.

[Dans] Six Days, j'ai mis en œuvre une migration d'hôte de base en utilisant uniquement le pilote de réseau Unreal et cela fonctionne bien dans sa forme très basique. Je ne veux pas entrer trop dans les détails ici car c'est pour les geeks d'Unreal, donc vous pouvez me demander dans une conversation privée après, si vous êtes curieux.

Mais l'ensemble du projet nécessitait une refonte complète pour que toutes les fonctionnalités le supportent. Maintenant, chaque petite fonctionnalité, chaque blueprint créé par les designers devait être retravaillé, et il n'y a pas de solution miracle pour implémenter la migration d'hôte, à moins que votre moteur ne le supporte nativement, mais cela engendrera un coût de bande passante réseau.

Il y avait trop de risque en gestion de projet pour trop peu de gains par rapport à d'autres alternatives.

La conclusion étant que, même si le coût initial des relais était peu élevé, la solution de migration des hôtes que vous devez construire devient extrêmement coûteuse. Pas si bon marché après tout.

Toute cette enquête sur différentes technologies et services nous a conduits à réaliser que la solution "bon marché" qui était le peer-to-peer, nécessitait la construction d'un système complet appelé migration des hôtes, qui ne serait pas une résolution transparente et une mauvaise expérience utilisateur, puis nous devrions la maintenir.

Donc, soit vous embauchez du personnel supplémentaire, soit vous déplacez votre date de sortie de projet. Dans les deux cas, vous brûlez de l'argent. Tout cela parce que vous augmentez la complexité de littéralement chaque partie du jeu. Notre évaluation est que nous aurions besoin d'un testeur supplémentaire et d'un développeur qui seraient purement affectés à la refonte de toutes les fonctionnalités pour progresser plus loin avec cela.

Cela nous coûterait environ 15 000 $ par mois. Et cela ne fera que croître par la suite. Et je veux que vous vous souveniez de cette question, que pouvons-nous obtenir d'autre pour 15K ? Que pouvons-nous obtenir d'autre pour ces ressources de développement ?

Serveurs Dédiés - Infrastructure & Répartition des Coûts

La prochaine étape était d'évaluer d'autres options, à savoir des serveurs dédiés. Comparons chaque option et faisons une répartition des coûts.

Avant d'aller plus loin, regardons ce graphique. Sur le côté gauche, vous pouvez voir les sessions de jeu de Six Days dans le temps. C'est des données historiques réelles sur une période de 24 heures.

Comment lire cela. Par exemple, le tracé rouge est Amérique du Nord Est et à UTC zéro, il y a un pic de trente-trois jeux. Cela signifie qu'il y a trente-trois serveurs de Six Days tournant en parallèle.

Comme notre jeu nécessite deux vCPUs ou fils logiques, cette région nécessite soixante-six processeurs logiques pour soutenir. Sur le côté droit, vous avez un coût mensuel de cette distribution de jeu. Et cela ne serait que pour une région. Donc, multiplions cela quelques fois. Et voyons combien de jeux nous pourrions avoir sur le graphique si nous devions échanger les ressources de développement contre l'infrastructure.

Et le budget supposé était de 15K.

Cloud Public (AWS)

Tout d'abord le plus évident, tout le monde va sur AWS.

Voyons ce que nous pouvons obtenir sur le cloud public le plus reconnu. J'ai calculé le coût du pic pour chaque région séparément pour que ce soit aussi précis que possible.

[Six Days a] génération de cartes procédurales et IA très sophistiquée, notre jeu nécessite un peu plus de puissance, mais il reste 2 200 joueurs par jour en sessions de jeu. Ce n'est pas mal, n'est-ce pas ? Et si notre jeu était comme Valorant ou Counter Strike, il aurait presque 10K sessions de joueurs.

Serveurs Bare Metal

Le bon vieux bare metal.

Je sais que certains d'entre vous pourraient dire que le bare metal a de meilleures performances et pourrait accueillir 20 % de plus. Dans le cas de Six Days, mon ordinateur portable de jeu ne peut pas exécuter le serveur sur un seul fil logique, donc le calcul, malheureusement, reste le même.

Peut-être quelque chose de plus simple, comme Valorant, pourrait accueillir 8K comme Amazon.

Quoi qu'il en soit, dans notre cas, ce n'était pas les options. De plus, je dois noter qu'il pourrait y avoir des options bare metal flexibles supplémentaires là-dehors, où vous pourriez accueillir un peu plus de joueurs, mais je ne pouvais pas les mentionner dans cette présentation.

Instances de Conteneurs - Vue d'ensemble

Ainsi, j'ai commencé à chercher des instances de conteneurs, car je me demandais s'il y avait des progrès dans la technologie de serveur de jeu conteneurisé, et j'ai trouvé ces gars.

Comme les instances de conteneurs sont entièrement gérées, elles ne nécessitent aucun coût d'ingénierie, je télécharge simplement l'image du jeu, je ne me soucie pas des régions, des frais généraux ou de toute configuration que je devais faire avec d'autres technologies d'infrastructure.

C'est ainsi que j'ai découvert Edgegap. Nous étions les premiers à le développer de manière à ce qu'il soit utilisable pour des jeux multijoueurs.

Instances de Conteneurs - Mise en Cache des Images

Toutes les entreprises aiment Azure, parce que pourquoi ai-je pensé aux instances de conteneurs ? Je ne suis pas arrivé de nulle part.

La première fois que j'ai fait de l'infrastructure pour une entreprise de VR, je cherchais d'autres options que le calcul cloud évolutif. J'ai trouvé les instances de conteneurs dans Azure, mais elles étaient super, super lentes à déployer.

Parce qu'elles ne font pas de mise en cache des images, ce que fait Edgegap.

J'étais très content de trouver que quelqu'un avait enfin implémenté ce qui manquait pour les instances de conteneurs. Cela nous permet de gérer deux fois plus que sur le cloud public avec le même budget. Et encore une fois, si ce jeu était comme Valorant, 15k USD fermerait leur budget mensuel pour l'infrastructure des serveurs pour héberger tout le jeu.

Instances de Conteneurs - Orchestration Distribuée

Une autre chose intéressante à noter ici, c'est qu'avec les conteneurs, nous ne sommes pas liés à un centre de données spécifique.

Par exemple, nous pouvons héberger un jeu quotidien pour notre ami à Cape Town sans gérer un cluster Kubernetes local qui resterait inutilisé le reste du temps. Cela rend notre jeu plus inclusif.

En général, lorsque vous réalisez un jeu, vous optez pour le fruit le plus facile en termes de régions de jeu, n'est-ce pas ? Mais si vous ajoutez tous ces petits endroits où les gens ne peuvent pas jouer à cause de la latence élevée vers le centre de données, ces petites baies deviennent un véritable repas.

Comme il y a beaucoup de discussions ici sur la monétisation des jeux, vous pouvez considérer cela comme une opportunité d'ouvrir de nouveaux marchés qui n'étaient pas disponibles auparavant.

Cloud Public - Capacité Gaspiée vs Instances de Conteneurs

Pourquoi ces instances de conteneurs sont-elles si bonnes ?

Jetons un coup d'œil à ce graphique que j'ai fait. La ligne verte représente des données réelles de joueurs non moyennées. Comme vous le voyez, elle a des pics, des fluctuations, très difficiles à prédire.

Lorsque nous utilisons des solutions cloud publics, nous devons conserver une surcharge de serveurs de jeux vides et inutilisés afin d'accueillir ces joueurs et toute déviation potentielle.

C'est pourquoi l'augmentation et la diminution de la piscine de serveurs disponibles est très lente. Donc, dans le cloud public, toute la zone en dessous de la ligne rouge est ce que vous payez, et la zone en dessous de la ligne verte est ce que vous devriez payer. L'espace en rouge est où l'argent s'échappe.

Maintenant, c'est seulement pour une seule région qui évolue et se multiplie par le nombre de régions que vous avez.

Les instances de conteneurs résolvent ces problèmes parce qu'elles sont super rapides à déployer grâce à la mise en cache des images dont j'ai parlé précédemment. Il n'y a pas de délai pour démarrer ou arrêter, de sorte que nous puissions nous ajuster précisément à la demande en temps réel.

En conséquence, la ligne bleue s'aligne presque parfaitement avec le trafic des joueurs, et vous finissez par ne payer que pour ce que vous utilisez.

Comparaison Finale

Tout cela m'amène à la dernière diapositive de notre présentation, sur la façon dont nous avons géré l'infrastructure réseau dans Six Days. Nous avons découvert que lorsque vous jouez dans une fête privée avec votre ami, le peer to peer sans migration d'hôte est suffisant, et cela représente 40 % de notre trafic.

Conclusion

Quand j'étais enfant, de nombreux jeux étaient peer-to-peer comme Counter Strike. Et il y avait, nous étions des serveurs d'écoute peer-to-peer. Et nous n'avons jamais eu de problèmes avec les hôtes qui partaient, car nous nous connaissions, et nous ne voulions pas ruiner le plaisir. À moins, bien sûr, que maman ne rentre dans la pièce et nous dise d'arrêter de jouer et de faire nos devoirs, car jouer à des jeux ne vous rapportera pas de diplôme en sciences.

Maman avait en partie raison. Mais pour les jeux avec matchmaking avec des personnes aléatoires, le mode peer-to-peer était un véritable désastre. Surtout pour un jeu difficile comme le nôtre.

Nous avons donc des serveurs dédiés sur Edgegap pour les jeux qui sont assortis afin que votre expérience de joueur ne repose pas sur le ragequit d'un gars aléatoire.

Donc, je vous recommande de tout cœur d'opter pour une solution hybride [d'Edgegap] avec votre jeu si vous voulez vraiment de la qualité ainsi qu'une quantité.

C'est tout. Merci pour votre temps et n'hésitez pas à m'ajouter sur LinkedIn. Merci à tous !