While having simulations match each other precisely is an admirable goal for some games, it comes with a steep computational and performance cost.

Every game I've worked on, and nearly every fast-paced game I've read about, follow a model where everybody does their own thing and continuously corrects to whatever source they consider authoritative.  Close enough is usually adequate, for the few things that require round-trip verification you can often mask the latency with a mix of audio and animations.

There is significant difficulty even in making the CPU instructions work deterministically. SSE floating point operations have been a massive improvement in this area between machines, but still many math functions like trig operations give various results both between machines and even in different locations in the code. The optimizer is also not friendly for keeping other operations deterministic and properly sequenced everywhere.  It can be done, but I don't envy anyone who has to do it.

On 2/6/2019 at 3:17 AM, Hodgman said:

We do a clock-synchronization process during connection to get a common wall clock for each client and the server to refer to, and then the clients can adjust their in-game clock appropriately to maintain themselves in the future slightly.

I've been trying to understand how jitter is handled myself after reading Gaffer's article on state sync. He explains the reasons why he delays but nothing specifically about how the client chooses it's time base. Could you elaborate on how you do this a little? eg what amount of time you spending choosing the right number and how you handle resolving if the time drifts and the client is ahead/behind?