Timestep dans le jeu multijoueur


8

J'essaie d'envelopper mon cerveau autour du concept de création d'une expérience multijoueur serveur / client.

Mon problème est principalement lié à l'horodatage. Considérez le scénario suivant:

Un client se connecte à un serveur. Le client envoie ses entrées au serveur pour indiquer qu'il souhaite déménager. Le serveur simule l'entrée et détermine la position de ce client dans le monde du jeu.

Étant donné que le client et le serveur s'exécutent tous les deux sur des pas de temps différents, comment simulez-vous avec précision afin que tous les clients soient synchronisés avec le serveur? Mon serveur est actuellement réglé sur un pas de temps de 30 ms. Lorsque je traite des mouvements de clients, il y a potentiellement des centaines de demandes en attente de traitement, mais aucun moyen d'indiquer le temps qu'il a fallu entre chacune des demandes.

Je ne sais vraiment pas comment simuler correctement sur le serveur en fonction du temps, afin d'avoir tout synchronisé.



3
Vous pouvez également essayer ces liens: Gaffer multijoueur à rythme
AshenBee

Réponses:


3

Autrement dit, vous devez envoyer un horodatage avec chaque instantané du serveur et avec chaque entrée du client.

Aux deux extrémités, vous avez besoin d'un processus pour "remplir" toutes les trames où les paquets ne sont pas reçus.

Dans mon jeu (un jeu d'action rapide - le vôtre peut être différent), sur le serveur, je rejette toute entrée "plus ancienne" (hors service), et je suppose simplement que si aucun nouveau paquet d'entrée n'arrive, les mêmes boutons continuez à être maintenu enfoncé (il y a un peu plus de choses pour vous assurer que les pressions / relâchements des boutons courts sont traités, mais c'est la prémisse de base).

Sur le client, je garde un "tampon de retard" (décrit dans cet article que Tetrad a lié). J'utilise une moyenne mobile des heures d'arrivée pour m'assurer que le tampon de décalage reste à la bonne longueur - ce qui rend le jeu client un peu plus lent ou plus rapide pour rattraper son retard. Si les instantanés n'arrivent pas à temps, je fais une extrapolation sur le client. Sinon, j'interpole entre les instantanés dans le tampon.

Le client est également chargé de suivre le temps d'aller-retour pour les entrées et de l'utiliser pour la prédiction (le serveur renvoie l'horodatage de l'entrée qu'il a utilisé lors du calcul d'une trame donnée). Il met les entrées en mémoire tampon pendant cette durée, les rejouant pour prendre la position du joueur de la position "ancienne" (dans l'instantané du serveur) à la position "actuelle" prédite.

Fondamentalement, le serveur continue de fonctionner à une fréquence d'images fixe. Il appartient aux clients de rester synchronisés avec le serveur.

Bien sûr, ce n'est qu'un aperçu de haut niveau. Il y a beaucoup de petits détails que vous devez comprendre lorsque vous l'implémentez.


Si le serveur reçoit 10 commandes d'entrée d'un client entre un pas de temps du serveur. Le serveur exécute les 10 commandes d'entrée. Comment savons-nous combien de temps pour simuler chaque commande d'entrée? Que faire si vous ne recevez qu'une seule commande d'entrée, simulez-vous la commande sur toute la durée du pas de temps?
jgallant

1
@Jon La plupart des jeux "d'action" envoient une entrée sous forme de bouton haut / bas pour chaque image. Le serveur utilise alors que le dernier état reçu comme l' état de cette tique de mise à jour. Les paquets abandonnés, en retard et en désordre sont ignorés. (Au moins au niveau de base - vous pouvez, par exemple, ajouter des informations de séquençage supplémentaires afin qu'un état de montée ou de descente très bref ne soit pas ignoré, même en cas de chute.) C'est probablement ce que vous devriez faire pour toutes les entrées qui ont un timing associé . Les actions basées sur des commandes (par exemple: "déplacer ici" dans un RTS) n'ont généralement pas de durée associée - vous devez donc simplement les exécuter dans l'ordre.
Andrew Russell
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.