Comment synchroniser des actions comme sauter en multijoueur?


11

Je suis un développeur de jeux débutant et j'ai fait des recherches sur les jeux multijoueurs. J'ai observé qu'il y a toujours une certaine latence, les joueurs reçoivent toujours des mises à jour des actions passées. Mais il existe des techniques telles que le calcul des morts pour gérer la latence. Je peux prédire le mouvement et rendre les mouvements fluides. Mais comment pourrais-je synchroniser des actions comme sauter, arrêter de marcher, etc.

Supposons que le client A se déplace, il se trouve à 100 m à 10,2 heure avec une vitesse de 100 m / s et envoie cette information. Le client B recevrait ces informations un peu plus tard, que ce soit 10.4. Donc, au client B, je peux utiliser la prédiction et placer le client A à 120 m. Mais que se passe-t-il si, le client fait un saut à 110m à 10,3. Je ne peux pas prédire cela et depuis que j'utilise la prédiction, je ne peux pas montrer au client un saut dans le passé.

Je peux résoudre ce problème en n'envoyant pas du tout d'action de saut. Mais que se passe-t-il si mon jeu comporte des vides où les joueurs peuvent tomber et mourir. Donc, si je ne synchronise pas les actions de saut, les autres joueurs remarqueront qu'un joueur courait, puis il tombe dans le vide et réapparaît à l'écran détruisant l'engagement visuel.

Jump n'est qu'un exemple, il peut y avoir de nombreux scénarios où la prédiction ne peut pas fonctionner. Alors, comment y faire face. Un tel exemple peut être les jeux d'arène de combat multijoueurs en ligne comme Awesomenauts.


Je ne connais pas grand-chose au multijoueur, donc je ne serai pas en mesure de donner une bonne réponse. Mais d'après ce que j'ai ramassé, la configuration idéale serait que vos clients soient plus ou moins stupides et envoient uniquement un clavier, une souris, une manette de jeu ou toute autre entrée au serveur, et le serveur fait tout ce mouvement et met à jour le monde et renvoie les positions et toutes les autres données pertinentes aux clients, qui affichent ensuite le résultat. Cela élimine presque complètement les prédictions et les choses similaires.
Christian

@Christian hey! Merci pour la réponse. Je connais cette approche mais cela peut rendre le gameplay saccadé si la latence est élevée et de plus j'utilise le système BaaS en temps réel d'AppWarp, donc toute ma logique se trouve côté client uniquement.
Suyash Mohan

La combinaison de vos deux méthodes est le serveur faisant autorité. Les clients et le serveur simulent tous les deux, les clients envoient leur entrée, le serveur renvoie l'état faisant autorité. Les clients ajustent leur état pour correspondre à l'état faisant autorité. Ainsi, lorsque les états concordent, les clients fonctionnent comme s'ils étaient simulés localement (pas de décalage).
MichaelHouse

j'ai récemment trouvé cette série de tutoriels pour donner de bons conseils sur la gestion de la latence, il semble que cela serait pertinent pour vos intérêts: lien
Kris Welsh

Réponses:


8

L'estimation des morts peut ne pas être la meilleure idée dans ce cas; vous devez faire une interpolation d'entité (en rendant efficacement les autres joueurs dans le passé, ce qui vous donne toujours des positions réelles et valides). J'ai écrit à ce sujet avec beaucoup plus de détails ici . Le fait que voir ou non des joueurs légèrement dans le passé soit acceptable ou non dépend des détails de ce que vous essayez de faire.


4
J'ai utilisé cette approche lors de l'écriture de mon premier jeu multijoueur en réseau. En fait, j'ai utilisé @ ggambett comme référence. Ça a bien marché pour moi.
NoobsArePeople2

1

Il existe une description assez détaillée du moteur source. Il semblerait qu'une partie du code source pertinent soit également disponible dans le cadre du SDK source.

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Il utilise un certain nombre de techniques pour essayer de gérer la latence du réseau dans un modèle serveur-client. Le point principal semble être que le client local gère les entrées et autres événements localement comme s'il n'y avait pas de serveur, puis traite la possibilité que le serveur dise que le client l'a mal fait plus tard.

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.