Prédiction côté client et réconciliation avec un serveur faisant autorité

Réactivité malgré un serveur faisant autorité

Attendre un aller-retour avec le serveur avant d'afficher chaque déplacement donne l'impression que le contrôle local est retardé. La prédiction permet au client de réagir immédiatement aux entrées, tandis que le serveur reste seul à décider de l'état de jeu retenu. La difficulté consiste à intégrer une réponse tardive sans écarter les entrées plus récentes ni les appliquer deux fois.

Se caler sur l'instant acquitté

Numérotez les entrées et conservez les commandes non acquittées. À la réception d'une mise à jour faisant autorité, restaurez l'état correspondant, puis rejouez dans l'ordre les commandes restantes. [1] Comparez le résultat du serveur avec la prédiction faite pour ce même instant acquitté, et non avec l'état présent du client, qui est plus avancé. L'implémentation de la prédiction chez Valve effectue explicitement une comparaison d'erreur sur l'état acquitté. [2]

Exemple détaillé

Prenons, à titre d'illustration, un contrôleur unidimensionnel : le client a prédit les commandes 101, 102 et 103. Une mise à jour du serveur acquitte 101 à la position 5.0 m ; le client avait prédit 5.1 m après cette commande. Les commandes 102 et 103 déplacent chacune de 0.2 m à partir de l'état restauré.

On supprime l'historique des commandes jusqu'à 101 incluse, on restaure 5.0 m, puis on rejoue 102 et 103. Le présent réconcilié vaut alors 5.4 m, contre 5.5 m pour l'ancien présent prédit. La correction pertinente est de -0.1 m ; se contenter de ramener la position à 5.0 m effacerait aussi deux déplacements encore en attente.

Pour l'affichage, un décalage visuel distinct peut s'atténuer progressivement depuis l'ancienne apparence vers la position corrigée de la simulation. Les collisions et les prédictions futures doivent, elles, utiliser immédiatement l'état corrigé. Traitez une téléportation comme une discontinuité explicite, plutôt que de la lisser à travers les murs situés entre les deux positions.

Démarche d'implémentation

Définissez précisément ce que représente une commande d'entrée : tick, durée, boutons et éventuelles valeurs quantifiées. Partagez les règles de mouvement dès que c'est possible, et incluez tout l'état nécessaire au rejeu, comme la vitesse, le mode de déplacement et les temps de recharge. Une position seule peut ne pas suffire à reconstruire le résultat suivant.

Rendez les effets rejoués identifiables, afin qu'une prédiction répétée ne duplique ni les sons, ni les particules, ni les transactions. Le serveur valide la progression des commandes et les règles du jeu ; recevoir une position plausible de la part d'un client n'équivaut pas à simuler des entrées valides. Bornez l'historique conservé et définissez la reprise à appliquer lorsqu'une mise à jour est antérieure à l'état disponible.

Limites et validation

La prédiction ne peut pas connaître toutes les actions distantes ni les obstacles nouvellement révélés. Des corrections fréquentes peuvent indiquer des pas de simulation incohérents, un état de rejeu incomplet, des géométries différentes ou une incertitude réelle. Mesurez séparément la fréquence des corrections, leur amplitude, l'âge des commandes et le coût du rejeu.

Testez la perte, la duplication et le réordonnancement des mises à jour, les plateformes mobiles et les entrées pendant la réapparition. Rejetez les mises à jour obsolètes faisant autorité selon l'ordonnancement du protocole. Ne réglez le lissage visuel qu'après avoir confirmé que la simulation est correcte : une image fluide peut masquer un désaccord persistant sans le corriger.

Sources

[1] Client-side prediction and reconciliation — Gabriel Gambetta.

[2] Source SDK prediction implementation — Valve.