It depends on the design of your game.

For many games, the better design is to have some globally-accessible timing information.

Common timers include:
* simulator step. A single unsigned integer for how much game time has passed. One tick may equal 1/4 second, or 1/10 second, or some other value. This stops when the game is paused.
* frame time. Often a high-performance counter or floating point number that shows how much time has passed since the last redraw
* wall time since program was started.


The game is then run "as fast as possible", and does not wait around for system timers. Rendering waits only until the display buffers have been flipped, the simulation ticks away on its own, sometimes running multiple ticks in a single visible frame.

It is generally unwise to base much of your game on the general purpose timers the system provides. While those timers are useful for many tasks, and they can be used for form games and turn games and such, they are not really designed for interactive animated simulators. Consider that the system timer has 15.6ms resolution on Windows 7, and different resolutions on older system. Then consider most of today's panel displays have refresh rates of 75 frames per second, or 13.3ms. The fact that a single timer tick is longer than an entire display frame would, by itself, disqualify it for use in many games.

Here's a C# simple static timer class I used on a game server. Uses a C# StopWatch to calculate the time elapsed since the previous frame in milliseconds.



//----------------------------------------------------------------
// TimeMgr.cs - time elapsed since previous update
//
// to use:
// - call TimeMgr.Initialize() on game start
// - at the start of every game update call TimeMgr.Update()
// - public field TimeMgr.timeElapsed is the elapsed
// milliseconds since the previous update
//----------------------------------------------------------------
using System.Diagnostics;

public static class TimeMgr
{

// stop watch and private vars
private static Stopwatch stopWatch;
private static float currentTime = 0f;
private static float oldTime = 0f;


// time elapsed since the previous tick
public static float timeElapsed = 0f;


//----------------------------------------------------------------
// Initialize() - init stopwatch
//----------------------------------------------------------------
public static void Initialize()
{
stopWatch = new Stopwatch();
stopWatch.Reset();
stopWatch.Start();
}


//----------------------------------------------------------------
// Update() - save previous time elapsed
// - update current time elapsed
//----------------------------------------------------------------
public static void Update()
{
oldTime = currentTime;
currentTime = (float)stopWatch.ElapsedMilliseconds;
timeElapsed = currentTime - oldTime;
}


}



while(gameRunning)
{
// Game logic, input, etc.
timer++;


Do I at least have the general idea of the concept? I've been pretty underslept lately, so I could be way off...

Basically, but I'd call it something like "simulatorTick".

The simulator is independent of everything else. It is independent of wall clock, allowing you to pause the simulator or fast-forward to 2x or 4x or other speeds. It is independent of rendering, or else you couldn't draw anything while paused or it would stutter if the CPU is busy with spyware or other tasks, or for some other reason frame rate changes. The simulator timing is independent of networking, independent of input hardware like keyboard and mouse, independent of window events, and so on. The simulator should be isolated from reality as much as possible.

Many systems, like physics, animations, and IA, should operate in terms of that simulator tick, not the real clock time.



All of that said, there is still a place for the C# timer objects if you choose to use them. They just don't belong as part of the simulator for most games.