And yes, time synchronization is complicated because it depends entirely on your network model, depending on your network technique you need very little of it, or a lot. I’ve shipped games with completely unsynchronized clocks, loosely synced clocks, and have done R&D projects with deterministic lockstep that requires complete synchronization.

cheers

However, as players can change direction almost instantly in FPS games (high jerk) prediction is of limited benefit. Most games assume you can get about 0.25secs of prediction in before it becomes potentially totally inaccurate, so if no packets are received after 0.25 secs the character stops extrapolating and stays still until the next packet arrives. This is rare, but avoids the players running fullspeed into walls when a player times out (it takes 10-15 secs to detect dirty disconnect via timeout…

In racing games input has a less direct effect, being that your momentum is so high the input typically guides the momentum slightly left vs. right, but cannot make the vehicle turn on a dime. Consider networking say, F-Zero or Wipeout for example. Here you should easily be able to come up with physics equations that predict 0.25sec or more of motion from the initial conditions sent each packet, and this prediction should be reasonably accurate. The error that needs to be repaired if the input changes and the remote view does not receive this is much smaller.

In some cases, especially physics simulation like with my “Fiedler’s Cubes” demo, the movement is slow and prediction is not necessarily important, except to fill the gaps between packets arriving — in this case, i just hold last inputs received and extrapolate with the physics simulation. You cannot do this for a racing game, because of the high speeds involved, the lag multiplied by the speed is quite a big difference in position, so you have to extrapolate forward to have two racing cars “next” to each other compensating for lag. But in my cube demo, speeds are slow, so I just have the other player cubes effectively running in the past.

I hope this is useful.

cheers

Another physics heavy sync approach can be seen in “Little Big Planet”. There is is networked deterministically by sending inputs, the cost being that you may only support a low player count (2-4) and the game network quality is proportional to the player with the worst network connection.

Also, see my GDC2011 talk about networked physics. The part in there about how GGPO does it, is basically the same strategy that LBP uses.

And yes. Yes he is

If you do #2, you really can only pull this off if you are COOP, or if you are on a console platform and have some way to detect these cheats. For example, Halo does this. Study the “Networking Halo Reach” talk by David Aldridge from GDC2011.

Even then it’s a large risk and the cheat detection code is onerous. I only recommend #2 if you lots of physically simulated objects that must interact with each other that would be too expensive/complicated to rewind and replay.

cheers

For more information google for “Latency Compensation Valve”

cheers