Authoritative movement with client side prediction

Question

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?

Answer 1

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.

Answer 2

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.