Techniques, algorithmes et ressources MMO pour maintenir une bande passante faible?


9

Existe-t-il des ressources et de la documentation sur la façon dont les MMO actuels gèrent les données d'action et de mouvement de la compression à la gestion sur le client? Des ressources pour les algorithmes de prédiction de mouvement?

Je suis particulièrement intéressé par ceux qui ont un mouvement wsad et se concentrent sur le maintien d'une latence faible. Quels sont également le taux et la taille des paquets pour différents types de MMO (en termes de réseau)?

Existe-t-il un moyen de faire évoluer le taux de paquets ou de désactiver carrément certains paquets si le joueur ne peut pas les atteindre ou, plus tard, les voir?

Réponses:


9

Eh bien, il y a ce livre - qui est un peu vieux maintenant, et je ne l'ai jamais vraiment lu, mais il vient d'un éditeur réputé. J'ai également trouvé celui-ci , qui est plus récent, mais je n'en ai jamais entendu parler auparavant. Les deux prétendent couvrir les problèmes de développement de jeux MMO (ou au moins en ligne); Cela dit, la prédiction côté client est plus ou moins la même quelle que soit l'échelle de votre base de joueurs simultanés, et Google a beaucoup d'informations à ce sujet .

Il est important de réaliser que d'un point de vue pratique, il est assez difficile pour un développeur indépendant / amateur de créer un jeu qui sera suffisamment populaire pour même attirer suffisamment de joueurs pour atteindre un pic de concurrence théorique suffisamment élevé pour être considéré comme "massif". Mais les techniques peuvent encore être pédagogiques à la recherche.

Il existe deux grandes catégories de choses que vous pouvez faire:

  • Soyez agressif en envoyant uniquement la quantité minimale de données à l'ensemble minimal de clients qui en ont besoin.
  • Concevez un jeu qui n'incite pas les joueurs à se regrouper trop, vous aidant à garder "l'ensemble des clients qui ont besoin" de petites choses en général.

Le second est vraiment un problème de conception de jeu et de manipulation sociale - c'est particulièrement délicat parce que les jeux multijoueurs sont naturellement sociaux, cela fait partie de leur attrait, donc vous ne voulez pas trop décourager les groupes de joueurs. D'un autre côté, un jeu où tout le monde dans le monde fraye du camping le seul gars qui lâche le meilleur butin du jeu sera difficile à mettre à l'échelle.

Pour la première option, vous pourriez envisager de faire de la messagerie à plusieurs niveaux - il y a des choses sur les autres joueurs qui sont toujours importantes à savoir, comme les positions. Mais d'autres choses, comme la santé, peuvent ne pas être aussi importantes pour les objets que le joueur actuel ne peut pas encore voir, donc vous transmettez ce que vous envoyez à ce joueur en fonction de la distance relative de toutes les autres entités à proximité - c'est essentiellement une limitation les données que vous envoyez, comme vous l'avez mentionné dans la dernière partie de votre question, ainsi que leur filtrage.

Les architectures multijoueurs à très grande échelle tamponneront également les rapports qui n'ont pas besoin de prendre des mesures immédiates. Les messages de sauvegarde de caractères envoyés au serveur peuvent être effectués en deltas, avec des mises à jour complètes uniquement aux points critiques, et ces mises à jour peuvent être mises en mémoire tampon sur un serveur de limitation afin qu'elles soient envoyées au serveur qui contient réellement les données de caractères de manière stable, mode périodique - à mesure que votre base de joueurs évolue, vous devez vous soucier de l'optimisation des E / S disque ainsi que du trafic réseau. Vous ne voulez pas provoquer le débordement de votre base de données de personnages.

Le taux et la taille des paquets diffèrent largement d'un jeu à l'autre, tout comme pour les jeux non MMO. C'est vraiment une chose très spécifique aux exigences et il n'y a pas de normes généralisées.


1
Il y a aussi une suite au premier livre (Massively Multiplayer Game Development 2). Ce n'est pas une série de livres terriblement utile à mon avis (ce n'est certainement pas un livre du début à la fin faire un MMO en x heures comme la plupart des livres de développement de jeux), mais il discute certains des problèmes théoriques demandé dans cette question. Et peut-être que ce serait plus utile pour quelqu'un qui a déjà un MMO en partie développé.
Ricket

5

En plus de la réponse ci-dessus, consultez TCP_NODELAY et le fonctionnement de la mise à l'échelle des fenêtres. Comprendre les détails de TCP (et oui, vous voulez utiliser TCP et non UDP sauf si la perspective de gérer des mises à jour différentielles arrivant en panne vous semble amusant) et la retransmission est essentielle pour le contrôle de la latence.


4
Je répéterai que si vous utilisez des mises à jour différentielles (généralement des différences binaires de structures en jeu) et que vous utilisez quoi que ce soit avec une livraison en panne (fiable ou non), vous le regretterez. Les gens qui n'aiment pas TCP dans les jeux ne le savent généralement pas assez (comme savoir ce que fait NODELAY). UDP est logique pour des choses comme les données vocales, où les paquets en panne peuvent simplement être supprimés, ce qui est rarement le cas dans un jeu.
coderanger

1
"rarement le cas dans un jeu"? À condition que le serveur me donne des états de jeu faisant autorité à chaque image, je me fiche de ce qui s'est passé dans le passé. Un simple numéro de trame à augmentation monotone provenant de paquets UDP est parfait pour cela. De combien de données avez-vous vraiment besoin pour transmettre de manière fiable?
ChrisE

2
"Pourvu que le serveur me donne des états de jeu faisant autorité à chaque image" Bien sûr, si vous traitez cela comme une donnée. Notez que j'ai dit "si vous utilisez des mises à jour différentielles", ce qui serait l'opposé de stroboscopiser l'état complet à chaque trame. Dans un MMO avec n'importe quel niveau de complexité dans le monde, il deviendra rapidement impossible d'envoyer des mises à jour complètes aussi fréquemment.
coderanger

1
Même si vous envoyez l'état complet des choses qui changent, vous vous retrouvez avec des problèmes de livraison dans le désordre où la fusion des choses peut devenir irréalisable. Pensez aux mises à jour "x = 1, y = 2" puis "y = 1, z = 2". Si ceux-ci arrivent en arrière, vous voulez supprimer le "premier" afin que la valeur de y soit correcte, mais vous perdez ensuite la modification en x.
coderanger

1
@Adam C'est pourquoi j'ai dit que vous devriez aller lire la spécification TCP et comprendre comment fonctionne la mise à l'échelle de la fenêtre et comment elle interagit avec la retransmission ;-) La réécriture de TCP est fondamentalement toujours mauvaise, les chances de le visser sont proches de 100%. Si vous voulez une livraison fiable et dans l'ordre, vous ne devriez pas utiliser UDP.
coderanger
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.