CODEWITHSUNDEEP
network-programmingclient-servergame-development
Bizcochito
Bizcochito

Reputation: 57

Client-side prediction & server reconciliation

I’ve read some articles about client-side prediction and server reconciliation but I'm missing some parts, I take the part of client side prediction but I don’t understand how exactly is reconciliation done. I’ll take these two pieces of well-known articles as reference:

http://www.gabrielgambetta.com/fpm2.html

#2. So applying client-side prediction again, the client can calculate the “present” state of the game based on the last authoritative state sent by the server, plus the inputs the server hasn’t processed yet

http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

In effect the client invisibly “rewinds and replays” the last n frames of local player character movement while holding the rest of the world fixed

Ok, I take that the client receives an acknowledgement from the server, but how exactly are the inputs re-applied? I can interpret this in two ways.

From the client point of view, where the game loop is executed ‘x’ times per second (frames per second)

First: The non-processed inputs are re-applied in the same frame, so here the expression “invisibly rewind and replay “ fits perfect because in the end what you see in the screen is the result for the last input re-applied.

I don’t see the benefit of doing this because I see no difference between re-applying the last n inputs from the server update to the present time and keeping the client state as it was before the update, we know in advance that the result will be the same.

Second: The inputs are re-applied one by one in the consecutive frames . A human being couldn’t notice a few frames being replayed but I cannot help thinking that if the client were experiencing significant latency he could notice himself going back to the past and replaying the last ‘n’ frames.

Can anyone point me in the right direction , please? Thanks

Upvotes: 4

Views: 3277

Answers (2)

DarQ
DarQ

Reputation: 102

I don’t see the benefit of doing this because I see no difference between re-applying the last n inputs from the server update to the present time and keeping the client state as it was before the update, we know in advance that the result will be the same.

You are correct if and only if the predicted GameState match the server GameState (the one we just received) so there is no reason to do any reconciliation. However, if they don't match, reapplying the inputs would give us a different result. That's when you apply server reconciliation.

Upvotes: 0

marsermd
marsermd

Reputation: 188

I know it's been quite a while since you've posted this question, but it is on google's feed, so I'll answer.

I don’t see the benefit of doing this because I see no difference between re-applying the last n inputs from the server update to the present time and keeping the client state as it was before the update, we know in advance that the result will be the same.

The whole point of reconciliation is to sync with the server. We don't really know what the result of our actions will be. We just predict it. Sometimes the result actually is different and we still want to get an image of what's going on on the server.

The first way is definitely the way to go.

The second way doesn't really make any sense. Remember that the player receives updates on a regular basis. That means that with a latency of 200 ms he will see his character about 200 ms in past all the time.

Upvotes: 3

Related Questions