Voici une introduction aux éléments fondamentaux du netcode pour le multijoueur en ligne. Tout au long de cet article, nous avons inclus des liens vers les définitions du glossaire pour chaque terme, ainsi que des analyses techniques approfondies (Backend Deep Dives) montrant comment chaque concept a été appliqué dans des jeux multijoueurs célèbres.

Qu'est-ce que le netcode ?

Le netcode désigne le code réseau qui maintient la cohérence d'une partie multijoueur entre des machines séparées par des millisecondes. Il ne fonctionne pas seul. Le netcode n'est qu'une couche d'un écosystème plus large qui comprend également l'hébergement de serveurs, l'orchestration et le matchmaking, qui permettent ensemble d'offrir une expérience multijoueur en ligne. Notre article sur le netcode de Call of Duty montre comment ces différentes couches interagissent dans un jeu en direct.

Le netcode lui-même se divise en sept composantes :

• Transport : le protocole qui achemine les paquets, presque toujours UDP pour les jeux en temps réel.

• Boucle de simulation : la fréquence à laquelle le serveur fait avancer le monde du jeu (le tick rate).

• Réplication : quelles données sont envoyées à chaque joueur et à quelle fréquence (le taux de rafraîchissement ou update rate).

• Autorité : quelle machine a le dernier mot sur ce qui s'est produit, généralement un serveur faisant autorité.

• Modèle d'hébergement : l'endroit où s'exécute la simulation faisant autorité, que ce soit sur la machine d'un joueur (peer-to-peer), derrière un relais, ou sur un serveur dédié.

• Modèle de synchronisation : la manière dont les machines restent en accord, par synchronisation à pas fixe (lockstep), rollback ou réplication d'état.

• Masquage de la latence : prédiction côté client, réconciliation côté serveur, interpolation d'entités et compensation du lag, des techniques qui rendent le délai invisible pour les joueurs.

D'où vient le netcode client/serveur

La plupart des jeux de tir modernes tirent l'origine de leur netcode d'un seul jeu. Le jeu Quake original (1996) utilisait une architecture purement client/serveur : les clients envoyaient leurs commandes au serveur, puis attendaient que le serveur leur dise ce qui s'était passé. Chaque client était un terminal affichant l'univers du serveur.

Sur un réseau local, cela fonctionnait. Sur Internet, non.

John Carmack, alors programmeur principal chez id Software, a écrit dans son journal de développement d'août 1996 qu'il « travaillait avec de mauvais postulats de base pour faire un bon jeu Internet ». La conception originale « ciblait des latences de connexion <200 ms », alors que les joueurs utilisant des modems constataient « des latences d'au moins 300+ ms ». Avec une approche purement client/serveur, chaque pression de touche devait attendre un aller-retour complet avant que quoi que ce soit ne bouge à l'écran.

Son correctif pour QuakeWorld a établi le modèle encore utilisé aujourd'hui. Le client allait désormais « deviner les résultats du déplacement de l'utilisateur jusqu'à ce que la réponse faisant autorité du serveur arrive ». Le serveur restait l'autorité finale. Le client prédisait.

En termes de modèle de synchronisation (détaillés ci-dessous), QuakeWorld utilisait la réplication d'état : le serveur envoie l'état du monde, et chaque client prédit son propre déplacement jusqu'à ce que la prochaine mise à jour arrive. Il ne s'agit pas du lockstep, où chaque machine attend les commandes de tout le monde avant d'aller de l'avant.

Cette association — un serveur faisant autorité combiné à une prédiction côté client — est devenue la base sur laquelle d'autres ont bâti. TRIBES (1998) a ajouté des ticks synchronisés de 32 ms, l'interpolation des autres joueurs et des entrées envoyées sur trois paquets consécutifs. Vingt ans plus tard, Overwatch utilisait toujours une fenêtre glissante de commandes que ses développeurs rattachaient à QuakeWorld.

Qu'est-ce que le ping, et en quoi est-il différent du lag ?

Le ping est une mesure. Votre machine envoie un petit message à une autre machine, qui répond, et le temps écoulé entre l'envoi et la réception est le temps d'aller-retour (RTT). Pour une initiation accessible aux débutants, consultez le guide d'Edgegap sur ce qu'est la latence dans le jeu vidéo.

Le lag est la conséquence. C'est l'écart entre ce que vous voyez sur votre écran et ce que le serveur, ainsi que chaque autre joueur, voit sur le sien.

Le lag est également bien plus qu'une simple impression. Dans le rapport sur la latence d'Edgegap, 50 % des joueurs ont cité le lag comme leur première source de frustration dans les jeux en ligne, et 34 % ont déclaré avoir totalement abandonné un jeu à cause de cela.

Il existe un plancher qu'aucun netcode ne peut briser. Les données circulent dans le cuivre et la fibre optique à une vitesse finie, de sorte que le lag ne peut jamais être inférieur au temps de trajet entre deux machines. Tout le reste s'ajoute à ce plancher.

Le principal facteur aggravant est généralement le routage. Les paquets ne voyagent jamais en ligne droite. Ils passent par une série de routeurs appartenant à différents réseaux, et chaque saut ajoute du temps. C'est pourquoi une infrastructure cloud distribuée commence par l'endroit où le serveur est physiquement situé.

C'est aussi là que l'intuition est trompeuse. Dans une partie à deux joueurs, une connexion peer-to-peer directe semble être le chemin le plus court possible. Aucun serveur intermédiaire, juste un joueur relié à l'autre.

En pratique, « direct » signifie tout de même quitter le réseau domestique d'un joueur, traverser son FAI, traverser le FAI de l'autre joueur et arriver sur une connexion grand public qui peut être en Wi-Fi. Ajoutez d'autres joueurs et l'un d'eux doit héberger la partie, ce qui procure à l'hôte un délai nul et à tous les autres un délai variable. Un serveur neutre, bien positionné entre tous les joueurs, supprime l'avantage de l'hôte et raccourcit souvent le trajet réel. La section suivante explique pourquoi.

Pourquoi la distance seule ne permet-elle pas de prédire le ping ?

Deux joueurs distants de 50 km peuvent tout de même avoir une mauvaise connexion entre eux. Ce qui importe, c'est l'itinéraire que leurs paquets empruntent réellement.

L'équipe d'ingénierie de Riot Games l'a documenté en 2015 lors de la création de son propre réseau de jeu. Les fournisseurs de transit (backbone) et les FAI, ont-ils expliqué, « privilégient un itinéraire moins cher plutôt qu'un itinéraire plus rapide ». Sur une connexion San Francisco - Portland, « un trajet direct aurait pu prendre 14 ms, mais l'itinéraire le moins efficace prend pas moins de 70 ms ».

La distance fixe le plancher. Le routage détermine à quelle hauteur au-dessus de celui-ci vous atterrissez.

La même logique s'applique au choix de l'emplacement d'un serveur. Être proche d'un seul joueur n'est pas le but. Le but est de trouver l'emplacement qui offre à chaque joueur de la partie la connexion la meilleure et la plus équitable possible.

L'étude de cas d'un jeu de combat 1v1 réalisée par Edgegap avec un éditeur du top 5 l'a mesuré. En déployant le serveur de chaque match à la demande au meilleur emplacement disponible, au lieu d'utiliser un ensemble fixe de régions de cloud public, l'écart de latence entre les adversaires est passé de 46,5 ms à 33 ms, soit une amélioration de 28 % de l'équité. 91 % des joueurs ont bénéficié d'une latence plus faible.

C'est la logique qui sous-tend la multiplication des emplacements : plus il y a d'endroits où un serveur peut démarrer, plus il est probable qu'il y en ait un situé sur un trajet court et équilibré pour tout le monde. C'est pour cette raison que le réseau d'Edgegap s'étend désormais sur plus de 615 emplacements dans le monde.

Pourquoi un joueur ayant un ping élevé affecte-t-il tout le monde ?

Dans un jeu de tir, un joueur ayant un ping élevé vise l'endroit où il a vu la cible, ce qui appartient déjà au passé. Si le serveur ne vérifiait les tirs réussis que par rapport au présent, ce joueur ne toucherait presque jamais sa cible.

La compensation du lag résout ce problème en procédant à un retour en arrière (rewind). Lorsqu'un tir est enregistré, le serveur replace tous les autres joueurs à l'endroit où ils se trouvaient au moment où le tireur a fait feu, puis vérifie l'impact à cet instant précis.

Cela fonctionne. Mais cela a aussi un coût. Yahn Bernier, alors développeur chez Valve, l'a décrit dans son article de 2001 sur la compensation du lag : lorsqu'« un joueur subissant un fort lag tire sur un joueur ayant moins de lag et le touche, le joueur ayant moins de lag peut avoir l'impression que le joueur avec du lag a en quelque sorte