Empêcher la tricherie
Si les Clients disent à l'hôte où ils sont et ce qu'ils font dans le jeu, et que l'hôte leur fait confiance, les Clients peuvent tricher. Il leur suffirait d'envoyer soudainement des données indiquant qu'ils se trouvent de l'autre côté d'un mur, ou qu'ils ont attaqué un joueur qu'ils ne pouvaient pas atteindre, etc. Pour éviter cela, les Clients ne communiquent à l'hôte que leurs entrées, par exemple les touches fléchées qu'ils maintiennent enfoncées. L'hôte reçoit ces informations et commence à déplacer le joueur, et renvoie des données indiquant au joueur où il pense se trouver.
Le problème immédiat est que cela ajoute un délai à toutes les entrées du joueur. Si un joueur appuie sur "Gauche" avec une latence de 100 ms, l'hôte recevra cette entrée 100 ms après avoir appuyé dessus. Il faudra ensuite 100 ms supplémentaires pour que la mise à jour de l'hôte avec la nouvelle position du joueur revienne. Cela signifie que toutes les commandes de l'homologue sont très lentes, ne prenant effet qu'après une fraction de seconde significative. Pour résoudre ce problème, le jeu local de l'homologue utilise la prédiction d'entrée locale.
Prédiction d'entrée locale
Au lieu de cela, le fait d'appuyer à gauche enverra un message à l'hôte indiquant que l'entrée a été pressée, puis le jeu local de ce joueur commencera à le déplacer de toute façon, sans attendre la confirmation de l'hôte ! Puisque l'hôte et le Client exécutent le même jeu, ils correspondent généralement assez bien. Le joueur obtient alors des commandes qui lui semblent réactives, et il ne peut toujours pas tricher : il ne fait qu'envoyer ses entrées, et ne peut pas prétendre être ailleurs. Même s'il a piraté son jeu local, cela ne fait que le désavantager, car tout ce qu'il peut faire, c'est se montrer au mauvais endroit par rapport à l'hôte.
Le joueur du Client déviera cependant inévitablement de la position dans laquelle l'hôte le voit. De nombreuses petites erreurs peuvent s'accumuler dans la synchronisation du réseau, la synchronisation de la fréquence d'images, les mesures du temps delta, etc. Le Client reçoit toujours des messages de l'hôte indiquant sa position, mais ces messages sont retardés. Dans l'exemple précédent, le Client reçoit sa position de l'hôte avec un retard total de 200 ms. Pour corriger les écarts, le moteur multijoueur examine l'historique de l'objet et compare où il se trouvait il y a 200 ms. En d'autres termes, les corrections sont effectuées en regardant où l'objet se trouvait dans le passé, en tenant compte de la latence vers l'hôte. Si l'objet se trouve au mauvais endroit, le moteur multijoueur le déplace progressivement pour compenser. Cela se produit au fil du temps pour essayer de le rendre moins perceptible. Dans les cas extrêmes, une correction importante et perceptible sera nécessaire, mais dans de bonnes conditions de réseau, le mouvement correspond étroitement et les petits ajustements sont effectués d'une manière qui est difficile à repérer.
Il est intéressant de noter que cela ne se limite pas aux positions. Le moteur multijoueur a la capacité de faire toute cette synchronisation avec n'importe quelle variable d'instance, et pas seulement avec les coordonnées X et Y.
Lag
Dans des conditions de réseau médiocres, les effets sur la jouabilité peuvent être évidents. Les joueurs appellent communément ces problèmes le "lag". Il peut s'agir de mouvements irréguliers (lorsque le tampon de mise à jour de 80 ms est vide), de sauts ou de discontinuités dans le jeu (lorsqu'il y a perte de paquets et que la mise à jour suivante modifie considérablement l'état du jeu), d'un changement soudain de position du joueur (lorsque la prédiction d'entrée locale rencontre une erreur importante) ou de conséquences qui semblent injustes (généralement le résultat du fait que chaque joueur voit le jeu avec un retard différent et que l'hôte prend une décision autoritaire en faveur d'un Client particulier).
Malheureusement, il n'y a pas de bonne solution pour éviter définitivement ces problèmes, si ce n'est de trouver une connexion Internet de meilleure qualité. Ces problèmes ne se produisent généralement que dans des circonstances graves, comme une perte totale de paquets pendant quelques secondes, ou des changements temporaires soudains et extrêmes dans la latence ou la PDV. Dans de tels cas, il est presque impossible pour les différentes techniques de compensation de les couvrir. C'est parfois simplement la réalité de la communication sur Internet.