Il existe différentes méthodes pour réduire ou masquer les retards, bien que beaucoup d’entre elles aient leurs inconvénients et ne soient pas applicables dans tous les cas. Si la synchronisation n’est pas possible par le jeu lui-même, les clients peuvent choisir de jouer sur des serveurs géographiquement proches d’eux afin de réduire les latences, ou les serveurs peuvent simplement choisir d’abandonner les clients ayant des latences élevées afin d’éviter d’avoir à gérer les problèmes qui en résultent. Toutefois, ces solutions sont loin d’être optimales. Au lieu de cela, les jeux seront souvent conçus en tenant compte de la compensation du décalage.
De nombreux problèmes peuvent être résolus simplement en permettant aux clients de garder une trace de leur propre état et d’envoyer des états absolus au serveur ou directement aux autres clients. Par exemple, le client peut indiquer exactement à quelle position se trouve le personnage d’un joueur ou qui le personnage a tiré. Cette solution fonctionne et élimine pratiquement tous les problèmes liés au décalage. Malheureusement, elle repose également sur l’hypothèse que le client est honnête. Rien n’empêche un joueur de modifier les données qu’il envoie, directement au niveau du client ou indirectement via un proxy, afin de s’assurer qu’il atteindra toujours ses cibles. Dans les jeux en ligne, le risque de tricherie peut rendre cette solution irréalisable, et les clients seront limités à l’envoi d’états relatifs (c’est-à-dire sur quel vecteur il s’est déplacé ou a tiré).
Client-sideEdit
Comme les clients ne sont normalement pas autorisés à définir l’état principal du jeu, mais le reçoivent plutôt du serveur, la tâche principale de la compensation côté client est de rendre le monde virtuel aussi précisément que possible. Comme les mises à jour arrivent avec un certain retard et peuvent même être abandonnées, il est parfois nécessaire que le client prédise le déroulement du jeu. L’état étant mis à jour par étapes discrètes, le client doit être capable d’estimer un mouvement sur la base des échantillons disponibles. Deux méthodes de base peuvent être utilisées pour accomplir cela ; l’extrapolation et l’interpolation.
L’extrapolation est une tentative d’estimation d’un état de jeu futur. Dès qu’un paquet en provenance du serveur est reçu, la position d’un objet est mise à jour avec la nouvelle position. Dans l’attente de la prochaine mise à jour, la prochaine position est extrapolée sur la base de la position actuelle et du mouvement au moment de la mise à jour. Essentiellement, le client suppose qu’un objet en mouvement continuera dans la même direction. Lorsqu’un nouveau paquet est reçu, la position peut être légèrement corrigée.
L’interpolation fonctionne essentiellement en mettant en mémoire tampon un état de jeu et en rendant l’état de jeu au joueur avec un léger retard constant. Lorsqu’un paquet du serveur arrive, au lieu de mettre à jour immédiatement la position d’un objet, le client commence à interpoler la position, en partant de la dernière position connue. Pendant un intervalle d’interpolation, l’objet sera rendu en se déplaçant doucement entre les deux positions. Idéalement, cet intervalle devrait correspondre exactement au délai entre les paquets, mais en raison de la perte et du délai variable, c’est rarement le cas.
Les deux méthodes ont des avantages et des inconvénients.
- L’interpolation garantit que les objets se déplaceront uniquement entre des positions valides et produira de bons résultats avec un délai constant et sans perte. Si des paquets abandonnés ou hors de l’ordre débordent du tampon d’interpolation, le client devra soit geler l’objet en position jusqu’à ce qu’un nouveau paquet arrive, soit se rabattre sur l’extrapolation à la place. L’inconvénient de l’interpolation est qu’elle entraîne un rendu du monde avec une latence supplémentaire, ce qui augmente la nécessité d’implémenter une forme de compensation du décalage.
- Le problème de l’extrapolation des positions est assez évident : il est impossible de prédire l’avenir avec précision. Il rendra le mouvement correctement seulement si le mouvement est constant, mais ce ne sera pas toujours le cas. Les joueurs peuvent changer de vitesse et de direction de manière aléatoire. Cela peut entraîner une petite quantité de « distorsion » lorsque de nouvelles mises à jour arrivent et que les positions estimées sont corrigées, et également causer des problèmes pour la détection des coups, car les joueurs peuvent être rendus dans des positions dans lesquelles ils ne sont pas réellement.
Souvent, afin de permettre un gameplay fluide, le client est autorisé à faire des changements doux à l’état de jeu. Alors que le serveur peut finalement garder la trace des munitions, de la santé, de la position, etc., le client peut être autorisé à prédire le nouvel état de jeu côté serveur en fonction des actions du joueur, par exemple en permettant à un joueur de commencer à se déplacer avant que le serveur n’ait répondu à la commande. Ces changements seront généralement acceptés dans des conditions normales et rendront le retard essentiellement transparent. Les problèmes ne surviendront que dans le cas de délais élevés ou de pertes, lorsque les prédictions du client sont très sensiblement annulées par le serveur. Parfois, dans le cas de différences mineures, le serveur peut même permettre des changements « incorrects » de l’état en fonction des mises à jour du client.
Modification côté serveur
Contrairement aux clients, le serveur connaît l’état de jeu actuel exact, et en tant que tel, la prédiction est inutile. L’objectif principal de la compensation du décalage côté serveur est plutôt de fournir des effets précis des actions du client. C’est important parce qu’au moment où la commande d’un joueur arrive, le temps aura passé et le monde ne sera plus dans l’état que le joueur a vu lorsqu’il a donné sa commande. Un exemple très explicite de ceci est la détection des coups pour les armes tirées dans les jeux de tir à la première personne, où les marges sont petites et peuvent potentiellement causer des problèmes importants si elles ne sont pas correctement gérées.
Rewind timeEdit
Une autre façon de traiter le problème est de stocker les états de jeu passés pendant une certaine durée, puis de rembobiner les emplacements du joueur lors du traitement d’une commande. Le serveur utilise la latence du joueur (y compris tout retard inhérent dû à l’interpolation ; voir ci-dessus) pour rembobiner le temps d’une quantité appropriée afin de déterminer ce que le client de tir a vu au moment où le tir a été effectué. En général, le serveur verra que le client a tiré à l’ancienne position de la cible et l’a donc touchée. Dans le pire des cas, un joueur sera tellement en retard que le serveur sera à court de données historiques et qu’il devra commencer à diriger ses cibles.
C’est une solution WYSIWYG qui permet aux joueurs de viser directement ce qu’ils voient. Mais le prix à payer est une aggravation des effets de la latence lorsqu’un joueur est sous le feu : non seulement sa propre latence joue un rôle, mais celle de son attaquant aussi. Dans de nombreuses situations, cela n’est pas perceptible, mais les joueurs qui viennent de se mettre à l’abri remarqueront qu’ils continuent à recevoir des messages de dommages/morts du serveur pendant plus longtemps que leur propre latence ne le justifie. Cela peut conduire plus souvent à l’impression (fausse) qu’ils ont été abattus à couvert et à l’impression (pas tout à fait inexacte) de « hitboxes laggy ».
Une question de conception qui se pose à propos du rembobinage est de savoir s’il faut arrêter de rembobiner les commandes laggy d’un joueur mort dès qu’il meurt sur le serveur, ou continuer à les exécuter jusqu’à ce qu’elles « rattrapent » l’heure de la mort. Couper la compensation immédiatement empêche les victimes d’attaquer leurs tueurs à titre posthume, ce qui répond aux attentes, mais préserve l’avantage naturel des joueurs en mouvement qui tournent un coin, acquièrent une cible et la tuent en moins de temps qu’un aller-retour vers le client de la victime immobile.
Le rembobinage peut être critiqué pour permettre à la latence élevée d’un joueur d’affecter négativement l’expérience des joueurs à faible latence. Les serveurs avec compensation de lag réduiront parfois la longueur de l’historique des joueurs stocké, ou appliqueront des limites de ping, pour réduire ce problème.
Faire confiance aux clientsModifier
Il est possible pour les clients de dire au serveur ce qu’ils font et pour le serveur de faire confiance aux données qu’il reçoit. Cette méthode est évitée dans la mesure du possible en raison de sa sensibilité à la tricherie : il est simple d’acheminer les données du réseau à travers un deuxième ordinateur qui insère des messages de succès fabriqués ou modifie les messages existants, une technique qui ne peut pas être détectée par les outils anti-tricherie.
Cependant, l’échelle même de certains jeux rend impossible les solutions coûteuses en calcul comme le rembobinage. Dans Battlefield 3, par exemple, on utilise un système de « détection hybride des coups » où les clients disent au serveur qu’ils ont frappé et où le serveur n’effectue qu’un vague test de plausibilité avant d’accepter la déclaration.
Faire confiance aux résultats d’un client présente par ailleurs les mêmes avantages et inconvénients que le rembobinage.
Faire extrapoler les clientsModifier
Une solution de lag moins courante consiste à ne rien faire sur le serveur et à faire extrapoler (voir ci-dessus) chaque client pour couvrir sa latence. Cela produit des résultats incorrects, à moins que les joueurs distants ne maintiennent une vitesse constante, accordant un avantage à ceux qui esquivent d’avant en arrière ou qui commencent/arrêtent simplement de se déplacer.
L’extrapolation étendue a également pour conséquence que les joueurs distants deviennent visibles (mais pas vulnérables) alors qu’ils ne devraient pas l’être : par exemple, si un joueur distant sprinte jusqu’à un coin puis s’arrête brusquement au bord, les autres clients le rendront en train de sprinter vers l’avant, à découvert, pendant la durée de leur propre latence. De l’autre côté de ce problème, les clients doivent donner aux joueurs distants qui viennent de commencer à se déplacer un sursaut de vitesse afin de les pousser dans un emplacement prédit théoriquement précis.
DesignEdit
Il est possible de réduire la perception du lag par le biais de la conception du jeu. Les techniques comprennent la lecture des animations côté client comme si l’action avait lieu immédiatement, la réduction/suppression des temporisateurs intégrés sur la machine hôte et l’utilisation des transitions de caméra pour masquer le warping.