client side prediction
Members - Reputation: 103
Posted 03 October 2012 - 03:06 PM
GDNet+ - Reputation: 2177
Posted 05 October 2012 - 06:54 PM
- The client keeps a cache of each inputs, and its associated predicted state, and each stamped with a sequence number.
- The server then runs those inputs in sequence, hopefully with no gaps, and compute the player state.
- The server sends back the latest player state, along with the latest sequence number received.
- If the server updates diverge from the local prediction (you can compare them by finding the prediction matching the sequence numbers), the client then resets his local player state to the correction, and re-run the subsequent inputs stored in his local cache, to compute the latest local predicted state.
So in short, you need to cache the inputs, and the associated prediction on the client so you can re-apply those inputs and re-adjust the predictions after a divergence is detected.
And so on and so forth. Once diverging, it is likely the client will still diverge to at least the time it takes for a round-trip latency, often more as divergences are generally caused by external event in the player's proximity. So as long as you have some unpredictable perturbation near the player, the client will need to correct himself continuously. Then everything will get in sync once the player is free from external forces.
There is an obvious network optimisation here, but that's a trivial change.
Edited by papalazaru, 05 October 2012 - 07:07 PM.
Everything is better with Metal.