Technologies de serveurs hybrides dans le jeu vidéo : analyse approfondie du modèle réseau de Destiny 2

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

Cet article s'appuie sur deux conférences de la GDC que nous avons couvertes en détail : celle de Justin Truman (actuel directeur de studio chez Bungie) sur l'architecture des missions en réseau de Destiny lors de la GDC 2015 (Destiny 2's Network Architecture - Multiplayer Game Deep Dive), et celle de John Chu (actuel directeur technique de programme principal chez Bungie) sur le développement du jeu multiplateforme sur sept plateformes lors de la GDC 2022 (Developing Destiny 2's Crossplay - Game Backend Deep Dive).

Comprendre les modèles Peer-to-peer et Client-Serveur

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

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

Le modèle hybride unique de Destiny 2

Dès le départ, l'objectif de Bungie était, comme l'a décrit Truman, de « gommer la frontière entre les expériences solo et multijoueur », en permettant aux joueurs d'en rencontrer d'autres simplement en cliquant sur « Jouer à Destiny » sans passer par les salons de matchmaking traditionnels. Pour y parvenir, il a fallu concevoir un modèle réseau unique, différent de ce qu'un serveur dédié classique ou une approche purement P2P pourraient offrir individuellement.

La solution repose sur trois couches distinctes fonctionnant en parallèle.

• Zones partagées (P2P) : La première est la couche P2P. Les joueurs situés dans une zone partagée communiquent directement entre eux, formant ce que Bungie appelle des « bulles » de peer-to-peer. Il s'agit de connexions directes de client à client afin de maintenir une réactivité élevée pour les mouvements et les interactions instantanées, et qui permettent à Bungie de connecter ces « bulles » entre elles pour que des inconnus puissent se rencontrer naturellement au milieu d'une mission, sans salon ni écran de chargement.

• Hôte physique (serveurs dédiés) : La deuxième est l'hôte physique, qui dans Destiny 2 fonctionne 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 subissait des saccades ou s'interrompait complètement. Le transfert de cette responsabilité à un serveur dédié a supprimé la dépendance vis-à-vis de la connexion de chaque joueur individuel et a rendu les sessions stables, indépendamment de qui rejoignait ou quittait la partie.

• Hôte d'activité (processus faisant autorité conçu spécifiquement pour l'état de la mission) : La troisième est l'hôte d'activité, un processus cloud allégé que l'équipe de Truman a conçu pour exécuter uniquement l'état strictement requis par la logique de la mission. Pas les trajectoires de balles, pas l'état des animations, pas les positions dans l'espace mondial. Uniquement les faits discrets dont les scripts d'activité avaient besoin : si une escouade était apparue, combien d'ennemis restaient en vie, si un objectif s'était déclenché. Le résultat était un exécutable d'environ 45 Mo, tournant à 10 Hz, qui permettait à un seul serveur de 40 cœurs de gérer près de 5 000 instances simultanées. Comme l'a expliqué Truman, cela se traduisait par 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 nécessité près d'un demi-million de processus sans tête exécutant l'intégralité du jeu.

La discipline clé qui a rendu cela possible est ce que Bungie a appelé les capteurs : un système basé sur la déclaration préalable, dans lequel un script devait formellement déclarer l'état dont il avait besoin avant de pouvoir y faire référence.

Rien ne se retrouvait sur le serveur par accident. Si un script ne déclarait pas une dépendance, cet état ne persistait pas côté serveur. Cela a permis de maintenir l'empreinte de l'hôte d'activité à un niveau minimal, de rendre la bande passante prévisible et de préserver l'intégrité de l'architecture.

Lors de la transition de Destiny 1 à Destiny 2, ces trois couches réunies ont remplacé le point de défaillance unique et fragile du modèle de physique hébergé par le joueur. Lorsque Bungie a finalement déployé le cross-play, John Chu a décrit les changements réseau sous-jacents requis comme « certains des changements structurels les plus importants et les plus effrayants » apportés au moteur, précisément parce que cette architecture multicouche devait être reconstruite pour assurer la cohérence des états 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 ingénieurs de Bungie ont eux-mêmes décrit leur topologie réseau comme étant « d'une complexité unique ». Les conséquences visibles pour les joueurs le confirment.

L'exposition des adresses IP est une conséquence structurelle du P2P, pas un bug. Dans toute configuration peer-to-peer, les clients communiquent directement entre eux, ce qui signifie que chaque joueur que vous rencontrez peut voir votre adresse IP. Dans Destiny 2, cela concerne chaque joueur, que ce soit en PvE ou en PvP. Comme Chris « Battle(non)sense » l'a observé dans son analyse de 2017 pour PC Gamer, la version PC comportait toujours un ensemble clair de compromis auxquels les jeux sur serveurs dédiés ne sont tout simplement pas confrontés :

« Le jeu diffuse votre adresse IP à tous ceux que vous rencontrez, les overlays des outils tiers ne fonctionnent pas, les fonctionnalités des outils de capture de gameplay sont dans certains cas limitées, la réactivité de l'enregistrement des tirs varie d'un joueur à l'autre, et certains joueurs rencontreront des problèmes avec la bande passante ascendante requise, un problème qui survient rarement avec des serveurs dédiés. »

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

La sécurité vient également compliquer les choses. Lorsque les clients gèrent des tâches sensibles comme l'enregistrement des tirs dans un environnement P2P, le jeu devient plus difficile à protéger contre la triche. Le principe fondamental du développement multijoueur est de « ne jamais faire confiance au client ». Dans un modèle hybride, ce principe devient plus difficile à appliquer rigoureusement.

Netcode : là où les coutures lâchent

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

Dans un jeu avec serveur dédié, le délai d'enregistrement de vos tirs dépend d'une seule variable : votre ping vers le serveur. Il est cohérent, prévisible et n'est influencé par aucun autre joueur de la partie.

Le P2P supprime totalement cette garantie. Comme l'a souligné Chris, « la qualité de la connexion Internet des joueurs et la distance qui les sépare ont un impact direct sur la réactivité de l'enregistrement des tirs ». Un joueur qui envoie des mises à jour à 15 Hz au lieu des 30 à 40 Hz attendus ralentit de manière mesurable le temps de réponse entre vous et lui, quelle que soit la qualité de votre propre connexion. La mauvaise connexion ascendante d'un seul joueur dégrade l'expérience de tous ceux qui sont connectés à lui. De plus, le nombre de joueurs disposant de connexions résidentielles avec une capacité d'envoi limitée est plus important que ce que la plupart des développeurs imaginent.

Les serveurs dédiés absorbent cette variabilité de manière centralisée. Le P2P la distribue sur chaque relation entre pairs dans la partie.

La bande passante s'adapte également très mal au nombre de joueurs pour cette même raison. En une heure de partie d'Épreuve en 4v4, Chris a mesuré qu'un seul client envoyait 152,3 Mo et recevait 128,3 Mo. Dans une topologie P2P, l'ajout de joueurs multiplie le trafic dans toutes les directions. Ce calcul a probablement influencé la décision de Bungie de limiter l'Épreuve à du 4v4 plutôt que du 5v5 ou du 6v6. Les studios qui conçoivent un modèle hybride devraient effectuer leurs propres projections de bande passante dès le départ, en particulier pour les nombres de joueurs plus élevés.

Enfin, le tick rate comporte sa propre nuance ici. Destiny 2 enregistre les dégâts de combat à 30 Hz (le chiffre de 10 Hz qui a circulé sous forme de rumeur fait référence à l'hôte d'activité, qui gère le score et l'apparition des munitions à une fréquence inférieure). Sur PC, les clients peuvent envoyer des mises à jour jusqu'à 40 Hz lorsque le taux de rafraîchissement dépasse 40 ips, un couplage direct entre les performances d'affichage et le taux de mise à jour réseau qui n'a aucun équivalent dans une architecture de serveur dédié.

Private Fleet : Orchestration hybride à grande échelle

Pour les studios qui gèrent des infrastructures à l'échelle de Destiny 2, l'orchestration des serveurs devient un enjeu d'ingénierie central.

La solution Private Fleet d'Edgegap est une solution d'orchestration basée sur des conteneurs qui gère les serveurs persistants pour optimiser les coûts, puis bascule automatiquement vers le cloud avec un déploiement juste-à-temps et des déploiements de serveurs mondiaux répartis sur plus de 615 sites à 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 que les studios aient besoin de concevoir et de gérer cette infrastructure eux-mêmes.

Conclusion

Le modèle réseau hybride utilisé par Destiny 2 illustre à la fois les possibilités et les coûts réels de la combinaison d'architectures de serveurs. Il prouve que l'association de la flexibilité du P2P avec l'autorité des serveurs dédiés peut offrir des expériences de monde partagé fluides et à grande échelle, mais cela nécessite une ingénierie minutieuse pour relever les défis de sécurité, de latence et de cohérence qui en découlent. Les deux conférences de la GDC mentionnées ci-dessus approfondissent considérablement la manière dont Bungie a résolu ces problèmes en pratique, et méritent d'être lues en complément de cet article.

—

Cet article s'appuie sur des informations issues de la présentation à la GDC 2015 par Justin Truman, de la présentation à la GDC 2022 par 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.