Time is really no different to any other game parameter.
You can think of a game as a giant simulation. When you make a networked game, parallel copies of these simulations are running on each machine. Because things are never exactly in sync (due to latency, packet loss, limited ability to send data from one machine to another, etc), these simulations will gradually diverge. It's like the butterfly effect: a single dropped frame may initially be only a tiny difference, but after another few minutes of gameplay, this will have magnified to the point where the two machines are obviously in a totally different state.
The goal of a good game networking system is to keep all simulations close enough together that the player will never notice any errors.
You can tackle this on many levels. One way would be to synchronize just the most basic input parameters, like time, gamepad button presses, etc, and then rely on each machine to independently repeat the exact same simulation based on those inputs. This can be very efficient (because there are typically not very many inputs) but is extremely fragile (if anything goes even slightly out of sync, it is then impossible to recover).
Another approach is just to let the input parameters get out of sync, and then re-coordinate higher level results such as the position of your player character in the game world. With that approach, it doesn't matter so much if a single frame goes missing, or a button press gets missed, since a later network packet will correct for it and move the player to their correct position regardless.
Choosing the right things to synchronize isn't easy, and tends to be different for each game: you need to find the right balance of objects which will be relatively small to synchronize, and relatively stable in their behaviors (so you can predict how they will move in between packets without too much butterfly-effect chaos getting in the way), while still being comprehensive enough to make the simulation seem consistent to the player.
For some games, time could well be one of the things that needs to be synchronized, but for many it will not be. Bear in mind that network packet send rates are very low (often around 5 to 20 frames per second) compared to game update framerates (typically 60 frames a second, or sometimes 30). This means that once you implement some prediction and smoothing to fill in the gaps between your 5 frames per second network packets, it may not end up making any difference at all if one machine happens to drop a 1/60 second frame during that interval, while another does not.
--
XNA Framework Developer
blog -
homepage