Jump to content
Posted 11 February 2012 - 11:18 PM
Posted 13 February 2012 - 06:24 AM
Posted 13 February 2012 - 01:54 PM
Posted 14 February 2012 - 09:41 AM
And that's a lot of prediction. When Client A changes direction and sends this message to the Server, the server performs a correction, then sends this out to Client B - and for all that time, Client B was simulating Client A's old position, based on old data from the server. That's a whole round-trip of latency to smooth out and no way you slice and dice it can get around that. Information takes time to travel, so you either have the correct information later or an estimate now.
The only real server-side prediction I do is assuming a client will retain a given input configuration until a client says otherwise. When a client does say otherwise, I roll back and re-simulate with the correct input configuration applied at the correct time.
Some don't rollback at all. There are arguments between various factions as to which approach is fairer. The Valve model is fairer for the shooter than the shootee, because it ensures that the shot is resolved relative to what the shooter was observing. Other models look at the authoritative server data copy at that time and may resolve the shot differently. Client A might have been able to see Client B in the open when he pressed the trigger, but the server may know that Client B was already behind cover by then and won't punish Client B for Client A's poor latency. It's just a decision each developer has to make.
Do shooters really only rollback to apply hit correction?