John Chu, maintenant chef de la gestion technique de programme dans la zone centrale de technologie en ligne chez Bungie, puis ancien chef de la gestion technique de programme chez Bungie, a présenté «Réunir les joueurs : construire le jeu croisé dans Destiny 2» à la GDC 2022, en retraçant toute l’histoire de production expliquant comment Bungie a livré le jeu multiplateforme sur sept plateformes pour l’un des jeux en service continu les plus actifs au monde.

Indirectement, cela met en lumière des bonnes pratiques que tout studio de jeux, grand ou petit, peut ajouter à son multijoueur pour améliorer son architecture multiplateforme.

[Note de l’éditeur : Compte tenu de l’ampleur considérable de la présentation de John, nous avons inclus spécifiquement pour cet article un « À retenir » sous chaque point de vue majeur afin d’améliorer la lisibilité.]

Construire le jeu croisé dans votre propre moteur signifie reconstruire presque tout à partir de zéro

Le jeu multiplateforme est un concept facile à comprendre. Vous acheminez des joueurs issus de différentes plateformes vers le même monde de jeu. Mais dans un moteur propriétaire, presque rien ne fonctionne simplement à travers les plateformes — tout doit être reconstruit.

Le moteur Tiger de Bungie a été conçu pour le premier Destiny, avec des parties de la base de code remontant à l’ère Halo. Chaque système qui dépendait auparavant d’API au niveau de la plateforme a dû être recréé à partir de zéro : réseau, identité des joueurs, listes d’amis, invitations de session, chat vocal et chat texte, le tout reconstruit pour fonctionner simultanément sur Sony, Microsoft, Valve et Google. Comme John Chu les a décrits, il s’agissait de « certains des changements les plus importants et les plus effrayants, qui brisaient tout », dans le moteur, parce que le réseau est l’un de ses systèmes sous-jacents les plus fondamentaux.

Les changements réseau à eux seuls étaient considérables. Comme Destiny 2 avait été publié et optimisé séparément pour chaque plateforme au fil des ans, ces optimisations ne s’accordaient pas bien entre elles une fois combinées. L’équipe a construit une couche de mappage pour communiquer sur le réseau à l’aide de descripteurs cohérents, qui pouvaient être traduits en descripteurs adaptés à la plateforme de chaque côté. Les sessions en ligne pour les Fireteams ont aussi dû être restructurées, en abandonnant une session unique hébergée par un seul joueur au profit du maintien de sessions en ligne distinctes par plateforme.

Les jeux utilisant des moteurs tiers comme Unreal ou Unity disposent déjà d’une grande partie de cette portabilité multiplateforme intégrée. Bungie, non. Si vous construisez dans votre propre moteur, dressez l’inventaire de chaque système qui touche à une API de plateforme avant de vous engager sur le périmètre de votre jeu croisé. La liste sera plus longue que vous ne l’imaginez.

À retenir : Dans un moteur propriétaire, presque tous les systèmes qui touchent aux API au niveau de la plateforme devront être reconstruits pour le jeu croisé. Le périmètre et le calendrier doivent refléter cette réalité dès le départ, et les développeurs de moteurs tiers devraient auditer leurs propres dépendances de plateforme avant de supposer qu’ils sont couverts.

Une identité joueur unifiée est un prérequis, pas une fonctionnalité

Les joueurs de Destiny 2 passent des centaines d’heures à façonner leur Gardien. Ce Gardien est une extension d’eux-mêmes, et une partie importante de cette identité est leur nom. Avant le jeu croisé, ce nom venait de la plateforme : votre gamertag, votre profil Steam, votre pseudo PSN. Avec le jeu croisé, cette approche s’effondre immédiatement. Le même joueur peut être « Oryx » sur PlayStation et « Savathun » sur Steam, et ses amis sur les autres plateformes ne le reconnaîtront pas.

La solution de Bungie a été le Bungie Name : un nom choisi par le joueur, combiné à un identifiant unique à quatre chiffres, par exemple « Oryx#1234 ». Il est généré automatiquement à partir du nom de plateforme utilisé par le joueur lors de sa première connexion, ce qui rend l’intégration fluide sans ajouter d’étapes supplémentaires. Il apparaît au-dessus de la tête du joueur en jeu et dans la liste des joueurs partout où il joue, offrant une identité cohérente quelle que soit la plateforme.

C’est désormais un problème bien compris dans l’industrie, et les studios qui construisent le jeu croisé aujourd’hui disposent d’options que Bungie a dû créer entièrement lui-même. Epic Online Services fournit gratuitement une couche d’identité et sociale multiplateforme via son interface Auth, qui fonctionne sur PC, consoles et mobile. brainCloud propose une infrastructure similaire d’identité et d’authentification multiplateforme, conçue spécifiquement pour les jeux, avec prise en charge intégrée de la fusion des comptes entre plateformes. LootLocker fournit une authentification des joueurs multiplateforme et des comptes joueurs unifiés qui relient plusieurs identités de plateforme sous un seul profil. Le principe sous-jacent reste le même, quel que soit l’outil utilisé : une couche d’identité unifiée doit être considérée comme une infrastructure, et non comme une fonctionnalité secondaire à traiter après tout le reste.

À retenir : Toute expérience de jeu croisé a besoin d’un système d’identité indépendant de la plateforme dès le premier jour. Les studios qui construisent aujourd’hui n’ont pas besoin de le faire à partir de zéro. De nos jours, des services comme Epic Online Services, brainCloud et LootLocker fournissent cette infrastructure prête à l’emploi.

Gérer les interdépendances sur un grand projet transversal à distance

Avec quatre équipes et environ 50 personnes travaillant simultanément sur différentes parties de l’expérience, les interdépendances étaient constantes. Un changement dans la couche réseau affectait le système d’invitations de session. Une décision concernant l’identité des joueurs se répercutait sur l’interface utilisateur du roster. Et comme toute l’équipe travaillait à distance, les conversations informelles de couloir qui aplanissent généralement ce genre de questions ne se produisaient pas naturellement.

La réponse de Bungie a été de mettre en place des structures de synchronisation intentionnelles. Ils organisaient des réunions récurrentes segmentées par domaine de fonctionnalités (tout le monde travaillant sur les amis et la présence, tout le monde travaillant sur la communication) ainsi que par discipline (tous les ingénieurs ou tous les testeurs se réunissant séparément). Cela permettait de faire émerger les différentes préoccupations dans les bonnes salles. Lors d’une synchronisation hebdomadaire centrée spécifiquement sur les amis et la présence, l’équipe a réalisé que personne n’avait entièrement résolu la manière dont le blocage fonctionnerait dans un monde de jeu croisé. Le fait d’avoir des ingénieurs et des designers dans la même réunion signifiait que l’ambiguïté était traitée immédiatement, au lieu de devenir silencieusement une dette de conception.

Cela dit, Chu a été franc sur le risque d’aller trop loin : « Les synchronisations destinées à construire un consensus dans l’équipe se font au détriment du temps des contributeurs individuels. » Au début du projet, trop de réunions signifiaient pas assez de temps pour que les contributeurs individuels construisent réellement des choses. L’équipe a itéré sur sa cadence et réduit le temps total des réunions jusqu’à ce que la surcharge paraisse proportionnée.

À retenir : Des synchronisations conçues délibérément, segmentées par domaine de fonctionnalités et par discipline, font ressortir les blocages et renforcent la cohésion de l’équipe. Mais trop de réunions nuit activement à la vitesse de livraison. Auditez régulièrement votre cadence et réduisez ce qui peut l’être.

Les pools de Matchmaking devraient refléter les enjeux du mode

Tous les modes de jeu n’ont pas le même poids compétitif, et cette distinction devrait déterminer la manière dont vous structurez votre Matchmaking multiplateforme. Bungie a séparé les modes compétitifs et coopératifs dès le départ, guidé par deux principes clairs : l’équité et la protection des joueurs.

Pour les modes coopératifs comme les Strikes, il n’y avait pas d’avantage de plateforme significatif. Aucun écart d’entrée qui change l’issue, aucune différence de sécurité qui expose injustement un groupe à des exploits. Tout le monde joue ensemble quelle que soit la plateforme. Pour les modes compétitifs, deux pools distincts ont été créés : un pool console couvrant PlayStation, Xbox et Stadia (qui fonctionne sur du matériel de centre de données contrôlé, peu susceptible d’être modifié côté client), et un pool PC couvrant Steam et le Microsoft PC Store. Les Fireteams multiplateformes sont gérées en permettant aux joueurs console de basculer dans le pool PC lorsqu’ils sont regroupés avec un joueur PC, mais pas l’inverse.

Le système de pools a également été conçu pour être extensible, de sorte que de futurs modes présentant des risques de déséquilibre différents puissent être pris en charge sans avoir à réarchitecturer quoi que ce soit. Avoir des principes directeurs clairs définis à l’avance a rendu les décisions de conception individuelles nettement plus simples. Les studios qui construisent le jeu croisé aujourd’hui peuvent appliquer directement cette même logique via la configuration du Matchmaking. La documentation du matchmaker d’Edgegap couvre exactement ce schéma dans son exemple de jeux compétitifs, montrant comment imposer différentes contraintes de Matchmaking pour les modes occasionnels par rapport aux modes compétitifs, y compris des restrictions de plateforme et d’entrée, sans construire une logique de pool personnalisée à partir de zéro.

À retenir : Définissez vos principes directeurs avant de concevoir les règles de vos pools. Séparez les pools par type d’activité, concevez le système pour qu’il soit extensible, et sachez que la bonne configuration du matchmaker peut mettre en œuvre ce type de logique sans ingénierie personnalisée.

Le jeu multiplateforme introduit de nouveaux vecteurs de toxicité qui exigent des solutions multiplateformes

Lorsque vous élargissez la surface sociale d’un joueur, vous élargissez aussi son exposition aux acteurs malveillants. Combiner des plateformes avec différentes normes de noms d’utilisateur, différentes cultures de sécurité et différents historiques de modération crée des formes de harcèlement qui n’existaient tout simplement pas dans un écosystème à plateforme unique.

Bungie a identifié très tôt deux risques principaux. Premièrement, la vulgarité et le langage dérogatoire dans les noms d’utilisateur : certaines plateformes filtrent de manière agressive, d’autres non. Sans leur propre couche de filtrage, les noms de plateforme inappropriés se seraient propagés directement dans les Bungie Names. Deuxièmement, les blocages au niveau de la plateforme sont cloisonnés. Un joueur qui bloque un harceleur sur PlayStation peut toujours être atteint par cette même personne via son compte Steam.

Pour le filtrage du contenu, Bungie a intégré une solution tierce dotée de capacités d’apprentissage automatique, suffisamment sensible au contexte pour distinguer un joueur insultant quelqu’un d’un joueur exprimant son enthousiasme avec le même langage. Construire et maintenir ce modèle en interne sur 12 langues prises en charge aurait nécessité un personnel spécialisé important. Pour le blocage, le système Bungie Block a été conçu pour s’étendre à tous les comptes liés sur toutes les plateformes. Bloquez quelqu’un une fois, et tous les comptes associés à cette personne sont bloqués partout. C’était une exigence non négociable pour pouvoir sortir le jeu. Chu a été explicite sur le fait que les comportements antagonistes tendent à viser les populations de joueurs minoritaires et plus vulnérables, rendant une protection adéquate non négociable.

À retenir : Les systèmes de blocage pour le jeu croisé doivent être multiplateformes. Un blocage limité à une seule plateforme qui ne couvre pas les comptes liés d’un joueur sur les autres plateformes n’est pas une vraie protection. Construisez cela avant le lancement.

Les exigences de certification des premiers partis influencent la conception — commencez à les lire en préproduction

Publier sur sept plateformes signifie naviguer dans sept ensembles d’exigences de certification, et de nombreux premiers partis disposent de sections dédiées au jeu croisé dans leur documentation de certification. Connaître les exigences à l’avance est le minimum. La partie la plus difficile consiste à réconcilier ces exigences avec la conception que vous visez.

Certaines plateformes exigent que les joueurs sur leur plateforme soient principalement identifiés par leurs propres noms de plateforme, ce qui créait un conflit direct avec le concept de Bungie Name chez Bungie. Certaines plateformes interdisent d’afficher les logos ou icônes d’autres plateformes lorsqu’on joue sur les leurs. Ce n’étaient pas des cas limites — c’étaient des exigences qu’il fallait résoudre avant que l’expérience puisse être publiée.

L’approche de Bungie a consisté à lancer ces discussions pendant la préproduction, à signaler les conflits tôt et à dialoguer avec les premiers partis pour comprendre l’esprit de chaque exigence plutôt que seulement sa lettre. Ce fut un long processus. Mais commencer tôt signifiait qu’il y avait du temps pour trouver des solutions qui fonctionnaient des deux côtés. Chu a reconnu que Bungie se trouvait dans une position favorable grâce à des relations étroites déjà établies avec les premiers partis. Le principe s’applique largement, quelle que soit la taille du studio : plus tôt vous faites remonter ces conflits, plus vous avez de marge pour les résoudre.

À retenir : Lisez les exigences de certification de jeu croisé des premiers partis au début de la préproduction, pas à la fin. Identifier les conflits tôt est ce qui permet de trouver une voie à suivre avant que votre calendrier ne soit menacé.

Soyez délibéré sur ce que vous construisez et ce que vous achetez

Une fois que vous avez catalogué tous les systèmes à reconstruire pour le jeu croisé, certains d’entre eux seront de véritables problèmes difficiles que d’autres entreprises ont déjà bien résolus. Des codecs vocaux qui fonctionnent de manière portable sur toutes les plateformes. Le filtrage de la vulgarité et de la toxicité dans une douzaine de langues. Ce ne sont pas des fonctionnalités différenciantes. Ce sont des infrastructures, et elles disposent de fournisseurs établis.

Bungie a intégré une solution vocale tierce, ce qui a libéré l’équipe pour concentrer son attention sur les parties du jeu croisé que Bungie seule pouvait construire. Pour le filtrage texte, construire et maintenir en interne un modèle sensible au contexte sur 12 langues aurait nécessité un personnel spécialisé important que le projet n’avait ni le temps ni le budget de recruter.

Le chat texte a constitué l’exception. Malgré les options disponibles, Bungie a construit son propre service de chat texte, estimant que le contrôle de la plateforme offrait un potentiel d’intégration à long terme qu’un tiers ne pouvait pas égaler. La distinction est utile : achetez là où le tiers est déjà meilleur que ce que vous pourriez faire ; construisez là où le contrôle et l’intégration profonde comptent.

Chu a cependant été direct sur ce que l’achat ne résout pas. L’intégration de solutions tierces demande un vrai temps d’ingénierie, et dans le cas de Bungie, certaines intégrations étaient trop ambitieuses et ont dû être repoussées à une sortie ultérieure. Vous liez aussi votre jeu au rythme de sortie et au calendrier de mise à jour d’un autre produit.

À retenir : Les solutions tierces pour la voix, l’identité et la modération peuvent réduire de manière significative le périmètre. Mais l’intégration prend toujours du temps et crée des dépendances externes. Considérez le choix construire-vs-acheter comme un outil de gestion du périmètre, et intégrez le temps d’intégration dans votre planification dès le départ.

Utilisez des sorties incrémentales pour réduire les risques des grandes fonctionnalités dans les jeux en service

Le jeu croisé a introduit plus de nouveaux services que tout ce que Bungie avait expédié depuis le lancement initial de Destiny 2. Le sortir en une seule saison signifiait n’avoir qu’une seule chance de bien faire les choses sur sept plateformes, avec une base de joueurs active dépendant du fait que l’expérience ne se casse pas. C’était trop de risque à accepter en une seule fois.

À la place, Bungie a réparti la sortie sur plusieurs saisons, en plaçant d’abord les changements les plus risqués. La refonte du réseau a été intégrée très tôt, lui donnant des mois pour mûrir et se stabiliser avant que le reste du jeu croisé en dépende. De nouveaux systèmes d’interface et de premières fonctionnalités de jeu croisé ont été introduits dans une saison précédente. Dans la saison précédant le lancement complet, les employés de Bungie ont eu accès aux fonctionnalités de jeu croisé dans le jeu commercial en ligne, jouant aux côtés du public pendant des mois avant la sortie réelle. Enfin, une bêta publique limitée a activé le jeu croisé dans une playlist Strike, mettant à l’épreuve le nouveau code réseau et le nouveau code de Matchmaking à l’échelle réelle de la population.

Il y a eu quelques couacs en cours de route, avec des joueurs tombant parfois sur des fonctionnalités de jeu croisé plus tôt que prévu. Mais ceux-ci ont été considérés comme des événements utiles pour faire remonter des bugs, plutôt que comme des échecs. « Nous ne pouvons pas contrôler nos résultats, mais nous pouvons contrôler notre exécution », comme Chu l’a cité en provenance du studio. La stratégie de sortie incrémentale était l’expression exacte de cela.

À retenir : Pour les grandes fonctionnalités dans les jeux en service, répartissez la sortie sur plusieurs mises à jour et placez en tête vos changements de moteur les plus risqués afin qu’ils aient le temps de se stabiliser. Les alphas internes avec de vrais joueurs et les bêtas publiques limitées sont vos meilleurs outils pour gagner en confiance avant le lancement complet.

Cet article s’appuie sur la présentation originale de John Chu, présentée à GDC 2022, et la cite. Tous les droits relatifs au contenu original appartiennent à leurs propriétaires respectifs.