4
\$\begingroup\$

I don't fully understand how client side prediction works with authoritative movement.

Let's say we have:

  1. client at position(0,0)
  2. server at position(0,0)

Now the client wants to move forward and calls a client side function move and then sends the server that the client wants to move forward.

Now the client has moved to position(10,0), while the server is still at position(0,0). Now the server moves to position(10,0) and sends an update to all clients.

But the client has now moved to position(20,0) and now receives the position state from the server that the client should be at position(10,0).

What happens now? The client can't just apply the position from the server otherwise the client would jitter around.

One simple solution that I could think of would be a distance check.

if(Distance(position(10,0),position(20,0) > SomeNumber){
   ForceUpdatePos();
}

But this is probably not a good idea because SomeNumber depends on the MovementSpeed and latency.

I probably also would have to include a timestamp of the package because maybe the client has not heard back from the server for several ticks and then receives a bunch of unordered position updates.

What is a common technique to solve this problem?

\$\endgroup\$
  • \$\begingroup\$ I would just not send the clients new position to itself at all (only to the other players) and let the client do its thing. Only if the server dislikes the clients movements, it should send the client a new position. \$\endgroup\$ – tkausl Jul 23 '15 at 18:38
1
\$\begingroup\$

The concept is that the new position is just predicted. When the next server-side position is received, client prediction is disabled. The client just guesses the future positions until the server verifies them.

Most game servers take the delay in account as well. In every client message the timestamp of the local player is sent. The server can now speed up the movement of the affected client character for a short period of time to conceal the delay between the input command of the player and the serverside movement which removes the jittering.

\$\endgroup\$
  • 1
    \$\begingroup\$ Also, the client can blend from it's predicted location to the authoritative position over a short period of time to hide the fact that it predicted wrong. \$\endgroup\$ – Alan Wolfe Jul 25 '15 at 16:19
  • 1
    \$\begingroup\$ Completely right, thats also the reason why killing enemies or interacting with items cannot be predicted. \$\endgroup\$ – Doctor Niklas Jul 25 '15 at 16:30
1
\$\begingroup\$

Input prediction generally works as following: Client sends commands to Server AND runs the same code as the Server to predict its actions. Client stores a number of timestamped commands. Now in the same step:

  • Client receives new state from server.
  • Client (knows its latency) rolls back in time for [latency] seconds (undo commands relative to [latency] seconds back).
  • Client updates past state using received state (from Server).
  • Client re runs commands to retrieve corrected present state.

In the server side: Server receives commands from Client. Server runs Client commands. Server sends new Client state.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.