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.
