Movement validation on server side
Author
Situation: A multiplayer FPS-like game, using a client/server model. For example, lets assume that updates are sent 30 times a second from both server->client and client->server.
The phrase 'never trust the client' is thrown around a lot here, but one thing that the client needs to have primary control over is the player movements for that client. There can not be any 'lag'; movement must be instant on the client side with no time to confirm with the server if the press of a movement key should have an effect or not. I understand this has caused lots problems in many commercial FPS's like counterstrike, where speed hacks could be used create unintended movement patterns for the client.
I am looking for ways in which the server can verify client movement, in real life circumstances (packet loss etc), or information on how other games handle this problem.
The details I would like to know are:
1. What data regarding player positioning/movement is sent from client to the server.
2. What methods does the server use to verify the movement, like I said keeping in mind packet loss, where the position between the currently received packet and the one received before may seem invalid (large difference in player position), but when considering the packets lost in-between, it may infact be valid. Similarly if the state of the movement keys are sent in every update, the missing ones due to packet loss can mean that a direct server side simulation of the player physics is not possible.
Both the server and the client have access to the player physics model, but as I mentioned above an identical 1-to-1 simulation on client-server may not be possible due to lost packets.
Any ideas?
1. What data regarding player positioning/movement is sent from client to the server.
Solution:
Player positon
Position player is facing
movement type (forward,back,left,right,strafeleft,straferight)
2. What methods does the server use to verify the movement, like I said keeping in mind packet loss, where the position between the currently received packet and the one received before may seem invalid (large difference in player position), but when considering the packets lost in-between, it may infact be valid. Similarly if the state of the movement keys are sent in every update, the missing ones due to packet loss can mean that a direct server side simulation of the player physics is not possible.
Solution:
simply the player does not move until you say he moved. But you will always verify if player is at x,y and moving to a,b at speed c is it possible? is there a wall in the way? can he move here? basically check for collisions in the path and that the distance <= speed than return to the client that its valid by giving all clients the updated position of that user (clients in view range)
Solution:
Player positon
Position player is facing
movement type (forward,back,left,right,strafeleft,straferight)
2. What methods does the server use to verify the movement, like I said keeping in mind packet loss, where the position between the currently received packet and the one received before may seem invalid (large difference in player position), but when considering the packets lost in-between, it may infact be valid. Similarly if the state of the movement keys are sent in every update, the missing ones due to packet loss can mean that a direct server side simulation of the player physics is not possible.
Solution:
simply the player does not move until you say he moved. But you will always verify if player is at x,y and moving to a,b at speed c is it possible? is there a wall in the way? can he move here? basically check for collisions in the path and that the distance <= speed than return to the client that its valid by giving all clients the updated position of that user (clients in view range)
The player needs to move immediately when the button is pressed -- everything else gives too much lag for an FPS. Also, for an FPS, you probably want to run the player at a physics rate that's higher than the networking control rate.
You can send a RLE compressed copy of the last N steps of input to the server; if there's some packet drop, the next packet will likely make up for it. You'll have to set up a system for managing where objects are at what specific physics step to have exact server-side hit detection, though. That way, you only need to send control inputs (WASD+walk/duck+fire/weapons+mouse aim) to the server.
On the client, display entities using forward extrapolation based on what the last received state is (typically, you'll linearly interpolate based on two forward extrapolated positions from the last two received packet updates). "State" might include things like rate-of-turn, to make someone keep turning while you're waiting for the next packet.
The server keeps sending entity state back to all the clients -- including entity state for the player himself. The client checks the server position for himself at the time it was received for, and compares against the log of where the client thought it was itself; if there's a discrepancy, it means the server is correcting the client, so the client needs to pay attention to that packet and update itself (this should be rare).
You can send a RLE compressed copy of the last N steps of input to the server; if there's some packet drop, the next packet will likely make up for it. You'll have to set up a system for managing where objects are at what specific physics step to have exact server-side hit detection, though. That way, you only need to send control inputs (WASD+walk/duck+fire/weapons+mouse aim) to the server.
On the client, display entities using forward extrapolation based on what the last received state is (typically, you'll linearly interpolate based on two forward extrapolated positions from the last two received packet updates). "State" might include things like rate-of-turn, to make someone keep turning while you're waiting for the next packet.
The server keeps sending entity state back to all the clients -- including entity state for the player himself. The client checks the server position for himself at the time it was received for, and compares against the log of where the client thought it was itself; if there's a discrepancy, it means the server is correcting the client, so the client needs to pay attention to that packet and update itself (this should be rare).
This artical on Dead Reckoning: Latency Hiding for Networked Games might be a good read. Even if it is several years old the fundamental ideas are solid and was the basis for the design of our movement/prediction system.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
