Rollback netcode : le mécanisme des jeux de combat en ligne

Pourquoi un coup qui vous touche à l'écran disparaît parfois une fraction de seconde plus tard, comme si la partie revenait en arrière ? Ce n'est pas un bug réseau. C'est le rollback netcode qui fait exactement ce pour quoi il a été conçu : deviner, simuler, et se corriger quand il s'est trompé.

Le rollback netcode prédit les entrées du joueur distant pour simuler la frame suivante sans attendre le réseau. Si la prédiction était fausse, le jeu revient à l'état correct et rejoue les frames avec les vraies entrées. Le delay-based, à l'inverse, retarde tout le monde au rythme du plus mauvais ping.

Le problème que le delay-based ne résout pas#

Avant le rollback, la solution standard consistait à synchroniser les deux machines en retardant artificiellement les entrées locales, le tout calé sur le joueur ayant le ping le plus élevé. C'est le principe du delay-based netcode, décrit par le site basgrospoing.fr dans sa traduction de l'analyse d'Infil sur le netcode des jeux de combat.

Ça marche, mais ça coûte cher en confort. Chaque input attend son tour avant de s'exécuter, et cette attente se ressent directement sur la précision d'un enchaînement. Le site actugaming.net résume le contraste par la comparaison : le rollback laisse la machine locale prédire la suite pour ne pas ralentir l'action, puis corrige si besoin, alors que le delay-based ralentit tout le monde au niveau du pire ping. Deux philosophies opposées pour un même problème, celui du temps de trajet réseau qui ne descendra jamais à zéro.

Sous le capot : prédire, simuler, corriger#

Passons au mécanisme lui-même, celui que la plupart des articles grand public survolent. D'après la documentation du SDK GGPO, disponible sur son dépôt GitHub sous licence MIT, le principe tient en une phrase : le système emploie la prédiction d'entrées et l'exécution spéculative pour envoyer les inputs immédiatement, donnant l'illusion d'un réseau à latence nulle.

Concrètement, comment le jeu devine-t-il ce que va faire l'adversaire avant de le savoir ? La méthode documentée par Infil est presque naïve, et c'est ce qui la rend élégante : le système duplique la dernière entrée connue du joueur distant, en pariant qu'un joueur de jeu de combat ne change pas de direction en continu. Le pari est raisonnable : un changement de direction survient environ 5 fois par seconde dans ce type de jeu, ce qui veut dire qu'une transmission réellement nécessaire ne concerne qu'environ 8 % du temps de jeu. Le reste, c'est de la duplication pure.

Si la vraie entrée arrive et confirme la prédiction, rien ne se voit. Si elle la contredit, Wikipédia décrit la mécanique sans détour dans son article consacré à GGPO : le jeu revient à l'état correct précédent, puis rejoue les entrées révisées de tous les joueurs jusqu'à la frame courante. C'est cette resimulation silencieuse, invisible à l'œil nu la plupart du temps, qui est le vrai travail du rollback.

Ce que ça coûte vraiment en CPU#

Prédire et resimuler n'est pas gratuit. La documentation d'Easel Games pose les deux exigences techniques qui rendent l'ensemble possible, et le chiffrage suivant vient du blog SnapNet, qui a détaillé le coût réel de l'opération. Seule la dernière ligne du tableau vient d'ailleurs, du guide d'Infil.

Élément	Valeur documentée
Budget total par frame à 60 images par seconde	16,66 ms
Budget CPU consommé pour resimuler une frame	environ 1,1 ms
Frames resimulées pour un aller-retour réseau de 100 ms	3 à 4 frames (jusqu'à 6 selon l'exemple cité)
Seuil au-delà duquel la prédiction devient injouable	100 à 150 ms

Ce tableau dit une chose simple : tant que le budget de resimulation reste largement sous le budget total de la frame, le rollback tient. Le problème arrive quand le temps nécessaire pour revenir en arrière et resimuler dépasse ce budget disponible. SnapNet décrit ce point de bascule, celui où la simulation ne rattrape plus jamais le temps réel : le spiral of death. C'est exactement ce qui arrive à votre framerate, et accessoirement à votre moral, quand un tournoi en ligne tourne mal.

Pourquoi c'est dur à greffer sur un moteur existant#

Voici la partie que je trouve la plus intéressante en tant que dev, et celle que le SERP francophone n'aborde presque jamais : le rollback impose deux contraintes strictes au moteur, pas seulement au code réseau.

Premièrement, le déterminisme total. La documentation d'Easel Games est claire : mêmes entrées, mêmes sorties, sur toutes les machines, à chaque fois. Deuxièmement, un état de jeu entièrement sérialisable, capable d'être sauvegardé puis restauré à volonté pour revenir en arrière et resimuler depuis ce point.

Ce n'est pas une fonctionnalité qu'on ajoute dans un coin du moteur. Ces deux exigences doivent être respectées à 100 % dans toute la base de code, et la moindre entorse produit des bugs de désynchronisation, silencieux jusqu'à ce qu'ils ne le soient plus. Or la plupart des moteurs de jeu ne garantissent pas ce déterminisme nativement. Si vous avez déjà comparé un moteur comme Unity face à Unreal Engine sur la gestion de la physique ou du floating point, vous voyez déjà où le bât blesse : le moindre calcul non déterministe entre deux machines casse toute la mécanique.

L'histoire GGPO : d'un problème irritant à une licence gratuite#

GGPO, ça sonne comme un sigle technique. C'en est un, mais il cache une private joke : selon Shacknews, il signifie « Good Game, Peace Out ».

Derrière le SDK, un nom : Tony Cannon, cofondateur du site communautaire Shoryuken et de l'Evolution Championship Series, l'EVO, fondée en 1996. D'après Wikipédia, Cannon aurait développé la première version de GGPO fin 2006, en réaction à la qualité jugée mauvaise du netcode de la réédition Xbox 360 de Street Fighter II: Hyper Fighting, sortie la même année. Difficile de vérifier l'anecdote au-delà de cette source, mais la frustration d'un joueur compétitif à l'origine d'un SDK devenu standard, ça a du sens.

Le 9 octobre 2019, Cannon annonce le passage de GGPO en open source sous licence MIT. Depuis, le SDK est gratuit pour un usage commercial comme non commercial, ce qui a changé la donne pour les petits studios qui n'avaient pas les moyens de développer leur propre solution de resimulation. Street Fighter III: 3rd Strike Online Edition en 2011, Skullgirls en 2012, Rising Thunder en 2015, The King of Fighters XV en 2022, Under Night In-Birth II en 2024 : la liste documentée par Wikipédia s'étale sur plus d'une décennie de jeux de combat qui s'appuient dessus.

Guilty Gear Xrd Rev 2 : une bascule datée précisément#

Un cas concret pour ancrer tout ça dans le temps. En février 2020, basgrospoing.fr recensait encore Guilty Gear Xrd parmi les jeux en delay-based. Le 20 janvier 2023, Arc System Works déploie une mise à jour qui bascule Guilty Gear Xrd Rev 2 sur PC vers le rollback netcode, précédée d'une bêta publique ouverte dès octobre 2022, d'après Gematsu.

Trois ans entre les deux relevés, pour le même jeu. Ce genre de bascule tardive, longtemps après la sortie initiale, illustre bien ce qui est en jeu techniquement. ScreenRant recense un autre cas comparable, Street Fighter V, où le rollback a lui aussi été ajouté après coup, preuve que la greffe est possible sur un moteur existant, mais visiblement pas sans un chantier conséquent. Si votre studio travaille avec un moteur open source comme Godot, c'est le genre de contrainte à anticiper avant d'écrire la première ligne de code réseau, pas après.

Les limites que le rollback ne cache jamais complètement#

Le rollback reste une illusion. SnapNet le rappelle sans détour : il ne réduit pas la latence réseau brute et n'empêche pas la perte de paquets, il masque seulement les symptômes d'une connexion médiocre. Quand l'écart entre la position affichée et la position réellement recalculée devient trop grand, à cause d'une forte perte de paquets ou de jitter, la correction se voit. C'est la fameuse téléportation, ou rubber-banding, du personnage à l'écran.

Sur ce point, j'hésite encore à trancher entre deux écoles chez les devs indé que je croise en game jam : certains préfèrent masquer le glitch visuellement au prix d'un peu de triche graphique, d'autres assument la téléportation brute plutôt que de complexifier encore l'interpolation. Aucune des deux n'est fausse, mais aucune ne résout le vrai problème, qui reste votre connexion.

Pour un usage compétitif, la meilleure protection reste en amont du jeu lui-même : une infrastructure réseau qui limite la variance, que ce soit via un serveur dédié bien hébergé ou une connexion qui encaisse mieux la charge, comme le permet le Wi-Fi 7 sur la latence. Le rollback compense un mauvais réseau, il ne le remplace pas.

FAQ#

Le rollback netcode élimine-t-il la latence réseau ?#

Non. D'après SnapNet, le rollback ne réduit pas la latence réseau brute et n'empêche pas la perte de paquets. Il masque seulement les symptômes d'une connexion médiocre en donnant l'illusion d'une réaction instantanée, mais le trajet réel des données reste inchangé.

Pourquoi certains jeux ne peuvent-ils pas ajouter le rollback facilement après leur sortie ?#

Parce que le rollback exige un déterminisme total et un état de jeu entièrement sérialisable, respectés à 100 % dans toute la base de code, d'après Easel Games. La plupart des moteurs ne garantissent pas ça nativement, la moindre entorse provoque des désynchronisations.

Que se passe-t-il si la latence dépasse le seuil supportable ?#

D'après le guide d'Infil, au-delà de 100 à 150 ms de prédiction, l'expérience devient rapidement injouable. Le décalage entre ce que prédit le jeu et la réalité devient trop grand pour être corrigé sans que le joueur le remarque en permanence.

Qu'est-ce que GGPO exactement ?#

GGPO est un SDK de rollback netcode créé par Tony Cannon, cofondateur de Shoryuken et de l'EVO, passé open source sous licence MIT le 9 octobre 2019. Son sigle signifie « Good Game, Peace Out », selon Shacknews, et il équipe des jeux de combat depuis 2011.

Un jeu peut-il combiner delay-based et rollback ?#

D'après SnapNet, certaines implémentations combinent un petit délai fixe avec le rollback, qui ne s'active que si la latence réseau dépasse ce tampon de base. C'est une approche hybride pensée pour limiter les corrections visibles sur les connexions déjà correctes.

Le rollback netcode n'a rien de magique : c'est un pari statistique sur ce que vont taper vos adversaires, corrigé en temps réel quand le pari échoue. Ce qui distingue un bon jeu de combat en ligne, c'est un moteur pensé pour le déterminisme dès le premier jour. Si votre prochain projet vise le milieu compétitif ou simplement une base de joueurs en ligne exigeante, ce choix se fait à l'architecture, pas en patch correctif.