La façon la plus simple d'expliquer la prédiction client
Le déplacement en multijoueur paraît compliqué. Ce sont en réalité trois étapes : prédire, comparer, corriger.
Pourquoi c'est nécessaire
Sans autorité serveur, impossible d'empêcher la triche. Mais si vous envoyez chaque entrée au serveur en attendant la réponse, le joueur voit un personnage qui bouge 80 ms après l'appui. C'est injouable.
La solution : le client applique immédiatement le mouvement en local et envoie l'entrée au serveur en parallèle. Autrement dit, il prédit l'avenir.
Trois étapes
Prédire : le client simule l'entrée immédiatement et écrit le résultat dans un tampon d'historique indexé par numéro de tick.
Comparer : quand le serveur envoie son propre résultat, le client le compare à ce qu'il avait stocké pour ce tick.
Corriger : si l'écart tient dans la tolérance, on ne fait rien. Sinon on cale sur la position serveur et on rejoue toutes les entrées reçues depuis ce tick.
Les pièges en pratique
La simulation doit être déterministe. La même entrée depuis le même état initial doit donner le même résultat. Un pas de physique piloté par Time.deltaTime casse ça — utilisez un tick fixe.
Ne corrigez pas brutalement. Lisser les petits écarts sur quelques frames évite au joueur la sensation d'être téléporté.
Par où commencer
Construisez d'abord le déplacement solo sur un tick fixe et rendez-le déterministe. La couche réseau vient ensuite.
Ceux qui inversent cet ordre finissent par déboguer en même temps les bugs de déplacement et de synchronisation. C'est du vécu.