Share
Prédiction côté client est une technique utilisée dans les jeux multijoueurs pour réduire (l'apparition de) le retard: la machine de chaque joueur exécute sa propre simulation de ce qui devrait se passer ensuite, puis se synchronise rapidement avec la version "officielle" des événements du serveur. Dans cet article, nous allons voir pourquoi nous voudrions le faire en premier lieu.
Cette technique est devenue populaire lorsque des jeux en réseau comme Quake (dont le code source est disponible sur GitHub) ont commencé à apparaître. Les vitesses de mise en réseau disponibles à l'époque n'étaient pas aussi rapides - en particulier pour Internet -, donc essayer de garder tous les joueurs parfaitement synchronisés avec le serveur a donné des résultats médiocres..
Pour commencer à expliquer le problème, comprenons d’où il vient..
Au premier abord, le problème que la prédiction côté client résout n'existe tout simplement pas!
Tout est simple: le joueur déplace son personnage et le jeu indique au serveur la nouvelle position; le serveur transmet ensuite cette nouvelle position aux autres joueurs, dont les clients mettent à jour la position du premier joueur en jeu. C'est tout.
Mais que se passe-t-il si le joueur modifie le jeu pour lui faire passer une position différente du serveur?
La triche! Le serveur fera confiance à la nouvelle position de joueur (39, 4), même si le joueur est à une distance considérable, il mettra à jour les autres clients en conséquence. Le tricheur peut alors se téléporter efficacement, rendant le jeu injouable aux autres joueurs..
Puisque la triche est si facile, nous avons besoin d’une nouvelle solution. Et si le serveur avait un contrôle total sur l'état du jeu?
Avec le serveur faisant autorité version du jeu, le flux ressemblera à ceci:
Ici, le client dit au serveur: "Je veux déplacer le personnage vers la droite"; le serveur traite cela et décide que cela signifie que le personnage doit maintenant être à (dix); le serveur dit ensuite à tous les clients des joueurs que le personnage du premier joueur doit être à (dix); et tous les joueurs voient le personnage passer à la nouvelle position.
Problème résolu, non? Pas entièrement…
Le problème de téléportation a été en grande partie évité, mais le problème de latence a été introduit. Le client doit attendre la réponse du serveur concernant son intention de se déplacer avant d'afficher le mouvement au joueur. Ce flux de travail rend le jeu assez lent sur les connexions moyennes et presque injouable sur les pauvres.
La prévision côté client affine le modèle ci-dessus. Au cours de la phase où le client a envoyé l’intention et attend la réponse du serveur, le mouvement qu’il affichera sera affiché. prédit qui va se passer:
Cela évite la sensation de décalage en supprimant le temps d'attente entre l'entrée du lecteur et la sortie affichée.
La simulation effectuée sur le client devrait avoir le même résultat que celle effectuée sur le serveur, mais il existe des exceptions. Par exemple, si deux joueurs tentent de se déplacer simultanément au même endroit, un joueur en sortira forcé. Lorsque la réponse du serveur est envoyée au client, celui-ci doit simplement confirmer qu'il correspond à sa propre prédiction. Si ce n'est pas le cas, le client doit utiliser la réponse du serveur comme source d'informations véritable et ignorer la prédiction pour corriger l'état du client..
J'espère que cet article vous aidera à comprendre cette technique utile pour les jeux en réseau qui doivent éviter la majorité des problèmes de triche tout en évitant les retards..
Accentsconagua