On Time

I don't have a definitive reference for you, but here are some pointers, in stream-of-consciousness order.

1) Decouple the simulation from the rendering and do the simulation in discrete time steps ( ie 16 milliseconds per tick ).

These together make your physics more stable, and testable. As part of this, you will make your game loop take an time argument like so



also, your rendering probably needs a tick, but not necessarily the same value as the session tick.



The renderer can track the time since it last rendered to do motion trails, etc. This allows an easy freeze frame matrix-like effect.

For consistency, I always work in seconds with my physics.



3) Have a game session object that tracks the current time as seen by this game session.

This should be where all game-related things get their time count. Very few places in your engine should ever query the actual system time.
When the simulation is paused, tick is either not called, or called with a zero time value.

Something like the HUD, gui or menu probably needs the real-time clock to do animations.

4) Game events should have a time to activate.

This allows you to ensure events happen in causal order, as well as schedule events for the future.

5) If each game object has its own tick function taking a time parameter, each object could potentially operate in slow or fast motion.

6) Networked games need a consistent time measurement for all clients. Typically the server provides this at connect time, and may periodically update the time.

7) Networked games often benefit from tracking the real-time latency of each client to do prediction and correction.

The usual references are David Baraff, Ron Fedkiw, Thomas Jakobsen, Chris Hecker, Jeff Lander. I'd also suggest looking at David Wu's work. These should all pop up readily in a google search, and you should also find direct links if you search the forum archives.

Actually,

I misread your question, :). You might search the forum archives for "frame-rate independent physics" or "physics time step" or similar. Many folks, myself included, believe that using a constant physics time step that doesn't vary with frame rate is the way to go. It certainly makes for 100%, perfectly repeatable results on any hardware. And, sync'ing up with the real game clock so you don't have objects moving fast on fast CPU's, slow on slow CPU's, is quite easy. This is discussed in prior threads, even some in the past couple of weeks here.

Forum member Gaffer wrote a nice article on how to do fixed physics time stepping:

Fix Your Timestep!

Forum member lonesock has written a nice article on Verlet integration using a variable time step that helps make that method more stable when you do choose to use a variable time step. (Actually, without his approach, it is NOT Verlet integration when time step is variable. Traditional Verlet is based, by definition, on a fixed time step.) Good reading, but it is somewhat academic. If you don't want to learn the math, you aren't going to get too far I'm afraid.

Time-corrected Verlet Integration

[Edited by - grhodes_at_work on January 3, 2005 11:42:12 PM]