Le cross-play a cessé d'être un facteur de différenciation il y a des années. C'est désormais plus proche d'une attente de base, et les joueurs remarquent immédiatement lorsqu'un salon multiplateforme offre une expérience moins fluide qu'un salon sur une même plateforme.

Dès 2021, Unity estimait que plus de 50 % des Américains jouaient à des jeux multijoueurs, et que 87 % de ces joueurs avaient déjà joué en multiplateforme. L'engouement était déjà présent. Ce qui n'a pas suivi le rythme, dans de nombreux jeux commercialisés, c'est l'infrastructure sous-jacente.

La plainte est suffisamment récurrente pour servir de diagnostic : les salons de cross-play souffrent de plus de latence que les salons sur une même plateforme, même lorsque les joueurs habitent dans la même rue. C'est rarement un problème de netcode. C'est presque toujours un problème de routage.

Pourquoi le trafic du cross-play fait-il de si grands détours ?

De nombreux studios commencent par le peer-to-peer car son fonctionnement ne coûte rien. Pas de serveurs, pas de relais, pas de facturation par CCU (utilisateurs connectés simultanément). Pour un salon sur une même plateforme hébergé sur un réseau propriétaire unique, cela fonctionne plutôt bien.

Le cross-play complique la donne de deux manières.

La première est technique. La traversée de NAT réussit à des taux très différents selon les réseaux que vous tentez de franchir. Les réseaux de consoles, le NAT de classe opérateur sur mobile et un PC domestique derrière un routeur grand public ne se comportent pas de la même façon. Les connexions directes qui fonctionnent très bien au sein d'un même écosystème commencent à échouer dès qu'on les mélange, d'où la nécessité d'une solution de secours.

La seconde est que cette solution de secours est généralement centralisée. Dès qu'un studio ajoute des relais ou des serveurs dédiés pour gérer les connexions que le P2P ne peut pas prendre en charge, ceux-ci sont déployés dans un nombre restreint de régions pour limiter les coûts. Trois ou quatre emplacements, parfois moins.

Voici donc le scénario que décrivent concrètement les joueurs. Vous êtes sur PlayStation, votre ami en face de chez vous est sur Xbox. Distance physique entre vous : quelques centaines de mètres. Distance parcourue par vos paquets : un aller-retour vers un centre de données situé à plusieurs centaines de kilomètres, pour chaque mise à jour, dans les deux sens.

Le netcode fonctionne très bien. C'est l'itinéraire qui pose problème.

Pour être précis sur un sujet avec lequel l'industrie prend parfois des libertés : le P2P multiplateforme n'est pas interdit. Epic Online Services et Steam Datagram Relay gèrent tous deux des sessions multiplateformes sur PlayStation, Xbox et PC aujourd'hui. Les contraintes résident dans les exigences de certification des constructeurs pour des fonctionnalités spécifiques, et dans la fiabilité de la traversée de NAT entre différents types de réseaux. Ce sont de vraies contraintes. Mais cela ne signifie pas pour autant qu'une PlayStation ne peut pas communiquer avec une Xbox.

Relais, serveurs dédiés et ce que chacun résout réellement

Il convient de distinguer trois concepts souvent confondus.

• Le Peer-to-peer envoie des paquets directement entre les clients. C'est le coût le plus bas, la latence la plus faible lorsqu'il se connecte, sans état d'autorité ni solution de secours en cas d'échec de la traversée.

• Les relais transmettent les paquets entre les clients sans les inspecter. Ils résolvent les problèmes de traversée et masquent les adresses IP des joueurs. Ils n'exécutent pas la logique de jeu.

• Les serveurs dédiés exécutent la simulation et détiennent l'autorité. C'est le coût le plus élevé, la meilleure configuration anti-triche, et la seule option si vous avez besoin que le serveur prenne les décisions.

La plupart des jeux cross-play finissent par utiliser plusieurs de ces solutions. C'est un choix judicieux, et non un défaut de conception. Notre guide explicatif sur les serveurs faisant autorité, les relais et le P2P détaille quelle option correspond le mieux à chaque genre.

En ce qui concerne la latence, ce qu'il faut retenir, c'est qu'un relais et un serveur dédié représentent tous deux un saut de réseau, et qu'un saut mal placé vous coûtera la même latence dans les deux cas.

Les relais résolvent la distance. Ils ne résolvent pas l'incompatibilité

Il existe un cas d'échec important à mentionner car il ressemble à un problème de réseau alors qu'il n'en est pas un.

Un studio sort une version console développée sous Unreal. Un an plus tard, un partenaire de co-développement la porte sur mobile et, pour des raisons de calendrier, ce portage se retrouve sur une pile réseau différente. Dès lors, les deux builds ne parlent plus le même protocole de transfert.

Aucun relais ne peut résoudre cela. Un relais transmet des octets qu'il n'analyse jamais. Si le client console émet un paquet que le client mobile ne peut pas décoder, le fait de faire transiter ce paquet par un relais ne change rien. Il en va de même pour le P2P direct.

Deux solutions permettent de corriger cela. Soit les deux builds convergent vers un seul protocole de transfert (ce qui est la réponse la plus propre et celle pour laquelle il faut se battre pendant la production). Soit vous exécutez un composant côté serveur qui analyse un format et émet l'autre, ce qui s'apparente à une passerelle de protocole plutôt qu'à un relais, même s'il est déployé sur la même infrastructure et y ressemble de l'extérieur.

Les changements complets de moteur en cours de portage sont rares. La version plus nuancée de ce problème ne l'est pas : des versions Unreal différentes selon les builds, une réécriture de la réplication pour s'adapter aux limites de bande passante du mobile, ou une couche de transport modifiée pour le SDK d'une plateforme. Chacun de ces facteurs peut modifier le format de transfert au point de rompre l'interopérabilité, et chacun d'eux est plus facile à détecter pendant la production qu'après le lancement.

La multiplication des emplacements est le vrai levier pour réduire la latence

À partir du moment où le trafic doit transiter par un saut de réseau, le seul moyen structurel de le raccourcir est de rapprocher ce saut des joueurs.

Ce n'est pas la partie la plus spectaculaire, mais c'est là que tout se joue. La compression, l'ajustement du tickrate et la compensation de latence aident à la marge, mais rien ne surpasse la physique. Un paquet qui traverse un océan paie ce coût à chaque tick, dans les deux sens, pendant toute la durée du match. Nous avons détaillé pourquoi multiplier les emplacements est la seule vraie réponse à la latence si vous souhaitez approfondir le sujet.

De nombreux fournisseurs de relais et d'hébergement vantent une couverture mondiale tout en ne proposant qu'entre cinq et trente emplacements. C'est suffisant pour lancer une session. Ce n'est pas suffisant pour maintenir deux voisins jouant sur des consoles différentes dans un seuil de faible latence, ce qui correspond précisément au cas de figure dont se plaignent les joueurs de cross-play.

Ce que cela donne en pratique

Edgegap déploie des serveurs de jeu et des relais dans plus de 615 emplacements à travers le monde sur un réseau sans région, activés à la demande plutôt que réservés à l'avance. Les serveurs démarrent à froid en environ 3 secondes, ce qui rend le déploiement à la demande viable et concret, plutôt qu'un simple concept théorique.

Le résultat mesuré pour les studios est une réduction moyenne de la latence de 58 %, avec une latence inférieure à 50 ms pour 78 % de la base de joueurs. Pour les titres compétitifs, réduire l'écart géographique entre les joueurs connectés améliore également l'équité de 28 %, car l'avantage de vivre près d'un centre de données s'amenuise lorsque le centre de données est proche de tout le monde.

Rien de tout cela n'élimine le risque d'une panne. Ce que cela élimine, c'est la dépendance à une seule région qui fait qu'un problème technique sur un centre de données gâche l'expérience de l'ensemble de vos joueurs.

Le cross-play n'a jamais été la cause de la latence dans les jeux. C'est la centralisation du trafic qu'il impose qui l'était.

Si vous réfléchissez à la manière de router votre trafic cross-play, notre analyse des serveurs dédiés pour le jeu multiplateforme couvre le choix entre développement interne et achat de solution, et vous pouvez commencer gratuitement.