Effet élastique
Le rubberbanding (ou effet élastique) est le retour brusque et visible qui se produit lorsque le serveur corrige la position erronée prédite par un client.
,
La désynchronisation n'est pas du lag
Les deux sont souvent confondus, mais ils représentent des défaillances différentes.
Le lag est un retard : tout ce que vous voyez est correct, mais simplement en retard. La désynchronisation (desync) est un désaccord : ce que vous voyez est faux, et agir en conséquence produit des résultats qui semblent arbitraires. Vous tirez sur quelqu'un qui est déjà parti, ou vous contournez un angle et mourez face à un joueur que vous n'avez jamais vu.
Cette distinction est importante car elle change ce que vous devez corriger. Un joueur à 15 ms peut subir une grave désynchronisation à cause d'un bug de déterminisme. Un joueur à 120 ms peut rester parfaitement synchronisé grâce à une bonne prédiction et réconciliation. S'attaquer au ping quand la cause est le code fait perdre un sprint.
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
La désynchronisation est un désaccord, pas un retard : Le lag signifie que l'information arrive tardivement. La désynchronisation signifie que deux machines détiennent des versions différentes du même monde, ce qui est une défaillance distincte avec des corrections distinctes.
Il en existe deux types distincts : La désynchronisation de réplication, où un serveur faisant autorité corrige un client qui a mal deviné, et la désynchronisation de déterminisme, où les simulations des pairs divergent et la session s'arrête carrément.
L'effet d'élastique (rubberbanding) a deux leviers : La fréquence à laquelle le client fait de mauvaises prédictions, qui dépend de la latence, et la visibilité de chaque correction, qui dépend du netcode. Modifiez l'un ou l'autre de ces leviers et les joueurs le verront moins.
Le tick rate (taux de rafraîchissement) n'est aucun de ces leviers : L'augmenter ne rend pas les prédictions plus précises, et sur une connexion qui perd déjà des paquets, cela aggrave les artefacts.
« Une désynchronisation s'est produite » est un échec de checksum (somme de contrôle) : Les jeux en lockstep comparent les hachages d'état à chaque tour, donc un seul flottant divergent ou un seul appel aléatoire non synchronisé met fin à la session.
Les quatre choses qui en sont réellement la cause
Fréquence de rafraîchissement instable. Le serveur met à jour l'état de la partie un nombre fixe de fois par seconde. Lorsque la surcharge du processeur fait chuter ou fluctuer cette fréquence, les clients reçoivent l'état moins souvent et effectuent des prédictions plus lointaines sur la base d'informations plus obsolètes. L'instabilité est plus préjudiciable qu'une fréquence basse mais stable — un serveur qui tourne à 60 Hz, puis à 44 Hz, puis à 60 Hz produit une désynchronisation pire qu'un serveur qui maintient constamment 30 Hz, car la prédiction ne peut pas se calibrer par rapport à une cible mouvante.
Latence et gigue. Un temps de trajet aller-retour élevé signifie que les prédictions reposent sur des informations plus anciennes. Un temps de trajet aller-retour variable est encore pire : le client ne peut pas se caler sur un rythme de correction, de sorte qu'il compense alternativement trop ou pas assez.
Simulation non déterministe. Dans les architectures en mode lockstep, chaque client exécute la même simulation et compte sur elle pour produire des résultats identiques. Les différences de virgule flottante entre les plateformes, les valeurs non initialisées ou tout élément lisant l'heure système vont diverger, et cette divergence s'accentue silencieusement jusqu'à devenir visible. C'est la cause contre laquelle un ping faible ne vous protège absolument pas.
Désalignement de l'horloge. Lorsque le serveur et le client ne sont pas d'accord sur l'heure qu'il est, chaque calcul basé sur le temps — temps de recharge des compétences, déplacement des projectiles, durée des buffs — se résout différemment de chaque côté.
Pourquoi la perte de paquets aggrave la situation, au lieu de simplement la ralentir
Une mise à jour d'état perdue n'est pas une mise à jour d'état retardée. Sous UDP, le client ne l'attend pas ; il continue à faire des prédictions à partir du dernier état dont il dispose. Chaque paquet perdu prolonge la fenêtre dans laquelle le client extrapole des données non vérifiées, et la correction lors de la réception de la mise à jour suivante est proportionnellement plus importante et plus visible. C'est le mécanisme qui est à l'origine de la plupart des effets de bande élastique (rubberband).
Comment y remédier, par ordre d'efficacité
Couche | Correctif | Ce qu'il résout |
|---|---|---|
Architecture | Un serveur faisant autorité comme source unique de vérité | Élimine la catégorie de désynchronisation où deux clients pensent chacun avoir raison |
Client | Prédiction avec réconciliation du serveur | Maintient la réactivité des entrées tout en laissant le serveur trancher chaque désaccord |
Client | Interpolation des entités distantes | Adoucit le mouvement visible des autres joueurs entre les mises à jour |
Serveur | Compensation du décalage (lag compensation) — retour en arrière vers la vue du tireur | Rend l'enregistrement des tirs équitable malgré les différentes latences |
Code | Simulation déterministe, virgule fixe si nécessaire | La seule solution pour la divergence en mode lockstep |
Infrastructure | Fréquence de rafraîchissement constante, serveurs proches des joueurs, marge de performance | Élimine complètement les causes liées à l'infrastructure |
Un mot de notre sponsor (nous-mêmes !)
La majeure partie du lag provient de la distance, non du code. L'Edge Cloud d'Edgegap est un réseau distribué disposant de plus de 615 emplacements disponibles sur demande, garantissant que chaque partie se déroule au meilleur endroit possible pour ses joueurs. Des tests indépendants sur le trafic d'un studio en direct ont mesuré une baisse de 58 % du temps de trajet aller-retour moyen par rapport au cloud public.
L'ordre importe. Les équipes perdent régulièrement du temps sur la dernière ligne alors que leur problème se situe à la quatrième, ou sur la quatrième alors que leur problème se situe à la sixième. Installez des outils de mesure avant d'optimiser : enregistrez les temps de tick du serveur et l'amplitude des corrections du client, et vous saurez en moins d'un jour dans quelle couche vous vous trouvez réellement.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
L'avis d'Edgegap
« La plupart des studios avec lesquels nous discutons arrivent convaincus d'avoir un problème de netcode, et environ la moitié d'entre eux ont en réalité un problème de capacité masqué sous un costume de netcode. Les serveurs trop densément peuplés se disputent le processeur, le taux de rafraîchissement (tick rate) devient erratique sous la charge, et la prédiction n'a plus de base stable sur laquelle se calibrer. L'indice révélateur est que cela ne se manifeste qu'aux pics de fréquentation. Avant de réécrire votre couche de prédiction, tracez les temps de cycle de votre serveur par rapport à votre nombre de joueurs. Si les deux sont corrélés, la solution réside dans la marge de manœuvre, pas dans le code… et cela représente une après-midi de travail bien moins coûteuse. »
,
