2
\$\begingroup\$

I've explored the concept of client-side prediction with reconciliation quite a bit and there's one thing that puzzles me a lot.

From what I've seen in most guides, the flow looks a bit like this:

T0. Client sends MOVE command and immediately simulates a predicted result.
T0. Server streams gamestate (server does not know about Client's MOVE command yet and thus the T0 gamestate does not contain results for it).
T3. Client receives gamestate T0 from the server. T0 does not contain any movement and thus Client is forced to reconcile with the Server gamestate.

This way, Client will have to reconcile with the Server every tick it receives because they will never agree. If Client would be delayed by ½RTT before predicting, Client and Server should agree most of the time, but that's an unwanted delay.

If the Client submits a tickstamp with each command sent, the server can apply those commands pasttime. But this would mean that the client is authorative because it can make the server reconcile with its commands. There's also an issue here where players with a high latency will be changing a relatively distant past on the server, potentially undoing/invalidating a lot of already streamed gamestates.

I suppose the Client could simply pretend that T3 is T0 (sync to a different server tick depending on how high the latency to Server is) but I don't know the effect of that when interacting with other non-predictable entities (such as other players). I guess the Client would take longer to reconcile with the correct Server gamestate because of the induced "tick latency".

Is there something I'm missing here? Which is the best way forward for a twitch gameplay competitive game? I.e. Air Hockey or similar.

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

I think the missing piece here is that. The server is authoritative. This means that the server state is the source of truth. The client states are just reproductions of the server state.

The server will apply client input packets as they are received. It doesn't care about client timestamps attached to them. As far as the server is concerned it is the source of truth and the clients' input happened when it received it.

The server will then push state snapshots to the clients. Because the server is the source of truth the clients will hard reset to these snapshots. The clients will also keep track of any input they collected since the last server snapshot was taken. They will then play these inputs back to bring it up to speed.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .