Entrée côté serveur

Actuellement dans mon jeu, le client n'est qu'un rendu. Lorsque l'état d'entrée est modifié, le client envoie un paquet au serveur et déplace le lecteur comme s'il traitait l'entrée, mais le serveur a le dernier mot sur la position.

Cela fonctionne généralement très bien, sauf pour un gros problème: la chute des bords. Fondamentalement, si un joueur marche vers un bord, disons une falaise, et s'arrête juste avant de sortir du bord, parfois une seconde plus tard, il sera téléporté hors du bord. Cela est dû au fait que le paquet «J'ai arrêté d'appuyer sur W» est envoyé une fois que le serveur a traité les informations.

Voici un diagramme de décalage pour vous aider à comprendre ce que je veux dire: http://i.imgur.com/Prr8K.png

Je pourrais simplement envoyer un paquet "W pressé" à chaque trame pour que le serveur le traite, mais cela semblerait être une solution coûteuse en bande passante.

Toute aide est appréciée!

Bien que le serveur ait le dernier mot sur la position, il doit le faire en vérifiant et en vérifiant la raison de ce que le client envoie comme entrées et position. Je dis cela parce que ce que vous faites déplace immédiatement le joueur et l'attente qui crée dans votre code est que le client est la vraie position.

Vous pensez que cela fonctionne généralement bien, mais ce n'est pas le cas. Remarque: vous dites que votre client n'est rien de plus qu'un moteur de rendu, puis lui donnez rapidement le contrôle local pour se déplacer sans messages du serveur. Vous ne pouvez pas jouer sur les deux tableaux, soit attendre que le serveur vous dise de bouger, soit assumer un certain contrôle sur votre position et utiliser le serveur pour vérifier les tricheurs.

Je note que vos réponses atteignent une seconde entière? C'est une latence de 500 ms, ce qui est ridiculement grand pour tout type de jeu d'action. Essayez de comprendre pourquoi ce retournement prend autant de temps, il peut s'agir de files d'attente de commandes sauvegardées de ne pas être traitées rapidement à une bande passante inondée ou même des démons provoquant de nombreux paquets perdus.

Je pense que ce qui devrait arriver est que

client sends a move + position update
server gets it t+latency time later
server verifies and sends out info to all clients
client receives this at (t+latency + latency)

La partie délicate ici est que si un client reçoit un message sur lui-même, il doit surtout l'ignorer à moins que ce message ne soit quelque chose comme "un mouvement invalide, allez plutôt à XYZ". Si ce message s'adresse au client de quelqu'un d'autre sur lequel vous obtenez des informations, vous devrez extrapoler en avant dans le temps afin qu'il semble être un peu là où il se trouvera.

Je comprends que votre question soit:

Le serveur reçoit un paquet lorsque je commence à appuyer sur le bouton «Suivant» et un autre paquet lorsque je relâche enfin le bouton «Suivant». Par conséquent, le mouvement réel sur le serveur commence et se termine environ 100 millisecondes «trop tard» dans le jeu réel par rapport à ce que le joueur exprime côté client. Donc, si le joueur veut se déplacer de 10 secondes, il peut finir par se déplacer 10.x secondes à la place x >= 1.

Il s'agit d'une mauvaise stratégie de conception car elle n'exprime pas la volonté du joueur dans le monde du jeu comme le souhaite le joueur, créant une expérience utilisateur plutôt médiocre.

La solution que je recommanderais est d'envoyer un paquet (aussi souvent que possible) qui indique combien de pas le joueur a pris et dans quelle direction. Le serveur met ensuite à jour le monde du jeu avec le nouvel emplacement du joueur s'il réussit un contrôle d'exactitude. Ainsi, le joueur peut se déplacer avec une grande précision et éviter de tomber de hauts rebords.

L'alternative serait de se souvenir des positions du joueur dans la dernière seconde et de corriger la position rétrospectivement au moment où le bouton a été relâché. On dirait que cela créerait cet effet élastique des temps anciens (uniquement pour une raison différente)

Donc, fondamentalement, vous devrez envoyer un paquet de quel bouton est pressé et quelle était l'heure de jeu réelle sur laquelle le bouton a été pressé, puis plus tard, quel bouton a été relâché et à quelle heure exacte.