Si vous suivez l'actualité des jeux de combat, vous ne pouvez pas être passé à côté des plaintes de nombreux joueurs pros comme amateurs au niveau du online de piètre qualité de certains jeux phares (Street Fighter V, Tekken 7, Smash Ultimate...). Le rollback est souvent avancé comme une solution potentielle, mais que signifie donc ce terme ?
Les jeux de combat n'ont jamais eu vraiment eu pour vocation de se pratiquer en ligne, mais entre joueurs regroupés physiquement. Avec la pandémie actuelle, cette tradition a forcément dû être remise en question, et de nombreuses faiblesses jusque-là peu mises en avant par les joueurs sont apparues. La situation du online de certains titres est devenue tellement invivable pour certains, que les moyens pour essayer d'alerter les développeurs n'ont pas manqué d'originalité. La consécration du problème fut sans doute lorsque l'EVO décida d'évincer la plupart des titres phares (ne gardant que Mortal Kombat XI) au profit d'autres jeux moins connus du grand public, mais tout aussi bien pensés et avec un netcode bien meilleur que les mastodontes du genre.
Quel type de netcode utiliser ? Un vrai casse tête pour les développeurs
Cri désespéré des fans de Smash Ultimate pour un bon online ; crédit @Le Pugilat des Étoiles
Le netcode est la façon dont deux ordinateurs distants essayant de jouer au même jeu, échangent leurs informations. Si les joueurs jouent en local, même sur deux machines différentes, chacune de leurs actions est traitée en même temps que celles de l'adversaire, ce n'est pas le cas en ligne. Pour différentes raisons (qualité de la connexion, si le joueur est en wi-fi ou pas, si plusieurs personnes utilisent la box simultanément, la distance physique par rapport à l'adversaire) les informations qu'un joueur envoie peuvent soit arriver avec un certain délai, soit n'être plus applicables à l'instant où l'adversaire les reçoit, voire simplement se perdre, et cela pour des dizaines de raisons différentes. Contrairement à la plupart des jeux en ligne, les jeux de combat n'ont pas réellement de serveurs dédiés, et les informations sont directement échangées entre les deux joueurs. Pour faire cela, deux méthodes existent aujourd'hui : le rollback et un netcode basé sur les délais.
- Lire aussi : Amélioration du mode online de Smash Ultimate
Avant d'expliquer comment fonctionne exactement chaque système, certains termes doivent être clarifiés. L'unité de mesure du temps dans ce type de jeu est la frame, c'est à dire une image. Les gens parlent souvent en FPS (Frame per Second) soit au nombre d'images par seconde. Un coup sortant frame 1, signifie que le coup touche instantanément dès que l'input est réalisé sans animations montrant le départ du coup (ces coups sont extrêmement rares, mais ce n'est pas ici le sujet). Pour simplifier les choses, nous allons considérer que chaque jeu se joue en 60 FPS, soit 60 images par secondes (ce n'est pas forcément le cas dans la pratique). Une frame correspond donc à environ 17 milisecondes (16,66666666... en réalité). Un jeu de combat fait également une boucle permanente qui doit prendre en compte (entre autres) les inputs des différents joueurs, s'il doit se passer une action non contrôlée par les joueurs à l'écran (disparition d'un projectile qui atteindrait sa distance maximale, etc.), ainsi qu'animer les combattants, effectuer des inputs pour un éventuel CPU, et vérifier qu'aucun combattant ne soit touché. Cette boucle doit être répétée à chaque frame pour chaque joueur quelle que soit la qualité de leur connexion.
Si cela ne pose aucun problème si deux joueurs jouent sur la même machine, ce n'est pas le cas lorsqu'ils jouent en ligne. Par exemple, une latence de 90ms signifie en gros que les informations mettent 45 ms à parvenir à l'autre ordinateur, créant un décalage d'à peu près trois frames. De plus, dans le cadre d'un jeu de combat, généralement chaque jeu fait tourner le combat en se synchronisant sur les actions de l'autre joueur, ce qui veut dire que généralement seuls les inputs sont envoyés d'un ordinateur à l'autre, et pas l'état géneral du jeu. C'est ce que l'on appelle le lockstep network, mais cela ne veut pas dire que les autres informations ne sont pas échangées. Généralement chaque jeu vérifie de temps en temps qu'il est toujours bien synchronisé avec l'autre jeu. Par exemple si un joueur triche en utilisant un hack pour faire sortir ses boules de feu plus rapidement, la partie risque fort de s'arrêter car le jeu du joueur honnête sera désynchronisé par rapport à l'autre, car pour lui il sera impossible qu'une boule de feu sorte aussi vite.
Delay-based netcode
Un jeu de combat doit traiter les inputs de chaque joueur en même temps. Seulement, en online, avec les temps de transmission, les inputs du joueur 1 arrivent forcément un peu avant ceux du joueur 2 (et vice versa, l'ordinateur du joueur 2 reçoit d'abord les inputs de celui-ci avant ceux du joueur 1). Il faut donc une solution pour pallier ce problème. Le delay-based netcode décide donc de mettre un délai sur les inputs du joueur 1 correspondant au temps qu'il lui faut pour recevoir les inputs du joueur 2. S'il lui faut 45ms, le délai sera de 45ms, mais s'il faut 2 secondes, alors le délai sera alors de 2 secondes. En théorie chaque input arrivera donc en même temps, et sera exécuté sur la bonne frame.
Fonctionnement théorique d'un delay-based netcode ; crédit @Infilament et @Magicmoste
Si le délai est très lèger (2-3 frames) seuls les joueurs les plus expérimentés seront capables de le remarquer, mais cela influera sur leur plan de jeu. Seulement plus ce délai s'allonge, et plus nombreux sont les joueurs qui le remarquent, et plus cela a d'influence sur le plan de jeu de chacun d'eux. En plus cela suppose que la vitesse de transmission reste constante, hors ce n'est pas toujours le cas. Si un joueur a un pic de lag, alors l'autre le subira aussi vu que le jeu ne recevant plus d'informations, va freeze en attendant de les recevoir. La distance jouant également un grand rôle sur la vitesse de transmission, il devient compliqué de jouer contre des adversaires sur un fuseau horaire différent, rendant impossible la réunion des joueurs d'un même continent, voire d'un même pays si celui-ci est assez vaste. La qualité des connexions influe grandement sur l'expérience de jeu de chacun des joueurs. Ces différents problèmes font que les delay-based netcode ne fournissent généralement pas une bonne expérience aux joueurs.
Il reste cependant majoritairement utilisé, car il est plus simple à développer et ne change pas le fonctionnnement du jeu entre le mode offline et le mode online. Ce sont majoritairement les studios japonais qui l'utilisent, alors que les studios américains sont souvent passés au rollback comme notamment Killer Instinct et Mortal Kombat.
Le rollback
Contrairement au delay-based netcode, le rollback n'attend pas d'avoir reçu les informations de l'adversaire pour commencer à animer le personnage du joueur local. Lorsque la machine reçoit les inputs de l'adversaire, elle corrige le passé de façon si subtile qu'il est rare qu'un joueur le perçoive.
Fonctionnement théorique du rollback ; crédit @Infilament et @Magicmoste
Le lockstep network est ainsi brisé temporairement, car les deux joueurs ne voient pas forcément la même chose pendant quelques frames. Les deux jeux vont quand même se corriger mutuellement pour que la plupart du temps, les deux joueurs aient exactement la même chose à l'écran. Ainsi des inputs entrés seront toujours effectués, même si les informations de l'adversaire arrivent de façon décalée, contrairement au delay-based netcode, où certaines actions peuvent être "effacées" car entrées pendant que le jeu attendait les données de l'adversaire. De même, s'il y a un petit freeze, le rollback va également s'appliquer à ce moment-là, faisant disparaître certains soucis de connexion, notamment ceux liés au wi-fi.
- Lire aussi : Les personnages du Season Pass 5 sur SFV
Le rollback n'est pas non plus passif, et utilise des prédictions pour continuer à animer l'adversaire en attendant de recevoir les informations. S'il maintenait sa garde, le jeu va supposer qu'il va continuer à la maintenir, et ne va pas le faire revenir en position neutre. Dans le cas où les informations qui arrivent ensuite disent que le joueur a effectué une autre manipulation, le jeu exécutera alors un rollback, mais si la supposition était correcte, alors le jeu n'aura même pas besoin de s'auto-corriger. Cette fonctionnalité permet de rapprocher davantage le jeu online et offline. Cela reste assez basique, et les prédictions assument toutes que le joueur 2 a conservé les mêmes inputs pendant le temps où les informations manquaient. Certains problèmes peuvent quand même survenir, surtout quand des objets sont détruits à l'écran.
Par exemple, le joueur 1 lance une boule de feu sur le joueur 2 qui est en train de bloquer. Le rollback va considérer que le second joueur a continué à garder, et que la boule de feu est détruite en le touchant. Seulement si les informations reçues contredisent cette destruction, dans le cas où le joueur 2 utiliserait un coup invincible pour traverser la boule de feu, alors le jeu du joueur 1 doit régénérer cette boule qu'il a préalablement détruite. Ces difficultés sont contournées en conservant la boule en mémoire et en la remettant immédiatement quand les informations sont reçues. Seulement cela demande des ressources supplémentaires, et il faut prendre tout ça en compte dès le développement du jeu, ce qui rend le rollback plus cher à développer, malgré le fait que le code pour le rollback soit disponible en Open Source. Cette disponibilité a d'ailleurs permis à FIZZI#36 de développer un simulateur de Super Smash Bros. Melee avec du rollback.
Le câble Ethernet... Pensons-y.
Néanmoins, si le rollback permet de masquer les petits problèmes de lags et de connexion, il ne peut rien faire si les connexions sont trop mauvaises, et n'est pas une solution miracle. De plus les soucis de distance resteront présents, et comme sur tous les autres types de jeux, il sera difficile d'avoir des parties fluides contre des joueurs très éloignés géographiquement. De plus avec les récentes statistiques données par Harada comme quoi la moitié des joueurs de Tekken 7 jouent en wi-fi, il semblerait que pour l'instant la meilleure façon d'améliorer l'expérience online des joueurs soit d'utiliser un câble Ethernet.
Modifié le 08/08/2020 à 18:17
Le problème que j'ai quand je lis ce genre de choses, c'est que je me rends compte à quel point les arguments des développeurs japonais polluent la communication autour du rollback. Des jeux comme "Tribes" ou "Quake 3" à la fin des années 90 avaient du rollback, le Japon toujours pas.
S'ils ne font pas de rollback c'est tout simplement parce qu'ils n'ont pas encore compris à quel point c'était important, la soi-disant difficulté c'est un faux argument. SNK a fait des tests avec certains jeux, notamment Garou. Résultat, les ventes ont explosé de +1,185.7%.
"[...] Il faut prendre tout ça en compte dès le développement du jeu, ce qui rend le rollback plus cher à développer."
Une fois de plus, c'est du baratin made in Japan. NetherRealm a codé un rollback en 2 semaines alors qu'il n'avait jamais été question de ça durant le développement. Garou sur PS4 n'avait pas de rollback avant que CodeMystics l'implémente sur la demande d'SNK via le portage PC. Initialement c'était du delay. Le patch pirate de SFV c'est un amateur qui a codé ça en 48 heures dans son coin. De quelle difficulté parle-t-on ? Diabotical qui n'est pas encore sorti a 3 netcodes différents, qui ont été codés en quelques semaines. Des exemples il y en a des dizaines.
Le rollback c'est pas l'avenir des jeux de VS, c'est déjà le passé (GGPO c'est 2006) et le présent depuis 10 ans sur console. Ce sont les Japonais qui émergent et qui commencent seulement à prendre conscience qu'ils ont 15/20 ans de retard. Il y a quelques jours quand ils ont fait une table ronde sur Twitch, au moment où Nishitani annonce qu'ils ont du rollback pour Fighting EX Layer, un des autres devs explique que Arika est un petit studio et que de ce fait ils peuvent se permettre "d'expérimenter", ç'en dit long sur leur absence totale de compréhension...