Gérer la latence dans les jeux en réseau

Question

Je pense créer un jeu en réseau.Je suis un peu nouveau dans ce domaine et j'ai déjà rencontré de nombreux problèmes en essayant d'élaborer un bon plan pour l'estime et la latence du réseau, j'aimerais donc voir de la bonne littérature sur le sujet.Je vais décrire les méthodes que j'ai envisagées.

À l'origine, j'envoyais simplement les entrées du joueur au serveur, j'y simulais et je diffusais les changements dans l'état du jeu à tous les joueurs.Cela rendait la triche difficile, mais avec une latence élevée, les choses étaient un peu difficiles à contrôler, car vous ne voyez pas immédiatement les résultats de vos propres actions.

Cet article du GamaSutra a une solution qui économise de la bande passante et rend les entrées locales fluides en simulant également sur le client, mais elle semble jeter la protection contre la triche par la fenêtre.De plus, je ne sais pas quoi faire lorsque les joueurs commencent à manipuler l'environnement, à pousser des rochers, etc.Ces objets auparavant neutres deviendraient temporairement des objets sur lesquels le client devait envoyer des PDU, ou peut-être que plusieurs joueurs le feraient en même temps.Quels PDU gagneraient ?Quand les objets cesseraient-ils d'être doublement suivis par chaque joueur (à comparer avec la version à l'estime) ?Dieu nous préserve que deux joueurs s'engagent dans un match de sumo (par ex.commencez à vous pousser).

Ce bit de gamedev.net montre la solution du gamasutra comme inadéquate, mais décrit une méthode différente qui ne résout pas vraiment mon exemple collaboratif de poussée de rochers.La plupart des autres choses que j'ai trouvées sont spécifiques aux tireurs.J'adorerais voir quelque chose de plus orienté vers des jeux comme SNES Zelda, mais avec un peu plus de physique/d'élan impliqué.

• Note:Je ne parle pas ici de simulation physique - d'autres bibliothèques s'en occupent.Juste des stratégies pour rendre les jeux fluides et réactifs malgré la latence du réseau.

Answer 1

Découvrez comment Valve procède dans le moteur source : http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

S'il s'agit d'un jeu de tir à la première personne, vous devrez probablement approfondir certains des sujets mentionnés, tels que :prédiction, compensation et interpolation.

Answer 2

je trouve ce billet de blog sur la physique des réseaux par Glenn Fiedler, et plus encore la réponse/discussion en dessous, géniale.C'est assez long, mais ça vaut le coup.

En résumé

Le serveur ne peut pas suivre la simulation réitérée chaque fois que l'entrée du client est reçue dans une simulation physique de jeu moderne (c'est-à-direvéhicules ou dynamique des corps rigides).Par conséquent, le serveur commande la latence + la gigue (temps) de tous les clients avant le serveur afin que tous les paquets entrants arrivent en JIT avant que le serveur n'en ait besoin.

Il donne également un aperçu de la manière de gérer le type de propriété que vous demandez.Les diapositives qu'il a montrées sur GDC sont géniales !

Sur la triche

M. Fiedler lui-même (et d’autres) déclare que cet algorithme souffre de ne pas être très résistant à la triche.Ce n'est pas vrai.Cet algorithme n'est pas moins facile ni difficile à exploiter que la prédiction client/serveur traditionnelle (voir l'article concernant la prédiction client/serveur traditionnelle dans Réponse de @CD Sanchez).

Pour être absolument clair :le serveur n'est pas plus facile à tromper simplement parce qu'il reçoit le positionnement physique du réseau juste à temps (plutôt que x millisecondes en retard comme dans la prédiction traditionnelle).Les clients ne sont pas du tout affectés, puisqu’ils reçoivent tous les informations de position de leurs adversaires avec exactement la même latence que dans la prédiction traditionnelle.

Quel que soit l'algorithme que vous choisissez, vous souhaiterez peut-être ajouter une protection contre la triche si vous sortez un titre majeur.Si c'est le cas, je suggère d'ajouter un cryptage contre robots comparses (par exemple un chiffrement de flux XOR où le « flux de clés est généré par un générateur de nombres pseudo-aléatoires ») et de simples contrôles d'intégrité contre les fissures.Certains développeurs implémentent également des algorithmes pour vérifier que les binaires sont intacts (pour réduire le risque de crack) ou pour s'assurer que l'utilisateur n'exécute pas de débogueur (pour réduire le risque de développement d'un crack), mais ceux-ci sont plus discutables.

Si vous créez simplement un jeu indépendant plus petit, qui ne peut être joué que par quelques milliers de joueurs, ne vous embêtez pas à implémenter des algorithmes anti-triche jusqu'à ce que 1) vous en ayez besoin ;ou 2) la base d'utilisateurs augmente.

Answer 3

nous avons mis en place un jeu de serpent multijoueur basé sur un serveur obligatoire et des joueurs distants qui font des pronostics.Toutes les 150 ms (dans la plupart des cas) le serveur renvoie un message contenant tous les mouvements consolidés envoyés par chaque joueur distant.Si les mouvements des clients distants arrivent en retard au serveur, celui-ci les rejette.Le client rejouera le dernier mouvement.

Answer 4

Consultez les sujets relatifs à l'éducation en réseau sur le site Web du XNA Creator's Club.Il aborde des sujets tels que l'architecture réseau (peer to peer ou client/serveur), la prédiction réseau et quelques autres éléments (dans le contexte de XNA bien sûr).Cela peut vous aider à trouver les réponses que vous recherchez.

http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1

Answer 5

Vous pouvez essayer d'imposer une latence à tous vos clients, en fonction de la latence moyenne dans la zone.De cette façon, le client peut essayer de contourner les problèmes de latence et cela sera similaire pour la plupart des joueurs.

Je ne suggère bien sûr pas que vous imposiez un délai de 500 ms à tout le monde, mais les personnes avec 50 ms peuvent se contenter de 150 (100 ms supplémentaires ajoutées) pour que le gameplay paraisse plus fluide.

En un mot;si vous avez 3 joueurs :

• John:30 ms
• Paul:150 ms
• Amy :80 ms

Après les calculs, au lieu de renvoyer les données aux clients en même temps, vous tenez compte de leur latence et commencez à envoyer à Paul et Amy avant John, par exemple.

Mais cette approche n'est pas viable dans des situations de latence extrême où les connexions commutées ou les utilisateurs sans fil pourraient vraiment gâcher la situation pour tout le monde.Mais c'est une idée.