David Aldridge, aujourd'hui directeur technologique chez Bungie, a présenté en 2011 l'une des conférences sur le réseau de gameplay les plus référencées de l'histoire de la GDC. Intitulée « I Shot You First », la session a levé le voile sur l'architecture réseau complète derrière le multijoueur compétitif à 16 joueurs de Halo: Reach.

La présentation couvre les aspects majeurs de l'architecture et de la philosophie de conception du jeu, depuis les protocoles de réplication fondamentaux et le moteur de priorisation jusqu'au processus pratique 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 meilleures pratiques que tout studio de jeu, petit ou grand, peut ajouter à son multijoueur pour l'aider à améliorer son architecture en ligne.

[Note de l'éditeur] Compte tenu de la portée massive de la présentation de David, nous avons inclus spécifiquement pour cet article le « point clé » sous chaque insight majeur afin de faciliter la lecture.

Une architecture héritée de Tribes

Le réseau de Halo: Reach n'est pas né de nulle part. Aldridge et son équipe ont tracé l'ensemble de leurs fondations architecturales à partir d'un article de la GDC de 1998 : « The Tribes Engine Networking Model » par Mark Frohnmayer et Tim Gift. Pour une analyse plus approfondie de cet article fondateur et de ses leçons pour les développeurs modernes, Edgegap propose une étude approfondie dédiée au modèle réseau de Tribes.

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

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

• Dans une partie à 16 joueurs, une approche naïve consistant à « tout envoyer » nécessite une bande passante d'environ 20 mégabits par seconde.

• En d'autres termes, « totalement irréalisable ».

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

Le mot « semi-fiable » ressemble à un compromis. C'est en fait un choix architectural délibéré.

Comme l'a expliqué Aldridge, « le manque de fiabilité permet une priorisation agressive », c'est ce qui fait que l'ensemble du système s'adapte. 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 compte le plus à l'instant présent et remplir chaque paquet en conséquence. Pas de dette de latence due à une connexion saturée. Pas de blocage global du système en attendant le renvoi d'un paquet perdu.

Point clé : Les protocoles semi-fiables ne sont pas un raccourci, ils sont la fondation d'un réseau multijoueur évolutif. Si votre jeu comporte un grand nombre d'objets et de joueurs, la livraison garantie finira par vous briser sur la bande passante. C'est pourquoi un netcode capable d'optimiser hautement la synchronisation des données est essentiel. De plus, les données impliquent des coûts de transfert sortant (egress), qui doivent être minimisés pour garantir des coûts cloud globaux plus bas.

Trois protocoles, trois tâches

Sur cette fondation semi-fiable, Bungie exploite trois protocoles de réplication distincts, chacun adapté à un type de données différent.

• Données d'état : elles fournissent une seule garantie : à terme, la valeur la plus récente arrivera. Elles ne garantissent aucune valeur intermédiaire. Si la position d'un joueur est mise à jour 30 fois par seconde mais que seulement 10 de ces mises à jour passent, le client reconstruit la position actuelle correcte et ignore tout le reste entre les deux. Cela couvre la grande majorité des propriétés du jeu, y compris les positions, la santé, les chronomètres et des centaines d'attributs d'objets pour chaque entité réseau de la partie.

• Événements : c'est l'opposé : aucune garantie de livraison. Ils peuvent être complètement abandonnés. C'est acceptable car les événements décrivent pourquoi quelque chose s'est produit, par exemple pourquoi 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 importe. La valeur de l'événement est une nuance contextuelle. Les données d'état portent la vérité.

• Données de contrôle : il s'agit d'un flux sous-échantillonné d'entrées de contrôleur de joueur, envoyé aussi fréquemment que possible du client à l'hôte et renvoyé à tous les clients. C'est minuscule, environ 20 bits par joueur, soigneusement emballé à la main. Son unique but est la précision de la prédiction. Si un joueur pousse son stick pour commencer à faire un pas de côté vers la gauche, le changement de position qui en résulte ne sera pas visible avant plusieurs images. Les données de contrôle transmettent cette intention immédiatement, permettant à tous les autres clients de commencer à prédire le mouvement bien avant qu'il ne se manifeste dans les données d'état.

Point clé : Toutes les données de jeu ne méritent pas le même traitement. Séparer l'état persistant, les événements contextuels et la prédiction des entrées en protocoles distincts avec des garanties de fiabilité distinctes est ce qui vous permet de servir efficacement chaque type de données plutôt que de sur-concevoir pour le pire des cas sur l'ensemble du système.

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 du 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 des interactions. Certaines pondérations sont intuitives. D'autres non.

L'équipe d'Aldridge a découvert que les joueurs surveillent de manière obsessionnelle leurs propres grenades en vol, « même si elles ne les concernent plus du tout après avoir été lancées », de sorte que les grenades appartenant aux joueurs avaient besoin d'une priorité plus élevée que ce que suggérait la pure logique de menace. Un cadavre obtient une pertinence quasi maximale pendant plusieurs secondes, car les joueurs regardent les ragdolls tomber juste après une élimination. Une grenade inactive qui roule 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 par ordre de priorité. Les objets de haute priorité entrent. Ceux de faible priorité attendent. Si la bande passante est limitée, le jeu se dégrade en douceur, les objets moins importants se mettant à jour plus lentement, plutôt que de bloquer toute la simulation. Le résultat est un système sans limite stricte d'objets, prenant en charge plus de 2 000 entités synchronisées dans une partie à 16 joueurs.

Ce type de visibilité par objet et par client est difficile à acquérir. Les outils d'analyse (analytics) d'Edgegap offrent aux développeurs de jeux un niveau d'analyse comparable sur les performances des serveurs et du réseau sans nécessiter des années d'investissement dans des outils personnalisés, faisant ressortir les données nécessaires pour prendre des décisions de développement éclairées et exploitables sur le multijoueur en direct.

Point clé : La priorisation est ce qui transforme les protocoles semi-fiables en un système évolutif. Pour y parvenir, il faut ajuster les poids en fonction du comportement réel des joueurs, et pas seulement de la proximité logique. Y parvenir nécessite également d'avoir les outils pour voir ce que fait réellement votre réseau en pratique.

Cartographier la latence : 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 : le client d'un côté, l'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 du diagramme. Elle rend visible 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 avant même que le code n'existe.

Le lancer de grenade en est l'illustration la plus claire. Sur une seule machine, le déroulement est simple : pression sur la gâchette, animation de préparation, image de libération, lancement de la grenade. La question est de savoir comment introduire une seconde machine sans créer d'artefacts.

• Option une : demander l'autorisation à l'hôte avant de commencer l'animation. Cartographier cela révèle immédiatement le problème. Il y a un intervalle complet d'aller-retour avant que le client n'obtienne un retour sur sa pression de bouton. « Les joueurs détestent ça au plus haut point », comme l'a dit Aldridge. Totalement inacceptable.

• Option deux : lancer localement et informer l'hôte simultanément. Cette approche ne présente pas de décalage visible, ce qui semble positif 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 refaire surface plus tard sous forme de désynchronisation.

La véritable réponse est un troisième chemin : prédire l'animation dès la pression du bouton, mais suspendre la création de la grenade à l'image de libération. Le bras du client bouge immédiatement. La grenade disparaît à l'image de libération. Une demande de création est envoyée à l'hôte. La confirmation de l'hôte arrive environ un aller-retour 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 lors d'un lancer de grenade ; ils visent à travers leur réticule. Ils ne remarquent pas les écarts allant jusqu'à 150 millisecondes. Les joueurs occasionnels ne remarqueront rien jusqu'à 200 millisecondes, selon Aldridge. Ce qui explique pourquoi Bungie a livré les lancers de grenades ainsi sur trois titres Halo.

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

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

Où se cache la latence ?

L'approche par diagramme de séquence que David a utilisée avec son équipe mène directement à la règle la plus importante de la conférence : toujours se demander où l'on cache la latence.

« Si vous avez une décision de l'hôte qui se produit, vous aurez de la latence quelque part. Si vous n'avez pas de latence quelque part, vous n'avez pas de décision de l'hôte — vous avez contracté une dette de latence. »

Elle ne peut pas être éliminée. Elle peut seulement être placée. Le travail de conception consiste à choisir où la mettre, là où les joueurs ne la remarqueront pas, ou là où son impact perceptuel est suffisamment faible pour être livré.

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

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

Point clé : La latence n'est pas seulement un bug à corriger ; c'est un budget à dépenser judicieusement. Réduire votre temps d'aller-retour de base grâce à un placement intelligent des serveurs aide à réduire ce problème de budget avant même que vos ingénieurs réseau n'aient à y toucher.

Quand le meilleur correctif réseau est un correctif de Game Design

Quatre des cinq victoires majeures d'optimisation réseau de Bungie dans Reach provenaient de modifications des mécaniques de jeu, et non du code réseau.

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

L'exemple de la carapace de combat (armor lock) le concrétise :

• La mécanique : appuyer sur un bouton, jouer une animation d'introduction de trois images, obtenir l'invulnérabilité et une masse infinie.

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

• Toutes deux présentaient 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 sur son écran recevoir des dégâts contre lesquels il était certain d'être immunisé.

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

La version finale a introduit un changement ciblé.

Comme l'a décrit Aldridge : « Nous sommes allés chercher le nombre de frames de délai que les concepteurs avaient si soigneusement ajusté et nous l'avons écrasé pour le réseau. Nous avons en fait modifié la façon de jouer. » L'hôte active le bouclier plus tôt, réduisant le délai d'introduction de la valeur du temps d'aller-retour mesuré entre l'hôte et le client qui l'active. Lorsque le client voit le bouclier apparaître, cela correspond à son attente. L'incohérence a été déplacée loin du joueur le plus concerné, celui utilisant la carapace de combat, pour être reportée sur l'hôte et les autres joueurs, qui remarquent à peine si le bouclier de quelqu'un d'autre s'est activé quelques images plus tôt.

La mécanique d'assassinat a suivi une courbe 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 debug, le mélange était visible et les animateurs l'ont immédiatement signalé. En jeu, il était invisible. La caméra passe à la troisième personne au début de chaque assassinat et se déplace à environ 25 pieds par seconde pendant cette même fenêtre. Les repères spatiaux des joueurs changent si vite qu'un mélange de 20 pieds passe totalement inaperçu. Leurs cerveaux comblent la continuité.

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

• premièrement, les ragdolls bloquant les balles (résolu en permettant une pénétration totale sans effets secondaires) et ;

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

Les deux étaient solvables, personne n'a remarqué les changements, et le résultat a été de libérer environ 10 à 12 % de bande passante.

Point clé : Vos ingénieurs réseau et vos game designers doivent travailler ensemble dès le départ. 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 même des mécaniques, dans les fenêtres de perception et les schémas d'attention des joueurs qui peuvent absorber les incohérences de manière invisible.

Construire d'abord les outils, optimiser ensuite

Aldridge a cité une règle d'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 construit les outils pour le faire en toute sécurité avant de toucher à une ligne de code réseau.

Le profiler de bande passante suivait l'utilisation et les résultats de priorité sur l'ensemble de la simulation.

La véritable capacité est venue de l'intégration des données du profiler 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é un bloc de debug après chaque image de jeu contenant tout l'état du réseau échantillonné pendant cette frame, 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 les performances du réseau après coup, revenir en arrière à n'importe quel moment, filtrer sur un client spécifique et examiner exactement ce qui était transmis, à qui et quand. Temps de développement total : environ six semaines pour les outils de base.

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

Un exemple de ce qu'il a révélé : les grenades inactives roulant sur le sol consommaient une part disproportionnée de la bande passante au niveau de la couche de priorité. La cause d'origine était un correctif de bug de la fin de Halo 3 qui donnait aux objets d'équipement un boost de priorité important pour répondre aux plaintes concernant la latence. Par un accident de conception, les grenades et les équipements partageaient la même classe parente. Chaque grenade tombée sur chaque carte héritait du boost et était traitée comme prioritaire à tout moment. Un correctif d'une seule ligne (c'est-à-dire appliquer le boost uniquement aux équipements actifs) a libéré environ 20 % de la bande passante.

Pour les studios qui n'ont pas six semaines pour construire une infrastructure de profiling personnalisée, les outils d'analyse (analytics) d'Edgegap font ressortir les couches de conteneurs et de serveurs de jeu des données de performance en direct et historiques, aidant les équipes à détecter le type de schémas systémiques, d'anomalies de bande passante, de problèmes de priorité au niveau des objets et de pics de temps de frame serveur que le profiler personnalisé de Bungie a été conçu pour trouver.

Point clé : 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 approfondie avant d'optimiser n'est pas optionnel, car c'est ce travail qui rend l'optimisation possible.

Transformer la latence perçue en science

Les tests de jeu dans des conditions réseau simulées ont donné à Bungie un environnement contrôlé, mais le problème de la mesure de la « qualité de la partie » était plus difficile. Comme l'a noté Aldridge, les joueurs « peuvent nous dire s'ils ont passé un bon moment, ce qui est presque parfaitement corrélé au fait qu'ils aient gagné ou non. » Ce n'est pas assez précis pour guider des décisions d'ingénierie.

La solution : un bouton de manette dédié lors des tests de jeu qui injecte un événement de debug horodaté directement dans le film. Chaque fois qu'un joueur ressent de la latence, il appuie dessus. Les ingénieurs sautent à cette image exacte, examinent l'état complet du réseau et enquêtent. Lorsque l'équipe a pu atteindre ses objectifs de bande passante et constater l'absence de pressions sur le bouton par les testeurs, elle a su qu'elle avait réussi.

Un effet secondaire utile est apparu : les joueurs n'appuyaient pas sur le bouton uniquement pour des problèmes de réseau réels, mais chaque fois qu'une mécanique de jeu les déroutait ou les désorientait.

Se faire tuer d'un seul coup par une grenade alors qu'on avait presque toute sa vie ressemblait à de la latence. Une caméra de mort qui n'expliquait pas clairement la cause du décès ressemblait à de la latence. L'équipe d'ingénierie récupérait ces clips de film et les apportait directement aux concepteurs, données à l'appui. L'outil réseau est devenu une boucle de rétroaction pour la conception de jeu.

Point clé : La latence perçue est un signal produit, pas seulement une métrique réseau. Permettre aux testeurs de la signaler précisément (lorsqu'elle est liée à un état de jeu reproductible) transforme des plaintes vagues en données exploitables tant pour les ingénieurs que pour les concepteurs.

Sélection intelligente de l'hôte et coût de la migration d'hôte

La migration d'hôte, à savoir l'action de basculer vers un meilleur hôte en milieu de session lorsque la connexion de l'hôte actuel se dégrade, est puissante quand elle fonctionne.

Cependant, Aldridge a reconnu que cela pourrait faire l'objet d'une conférence dédiée, car il s'agit d'une entreprise d'ingénierie importante, et les studios qui l'envisagent ne devraient pas sous-estimer sa portée.

Michał Buras de Highwire Games, ingénieur réseau principal sur Six Days in Fallujah, détaille dans sa conférence le niveau de défi que la complexité de la migration d'hôte apporte dans le multijoueur en peer-to-peer et basé sur des relais, ce qui constitue une référence utile avant de s'engager dans cette voie.

Les serveurs dédiés contournent complètement le problème. Avec des serveurs dédiés qui agissent comme hôtes, il n'y a pas d'hôte à migrer, et la continuité de la session est ainsi gérée au niveau de l'infrastructure.

Point clé : Qui héberge une session compte autant que la façon dont vous avez conçu la session. La migration d'hôte dans une architecture réseau en P2P ou basée sur des relais entraîne un coût d'ingénierie que l'infrastructure de serveurs dédiés évite entièrement.

Les chiffres, et ce qu'ils signifient pour le coût de la bande passante

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

Chaque kilobit économisé compte double :

• Premièrement pour les joueurs, car des besoins en bande passante plus faibles signifient qu'une plus grande partie de votre base de joueurs peut faire tourner le jeu correctement sur une plus large gamme de types de connexion.

• Deuxièmement pour votre facture d'infrastructure, car le coût de transfert sortant (egress) évolue directement avec la quantité de données que vos serveurs transmettent.

À ce titre, optimiser la réplication, le tickrate et la logique de priorisation revient également à optimiser vos dépenses cloud. Pour les développeurs Unreal Engine à la recherche d'un point de départ concret, Edgegap a publié une liste de contrôle pour le profiling et l'optimisation des serveurs Unreal Engine, avec un équivalent Unity en cours de développement.

Point clé : 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 qui impacte directement la rentabilité du jeu lui-même. Ainsi, chaque amélioration de l'efficacité de la réplication réduit directement les dépenses d'egress, ce qui en fait l'un des rares investissements en ingénierie qui rapporte des dividendes tant sur l'expérience des joueurs que sur le budget de l'infrastructure.

—

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