David Aldridge, maintenant chef de la technologie chez Bungie, a donné l'une des conférences les plus citées sur le réseau de gameplay dans l'histoire de la GDC en 2011. Intitulée "Je t'ai tiré dessus d'abord", la session a levé le voile sur l'architecture complète du réseau derrière le multijoueur compétitif à 16 joueurs de Halo: Reach.

La présentation couvre les principaux aspects de l'architecture du jeu et de sa philosophie de conception, depuis les protocoles de réplication fondamentaux et le moteur de priorisation jusqu'au processus concret de conception, de mesure et d'optimisation des mécaniques de jeu individuelles dans des conditions réseau réelles.

Indirectement, cela met en évidence les bonnes pratiques qu'un studio de jeu, grand ou petit, peut ajouter à son multijoueur pour améliorer son architecture en ligne.

[Note de l'éditeur] Étant donné l'ampleur massive de la présentation de David, nous avons inclus spécifiquement pour cet article le « point principal » sous chaque aperçu majeur pour faciliter la lisibilité.

Une Architecture Héritée de Tribes

Le réseau de Halo: Reach n'est pas apparu de nulle part. Aldridge et son équipe ont retracé l'ensemble de leur fondation architecturale jusqu'à un article de GDC de 1998 : "Le Modèle de Réseau de Tribes Engine" par Mark Frohnmayer et Tim Gift. Pour un aperçu plus approfondi de cet article fondamental et de ses leçons pour les développeurs modernes, Edgegap propose une plongée sur le modèle de réseau de Tribes.

Le problème central que Bungie devait résoudre est bien connu :

• pour N joueurs dans une partie, la quantité d'état de jeu à transmettre évolue presque au carré de N.

• Dans un jeu à 16 joueurs, une approche naïve de « tout envoyer » se traduit par environ 20 mégabits par seconde de bande passante requise.

• En d'autres termes, « totalement infaisable ».

Le modèle Tribes leur a fourni la réponse. Au lieu d'une livraison fiable, où chaque paquet doit arriver dans l'ordre, le système est basé sur des protocoles semi-fiables.

Le mot "semi-fiable" semble être un compromis. C'est en fait un choix architectural délibéré.

Comme l'expliquait Aldridge, « l'instabilité permet une priorisation agressive », ce qui rend l'ensemble du système évolutif. Lorsque vous n'avez pas à garantir la livraison de chaque mise à jour, vous pouvez laisser votre couche de contrôle de flux décider de ce qui est le plus important à un moment donné et remplir chaque paquet en conséquence. Pas de dette de latence due à une connexion saturée. Pas de blocage système en attente de la réexpédition d'un paquet perdu.

Point principal : Les protocoles semi-fiables ne sont pas un raccourci, ils sont le fondement du réseau multijoueur évolutif. Si votre jeu comporte un grand nombre d'objets et de joueurs, une livraison garantie finira par vous submerger en termes de bande passante. C'est pourquoi un code réseau capable d'optimiser fortement la synchronisation des données est essentiel. De plus, les données signifient des coûts de sortie qui doivent être minimisés pour garantir des coûts globaux inférieurs dans le cloud.

Trois Protocoles, Trois Fonctions

En plus de cette base semi-fiable, Bungie opère trois protocoles de réplication distincts, chacun adapté à un type de données différent.

• Données d'état garantissent une chose : éventuellement, la valeur la plus actuelle arrivera. Elles ne garantissent pas les valeurs intermédiaires. Si la position d'un joueur se met à jour 30 fois par seconde mais que seulement 10 de ces mises à jour passent, le client reconstruit la position actuelle correcte et ignore tout ce qu'il y a entre.

• Évènements sont l'opposé : aucune garantie de livraison. Ils peuvent être complètement abandonnés. C'est acceptable parce que les évènements décrivent pourquoi quelque chose s'est produit, comme la raison pour laquelle une barre de vie a baissé ou pourquoi un Warthog a perdu une roue. Si vous n'étiez pas présent pour voir la transition, seul l'état actuel vous intéresse.

• Données de contrôle sont un flux sous-échantillonné des entrées de contrôleur du joueur, envoyé aussi souvent que possible du client à l'hôte et reflété vers tous les clients. C'est minuscule, environ 20 bits par joueur, méticuleusement emballé. Son seul but est l'exactitude de la prédiction.

Les événements contextuels et la prédiction d'entrée dans des protocoles distincts avec des garanties de fiabilité distinctes est ce qui vous permet de servir efficacement chaque type de données au lieu de surconcevoir pour le pire des cas.

Priorisation: Le Moteur Sous le Capot

Trois protocoles vous donnent les bons types de données. La priorisation décide de ce qui est réellement envoyé dans chaque paquet.

Chaque objet dans le monde du jeu reçoit un score de priorité continu, évalué par client. Le système évalue la distance, la présence à l'écran, le potentiel de menace et l'historique récent d'interactions. Certaines pondérations sont intuitives. D'autres ne le sont pas.

L'équipe d'Aldridge a découvert que les joueurs regardent intensément leurs propres grenades en vol, « même si elles leur sont complètement inutiles après les avoir lancées », donc les grenades appartenant aux joueurs avaient besoin d'une priorité plus élevée que ce que la logique de menace pure aurait suggéré. Un cadavre obtient une pertinence presque maximale pendant plusieurs secondes, car les joueurs regardent les poupées de chiffon tomber juste après un meurtre. Une grenade inactive roulant dans un coin éloigné est mise à jour environ trois fois par seconde.

Lorsque le contrôle de flux décide d'envoyer un paquet, la couche de réplication le remplit dans l'ordre de priorité. Les objets à haute priorité entrent. Ceux à faible priorité attendent. Si la bande passante est limitée, le jeu se dégrade de manière transparente, avec des objets moins importants se mettant à jour plus lentement, plutôt que de bloquer toute la simulation.

Ce type de visibilité par objet et par client est durement gagné. Les analyses d'Edgegap offrent aux développeurs de jeux un niveau comparable d'information sur la performance du serveur et du réseau sans nécessiter des années d'investissement dans des outils personnalisés, mettant à jour les données nécessaires pour prendre des décisions de développement actionnables pour les multijoueurs en direct.

Point principal : La priorisation est ce qui transforme les protocoles semi-fiables en un système évolutif. L'obtenir correctement nécessite de régler les poids en fonction du comportement réel des joueurs, pas seulement de la proximité logique. L'obtenir correctement nécessite également d'avoir les outils pour voir ce que votre réseau fait réellement en pratique.

Cartographier le Décalage : Les Diagrammes de Séquence comme Outil de Conception

Avant d'écrire une ligne de code réseau pour une mécanique, l'équipe d'Aldridge dessinait un diagramme de séquence à deux machines : client d'un côté, hôte de l'autre, avec chaque flèche de message inclinée pour représenter la latence réseau unidirectionnelle en transit.

Cette inclinaison est tout l'intérêt. Elle rend chaque chevauchement potentiel, chaque fenêtre de vulnérabilité, et chaque moment où deux machines pourraient être en désaccord sur l'état du jeu visible avant que le code n'existe.

Le lancement de grenade est l'illustration la plus claire. Sur une seule machine, le flux est simple : appuyer sur la gâchette, animation de préparation, cadre de libération, grenade lancée. La question est comment introduire une seconde machine sans créer d'artéfacts.

• Option un : demander la permission à l'hôte avant de commencer l'animation. La cartographie de cela révèle immédiatement le problème. Il y a un décalage de trajet aller-retour complet avant que le client ne reçoit un retour sur sa pression de bouton. « Les joueurs détestent ça avec passion », comme l'a exprimé Aldridge. Complètement inacceptable.

• Option deux : lancer localement et dire à l'hôte simultanément. Cette approche n'a pas de fenêtre de décalage visible, ce qui semble bien mais signifie qu'aucune décision de l'hôte n'a réellement eu lieu. C'est une dette de latence qui s'accumule silencieusement, garantie de faire surface plus tard sous forme de désynchronisation.

La vraie réponse est une troisième voie : prévoir l'animation lors de l'appui sur le bouton, mais retenir la création de la grenade au cadre de libération. Le bras du client bouge immédiatement. La grenade disparaît au cadre de libération. Une demande de création est envoyée à l'hôte. La confirmation de l'hôte arrive environ un tour complet plus tard.

Pendant cette fenêtre, le bras animé surdimensionné du joueur remplit un tiers de l'écran. Les joueurs ne regardent pas leur main pendant un lancer de grenade ; ils visent à travers leur réticule. Ils ne remarquent pas des écarts jusqu'à 150 millisecondes. Les joueurs occasionnels ne remarqueront pas jusqu'à 200 millisecondes, selon Aldridge. Ce qui explique pourquoi Bungie a intégré les lancers de grenade à travers trois titres Halo.

Point principal : Les diagrammes de séquence avec deux machines sont l'un des outils les plus pratiques disponibles pour la conception de réseau. Esquisser une mécanique avec des flèches de latence explicites avant d'écrire du code révélera des fenêtres de décalage et des dettes de latence qui sont presque impossibles à repérer autrement.

[Note de l'éditeur : tout le monde n'a pas les ressources de Bungie sur un jeu AAA comme Bungie. L'optimisation est essentielle, mais la planification préalable est un luxe. C'est pourquoi s'assurer de réserver du temps dans votre production pour optimiser le serveur de votre jeu, le réseau et l'infrastructure globale est important pour la performance et l'efficacité des coûts.]

Où est le Décalage ?

L'approche de diagramme de séquence utilisée par David avec son équipe conduit directement à la règle la plus importante de la conférence : demandez toujours où vous cachez le décalage.

"Si vous avez une adjudication par l'hôte, vous aurez un décalage quelque part. Si vous n'avez pas de décalage quelque part, vous n'avez pas d'adjudication par l'hôte - vous avez contracté une dette de latence."

Il ne peut pas être éliminé. Il ne peut être que placé. Le travail de conception est de choisir où le mettre, quelque part où les joueurs ne le remarqueront pas, ou là où son impact perceptuel est suffisamment faible pour être expédié.

Un levier significatif auquel chaque studio a accès est simplement de réduire la latence de base grâce à un placement serveur. La plateforme d'orchestration d'Edgegap réduit la latence moyenne de 58% en déployant des serveurs de jeux au plus près de votre population de joueurs réelle. Cela n'élimine pas la question « où est le décalage », mais cela rétrécit considérablement la marge sur laquelle vous travaillez.

En d'autres termes, un trajet aller-retour de 200 ms nécessite des compromis de conception très différents de ceux d'un trajet de 40 ms. Les petits studios en bénéficient particulièrement, car moins de travail de mise en réseau doit être consacré à dissimuler une latence qui n'aurait pas dû être présente au départ.

Point principal : Le décalage n'est pas juste un bug à corriger ; c'est un budget à dépenser judicieusement. Réduire votre temps de trajet aller-retour de base grâce à un placement serveur intelligent aide à réduire ce problème de budget avant que vos ingénieurs réseau n'aient à y toucher.

Quand la Meilleure Solution de Code Réseau est une Solution de Conception de Jeu

Quatre des cinq principales « victoires d'optimisation réseau » de Bungie dans Reach provenaient de la modification des mécaniques de jeu, et non du code de mise en réseau.

C'est la leçon la plus contre-intuitive de la conférence, et probablement la plus durable.

L'exemple de l'armure verrouillée le rend concret :

• La mécanique : appuyez sur un bouton, jouez une animation d'introduction en trois cadres, gagnez en invulnérabilité et en masse infinie.

• Deux itérations échouées ont précédé la version finale.

• Les deux avaient une fenêtre où une grenade pouvait exploser sur l'hôte pendant l'animation d'introduction et infliger des dégâts, laissant un joueur qui avait déjà vu le bouclier bleu à l'écran recevoir des dégâts pour lesquels ils étaient certains d'être immunisés.

• Des milliers de publications sur les forums ont suivi chaque bêta.

La version finale a introduit un changement ciblé.

Comme Aldridge l'a décrit : « Nous sommes entrés et avons pris le numéro de retard de cadre que les concepteurs avaient soigneusement ajusté et l'avons remplacé pour le réseau. Nous avons en fait changé la façon dont le jeu se jouait. » L'hôte active le bouclier tôt, réduisant le délai d'introduction du temps de trajet aller-retour mesuré entre l'hôte et le client activant. Lorsque le client voit apparaître le bouclier, cela correspond à leur attente. L'incohérence a été déplacée loin du joueur qui se soucie le plus, celui utilisant verouillage d'armure, et sur l'hôte et les autres joueurs, qui ne remarquent guère si le bouclier de quelqu'un d'autre est apparu quelques cadres plus tôt.

La mécanique d'assassination a suivi un arc similaire. La version finale utilisait un mélange d'interpolation purement visuel d'environ trois quarts de seconde pour absorber les écarts de position à l'entrée. En mode de débogage, le mélange était visible et les animateurs l'ont immédiatement signalé. En jeu, il était invisible. La caméra se retire en troisième personne au début de chaque assassinat et se déplace à environ 25 pieds par seconde pendant cette fenêtre exacte. La référence spatiale des joueurs change si rapidement qu'un mélange de 20 pieds passe complètement inaperçu. Leur cerveau comble la continuité.

La solution de ragdoll a poussé le principe le plus loin : arrêter complètement la mise en réseau des ragdolls. Synchroniser uniquement l'état de mort initial entre tous les pairs. Après cela, laisser la physique diverger localement. Deux préoccupations de conception ont été résolues :

• d'abord, les ragdolls bloquant les balles (résolu en permettant une pénétration complète sans effets secondaires) et ;

• une longue tradition de la communauté Halo de s'accroupir sur le corps tombé d'un adversaire, ce qui nécessitait que le ragdoll soit à peu près dans la bonne position.

Les deux ont été résolus, personne n'a remarqué les changements, et le résultat était environ 10 à 12 % de bande passante libérée.

Point principal : Vos ingénieurs réseau et vos concepteurs de jeu doivent travailler ensemble dès le début. Certaines des solutions de latence les plus efficaces ne se trouvent pas du tout dans la couche réseau. Elles se trouvent dans la conception des mécaniques elles-mêmes, dans les fenêtres perceptuelles et les schémas d'attention des joueurs qui peuvent absorber les incohérences de manière invisible.

Construire d'Abord les Outils, Puis Optimiser

Aldridge a cité une règle pour l'optimisation : « Première règle de l'optimisation de programme : ne le faites pas. Deuxième règle, pour les experts uniquement : ne le faites pas encore. »

Bungie savait qu'ils devaient optimiser, ils ont donc créé les outils pour le faire en toute sécurité avant de toucher une ligne de code de mise en réseau.

Le profileur de bande passante a suivi l'utilisation et les résultats de priorité à travers toute la simulation.

La vraie capacité est venue en intégrant les données de profilage dans le système de film existant de Halo.

Les films sont des enregistrements de gameplay déterministes, une fonctionnalité destinée aux utilisateurs depuis Halo 3. L'équipe d'Aldridge a injecté une bulle de débogage après chaque cadre de jeu, contenant tout l'état du réseau échantillonné pendant cette unité, chaque paquet envoyé et reçu, et chaque décision de priorisation. « Pour la première fois dans l'histoire de Halo », comme il l'a dit, ils pouvaient analyser la performance du réseau après-coup, revenir à n'importe quel moment, filtrer vers un client spécifique et examiner exactement ce qui a été transmis à qui et quand. Temps de développement total : environ six semaines pour les outils de base.

Cet ensemble d'outils a directement permis la réduction de la bande passante de plus de 80 % de Halo 3 à Reach.

Un exemple de ce qu'il a mis en évidence : les grenades inactives roulant au sol consommaient une part disproportionnée de bande passante au niveau de la priorité. La cause racine était un correctif de bug de la fin de Halo 3 qui avait donné aux objets d'équipement un grand coup de priorité pour répondre aux plaintes de lag. Par accident de conception, les grenades et l'équipement partageaient la même classe parente. Chaque grenade abandonnée sur chaque carte héritait du coup et était traitée comme une priorité élevée à tout moment. Une correction en une ligne (c'est-à-dire, appliquer le coup uniquement à l'équipement actif) a libéré environ 20% de bande passante.

Pour les studios qui n'ont pas six semaines pour construire une infrastructure de profilage personnalisée, les outils d'analytique d'Edgegap mettent en évidence les couches de conteneurs et de serveurs de jeux de données de performance en direct et historiques, aidant les équipes à détecter les motifs systémiques, les anomalies de bande passante, les problèmes de priorité au niveau des objets, les pics de temps d'image serveur, que le profileur personnalisé de Bungie avait pour but de trouver.

Point principal : L'entropie du réseau s'accumule silencieusement, et vous ne pouvez pas corriger ce que vous ne pouvez pas voir. Investir dans des outils d'inspection approfondis avant d'optimiser n'est pas facultatif, car c'est le travail qui rend l'optimisation possible du tout.

Transformer le Décalage Perçu en Science

Jouer sous des conditions réseau simulées a donné à Bungie un environnement contrôlé mais le problème de mesure de la « qualité de la correspondance » était plus difficile. Comme Aldridge l'a noté, les joueurs "peuvent nous dire s'ils ont passé un bon moment, ce qui correspond presque parfaitement à savoir s'ils ont gagné ou non." Ce n'est pas assez granulaire pour aiguiller des décisions d'ingénierie.

La solution : un bouton dédié sur le contrôleur dans les playtests qui insère un événement de débogage horodaté directement dans le film. Chaque fois qu'un joueur ressent un décalage, il l'appuie. Les ingénieurs sautent à ce cadre exact, examinent l'état complet du réseau et enquêtent.

Un effet secondaire utile est apparu : les joueurs appuyaient sur le bouton non seulement pour les vrais problèmes réseaux, mais chaque fois qu'une mécanique de jeu les déroutait ou les désorientait.

Être tué en un seul coup par une grenade à presque pleine santé donnait l'impression de décalage. Une caméra de mort qui n'expliquait pas clairement la cause du décès donnait l'impression de décalage. L'équipe d'ingénierie tirerait ces séquences et les amènerait directement aux concepteurs, avec des données. Les outils de mise en réseau sont devenus une boucle de rétroaction pour la conception de jeu.

Point principal : Le décalage perçu est un signal produit, pas seulement une métrique réseau. Construire une méthode permettant aux testeurs de l'identifier précisément (lorsqu'il est lié à un état de jeu reproductible) transforme les plaintes vagues en données exploitables pour les ingénieurs et les concepteurs.

Sélection Intelligente de l'Hôte et le Coût de la Migration de l'Hôte

La migration de l'hôte, à savoir l'acte de passer à un meilleur hôte en cours de session lorsque la connexion de l'hôte actuel se dégrade, est puissante lorsqu'elle fonctionne.

Cependant, Aldridge a reconnu que cela pourrait être un sujet de conversation à part entière car c'est une entreprise d'ingénierie significative, et les studios qui la considèrent ne devraient pas sous-estimer l'ampleur.

Le Michał Buras de Highwire Game, Ingénieur Réseau Principal sur Six Days in Fallujah, décompose dans sa conférence le niveau de défi que la complexité de la migration de l'hôte apporte dans le multijoueur basé sur le peer-to-peer et le relais, ce qui constitue une référence utile avant de s'engager sur cette voie.

Les serveurs dédiés contournent le problème entièrement. Avec des serveurs dédiés qui agissent en tant qu'hôte, il n'y a pas d'hôte à migrer, et la continuité de la session est donc gérée au niveau de l'infrastructure.

Point principal : Qui héberge une session est aussi important que la manière dont vous avez conçu la session. La migration de l'hôte dans une architecture réseau P2P ou basée sur les relais entraîne un coût d'ingénierie que l'infrastructure de serveur dédié évite entièrement.

Les Nombres, et ce qu’ils Signifient pour le Coût de la Bande Passante

Le dernier benchmark de Reach : des jeux pour 16 joueurs fonctionnant solidement sans artefacts de décalage à 250 kbps, contre un objectif de conception de 384 kbps. Une réduction totale de bande passante de plus de 80 % par rapport à Halo 3.

Chaque kilobit économisé compte double :

• D'abord pour les joueurs, car des besoins en bande passante inférieurs signifient que plus de votre base de joueurs peut exécuter le jeu de manière fluide sur une plus large gamme de types de connexion.

• Ensuite pour votre facture d'infrastructure, car le coût de sortie évolue directement avec la quantité de données que vos serveurs transmettent.

Ainsi, optimiser la réplication, le taux de tick et la logique de priorisation revient aussi à optimiser vos dépenses cloud. Pour les développeurs d'Unreal Engine à la recherche d'un point de départ concret, Edgegap a publié une liste de contrôle complète de profilage et d'optimisation de serveur d'Unreal Engine, avec un équivalent Unity en cours de développement.

Point principal : L'optimisation de la bande passante n'est pas seulement un problème de qualité réseau. C'est un problème de coût commercial ayant un impact direct sur la rentabilité du jeu lui-même. Ainsi, toute amélioration de l'efficacité de la réplication réduit directement les dépenses de sortie, faisant de cela l'un des rares investissements d'ingénierie qui rapporte des dividendes tant sur l'expérience utilisateur que sur le budget d'infrastructure.

—

Cet article est basé sur et cite la conférence originale GDC 2011 de David Aldridge, publiée sur la chaîne YouTube de la GDC. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.