Le netcode des jeux de combat

Bon retour sur Fightin' Words ! Cela fait un moment depuis que nous avons discuté de comment les plus célèbres bugs de jeux de combat ont affecté quelques-uns de nos jeux favoris. Le sujet d'aujourd'hui est un peu plus technique, mais c’est un facteur tout aussi important dans la façon dont on joue à nos jeux modernes favoris : nous allons nous plonger dans les tréfonds du netcode, ou jeu en réseau.

Fondamentalement, le netcode est simplement une technologie qui permet à plusieurs ordinateurs, chacun en train d'essayer de jouer au même jeu, de communiquer entre eux via internet. Alors que le jeu en local garantit toujours l'arrivée et le traitement des actions des joueurs en simultané, les réseaux sont instables de bien des manières, que l'on ne peut ni contrôler ni prédire. Les informations envoyées à l'adversaire peuvent arriver en retard, dans le désordre, ou bien être complètement perdues. Cela peut-être dû à de nombreux facteurs : la distance par rapport à votre adversaire, si vous êtes connectés en WiFi, ou si votre colocataire regarde Netflix.

Le jeu en ligne dans les jeux vidéo n'a rien de nouveau, mais les jeux de combat apportent leur propre lot de défis à résoudre. Contrairement à beaucoup d'autres types de jeux populaires, ils ont tendance à impliquer des connexions directes entre les joueurs. Une latence basse et constante est extrêmement importante car la mémoire musculaire et les réactions sont capitales dans tous les jeux de combat. Par conséquent, deux stratégies principales ont émergé pour s’affronter en ligne : le netcode « delay » et le netcode « rollback ».

Récemment beaucoup de voix se sont élevées en faveur du rollback. Pareillement, on entend que les développeurs de jeux de combat qui choisissent le netcode à base de délai empêcheraient le genre d'évoluer. Bien que ce sujet soit important aux yeux de la communauté du jeu de combat depuis de nombreuses années, de nouveaux titres – pourtant excellents de manière générale – proposent régulièrement de mauvaises expériences de jeu en ligne, causant bien des frustrations.

Peu d’explications sont nécessaires pour comprendre ce qu'est le netcode rollback, comment il fonctionne, et pourquoi il est si efficace pour cacher la misère induite par de mauvaises connexions (bien qu'il ne s'agisse pas d'une solution miracle). Ce sujet est extrêmement important pour le futur et notamment pour la santé de la communauté du jeu de combat. Aussi, je souhaite démystifier certaines idées reçues concernant ces technologies et expliquer en détail leur fonctionnement, afin que chacun puisse en discuter de manière informée.

Avant d'entrer dans les détails, cependant, j'aimerais clarifier une chose.

Pourquoi devrais-je me sentir concerné ?

Tous les studios et joueurs devraient se saisir du sujet. Jouer en ligne n'est plus un hypothétique futur, il s'agit désormais du présent.

Bien que la plupart des autres genres de jeux vidéo l'aient compris depuis une dizaine d'années ou plus, les développeurs de jeux de combat rechignent à accepter l’idée du jeu en ligne. Peut-être est-ce dû aux origines du genre, qui prennent racine dans des environnements hors ligne tels que les salles d'arcade et les tournois. C'est fantastique de pouvoir jouer hors ligne, et cela sera toujours quelque chose d'important. Cependant, la dure réalité, c'est qu'un gros pourcentage des joueurs ne jouera jamais hors ligne. Pour beaucoup de férus de jeux de baston, jouer en ligne, c'est le jeu. Une mauvaise expérience en ligne les empêche de s'améliorer, de jouer ou de recommander le jeu à leurs amis, et finit par provoquer une perte d'intérêt.

Même avec une bonne connexion, ou même si l’on vit dans une région du monde possédant une infrastructure internet robuste, un bon netcode reste indispensable. En effet, perdre des informations ou bien les recevoir en retard lors d’un transfert de données est courant. Même sur les meilleurs réseaux un mauvais netcode peut très facilement empêcher le bon déroulement d'un match. À l’inverse, un bon netcode a l'avantage de mettre en lien des joueurs sur de plus grandes distances, ce qui permet de rapprocher des communautés disparates.

Qu'en est-il de ceux qui ne jouent jamais en ligne parce qu'ils préfèrent jouer hors ligne avec leurs amis ? Un bon netcode crée un cercle vertueux. Il y aura plus de joueurs actifs, donc plus de chances de profiter de votre jeu du coeur. Plus de vidéos, d'avantage de tournois en ligne à regarder en streaming, plus de guides et tutoriels pour les personnages peu populaires. En bref : plus d'effervescence autour du jeu. Par exemple, il ne fait aucun doute que l’excellent netcode de Killer Instinct (basé sur le rollback) ait joué un rôle important dans la croissance de sa communauté.

Un bon netcode c'est important, point à la ligne. Donc parlons-en.

LES BASES

Avant de s'intéresser aux spécificités des différents types de netcode, nous devons d'abord rappeler certaines règles qui gouvernent les jeux de combat ainsi que certains termes.

Dans les jeux de combat, le temps est mesuré avec une unité appelée frame. Pour faire simple, on va considérer que tous les jeux de combats tournent à 60 frames/images par seconde, ce qui veut dire qu'une frame correspond environ à 16 millisecondes (ms).

Note du traducteur : pour le reste de l’article, le terme input désigne les commandes entrées par le joueur via son contrôleur et récupérées par la console ou l’ordinateur.

Contrairement aux apparences, une frame n'est pas seulement la vitesse à laquelle le jeu affiche de nouvelles images sur votre écran. Chaque frame, le jeu exécute une boucle, qui, entre autres, demande les inputs aux contrôleurs des joueurs, vérifie s'il y a de nouvelles informations sur le réseau, fait fonctionner l'IA des joueurs « ordinateurs », anime les coups que chaque personnage est en train d'exécuter, et vérifie si quelqu'un se prend un coup. Ensuite, la boucle de jeu traduit les résultats de tous ces calculs à l'écran, puis recommence 16 millisecondes plus tard. Dans les jeux de combat, cette boucle se doit d'être propre et régulière pour tous les joueurs, peu importe la vitesse de leur système.

Quand vous jouez hors ligne à un jeu de combat avec un ami, vous connectez deux contrôleurs de jeu à un ordinateur ou une console. Si vous appuyez tous les deux sur un bouton durant la même fenêtre de 16 millisecondes, le jeu recevra et traitera les inputs pendant la même frame et appliquera la logique comme prévu. Vous verrez tous deux le même résultat, car il n'y a qu'un seul ordinateur pour réaliser les calculs.

Cela change lorsque deux joueurs jouent via internet.

Premièrement, il faut envoyer les informations à travers le réseau. On appelle « ping » le temps que prennent les informations à faire un aller-retour entre vous et l’autre joueur. Avec une connexion dont le ping est de 90 millisecondes, les informations mettront, logiquement, 45 millisecondes pour atteindre votre adversaire, ce qui correspond à environ 3 frames. Cela veut dire que les jeux doivent désormais traiter habilement la partie « inputs » de leur boucle de jeu, puisqu’il faut pouvoir s’assurer que les deux joueurs aient les mêmes informations.

Deuxièmement, deux ordinateurs différents sont en train d'essayer de faire tourner deux copies du jeu en même temps, mais doivent malgré tout produire des résultats identiques pour les deux joueurs. C’est pour cela qu’on dit des jeux de combat qu’ils sont déterministes – en lui donnant des inputs identiques, chaque machine produira des résultats identiques. C'est utile pour les fonctionnalités hors-réseau comme les replays, parce qu'on peut simplement sauvegarder les inputs de chaque joueur et reconstruire le match à l'identique. Mais surtout, cela veut dire qu’une machine n’a besoin d'envoyer que les inputs des joueurs à travers le réseau pour pouvoir jouer en ligne. On évite ainsi l'envoi d'informations compliquées concernant l'état du jeu et on économise beaucoup de bande passante.

Quand les jeux s'envoient des informations l'un à l'autre, et que les deux machines font fonctionner indépendamment leurs boucles de jeu de manière synchronisée, on dit qu'ils utilisent un système de réseau « lockstep » (en parallèle).

Les machines ne communiquent pas avec une autorité centrale qui surveillerait le jeu pour elles et leur dirait quoi faire, comme un serveur. Au lieu de cela, elles se surveillent mutuellement, s’assurant régulièrement qu’elles ont bien le même état du jeu. Si les machines entrent en désaccord, elles sont désynchronisées et devront probablement abandonner le match.

La communication directe entre les jeux est souvent plus rapide qu'en passant par un intermédiaire. De plus, le système lockstep est particulièrement bon pour prévenir un grand nombre de tricheries. Par exemple, même si vous aviez modifié votre jeu afin que Ryu puisse lancer des boules de feu plus rapides, ma version du jeu ne serait pas en accord avec la vôtre et nous serions vite désynchronisés.

Maintenant que le décor est posé, nous pouvons enfin nous attaquer au cœur du problème. Puisque nous avons un jeu de combat déterministe, qui utilise un système de réseau lockstep, les seules choses dont nous avons besoin pour jouer en ligne sont les inputs des deux joueurs. Nous allons pouvoir parler des façons « ingénieuses » dont un jeu de combat gère des inputs, qui dans les faits, arriveront toujours en retard.

Le netcode à base de délai

Pour résumer le problème, les jeux de combat doivent traiter les inputs provenant de deux joueurs en même temps. Lorsque l'on joue en ligne, vos propres inputs sont reçus immédiatement, mais les inputs de l'adversaire pour la même frame doivent parcourir le réseau et arrivent en retard. Le jeu a besoin d'une stratégie afin de gérer ces inputs tardifs tout en gardant une sensation de jeu aussi proche du hors-ligne que possible.

Malheureusement, que chaque joueur attende l’input distant de son adversaire avant de finir la boucle de jeu pour chaque frame n’est pas une solution. Cela ralentirait indéfiniment la boucle de jeu et rendrait le jeu totalement injouable.

La première stratégie, à base de délai ou encore à délai d'inputs, est la plus simple et la plus commune pour les jeux utilisant le lockstep. Si les inputs d'un joueur distant arrivent en retard car envoyés via le réseau, les technologies basées sur le délai décalent artificiellement les inputs du joueur local pour compenser le retard. En théorie, les deux inputs arrivent alors en même temps. Ils peuvent être exécutés comme prévu, de manière synchronisée.

Illustrons ceci plus clairement avec un exemple vidéo. Ici, deux joueurs sont en train de jouer à Under Night In-Birth, un jeu qui utilise un netcode à base de délai. Nous avons 90 millisecondes de ping. Cela veut dire qu'il faut – en moyenne – la moitié de ce temps (45 millisecondes soit à peu près 3 frames), pour récupérer les inputs de l’adversaire. Le joueur local appuie sur un bouton à la 3ème frame. Hors-ligne, nous verrions l'animation de ce coup commencer immédiatement, mais au lieu de cela, le jeu retarde l'input de 3 frames et commence à exécuter le coup à la 6ème frame.

Dans la vidéo ci-dessous, ces 3 frames de décalage local donnent le temps nécessaire à l'input distant, commencé à la 3ème frame, de nous arriver via internet. À la 6ème frame, nous aurons les inputs de chaque joueur et le jeu pourra continuer. Du moment que chaque input de l'adversaire voyage à travers le réseau dans cet intervalle de 3 frames, le jeu restera stable.

Malheureusement, ce n'est pas la réalité d'internet.

Les problèmes du netcode à base de délai

Bien qu’ajouter du délai ne soit pas idéal, s’il est suffisamment léger, beaucoup de joueurs ne sont pas capables de le remarquer. Cependant, peu importe le nombre de frames, cela a un impact sur votre jeu. Votre capacité à réagir s’en trouvera diminuée, créant une expérience totalement différente du jeu hors-ligne. La prise en compte du délai dans la conception du jeu, ainsi que sa stabilité limite les effets négatifs. Cela permet au mode en ligne d’être un terrain d’entraînement acceptable à défaut d’idéal.

En effet, le problème principal c’est qu’internet n’est pas connu pour sa stabilité. Et manque de chance, les technologies basées sur le délai en pâtissent. Supposons qu'il y ait un pic dans la connexion et qu'une information provenant de l'adversaire prenne un peu plus de temps que les 3 frames prévues. Parce que le jeu ne peut tout simplement pas continuer sans les informations attendues, il n'a d'autre choix que de s'arrêter et d’attendre. Cette attente donne l’impression que le jeu rame.

Puisque mettre le jeu en pause même brièvement a un impact sur l'expérience du joueur, la plupart des technologies basées sur le délai rusent afin d’en limiter les effets négatifs.

En surveillant les conditions du réseau, elles peuvent changer ce délai en temps réel afin de s'aligner sur l'état actuel de la connexion. Mais parce que le comportement du réseau est très difficile à prédire, ce changement de délai arrive souvent trop tard. Le jeu subit quelques pauses, et l'augmentation de ce délai dure souvent plus de temps que nécessaire.

Par exemple, avant de changer de technologie et d’adopter le rollback, le netcode à base de délai de Mortal Kombat X pouvait fluctuer entre 5 et 20 frames. Un ping subitement élevé augmentait le délai pendant de nombreuses secondes, même si cette hausse de ping n'avait affecté que quelques frames. Cela peut mener à des situations où les joueurs ressentent que le jeu rame beaucoup plus qu’indiqué.

Le netcode à base de délai est aussi extrêmement sensible à la distance qui vous sépare de votre adversaire. Une plus grande distance augmente le temps que mettent les informations à voyager à travers le réseau, obligeant le jeu à augmenter le délai. La distance joue un facteur dans toutes les connexions en ligne peu importe le choix du netcode, réduisant de facto les chances d’unir une communauté au niveau mondial.

Enfin, un dernier défaut peut-être peu évident à première vue, c'est que les solutions à base de délai ne se soucient pas de l'état du jeu. Que l'annonceur soit en train de dire « Round 2, Fight », que l'adversaire soit mis au sol, que les deux joueurs soient en train de marcher en neutral ; un jeu à base de délai traite unilatéralement les problèmes de connexion. Cela veut dire, et on y reviendra, qu'il n'y a pas de moyen d’atténuer une mauvaise connexion.

Pour conclure, les solutions à base de délai ne permettent pas une bonne expérience utilisateur puisqu’à l'inverse du jeu hors-ligne, les inputs des joueurs ne sont pas réguliers. Les joueurs de jeux de combat s'améliorent en mémorisant des situations où les réactions et les réflexes priment. Ces situations doivent être reproductibles à l’identique. Si l'adversaire saute, je dois pouvoir faire un anti-air. Si je touche avec ce début de combo, je dois pouvoir continuer grâce à ma mémoire musculaire. Quand je mets mon adversaire au sol, je peux appliquer une stratégie spécifique. Quand le délai fluctue de manière imprévisible, que cela soit entre deux matches différents ou durant le même match, les joueurs finissent par douter. Est-ce eux qui ont raté, ou est-ce dû au délai ? Quand les joueurs sont incapables d'exécuter leur stratégie, jouer sur internet devient frustrant et même inutile.

Mais, et si j'ai une bonne connexion ?

Qu’on se le dise : les gens surestiment grandement leur connexion. Bien qu'il soit possible que vous ayez une connexion rapide et stable avec les personnes proches de vous, qu’en est-il des autres ? Certains joueurs peuvent être loin de vous ou perdre des informations sur le réseau. Même deux personnes vivant proches l’une de l’autre et naviguant habituellement vite sur internet peuvent avoir des difficultés à maintenir une connexion stable, pour des raisons entièrement hors de leur contrôle.

Bien sûr, avec certaines connexions, des matches en ligne sur des jeux avec délai peuvent bien se passer. Cependant, le netcode doit être jugé sur les mauvaises connexions, pas les bonnes. Si l'on se base sur une connexion parfaite avec des inputs toujours bien synchronisés, il n'y a pas besoin d'une quelconque stratégie pour se rapprocher d'une expérience hors-ligne ; on a déjà atteint l’objectif !

Le travail du netcode, c’est justement de cacher habilement la latence. S’il échoue au plus petit signe d’instabilité du réseau, alors il ne peut être considéré comme efficace.

Pourquoi utilise-t-on toujours le délai ?

La raison principale pour laquelle tant de jeux de combat implémentent un netcode à base de délai, c'est parce que c'est simple. La logique du gameplay est inchangée comparée au jeu hors-ligne, puisqu'on considère que les inputs des deux joueurs sont enregistrés au début de la boucle de jeu. Il n'y a pas non plus besoin d’optimiser le jeu pour qu’il fonctionne en ligne. La machine consomme autant de ressources pour un match hors-ligne que pour un match en ligne. C'est l'option la plus rentable pour les développeurs qui souhaitent proposer du jeu en ligne.

Aujourd’hui, les développeurs japonais sont les principaux utilisateurs du netcode à base de délai, alors que tous les jeux de combat développés en Occident sont passés au rollback. On parle de titres de gros éditeurs, comme Killer Instinct et Mortal Kombat 11, et de titres indés plus modestes comme Skullgirls, Punch Planet, Pocket Rumble, et Them's Fightin' Herds. Il est fort probable que les vastes zones géographiques d'Europe et d'Amérique aient encouragé ces développeurs à faire du netcode une plus grande priorité. Mais ce n'est pas comme si les japonais étaient exempts de mauvaises connexions et des frustrations liées à un mauvais netcode.

De part la pression des fans et les tendances de l'industrie, il est de plus en plus improbable que les développeurs japonais ne soient pas conscients de l’existence du rollback.

Capcom, un des grands développeurs japonais de jeux de combat, a tenté le netcode rollback sur trois titres différents (Street Fighter x Tekken, Street Fighter V, Marvel vs. Capcom Infinite), avec un degré de succès variable. Daisuke Ishiwatari, Responsable Créatif chez Arc System Works, a admis que les fans lui ont demandé de s'intéresser au netcode rollback à de nombreuses reprises, mais Arc System Works a quand même choisi d'utiliser le netcode à base de délai pour leur jeu Blazblue : Cross Tag Battle sorti en 2018.

Des fans (et même des développeurs) ont émis l'hypothèse selon laquelle certains studios préfèrent réinventer la roue, un souci qui semble surtout affecter les studios japonais. Mais parce que tant de jeux de combat populaires dans notre communauté sont créés au Japon, le netcode à base de délai reste la norme. Plus d'une décennie après l'invention du netcode rollback, seul 1 des 9 jeux présents à l'EVO 2020 utilise le rollback pour son multijoueur en ligne. Et encore, la qualité du netcode de ce dernier ne fait l'unanimité.

Ces précisions établies, expliquons le fonctionnement du rollback.

Le netcode rollback

On l’a vu, un netcode ne peut pas ignorer la distance séparant les joueurs ni empêcher la perte d’information entre eux. Ces problèmes étant inévitables, comment une technologie pourrait-elle être supérieure à une autre ? Dans le cas du rollback, l’amélioration vient de la gestion de l’incertitude.

Quand il n'y a pas d'information provenant du joueur distant, le netcode à base de délai a besoin de faire une pause et d'attendre. La principale qualité du rollback, c'est qu'il n'attend pas, même si un input de l’adversaire viendrait à manquer. Au lieu de cela, le rollback continue de faire tourner le jeu normalement. Tous les inputs du joueur local sont enregistrés immédiatement, comme si l'on était hors-ligne. Puis, quand les inputs du joueur distant arrivent quelques frames plus tard, le rollback résout ses erreurs en corrigeant le passé. Cette stratégie est tellement habile que le joueur local pourrait même ne pas remarquer une grande partie des instabilités du réseau. Il peut jouer en sachant que ses inputs sont stables.

Mais intéressons-nous tout d'abord à ce qu'est le « rollback ».

Agir maintenant et s'excuser plus tard

Quand des inputs distants n'arrivent pas à destination, le netcode rollback continue quand même à simuler le jeu. Fatalement, quand ces inputs finissent par arriver, le jeu est en avance par rapport au moment où l'adversaire a appuyé sur ce bouton. Le jeu a déjà affiché un résultat différent à l'écran. Pour résoudre ce problème, le netcode rollback va rembobiner le jeu. Il va appliquer le bon input et immédiatement afficher le nouveau résultat au joueur qui était en avance.

Dans l'exemple ci-dessous, le joueur local et le joueur distant appuient tous deux sur le bouton poing moyen à la frame 1, mais disons que l'input de l'adversaire est retardé à travers le réseau et nous arrive trois frames plus tard, à la frame 4. Comme pour le jeu hors-ligne, l’attaque du joueur local entame son animation immédiatement sur son écran. Le jeu fait son petit bonhomme de chemin en considérant que l'adversaire n'a rien fait. À la frame 4, l'input de l'adversaire, noté comme ayant été exécuté à la frame 1, arrive finalement. Cela veut dire que ce que l'on a montré au joueur local dans les 3 frames précédentes n'est pas ce qu'il s'est passé. Le jeu doit alors corriger le passé en effectuant quelques calculs en arrière-plan.

Tout d'abord, l'état du jeu est rechargé à ce qu'il était avant la frame 1 – c'est-à-dire, il « rollback » (littéralement, il recule) dans le passé jusqu'à la frame où l'input doit être appliqué. Ensuite, les inputs du joueur distant, ainsi que les anciens inputs du joueur local, sont appliqués. Enfin, le jeu re-simule plusieurs frames en avant afin d'atteindre de nouveau la frame présente.

Tous ces calculs, toutes ces opérations se passent instantanément, en 1 frame de jeu ; le joueur local ne voit jamais ces étapes se dérouler individuellement. Au lieu de cela, tout ce qu'il peut voir, c'est l'état du jeu qu'il pensait être correct (alors qu'il était faux) se faire immédiatement remplacer par le vrai état du jeu.

Selon ce qui arrive en jeu, les personnages peuvent avoir un léger soubresaut, et quelques frames d’animation au début du coup adverse sont supprimées chez le joueur local.

En d'autres termes, le rollback permet à chaque machine de casser temporairement la règle du lockstep. Le jeu peut afficher des choses différentes pour chaque joueur en fonction de la qualité de la connexion et de ce qu'il se passe au moment des rembobinages. Cependant, le jeu se corrigera toujours lui-même pour afficher la même chose aux deux joueurs lorsque les inputs sont reçus quelques frames plus tard.

Il est utile de répéter cette propriété importante du netcode rollback ; les inputs du joueur local sont toujours affichés immédiatement et ne peuvent jamais être annulés. Si vous appuyez sur un bouton à la frame 4, cette information est immédiatement traitée par votre jeu, et votre coup sort instantanément sur votre écran. Si du rollback se passe quand vous avez appuyé sur ce bouton, il est toujours ré-appliqué correctement durant les calculs du rollback. Il n'y a ainsi aucun moyen que votre input soit invalide ou « mangé » par le réseau, ce qui peut arriver dans les netcodes à base de délai.

Par conséquent, les joueurs sont sûrs que les boutons sur lesquels ils appuient seront exécutés peu importe la qualité du réseau. Cela améliore drastiquement l’exactitude du jeu en ligne.

Cerise sur le gâteau, si une information est perdue sur le réseau, il n'y aura de rollbacks que sur les frames concernées par cette perte. À l’inverse, avec le netcode basé sur le délai, le jeu peut choisir d'augmenter le retard des inputs pendant de nombreuses secondes, même si le réseau s'est stabilisé entre temps. Le rollback est particulièrement bon pour les connexions qui ont tendance à perdre des informations, comme le WiFi.

Voici donc le concept initial du rollback. Mais on peut faire encore mieux.

Les bases de la prédiction

Dans l'exemple ci-dessus, quand l'input du joueur distant est manquant, on considère qu'il ne fait rien pour permettre à la machine de simuler le jeu. Mais c'est une supposition plutôt candide car les joueurs ne font rarement rien ! Si l’on s’arrêtait à cette supposition, le jeu présenterait presque toujours l’adversaire de manière incorrecte. En vérité, on peut prédire ce que l'adversaire est en train de faire avec un degré de précision surprenant.

Quand un input est manquant car perdu par le réseau, le rollback simule le dernier input connu du joueur distant pour la frame manquante. S'il maintenait bas-arrière, le jeu prédit qu'il maintiendra bas-arrière enfoncé. S'il maintenait un bouton, le jeu suppose qu'il est probablement toujours en train de maintenir ce bouton enfoncé. Pour le joueur local, le jeu fonctionne avec les inputs supposés du joueur distant.

(N.B. : dans le but de garder ces exemples vidéo aussi accessibles que possible, on considérera temporairement que le temps de transmission du réseau est instantané et que lorsqu'il y a des frames manquantes, c'est parce que le réseau a été brièvement surchargé. Ne vous inquiétez pas, le concept fonctionne toujours très bien avec des retards réseau, mais les vidéos auraient été un peu trop déroutantes).

Quand les vrais inputs distants arrivent quelques frames plus tard, le jeu doit décider comment les utiliser. Si les inputs étaient incorrects, un rollback a lieu, comme décrit précédemment ; le jeu se rembobine jusqu'à un ancien état et utilise les nouveaux inputs pour continuer de simuler. Mais si ces inputs sont exactement tels que prédits (par exemple, le joueur a bien maintenu bas-arrière enfoncé), aucun rollback n'est nécessaire ; la prédiction affichée au joueur était correcte !

Le jeu met simplement à jour le dernier input correct et connu du joueur distant, tandis que le joueur local n’y voit que du feu. Quand le jeu prédit correctement les inputs, le rollback permet une sensation de jeu parfaite, même s’il y a des problèmes réseau.

La prédiction peut sembler anecdotique mais elle a un impact énorme. Reculer dans le temps et re-simuler le jeu uniquement si le joueur distant a fait quelque chose de différent possède beaucoup d'avantages. En particulier, cacher les effets d'une mauvaise connexion.

Pourquoi la prédiction est aussi éfficace

Contrairement à d’autres types de jeu comme les FPS, la prédiction dans le jeu de combat n’est pas aussi complexe qu’on pourrait l’imaginer. Comme dit précédemment, tout ce qu'elle fait, c'est vérifier que les inputs du joueur distant n'ont pas changé depuis la dernière fois.

Si l’on regarde la fréquence à laquelle les joueurs changent d’input dans un jeu comme Street Fighter où les joueurs vont et viennent en marchant ; on va considérer qu'un joueur change de direction environ 5 fois par seconde, une plutôt bonne fourchette même pour les joueurs très actifs. On a besoin des inputs du joueur distant sur seulement 5 des 60 frames d'une seconde donnée (uniquement 8% du temps). Pour les 55 frames restantes, les inputs du joueur peuvent être prédits avec un grand degré de précision, simplement en supposant qu'ils sont les mêmes qu'à la frame précédente.

Et là, on parle de la partie la plus active du match. Si vous avez mis votre adversaire au sol et que vous tapez dans sa garde, il est assez courant pour le joueur qui défend de simplement maintenir bas-arrière pendant 30, 60, ou 120 frames consécutives. Si votre adversaire saute, il est en saut pendant environ 45 frames et il y a des chances pour qu'il n'appuie que sur un seul bouton pendant tout ce temps. Pourquoi devrait-on attendre que le réseau nous communique l'information si la prédiction s'avère correcte 95% du temps ?

Cela veut dire que si un retard a lieu durant un moment où l'input distant est inchangé, il est complètement invisible pour les deux joueurs. Même avec des connexions aléatoires où l'information peut arriver en retard de nombreuses fois par seconde, un gros pourcentage de ces retards coïncide avec des moments où le joueur distant n'a pas changé ses inputs. Un jeu basé sur le délai serait obligé de se mettre en pause et d'attendre. Mais parce qu'un jeu avec rollback vérifie que les actions du joueur distant sont conformes à sa prédiction, la machine n'a pas besoin de changer quoi que ce soit. La connexion semble parfaite.

Le rollback dépend de l'état du jeu

Ce n’est pas tout, car le rollback emploie d’autres méthodes pour atténuer les effets des mauvaises connexions. Contrairement aux technologies à base de délai qui peuvent stopper le jeu à n’importe quel moment, le rollback n’intervient que si les inputs du joueur distant ont effectivement changé l'état du jeu.

Expliquons ceci en vidéo. Ci-dessous, l'adversaire distant jouant Jago utilise un gros poing à la frame 2. Le jeu local reçoit l'input correctement et commence à animer le coup. Juste après avoir appuyé sur gros poing, il y a un ralentissement et toutes les informations pour les 5 prochaines frames n'arrivent pas à temps. Comme nous l’avons expliqué, le rollback ne s'en soucie guère ; il continue à simuler le jeu dans tous les cas. Dans ce cas précis, il considérera que Jago n’a entré aucun input, puisqu'il a relâché le bouton gros poing à la dernière frame connue.

Six frames dans le futur, à la frame 8, toutes les informations des 5 frames manquantes arrivent d'un coup. Il se trouve que Jago appuyait sur des boutons ! Ce n'est pas ce qui était prédit, donc la machine rembobine le jeu de de 5 frames, au début du gros poing, re-simule ces 5 frames avec le bon input, et affiche ce qui se passe vraiment.

Cependant, le système de jeu de Killer Instinct interdit d’annuler un coup par un autre dans cette situation. Ces nouveaux inputs n'ont donc rien changé à l'état du jeu ! Même si le jeu est revenu en arrière et a re-simulé de multiples frames, le résultat final était le même que celui affiché à l'écran ; et encore une fois, le retard est complètement invisible pour les deux joueurs.

Il y a en fait de nombreux moments où notre adversaire ne peut rien faire car le système de jeu ne le permet pas. Lorsqu’il est mis au sol, qu’il subit un combo, qu’il garde un pressing, qu’il lance, finit ou rate un coup. Toutes ces actions prennent un temps conséquent. Une mise au sol dans Street Fighter peut prendre jusqu’à 60 frames. Les attaques fortes près de 30 frames ou plus si faites dans le vent. Les combos peuvent durer jusqu’à 10 secondes ! Même si la connexion devenait chaotique, cela n’aurait aucune influence dans ces situations. Tant que la machine a bien enregistré le début de ces actions, il n’est de toute façon pas permis de les modifier.

En ajoutant la prédiction à ces règles de jeu immuables, une quantité de problèmes réseau sont « absorbés » durant un match. Les problèmes de connexion n'ont pas disparu, mais le rollback les camoufle dès que possible et permet même de jouer avec les plus mauvaises connexions. Dans le cas de Killer Instinct, il permet des matches en ligne entre Singapour et l'Est des États-Unis malgré un ping de 200 millisecondes, soit 6 frames. Impensable avec n'importe quel netcode à base de délai.

Peut-on couper la poire en deux ?

Vous en avez peut-être déduit – à juste titre – que chaque bouton enfoncé ou changement de direction de l'adversaire cause un vérification et un rembobinage parfois inutile de l’état du jeu.

Il s'avère qu'on peut éliminer ces micro-rembobinages en combinant les techniques à base de délai et de rollback. En fait, tout jeu de combat moderne qui utilise le rollback repose sur une structure à base de délai. Avec cependant une nuance importante : le délai est stable et fixé d'avance. Si ce délai est suffisamment bas, les inputs de votre adversaire arriveront sans avoir besoin de rembobiner à chaque changement d'état du jeu. En cas de souci sur le réseau, le rollback prend le relai.

Quand le délai est bas et stable, les joueurs peuvent s’adapter à sa présence. Avec le temps, beaucoup ne remarquent plus la différence avec le jeu hors-ligne.

La quantité de délai fixée par les développeurs pour garantir cette stabilité dépend des jeux. Certains comme 3rd Strike Online Edition, Darkstalkers Resurrection, Skullgirls et Samurai Shodown V Special, laissent le choix du délai à l'utilisateur, habituellement entre 0 et 8 frames.

D'autres jeux, comme Killer Instinct et Injustice 2, choisissent un délai universel pour tous les joueurs (3 frames en l’occurrence) et ne donnent pas l'option d’en changer.

Les deux méthodes ont leurs avantages et inconvénients. Autoriser le joueur à choisir son propre délai lui permet de prendre en compte la qualité de la connexion et d'ajuster le délai en fonction. Mais encore faut-il comprendre comment le rollback fonctionne, pour ne pas se tromper de configuration. Définir arbitrairement un délai unique pour tout le monde signifie qu’en théorie, certains matches auront un peu plus de délai que nécessaire. Mais en contrepartie, cela permet d’avoir une base commune pour toutes les connexions, limitant la nécessité de s’adapter à différents délais.

Un récapitulatif des avantages du rollback

Le rollback ne crée pas de retard variable dans les inputs, véritable fléau des solutions à base de délai. Le joueur local n'est pas affecté par les problèmes de réseau, ce qui permet de toujours traiter ses inputs de la même façon. Si vous effectuez un setup de mise-au-sol spécifique, ou si vous avez un combo avec un timing très serré, le rollback vous permet toujours de l'exécuter de la même façon peu importe les problèmes de connexion. Si une information est perdue, cela n’affecte que le moment présent, tandis qu'un jeu à base de délai augmente le délai d'inputs pendant de nombreuses secondes.

Une grande partie de l'instabilité du réseau est tout simplement rendue invisible grâce au netcode rollback. Chaque fois que le joueur distant ne peut pas modifier l’état de son personnage ; chaque fois qu'il choisit de répéter l’action (ou l’inaction) de la frame précédente, le système rollback ne produit aucun changement visuel. Le problème réseau est invisible sur cette période de temps. Au passage, cela affecte aussi les objets non-contrôlés par votre adversaire comme les boules de feu. Une fois lancées, le rollback ne peut pas changer leurs trajectoires ou vitesses, ce qui permet de bloquer ou sauter par-dessus avec le même timing qu'hors-ligne.

Le rollback est la meilleure solution pour cacher le lag dans les jeux de combat. À présent, il est temps de parler des conditions d’implémentation du netcode rollback.

L'aspect technique du netcode rollback

Comment est construit un netcode rollback ? Qu’est-ce qu’un jeu doit faire pour l’utiliser ? Pourquoi autant de studios ont du mal à s’y mettre ?

Implémenter le rollback demande du travail et de la détermination. Avant toute chose, il faut avoir envie de créer du jeu en ligne de qualité.

Pour rappeler brièvement comment le rollback fonctionne, quand les inputs distants sont inconnus, le jeu prédit la suite avec les inputs déjà connus. Si ces prédictions s'avèrent incorrectes lorsque l'input réel est reçu, le jeu recule dans le temps en chargeant un précédent état du jeu et en re-simulant la logique du jeu.

Par conséquent, le prérequis principal d'un jeu avec rollback, c'est qu'il soit capable de sauvegarder et charger différents états du jeu. Il doit pouvoir simuler la logique du jeu en arrière-plan et cela très rapidement. Cette condition simple sur le papier peut être un véritable casse tête.

L'action de convertir des objets dans la mémoire de l'ordinateur en un format qui puisse être sauvegardé et chargé est appelée sérialisation. L'état du jeu à chaque frame doit être sérialisé et sauvegardé, au cas où nous aurions besoin de rembobiner. Cela signifie que la sérialisation de l'état du jeu, qui est une opération qui peut prendre du temps selon les données à traiter, doit être instantanée et très bien optimisée.

Si ces performances ne sont pas satisfaisantes, il faut alors revoir la façon dont les données sont stockées, et comment les différents systèmes du jeu les utilisent. Construire un jeu avec le rollback en amont réduira pour sûr la charge de travail en aval. En revanche, ajouter le rollback dans un jeu déjà existant peut nécessiter d'énormes changements au cœur même du jeu. Michael Stallone, ingénieur chez NetherRealm Studios, estime que cela a pris 2 années-homme à son équipe pour construire et optimiser les systèmes de sérialisation de Mortal Kombat X lors de l’ajout du netcode rollback.

Si un jeu a besoin de rembobiner un nombre important de frames, le processus doit être parfaitement optimisé. Une fois que l'état du joueur distant a été désérialisé et chargé, le jeu doit re-simuler toutes les frames jusqu'au présent, puis les sérialiser ! Cela doit être fait vite et en arrière-plan. Par conséquent, la logique du gameplay doit être indépendante du reste de la boucle de jeu. Il faut pouvoir simuler toutes ces frames sans pour autant les afficher à l'écran, sans attendre le réseau, et sans dépendre d'autres systèmes qui opèrent habituellement à chaque frame.

Selon le moteur choisi, ou à quel point les systèmes de boucle de jeu sont personnalisés, séparer et « éteindre » les autres sous-systèmes peut se révéler étonnamment difficile.

Parce que toutes ces opérations doivent être effectuées en l'espace d'une frame, l'optimisation devient un vrai casse-tête. Il est possible que les systèmes de particules ou de simulation de vêtements ne soient plus assez performants. Peut-être la puissance de la machine a-t-elle été surestimée.

Stallone prend l’exemple de Mortal Kombat X. Sous son ancienne solution à base de délai, sur une Playstation 4 ou une Xbox One, le titre ne prenait en moyenne que 10 millisecondes de son budget total de 16 pour calculer une frame. Quand l'équipe a implémenté puis testé sa solution rollback pour la première fois, le coût de calcul d’une frame avait plus que triplé pour s'élever à 32 millisecondes. Résultat ? Obligé de repasser sur presque tous les systèmes du jeu pour gagner en performance.

Profitons-en pour réfuter une idée reçue sur le rollback : il n'y a pas de limitation liée au genre du jeu. Le rollback peut être (et a été) utilisé pour des jeux de combat 2D tout comme des jeux de combat 3D, notamment Street Fighter III 3rd Strike: Online Edition, Killer Instinct, Brawlhalla, ou encore For Honor. Il est aussi utilisé en dehors des jeux de combat. Iron Galaxy a incorporé un netcode rollback dans le jeu d'action à 4 joueurs Dungeons & Dragons: Chronicles of Mystara. Même des jeux comme Rocket League utilisent le rollback afin de rendre l'expérience de jeu en ligne tout aussi réactive qu'hors-ligne.

Synchroniser le monde

Toutes les solutions de jeu en réseau, peu importe qu’elles utilisent le délai ou le rollback, doivent maintenir les deux machines complètement synchronisées. Cela signifie que les deux machines montrent à chaque joueur la même frame au même moment, ou s’en approchent le plus possible.

Malgré leur framerate à 60 images par seconde, rien ne garantit que les joueurs resteront synchronisés pour toute la durée du match. Beaucoup de soucis indépendants du réseau, tels que la surchauffe pour les consoles ou le multitâche pour les ordinateurs peuvent causer une perte de performances qui peut désynchroniser les joueurs.

Une désynchronisation des joueurs qui n’est pas résolue rapidement a des effets catastrophiques. Considérons un système de rollback où l'on affiche la frame 20 au joueur A, mais où l'on affiche la frame 23 au joueur B, à travers un délai de 3 frames. Le joueur B envoie l'input de sa frame 23 au joueur A. Parce que le joueur A est à la frame 20, le délai du réseau fait qu'il recevra l'input à sa propre frame 23, juste à temps pour l'exécuter sans subir de rollback. Côté joueur A donc, tout va bien.

À son tour, le joueur A envoie son input pour la frame 20 au joueur B. Avec le délai du réseau, le joueur B recevra cet input sur sa frame 26 au lieu de sa frame 23, ce qui causera un rembobinage massif de 6 frames.

Il faut noter que ce rollback est entièrement à sens unique. Seul le joueur qui est en avance par rapport à l'autre subira les effets de la mauvaise connexion. Tony Cannon, fondateur du rollback moderne avec GGPO, théorise que c'est l'un des défauts du système de rollback de Street Fighter V ; et la cause de la mauvaise réception du rollback auprès des joueurs qui ne l’ont expérimenté qu’à travers ce jeu. Des fans ont également effectué leurs propres tests et sont arrivés à des conclusions similaires. Pour illustrer cet exemple, Zinac montre l'effet du rollback à sens-unique en action en utilisant un projet très simple.

Le problème est relativement facile à résoudre. La plupart des systèmes rollback mettent le jeu du joueur qui est en avance en pause pendant 1 ou 2 frames, afin que le joueur en retard puisse le rattraper. Si le jeu emploie ce système et qu'il ne laisse jamais les jeux se désynchroniser trop longtemps, la correction est rapide et indolore. Remarquez que ces pauses ne sont pas dues à des inputs manquants ou à d'autres difficultés du réseau ; elles sont pensées pour résoudre des problèmes de performances liés à l'hétérogénéité du matériel. Par exemple, les deux joueurs peuvent faire tourner le même jeu à des vitesses légèrement différentes. Dans ces conditions, perdre 1 frame toutes les 10 secondes afin de maintenir les jeux synchronisés passe inaperçu, même auprès des joueurs les plus aguerris.

Qu'est exactement GGPO ?

Si vous avez un tant soit peu côtoyé la communauté des jeux de combat, vous avez sans doute entendu parler de GGPO, la solution rollback (désormais gratuite et open-source !) écrite par Tony Cannon, co-fondateur de l'EVO.

Vous entendrez souvent « GGPO » et « rollback » utilisés de manière interchangeable. La première version de GGPO, sortie en 2006, a été faite pour tester le concept du rollback via un émulateur. Peu de temps après, Cannon a sorti une version commerciale afin de permettre son implémentation dans d’autres jeux.

La principale fonction de GGPO est de fournir des outils pour synchroniser les machines et les états du jeu. Par exemple, GGPO peut communiquer au jeu si les deux machines sont désynchronisées, et dans quelle mesure. Il peut aussi surveiller les inputs de tous les joueurs connectés et indiquer quand rembobiner, de combien de frames, et quels nouveaux inputs doivent être appliqués.

Parce que GGPO est une solution testée et approuvée, c’est un excellent outil à adosser à tout projet souhaitant utiliser du rollback. Mais GGPO ne fait pas tout le travail. Améliorer les performances, gérer la séparation de la logique et de la boucle de jeu, s’occuper de tous les petits cas particuliers, tout cela reste à la charge des développeurs.

Autrement dit, GGPO se contente de communiquer quand et pourquoi un rembobinage est nécessaire et avec quels inputs, mais il ne fait rien d’autre. Cela en fait un outil flexible mais pas une solution miracle. C’est pour cette raison que d’autres jeux, comme Killer Instinct, n’utilisent pas GGPO, préférant leur propre solution.

Si la façon dont GGPO gère le rollback et communique avec les jeux vous intéresse, je vous recommande de lire cet excellent article (en anglais) écrit par Tony Cannon dans le Game Developer Magazine. Plutôt technique, il peut vous intéresser si vous êtes développeur ou tout simplement curieux. Vous pouvez également consulter le code source et lire la documentation de Tony quant à la théorie à l’origine du rollback.

Méfiez-vous des cas particuliers

Comme si le rollback n'était pas assez compliqué, mentionnons quelques cas particuliers rencontrés lorsqu’il est implémenté dans un jeu de combat.

Créer et détruire des objets non contrôlés directement par le joueur devient plus difficile. Admettons que le joueur local lance une boule de feu sur son adversaire. Ce dernier se prépare à la bloquer et s’accroupit en maintenant arrière. Dans la partie du joueur local, la boule de feu est bloquée et donc détruite en un amas de particules visuelles. Mais ! L’autre joueur passe au travers avec un coup invincible ! De son côté la boule de feu n’a pas été détruite et continue son chemin à travers l’écran.

Dans beaucoup de jeux, recréer un objet comme cette boule de feu est coûteux en ressources et peut résulter en un étrange sursaut visuel. Une solution possible est de garder les objets en mémoire après leur disparition. Si le rollback annule leur destruction, il faut donc re-simuler la logique du jeu. Avoir l’état des objets en mémoire facilite ce travail. C’est le cas des systèmes de particules, souvent simulées via des calculs, et qui demandent donc une attention toute particulière lors de l’implémentation du rollback.

Le son est également un élément difficile à gérer dans les jeux avec rollback. Comme le rollback utilise la prédiction et que celle-ci peut-être fausse, il faut alors couper le son en cours pour le remplacer par autre chose. Cela signifie lire un son non pas depuis le début, mais depuis le moment où l’on en a besoin afin d’être synchronisé avec l’état du jeu. Encore une fois, il faut séparer la logique du jeu de tous les autres aspects.

Certains jeux en ont fait les frais. C’est le cas de Street Fighter x Tekken, dans lequel on subissait d'horribles bugs de son tels que des absences pendant plusieurs secondes ou une totale désynchronisation. Dans un article pour Games Developer Magazine, Tony Cannon offre quelques conseils pour gérer l'audio dans un moteur rollback, plus précisément dans la section « Separating Game State from Rendering ».

Il peut aussi y avoir des moments où l'on ne voudrait jamais rollback. Stallone mentionne combien les rollbacks sont extrêmement indésirables durant les événements où la caméra change drastiquement d'angle, commes les brutalities de Mortal Kombat X ou les transitions de stage d'Injustice 2. Cela signifie que ces jeux doivent empêcher de tels événements de s'exécuter tant que le joueur local n’est pas sûr qu'il se sont bien déroulés, et ne peuvent être annulés. Résoudre un tel problème demande un effort supplémentaire de débogage et de calibrage de la part des développeurs. Et donc évidemment, plus d’argent.

Enfin, il faut être pointilleux avec l'algorithme de prédiction, et copier proprement la dernière frame connue. Cela inclut des cas particuliers comme le maintien ou le relâchement de boutons sur une longue période. Si cette prédiction est ratée, cela peut donner lieu à de véritables aberrations, comme effectuer un coup qui n’a rien à voir avec sa manipulation.

Le rollback vaut-il le coup ?

Certes, le rollback demande des moyens et de gros efforts, mais cela ne veut pas dire qu’implémenter le rollback dans un jeu est forcément difficile. La réalité est quelque part entre « copier/coller GGPO dans votre jeu en un après-midi » et « investissez tout votre argent dans les systèmes de rollback ».

La difficulté dépend en grande partie du moment où l’implémentation du rollback commence. Ajouter le rollback dans un jeu après que ses systèmes aient été développés est souvent un véritable challenge. Quand NetherRealm Studios s’y est attelé pour Mortal Kombat X, le jeu avait déjà été livré. L’implémentation a pris environ 8 années-homme réparties sur 10 mois.

Après la sortie de Rivals of Aether, le très petit studio responsable de sa création a tenté pendant des années d’y implémenter un netcode rollback. Faute de moyens, le studio a finalement dû abandonner.

Complètement à l'opposé, il a fallu environ 2 semaines à Mike Zaimont, principal développeur sur Skullgirls, pour ajouter GGPO dans son jeu. Sa décision fut prise tôt dans le projet et Mike Zaimont avait l’avantage d’avoir créé son propre moteur. En résumé, plus la décision est prise tôt, moins cela coûte cher.

Sur le long terme, ces efforts peuvent être rentabilisés. Par exemple, sauvegarder et charger des états du jeu efficacement est utile pour d’autres modes tels que l’entraînement et les replays. Implémenter le rollback une fois, c’est aussi acquérir un savoir-faire pour de prochains jeux. Après avoir durement travaillé sur Mortal Kombat X, NetherRealm fait bénéficier à ses fans d'un jeu en ligne fluide pour tous ses titres basés sur le même moteur, notamment Injustice 2 et Mortal Kombat 11.

Dans le jeu vidéo, ce n’est pas toujours dans les vieux pots qu’on fait les meilleures soupes. Des techniques d'animation nécessitant un investissement plus important, comme la cinématique inverse, sont à présent un standard dans de nombreux projets.

Ce qui fut un coût supplémentaire il y a des années est aujourd’hui un standard qualitatif qui produit de la valeur. Celle du rollback est réelle et les studios ne devraient pas craindre d'en faire une priorité. Après tout, y'a-t-il plus important pour un jeu de combat moderne que de proposer une expérience en ligne stable, qui puisse connecter les communautés du monde entier ?