Les objets énormes et statiques comme l'environnement sont-ils transmis du serveur au client dans les jeux multijoueurs modernes?


18

J'ai un système faisant autorité, où lorsque le joueur rejoint le match, il obtient tous les objets déjà générés - générés sur lui-même (le client).

Cela ressemble à ceci:

  1. Client envoie le jeton d'accès au Server
  2. Client reçoit l'acceptation du Server
  3. Client bascule la scène sur la scène du jeu
  4. Serverenvoie des joueurs, des caisses, des objets avec clientlesquels vous pouvez interagir afin qu'ils puissent apparaître et les afficher.

Mais qu'en est-il de l'objet au sol? Pour l'instant, j'ai exactement la même scène sur le serveur et le client - avec un plan statique faisant office de plancher. Actuellement, j'ajoute de nouvelles choses, des arbres, des escaliers et je construis des choses ensemble.

Je pensais - nous sommes bons. Mais l'environnement ne devrait-il pas aussi être synchronisé? Être en réseau en quelque sorte? Possédé par le serveur?

Prenons League of Legends:

entrez la description de l'image ici

C'est un environnement statique, probablement un maillage combiné (escaliers, gazon, murs, magasin). Mais est-il vraiment conservé sur le client ou envoyé par le serveur lors de l'écran de chargement?


1
Vous pouvez même y penser à partir du moment où vous pouvez ajouter des skins personnalisés aux personnages et à l'environnement de la ligue. Vous ne les envoyez pas sur serveur, ils sont affichés localement, il est donc logique de conclure qu'ils sont stockés et rendus localement. De plus, ils n'affectent pas le gameplay, si vous posez des questions sur les collisions, ils sont un mélange de serveur et de client, de sorte que le joueur ne peut pas tricher et traverser les murs.
Candid Moon _Max_

Réponses:


41

Pour la plupart, non, les actifs artistiques de toute nature ne sont pas systématiquement envoyés sur le réseau. En général, tous les clients auront les mêmes actifs de contenu localement. Il peut y avoir du code pour s'assurer que c'est le cas via la somme de contrôle du contenu, ou similaire. Si vous craignez que les utilisateurs n'altèrent certains de leurs contenus côté client, vous pouvez implémenter un système similaire.

Le serveur peut envoyer des directives au client indiquant qu'il doit afficher ou masquer certains actifs, mais il n'enverra pas les données réelles de l'actif. Ceci est, en pratique, trop de gaspillage et de lenteur, et pourrait causer de réels problèmes aux personnes disposant de données limitées.

Dans certains cas, des actifs plus petits peuvent être diffusés dans leur intégralité si l'actif est en quelque sorte considéré comme un «spoiler» ou autre. Mais c'est rare. Généralement, ce que vous voyez, c'est qu'un jeu peut télécharger du nouveau contenu à partir d'un correctif ou autre, mais cela ne se produira qu'une seule fois, pendant le processus de correction au démarrage. Pas pendant le gameplay.


21
Notez que cette réponse ne concerne que les actifs statiques. Les actifs dynamiques / générés par les joueurs (par exemple, les morceaux du monde Minecraft ou les logos de guilde MMORPG que les joueurs peuvent télécharger) devront être transmis. Mais même dans ce cas, on essaie généralement de minimiser la quantité de données nécessaires (pour continuer l'exemple de Minecraft: envoyer des mises à jour de blocs au lieu de blocs entiers, en indiquant uniquement le type / état du bloc et les coordonnées qui ont changé) et / ou mettre en cache les données côté client .
hoffmale

@hoffmale Oui, bon point; la question mentionnait que le paysage était statique à la fin, donc je n'ai pas pensé à soulever ce point, mais il est bon.

3
Si un actif est un spoiler, il est généralement sur le client, chiffré et la clé de déchiffrement est transmise du serveur au client lorsque l'actif est nécessaire.
Grant Davis

4
Et par exemple, si vous devez placer au hasard des arbres sur une carte, au lieu d'envoyer les coordonnées des arbres au client, il envoie la graine (du générateur de nombres aléatoires) au client.
Grant Davis

5

Cela dépend de plusieurs facteurs, y compris le type de jeu (je suppose que RTS ici, bien que le MMO en monde ouvert me vienne également à l'esprit). Un état de terrain de base local vers le joueur est envoyé lors de la connexion ou fait partie des actifs du client - pensez à un jeu RTS où la carte est soit livrée avec le client, soit téléchargée avant le début du jeu.

En effet, le maillage ne serait généralement pas envoyé, comme il le serait déjà sur le client dans la plupart des cas RTS. La question de savoir si la carte de collision, qui est vraiment cruciale pour garder les deux synchronisés, est envoyée, est une autre question. Mais dans la plupart des RTS, cela serait à nouveau pré-stocké sur le client.

Donc, vraiment, tout dépend de ce que votre RTS est livré, que vous téléchargiez des cartes avant le début du jeu ou au moment où le jeu commence.

Après cela, il existe quelques façons typiques de rester synchronisé:

  • Les deltas sont envoyés au client - le moyen le plus courant et le plus efficace de maintenir le monde local / client à jour avec le serveur;
  • Des sommes de contrôle sont parfois envoyées du serveur au client ou du client au serveur pour s'assurer que l'état mondial correspond bien;
  • Parfois, l'état complet est renvoyé pour resynchroniser le client - souvent en raison de problèmes techniques tels que la dérive en virgule flottante.

4

Quant à votre question exacte telle que posée, je ne sais pas comment League of Legends la traite spécifiquement. Je n'ai jamais joué à ce jeu, je ne peux donc pas suggérer s'il le faut ou non.

Mais la réponse à votre question, en général, est assez simple et directe:

Si les données sont statiques et que vous savez avec certitude qu'elles ne changeront jamais (à moins de mises à jour périodiques complètes du jeu, mais c'est séparé), alors pourquoi voudriez-vous jamais envoyer ces données supplémentaires? Habituellement, vous essayez d'éviter d'envoyer tout ce qui peut être évité. N'envoyez des données que si cette communication est nécessaire .

D'un autre côté, si les données vont changer avec le temps , ou si vous voulez simplement laisser cette option ouverte, avez-vous vraiment le choix? Dans ce cas, vous devez envoyer les données. Sinon, le client n'a pas ce dont il a besoin.

Cela s'applique à toutes les communications réseau, pas seulement aux données de terrain. Tout .


2

Non.

J'ai fait beaucoup de fouilles dans la source de League of Legends, et tout, y compris les modèles Champion, le commerçant, l'arrière-plan général de la carte et les créatures en peluche ajoutées après le fait (comme le petit écureuil sur des rochers et un escargot dans la rivière) sont conservés côté client. Le fait que le client possède tous ces modèles est l'une des raisons pour lesquelles LoL est de plusieurs gigaoctets.

Transférer toutes ces données du serveur au client serait un enfer, sans parler de l'utilisation de la bande passante pour recommencer le prochain jeu.

Alors, comment est-il résolu alors? Chaque joueur envoie SEULEMENT au serveur les données importantes pour les autres joueurs du jeu. Personne n'a besoin de savoir s'il vous reste 5 secondes sur le temps de recharge de Q, ou que la peau de Deep Terror Thresh crée des bulles pour vous. Les choses qui se transmettent dans le jeu sont des choses comme, Vel'Koz a lancé Q, Viktor s'est déplacé vers la gauche, etc.

Plus explicitement, en ce qui concerne l'écran de chargement, comme vous l'avez mentionné, des choses se produisent, comme des patchs intermédiaires, dont chaque joueur doit parler aux serveurs de riot avant le début du jeu, des connexions sécurisées et des protocoles anti-triche.

REMARQUE:

Si vous voulez regarder ce que le client a, et par conséquent, le serveur ne vous dépasse pas, recherchez le dossier C: \ Riot Games \ RADS \ lol_Game_Client \ Projects (qui pourrait être un peu éteint, pardonnez-moi I '' m travaille sur la mémoire en ce moment) et trouvez un décompresseur de fichiers .RAF en ligne. Ensuite, vous pouvez voir tout ce qui est hébergé localement, comme le chargement d'éclaboussures d'écran et de textures de peau, même des squelettes champions.


1
Il semble que la façon la plus évidente de mettre en œuvre cela serait d'avoir le client demande (à partir d'un serveur d'actifs dédié) tous les actifs qu'il n'a pas déjà stockés localement, et lorsqu'il les reçoit, il les ajoute (semi) de façon permanente à son magasin persistant local sur le disque. De cette façon, les actifs ne sont téléchargés qu'une seule fois, et uniquement lorsqu'ils sont réellement nécessaires. (Une fois que cela fonctionne, une optimisation serait de préremplir le magasin local du client avec des actifs qui sont très probablement nécessaires. Cela réduirait le temps de démarrage du jeu lors de la première connexion, au prix d'agrandir le package d'installation du jeu)
Jeremy Friesner

1
@JeremyFriesner Pourquoi serait-ce la manière évidente? Cela semble pire que l'implémentation actuelle décrite dans cet article, qui vous permet d'installer tous les actifs à l'avance afin de les avoir immédiatement disponibles lorsque vous en avez besoin. Cela pourrait fonctionner pour un jeu solo, bien que je pense que beaucoup de gens préféreraient un temps d'installation plus long (et plus d'espace disque) plutôt que d'attendre constamment que de nouveaux éléments soient téléchargés pendant le jeu.
Anthony Grist

2
Pour un jeu multijoueur? Catastrophe absolue. Vous ne voulez pas que tous les autres joueurs attendent pour commencer le jeu, car une personne doit télécharger certains éléments dont ils n'ont jamais eu besoin jusqu'à présent.
Anthony Grist

1
@AnthonyGrist C'est pourquoi de nombreux jeux comme League of Legends exigent qu'un joueur ait téléchargé tous les actifs du jeu avant de rejoindre la file d'attente pour trouver un match. Cela fonctionne beaucoup mieux que d'avoir le décalage de jeu pendant que vous attendez qu'un gros atout fonctionne. Gardez à l'esprit que dans ce genre de jeu, les joueurs sont excités par une réduction de 10 ms du ping et jouent souvent avec <50 ms de ping et peuvent dire si cela passe à la plage 100 à 150. Attendre pour récupérer un actif pendant un jeu serait un désastre dans un MOBA ou un FPS, et si cela arrivait au mauvais moment, cela pourrait même changer le résultat d'un jeu.
JustWannaFly

@AnthonyGrist (suite) Je suppose que vous pourriez y penser comme ça. Dans certains jeux multijoueurs / compétitifs, les joueurs échangent un temps de chargement / patch / installation plus long pour une expérience de jeu plus en temps réel en faisant en sorte qu'un client s'occupe de toutes les mises à jour et de l'entrée de la file d'attente. Cela fait que seul le joueur spécifique ayant besoin d'actifs doit attendre à moins qu'il ne veuille rejoindre une partie premade, alors tous les joueurs de la partie devraient attendre pour entrer dans la file d'attente pour trouver des adversaires
JustWannaFly

1

Un exemple où cela n'a pas été fait était le Elder Scrolls Online, où il faisait confiance au client à propos de l'altitude du niveau du sol .

Les chercheurs d'or ont baissé le niveau du sol de plusieurs pieds. Ils pouvaient ensuite se promener «sous» le terrain et extraire des ressources par le bas sans être vus par les PJ ni attaqués par les PNJ.

Des modifications similaires leur ont permis de lisser les falaises afin de pouvoir les gravir, les retirer ou les passer sous les murs statiques, voir à travers tous les objets statiques, etc.

Essentiellement, le serveur a fait confiance au client quant à l'emplacement du joueur, le calcul de la collision côté serveur pour chaque joueur contre toutes les statistiques serait assez lourd.

Dans les jeux basés sur des tuiles comme Furcadia, cependant, c'est différent: chaque carré dans lequel vous vous déplacez a une capacité de marche côté serveur, et le serveur n'a pas besoin de faire confiance au client pour quoi que ce soit: le serveur connaît et valide chaque mouvement et action de l'utilisateur, et le client n'affiche l'action que lorsque le serveur lui indique le résultat.


1
TL; DR: supposez toujours que le client est un outarde menteur, tricheur . Mais la validation du serveur de tout réduit votre capacité.
Draco18s
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.