Prédire son propre mouvement

Vous agissez sur vos propres entrées avant que le serveur ait répondu, et là où les deux divergent, votre client se corrige. Une erreur ici ne coûte qu’une petite correction visuelle, rien de plus : c’est pourquoi, des trois mécanismes de prédiction, c’est le seul où l’on peut se montrer agressif sans risque.

La prédiction rejoue les règles déclarées, elle n’en fait pas une seconde copie

Votre client ne fait pas tourner une implémentation parallèle de votre mouvement. Il exécute le même modèle déclaré que la plateforme — ce modèle appartient à Locomotion, et la prédiction se contente de l’appliquer plus tôt. C’est pour cela que les deux côtés sont d’accord la plupart du temps : un seul jeu de règles, appliqué deux fois.

Il n’y a donc aucune opération « prédire » à appeler, ni aucune opération « corriger ». La prédiction a lieu parce que l’aspect a été déclaré prédictible.

Ce qui se prédit se déclare aspect par aspect

La prédictibilité est une déclaration portée par l’aspect de l’entité, pas un interrupteur global :

Un aspect que le client sait calculer — la position sous vos propres entrées — peut être prédit.
Un aspect que l’autorité modifie selon des règles que le client n’a pas ne doit pas être prédit. Si le client ne peut pas le déduire, le deviner produit un rollback que le joueur perçoit comme un mensonge du jeu.

Le protocole de correction, et les deux valeurs qui le façonnent

L’état faisant autorité arrive avec le numéro de la dernière entrée qu’il a appliquée : votre client sait donc exactement quelle part de son tampon reste non confirmée. À partir de là :

Il accepte l’état faisant autorité.
Il rejoue les entrées en tampon postérieures à celle que cet état confirme.
Il réconcilie le résultat avec ce qu’il affichait déjà.

Deux valeurs déclarées décident du ressenti. Le seuil de divergence : en dessous, la correction est lissée ; au-dessus, votre client se recale d’un coup et rejoue. Et la borne du tampon d’entrées non confirmées : son débordement n’a rien d’indéfini — la dégradation est déclarée et observable, si bien qu’un client sur une mauvaise connexion sait qu’il a cessé de prédire au lieu de dériver sans rien dire.

La divergence est observable par le client qui l’a subie, et par lui seul. Vous pouvez savoir que votre prédiction a été corrigée, et de combien — utile pour le réglage, et pour afficher au joueur un indicateur de connexion fiable. Vous ne pouvez pas lire la divergence d’un autre : l’ampleur d’une erreur de prédiction renseigne sur sa connexion, pas sur le jeu. La correction se fait côté client, car l’état de l’autorité est justement ce que tous les autres voyaient déjà.

Si vous venez d’ailleurs

Mover 2.0 d’Unreal. La forme vous sera familière : entrées horodatées au tick, un modèle de mouvement, des corrections venues de l’autorité. La différence tient à l’endroit où vit le modèle — ici, vous le déclarez et la plateforme le simule : vous n’avez donc aucun composant de mouvement de notre part à dériver ni à remplacer.
Le netcode à rollback et rejeu, comme dans Photon Fusion. Rejouer vos propres entrées non confirmées après une correction, c’est le même mécanisme, et il est entièrement présent ici. Ce qui est volontairement absent, c’est la réexécution du monde après coup — voir Lag Compensation pour ce qui se passe à la place, et pourquoi.

Ce que cette page ne couvre pas

Les entités des autres joueurs ne sont pas prédites, elles sont affichées — c’est l’objet de Afficher les autres joueurs. Juger un tir dans la chronologie du tireur est un mécanisme serveur, décrit dans Lag Compensation. Et aucun des trois ne s’applique quand le mode d’autorité de la salle (room) est externe : le tick appartient alors à celui qui l’exécute, et la prédiction aussi.