Technologies de serveur hybride dans le jeu vidéo : plongée approfondie dans le modèle réseau de Destiny 2

Destiny 2, développé par Bungie, utilise un mélange de deux technologies réseau, créant un modèle hybride qui le distingue de la plupart des shooters en ligne. Leur solution combine les forces des deux approches traditionnelles tout en atténuant certains de leurs défauts inhérents.

Cet article s'appuie sur les enseignements de deux conférences GDC données par des ingénieurs de Bungie, que nous avons couvertes en détail ailleurs sur ce blog. Justin Truman, aujourd'hui directeur du studio chez Bungie, a expliqué l'architecture de mission en réseau derrière le monde partagé de Destiny dans « Jeu de tir en monde partagé : l'architecture des missions en réseau de Destiny » à la GDC 2015 (couverte ici : Architecture réseau de Destiny 2 - Plongée approfondie dans le jeu multijoueur). John Chu, aujourd'hui responsable technique principal de programme dans la Central Technology Online Area chez Bungie, a présenté « Rassembler les joueurs : construire le crossplay pour Destiny 2 » à la GDC 2022 (couverte ici : Développer le crossplay de Destiny 2 - Plongée approfondie dans le backend du jeu), en détaillant ce qu'il avait fallu pour étendre cette architecture aux sept plateformes. Ensemble, ces deux conférences donnent un tableau détaillé de la manière dont le modèle réseau hybride de Bungie a été conçu, mis à l'échelle et renforcé au fil du temps.

Comprendre les modèles pair à pair et client-serveur

Pour apprécier l'approche de Bungie, il est utile de comprendre les deux briques de base qu'ils ont combinées. Le réseau pair à pair est une forme de communication directe dans laquelle les clients (les joueurs) interagissent les uns avec les autres sans intermédiaire. Son principal avantage réside dans une latence plus faible. En revanche, il entraîne souvent des problèmes de sécurité et de confidentialité, comme nous le verrons plus loin.

Le modèle client-serveur, quant à lui, fonctionne via un serveur dédié qui héberge le jeu, offrant stabilité et cohérence, mais introduisant potentiellement de la latence en raison de la distance géographique entre les joueurs et les serveurs.

Le modèle hybride unique de Destiny 2

L'objectif de Bungie dès le départ était, comme l'a décrit Truman, de « brouiller la frontière entre les expériences solo et multijoueur », permettant aux joueurs de rencontrer d'autres personnes simplement en appuyant sur « jouer à Destiny », sans les salons de matchmaking traditionnels. Réaliser cela exigeait un modèle réseau qu'aucun serveur dédié traditionnel ni aucune approche P2P pure ne pouvait fournir à lui seul.

La solution comporte trois couches distinctes fonctionnant en parallèle.

• Zones partagées (P2P) : la première est la couche P2P. Les joueurs au sein d'une zone partagée communiquent directement entre eux, formant ce que Bungie appelait des « bulles » pair à pair. Il s'agit de connexions directes de client à client destinées à maintenir une forte réactivité pour les déplacements et les interactions de moment à moment, et qui permettent à Bungie de relier ces « bulles » entre elles afin que des inconnus puissent se rencontrer naturellement en plein milieu d'une mission, sans lobby ni écran de chargement.

• Hôte physique (serveurs dédiés) : la deuxième est l'hôte physique, qui dans Destiny 2 s'exécute sur un serveur dédié plutôt que sur la machine d'un joueur. Il s'agissait d'une correction délibérée de l'un des problèmes les plus persistants de Destiny 1 : la migration d'hôte. Lorsque le joueur qui hébergeait la physique quittait une session, le jeu saccadait ou se cassait complètement. Déplacer cette responsabilité vers un serveur dédié supprimait la dépendance à la connexion d'un joueur individuel et rendait les sessions stables, peu importe qui rejoignait ou quittait.

• Hôte d'activité (processus faisant autorité conçu sur mesure pour l'état des missions) : la troisième est l'hôte d'activité, un processus cloud allégé que l'équipe de Truman a conçu pour n'exécuter que l'état strictement requis par la logique de mission. Pas les trajectoires des projectiles, pas l'état des animations, pas les positions dans l'espace du monde. Juste les faits discrets dont les scripts d'activité avaient besoin : si une escouade s'était matérialisée, combien d'ennemis restaient en vie, si un objectif s'était déclenché. Le résultat était un exécutable d'environ 45 Mo, fonctionnant à 10 Hz, qui permettait à un seul serveur à 40 cœurs de gérer près de 5 000 instances simultanées. Comme l'a expliqué Truman, cela équivalait à environ 1 million d'utilisateurs simultanés pris en charge par seulement quelques centaines de machines. Une approche de serveur dédié avec simulation complète aurait exigé quelque chose de plus proche d'un demi-million de processus sans interface graphique exécutant l'intégralité du jeu.

La discipline clé qui a rendu cela possible était ce que Bungie appelait les capteurs : un système déclaratif où un script devait déclarer formellement l'état dont il avait besoin avant de pouvoir s'y référer.

Rien ne dérivait accidentellement vers le serveur. Si un script ne déclarait pas une dépendance, cet état ne persistait pas côté serveur. Cela maintenait une empreinte réduite pour l'hôte d'activité, une bande passante prévisible et une architecture cohérente.

Dans la transition de Destiny 1 à Destiny 2, ces trois couches ont ensemble remplacé le point unique de fragilité du modèle physique hébergé par le joueur. Lorsque Bungie a fini par lancer le cross-play, John Chu a décrit les changements réseau sous-jacents nécessaires comme « certains des changements les plus massifs et les plus effrayants du moteur », précisément parce que cette architecture en couches devait être reconstruite pour transporter un état cohérent entre des plateformes qui avaient auparavant été développées et optimisées de manière isolée.

Les défis du modèle hybride de Destiny 2

Les propres ingénieurs de Bungie ont décrit leur topologie réseau comme « particulièrement compliquée ». Les conséquences pour les joueurs le confirment.

L'exposition de l'IP est une conséquence structurelle du P2P, pas un bug. Dans toute configuration pair à pair, les clients communiquent directement entre eux, ce qui signifie que chaque joueur que vous rencontrez peut voir votre adresse IP. Dans Destiny 2, c'est le cas pour chaque joueur, en PvE comme en PvP. Comme l'a observé Chris « Battle(non)sense » dans son analyse de 2017 pour PC Gamer, la version PC conservait encore un ensemble clair de compromis auxquels les jeux à serveur dédié n'ont tout simplement pas à faire face :

« Le jeu annonce votre adresse IP à toutes les personnes que vous croisez, les superpositions d'outils tiers ne fonctionnent pas, la fonctionnalité des outils de capture de gameplay est dans certains cas limitée, la réactivité de l'enregistrement des impacts variera d'un joueur à l'autre, et certains joueurs rencontreront des problèmes avec la bande passante montante requise, un problème qui arrive rarement avec des serveurs dédiés. »

Pour les studios qui envisagent un modèle hybride, l'exposition de l'IP mérite d'être traitée comme une contrainte de conception de premier plan. Le P2P et la confidentialité de l'IP sont fondamentalement incompatibles sans une couche de relais entre les pairs.

La sécurité aggrave aussi cela. Lorsque les clients gèrent des tâches sensibles comme l'enregistrement des coups dans un environnement P2P, le jeu devient plus difficile à protéger contre l'exploitation. Le principe courant du développement multijoueur est « ne faites jamais confiance au client ». Dans un modèle hybride, ce principe devient plus difficile à appliquer proprement.

Netcode : là où les coutures apparaissent

Note : les informations suivantes sont basées sur des tests réseau réalisés par Chris « Battle(non)sense » pour PC Gamer en 2017 ; certains détails ont pu évoluer avec les mises à jour ultérieures du backend.

Dans un jeu à serveur dédié, le délai d'enregistrement de vos impacts se résume à une seule variable : votre ping vers le serveur. Constant, prévisible, et non affecté par les autres joueurs du match.

Le P2P supprime entièrement cette garantie. Comme l'a noté Chris, « la qualité des connexions Internet des joueurs, et la distance entre eux, ont un impact direct sur la réactivité ressentie de l'enregistrement des impacts ». Un joueur qui envoie des mises à jour à 15 Hz au lieu des 30 à 40 Hz attendus ralentit de manière mesurable le décalage entre vous et lui, quelle que soit la solidité de votre propre connexion. La mauvaise qualité de l'upload d'un joueur dégrade l'expérience de tous ceux qui sont connectés à lui. Et le nombre de joueurs disposant de connexions résidentielles à capacité d'envoi limitée est plus élevé que la plupart des développeurs ne l'imaginent.

Les serveurs dédiés absorbent cette variabilité de manière centralisée. Le P2P la répartit sur chaque relation de pair à pair de la partie.

La bande passante évolue mal avec le nombre de joueurs pour la même raison. En une heure de Crucible en 4v4, Chris a mesuré un client unique envoyant 152,3 Mo et recevant 128,3 Mo. Dans une topologie P2P, ajouter des joueurs multiplie le trafic dans toutes les directions. Ce calcul a probablement influencé la décision de Bungie de plafonner le Crucible à 4v4 plutôt qu'à 5v5 ou 6v6. Les studios qui conçoivent autour d'un modèle hybride devraient établir leurs propres projections de bande passante très tôt, en particulier pour des nombres de joueurs plus élevés.

Enfin, le taux de tick a ici sa propre nuance. Destiny 2 échantillonne les dégâts de combat à 30 Hz (le chiffre de 10 Hz qui a circulé comme une rumeur fait référence à l'hôte d'activité, qui gère le score et les apparitions de munitions à une fréquence plus faible). Sur PC, les clients peuvent envoyer des mises à jour jusqu'à 40 Hz lorsque la fréquence d'images dépasse 40 ips, un couplage direct entre les performances de rendu et la fréquence de mise à jour réseau qui n'a pas d'équivalent dans une architecture de serveur dédié.

Private Fleet : orchestration hybride à grande échelle

Pour les studios qui exploitent une infrastructure à l'échelle de Destiny 2, l'orchestration des serveurs devient une préoccupation d'ingénierie centrale.

Private Fleet d'Edgegap est une solution d'orchestration basée sur des conteneurs qui gère des serveurs persistants pour optimiser les coûts, puis passe automatiquement à l'échelle dans le cloud avec des déploiements juste-à-temps et des déploiements de serveurs mondiaux dans plus de 615 emplacements à travers le monde. L'hébergement de proximité place les joueurs sur le serveur disponible le plus proche, ce qui réduit la latence jusqu'à 58 % en moyenne, sans obliger les studios à construire et gérer eux-mêmes cette infrastructure.

Conclusion

Le modèle réseau hybride qu'utilise Destiny 2 illustre à la fois les possibilités et les coûts réels du mélange des architectures de serveur. Il prouve qu'associer la flexibilité du P2P à l'autorité des serveurs dédiés peut offrir des expériences de monde partagé fluides à grande échelle, mais cela exige une ingénierie minutieuse pour répondre aux défis de sécurité, de latence et de cohérence qui l'accompagnent. Les deux conférences GDC liées ci-dessus vont beaucoup plus loin sur la manière dont Bungie a résolu ces problèmes en pratique, et méritent d'être lues en parallèle de cet article.

—

Cet article s'appuie sur les enseignements de la présentation GDC 2015 de Justin Truman, de la présentation GDC 2022 de John Chu et de l'analyse réseau de Chris "Battle(non)sense" publiée par PC Gamer en novembre 2017. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.