Prédiction côté client
La prédiction côté client exécute la simulation localement dès qu'un joueur appuie sur une touche, au lieu d'attendre que le serveur la confirme. Le mouvement semble instantané. Lorsque l'état faisant autorité du serveur arrive et diverge, le client se réconcilie pour s'y conformer. C'est de cette réconciliation que proviennent les corrections visibles.
Aussi appelé
prédiction
,
Que prédit la prédiction côté client ?
Généralement, ce que le joueur contrôle. Lorsqu'une touche est enfoncée, le client exécute le même code de jeu que le serveur exécutera et affiche immédiatement le résultat : le personnage se déplace, la caméra tourne, l'animation de l'arme se lance. L'action reste envoyée au serveur, qui conserve l'autorité sur ce qui s'est passé.
Ce qui est prédit d'autre dépend du jeu et du netcode. De nombreuses bibliothèques prédisent ce que le joueur local contrôle et affichent tous les autres joueurs entre les mises à jour du serveur, ce que l'on appelle l'interpolation. Le composant Character Movement d'Unreal fonctionne de cette manière, et le Netcode for Entities d'Unity le propose sous la forme d'un mode « Owner Predicted », aux côtés d'objets entièrement prédits et entièrement interpolés (documentation Unity). Les jeux de combat et de sport prédisent souvent chaque joueur, et les projectiles qu'un joueur doit esquiver sont également souvent prédits (SnapNet).
Certains résultats sont généralement laissés au serveur : savoir si un tir a touché quelqu'un d'autre, combien de dégâts il a infligés, qui a atteint un objet contesté en premier. Le client peut afficher un marqueur de coup immédiatement, mais le serveur décide s'il est valide. C'est pourquoi la prédiction ne redonne pas l'autorité au client. L'estimation est affichée à l'écran, elle n'est jamais acceptée comme un fait.
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
La désynchronisation est un désaccord, pas un retard : Le lag signifie que l'information arrive tardivement. La désynchronisation signifie que deux machines détiennent des versions différentes du même monde, ce qui est une défaillance distincte avec des corrections distinctes.
Il en existe deux types distincts : La désynchronisation de réplication, où un serveur faisant autorité corrige un client qui a mal deviné, et la désynchronisation de déterminisme, où les simulations des pairs divergent et la session s'arrête carrément.
L'effet d'élastique (rubberbanding) a deux leviers : La fréquence à laquelle le client fait de mauvaises prédictions, qui dépend de la latence, et la visibilité de chaque correction, qui dépend du netcode. Modifiez l'un ou l'autre de ces leviers et les joueurs le verront moins.
Le tick rate (taux de rafraîchissement) n'est aucun de ces leviers : L'augmenter ne rend pas les prédictions plus précises, et sur une connexion qui perd déjà des paquets, cela aggrave les artefacts.
« Une désynchronisation s'est produite » est un échec de checksum (somme de contrôle) : Les jeux en lockstep comparent les hachages d'état à chaque tour, donc un seul flottant divergent ou un seul appel aléatoire non synchronisé met fin à la session.
Comment fonctionne la réconciliation des serveurs ?
La prédiction du client et la réponse du serveur ont toujours un temps de retard correspondant à un aller-retour. Au moment où le résultat du serveur pour une entrée arrive, le joueur a déjà appuyé sur d'autres touches. La réconciliation permet de synchroniser à nouveau les deux sans perdre ces touches.
Numéroter chaque entrée. Le client marque chaque entrée d'un numéro de séquence et en conserve une copie.
Le serveur répond par un numéro. Sa mise à jour contient l'état et la dernière entrée qu'il a traitée.
Réinitialisation et rejeu. Le client se réinitialise à l'état du serveur, puis applique de nouveau chaque entrée que le serveur n'a pas encore traitée, ce qui le ramène au présent (Gabriel Gambetta, Fast-Paced Multiplayer).
Le système de déplacement d'Unreal suit les mêmes étapes avec des « mouvements sauvegardés » : le serveur réexécute chaque mouvement, envoie une correction lorsque son résultat diffère, et le client rejoue ses mouvements sauvegardés à partir de ce moment-là (Epic documentation). SnapNet décrit la même boucle par image : entrée envoyée à l'image 1, réponse reçue à l'image 4, puis « retour en arrière de la simulation du client aux résultats de l'image 1, nouvelle simulation des images 2 et 3, et enfin simulation de la nouvelle image » (SnapNet).
Lorsque la prédiction était correcte, le rejeu aboutit là où le joueur se trouve déjà et rien de visible ne se produit. Sans le rejeu, le personnage reviendrait brusquement à la position antérieure du serveur à chaque mise à jour.
Pourquoi les joueurs prédits sont-ils corrigés ?
Parce que le client a fait des prédictions sans connaître certains éléments dont le serveur disposait : un autre joueur sur le chemin, un recul, ou une commande que le serveur n'a jamais reçue en raison d'un paquet perdu. Une correction se manifeste par un personnage qui se téléporte ou glisse vers l'arrière, ce que les joueurs appellent le rubberbanding (ou effet d'élastique).
Le temps de trajet aller-retour détermine l'ampleur des erreurs possibles. À 60 étapes de simulation par seconde, une étape dure environ 16,7 ms. Ainsi, un trajet aller-retour de 30 ms laisse environ deux étapes en attente sur le serveur, et un trajet de 180 ms en laisse environ onze. Plus il y a d'étapes non confirmées, plus le risque d'erreur de prédiction est élevé, et plus la correction sera importante si l'erreur se produit.
Le netcode peut atténuer ce phénomène. Les corrections peuvent être lissées sur quelques images plutôt que d'être appliquées instantanément, et certaines bibliothèques ajoutent un délai de saisie à mesure que la latence augmente afin que le client ait moins de choses à prédire. Avec les paramètres par défaut de SnapNet, « à mesure que la latence d'un joueur dépasse 150 ms, ses commandes deviennent progressivement plus lourdes, mais le jeu reste jouable ». Chaque technique a un coût : le lissage affiche brièvement une position incorrecte, le délai de saisie rend les commandes moins réactives, et rejouer davantage d'étapes « engendre un coût CPU important » (SnapNet).
Un mot de notre sponsor (nous-mêmes !)
La majeure partie du lag provient de la distance, non du code. L'Edge Cloud d'Edgegap est un réseau distribué disposant de plus de 615 emplacements disponibles sur demande, garantissant que chaque partie se déroule au meilleur endroit possible pour ses joueurs. Des tests indépendants sur le trafic d'un studio en direct ont mesuré une baisse de 58 % du temps de trajet aller-retour moyen par rapport au cloud public.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
Estimations plus précises, confrontations plus équitables
La prédiction fonctionne au mieux lorsqu'elle a moins de conjectures à faire. Chaque milliseconde de trajet aller-retour est un temps où le client devance le serveur, et chaque entrée dans cette fenêtre temporelle est susceptible d'être corrigée par le serveur. Raccourcissez ce trajet et les corrections ont tendance à devenir plus petites et plus rares, quel que soit le code réseau utilisé par le jeu.
La distance détermine également l'équité. Un joueur situé à 150 ms du serveur est susceptible d'être corrigé plus souvent qu'un joueur situé à 20 ms, pour un même style de jeu. Démarrer le serveur de chaque match au meilleur emplacement disponible pour l'ensemble de ses joueurs réduit cet écart : le placement de serveurs dédiés a permis de mesurer une réduction moyenne de la latence de 58 % par rapport au placement de relais sur le cloud public (données de la plateforme, 18 septembre 2026).
Rivals of Aether 2 associe la prédiction et le rollback de SnapNet à des serveurs situés à proximité des joueurs de chaque match, avec un objectif de ping inférieur à 20 ms, ce que l'étude de cas explique en détail.
,
