Comment gérer la latence réseau dans les jeux multijoueurs ?
Introduction à la latence réseau
La distance entre le serveur et les clients, les sauts de paquets, le taux de tick et mise à jour d'un serveur, et une pléthore d'autres problèmes contribuent au lag multijoueur - voici comment y remédier.
Les jeux en ligne ont des problèmes que les jeux solo ou uniquement en LAN n'ont pas à craindre, tels que le jitter, le temps de réponse (RTT) ou la perte de paquets.
Tout type de retard entre l'envoi, la réception et la mise en file d'attente des informations entre les clients et les serveurs peut causer un problème pour le gameplay. Pour une liste complète de définitions et de problèmes, consultez ce guide ici.
Pour résoudre avec succès les problèmes de latence, vous devez prendre en compte la priorité et la relation entre les éléments suivants :
1. Sécurité
2. Réactivité
3. Précision et cohérence
Aucune solution n'est parfaite, et chaque manière d'aborder les problèmes de latence a ses forces et ses faiblesses. La clé est de trouver la méthode qui fonctionne le mieux pour votre jeu et ce guide vous aidera à comprendre comment prendre cette décision.
Autorité définit qui a le droit de prendre des décisions finales sur le gameplay concernant les objets dans la relation client-serveur. Le modèle d'autorité que vous sélectionnez a des implications sur la latence du réseau dans votre jeu.
Il existe deux types d'autorité dans les jeux multijoueurs, et chacun a sa propre relation avec la sécurité, la réactivité et la cohérence :
- Autorité du serveur: Plus sécurisé, moins réactif, pas de problèmes de synchronisation.
- Autorité du client : Moins sécurisé, plus réactif, problèmes de synchronisation possibles.
Tout code qui existe du côté du client peut être manipulé et les joueurs peuvent falsifier de faux messages réseau envoyés au serveur.
Si vous voulez savoir à quoi cela pourrait ressembler dans votre jeu, considérez l'exemple d'un jeu où vous ne pouvez pas tuer les imps à une certaine distance.
Si vous spécifiez dans votre logique client que vous ne pouvez pas tuer ces imps à plus de 10 mètres, mais que le message "tuer l'imp" est un RPC serveur qui ne vérifie pas la distance côté serveur, les joueurs peuvent falsifier ce message réseau pour contourner votre logique côté client.
Malheureusement, certaines personnes essaieront toujours de perturber votre jeu, donc vous devez toujours garder à l'esprit que vous ne pouvez jamais faire entièrement confiance aux clients. Pour le bien de ces pauvres lutins et de tous les autres jouant à votre jeu, votre serveur a besoin d'une logique pour valider les actions des joueurs venant des clients.
Modèles d'autorité et latence
Le modèle d'autorité que vous sélectionnez a des implications sur la latence du réseau dans votre jeu. Examinons les deux types d'autorité et leur relation avec la sécurité, la réactivité et la cohérence.
Un jeu autoritaire sur serveur a toutes ses décisions finales de gameplay exécutées par le serveur.
Sécurité ✅
Des données critiques telles que la santé de votre personnage ou sa position peuvent être autorisées par le serveur pour garantir que les tricheurs ne peuvent pas y toucher. Dans ce cas, le serveur aura le dernier mot sur la valeur de ces données.
Consistance ✅
Un avantage des jeux autoritaires sur serveur est la cohérence de votre monde. Puisque toutes les décisions de jeu sont prises par le même nœud sur le réseau (le serveur), vous pouvez être sûr que ces décisions sont prises en même temps.
Réactivité 🚫
Un problème avec l'autorité du serveur est que vous finissez par attendre que votre serveur vous dise de mettre à jour votre monde. Cependant, restez à l'écoute car il existe des modèles que vous pouvez utiliser pour résoudre ce problème tout en restant autoritaire sur le serveur.
Dans un jeu autoritaire client, vous avez toujours un serveur utilisé pour partager l'état du monde, mais les clients posséderont et imposeront leur propre réalité.
Réactivité ✅
Un modèle client autoritaire peut souvent être utilisé lorsque vous faites confiance à vos utilisateurs ou à leurs appareils, et c'est un modèle utile pour la réactivité. Puisque le client lui-même prend toutes les décisions importantes concernant le gameplay, il peut afficher le résultat des entrées utilisateur dès qu'elles se produisent.
Consistance 🚫
Les jeux autoritaires des clients peuvent rencontrer des problèmes de synchronisation. Si vous laissez votre client prendre une décision autoritaire en utilisant des informations obsolètes, vous rencontrerez des désynchronisations, des objets physiques qui se chevauchent et d'autres problèmes similaires.
Sécurité 🚫
L'autorité du client est une porte assez dangereuse à laisser ouverte sur votre serveur, car tout joueur malveillant pourrait falsifier des messages pour gagner le jeu.
Résoudre les problèmes de latence dans les jeux autorisés par le serveur
La meilleure pratique pour le développement multijoueur est d'adopter un modèle autoritaire de serveur pour la cohérence et la sécurité. Couvrons quatre stratégies clés pour gérer la latence dans ces jeux.
Lors de la conception de votre fonctionnalité, utilisez l'autorité du serveur par défaut, puis identifiez quelle fonctionnalité nécessite de la réactivité et n'a pas un grand impact sur la sécurité ou la cohérence du monde.
Les entrées des utilisateurs sont un bon exemple. Puisque les utilisateurs possèdent déjà leurs entrées (je possède ma pression de touche, le serveur ne peut pas me dire "non, tu n'as pas appuyé sur la touche W"), les données d'entrée des utilisateurs peuvent facilement être pilotées par le client.
Dans les jeux de tir à la première personne, votre direction de regard peut facilement être contrôlée par le client sans beaucoup d'impact. Le client enverra au serveur sa direction de regard au lieu des mouvements de la souris. Avoir une correction sur où vous regardez semblerait étrange et la sécurité pour cela a ses propres défis.
La prédiction peut garder votre serveur de jeu autoritaire tout en restant réactif. Votre client simule et exécute du code de jeu qui anticipe les entrées de déclenchement de vos joueurs au lieu d'attendre un RTT complet pour les résultats d'action.
C'est là que la "réconciliation" entre en jeu - lorsque des erreurs se produisent dans la prédiction. Le client garde un historique des positions qu'il a prédites et, étant autoritaire côté serveur, le client reçoit toujours des positions provenant du serveur. Le client validera si les positions qu'il a prédites dans le passé correspondent aux anciennes positions provenant du serveur.
Le client peut alors détecter les écarts et corriger sa position en fonction de la position autoritaire du serveur.
Remarque: Cette méthode n'est pas entièrement prise en charge par Netcode pour GameObjects à ce moment.
Il y a plusieurs raisons pour lesquelles le code de jeu autoritaire du serveur ne doit pas s'exécuter à la fois côté client (avec prédiction) et côté serveur. Mais comment vous assurez-vous que le lancer se sent réactif et que votre client n'a pas à attendre un RTT complet avant de voir quoi que ce soit réagir à son entrée ?
Un truc souvent utilisé pour cacher le lag est de déclencher immédiatement une animation, un son ou un VFX non impactant sur le gameplay lors de l'entrée du joueur, mais d'attendre tout de même que les éléments de gameplay autorisés par le serveur dirigent le reste de l'action.
Si le serveur a un état différent, le pire qui puisse arriver du côté client est que vous ayez joué une animation rapide mais inutile. Il est facile de laisser l'animation se terminer ou de l'annuler. Ceci est référencé comme le lancement d'action ou l'anticipation d'action.
Le retour en arrière du serveur est un contrôle de sécurité sur une fonctionnalité pilotée par le client pour s'assurer que nous restons autoritaires sur le serveur.
Le client envoie avec son entrée un message disant au serveur "J'ai atteint mon objectif à l'heure t". Le serveur, lorsqu'il reçoit cela à l'instant t+RTT/2, rembobinera sa simulation à l'instant t-RTT, validera le tir et corrigera le monde au dernier instant (c'est-à-dire tuera la cible). Cela permet au joueur de sentir que le monde est cohérent tout en restant sécurisé et autoritaire sur le serveur.
Remarque : Le retour en arrière de l'état du jeu se fait dans le même cadre et cela est invisible pour les joueurs. Ceci est une vérification côté serveur qui permet de valider un client vous disant quoi faire.
Remarque: Cette méthode n'est pas entièrement prise en charge par Netcode pour GameObjects à ce moment.
Construire un jeu multijoueur est une entreprise difficile, mais aussi passionnante. Que vous construisiez le prochain succès de battle royale ou un co-op en ligne confortable, comprendre les nuances de la latence et comment la gérer est essentiel.
Consultez notre documentation multijoueur pour commencer votre prochain projet dès aujourd'hui.