To start, some definitions:

High Resolution: this means that small increments of time can be discerned. Usually in games this means around the tens of milliseconds to nanoseconds range when talking about video games.

Low Resolution: this means that only large increments of time can be measured. Anything above one second (minutes, hours, months, years, centuries… etc.) is considered low resolution for a video game

Refresh rate: how many times a monitor or LCD is refreshed. Almost certainly going to be between 60 -85 Hz (60- 85 times a second).

Frame rate: how many times the image for the game is changed. Your screen will always be refreshed 60 times a second but if your game takes half a second (0.5 seconds) to compute player positions, collision,  awesome particle effects, and then display the changes; your frame rate is going to be 2 (the screen will be refreshed 30 times with the same image because your game hasn’t gotten around to changing the memory where your video is stored but spent time doing other game logic stuff).

Game-Speed / Time Step: Game speed is totally different concept than fps or refresh although they can be dependant on one another. A constant game-speed is desired for anyone who plays your video game so that you can design a fair game with predictable results.  All the concepts presented here are basically to achieve a constant rate for gameplay despite varying cpu and fps changes. A time step is just the time that goes by in any simulation – Sometimes there are multiple time steps that happen in a frame to increase the accuracy of the simulation

Ok, hopefully you understand most of that. Next, here is a brief explanation of the three main timing techniques used for games

Technique #1 –  Non-Stop Game-Loop with loop delays

This is by far the most used way to time video games on older generation video game consoles and computers – DON’T DO IT!!!. Rendering the graphics and doing game logic were developed with particular machines with a particular cpu speed and with the expectation that the video game will not have full control of all computing resources and will not share it.

while(!ending)
{
    runGame(); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
}
void runGame()
{
    float unit = 4.5;
    xTransformSprite(unit);
}

In the main game-loop, which is running constantly, a tiny loop that does nothing inside of it but waste time by counting to some constant, is tweaked by the programmer (sometimes user defined) and is used to delay for a certain period until the program updates at the desired frame rate.

As you can see, downsides to this approach include a barrier of putting hard-coded values in your code, that when your program take longer than you anticipated for the game-loop, all those values have to be accommodated for a slower frame rate.

Technique #2 – Callbacks and Interrupts

This process is actually still very common and is very similar to the previous technique except for 2 small differences. The first is that instead of using a loop, it requests the Operating System to wait for a specified period of time and then come back. The other difference and advantage is that this gives other programs a chance to run.

a call-back for a game loop might look something like this using Allegro

while(!ending)
{
    runGame(); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
    rest(50); // tells the system to take back control and return in 50 milliseconds
}
void runGame()
{
    float unit = 4.5;
    xTransformSprite(unit);
}

For handheld systems, hardware interrupts are a way of performing this exact task they are similar to callbacks except they are a very reliable way of timing your game. On the Game boy advance, for example, all the game logic and drawing has to be done in between the screen refresh, and it is called from the beginning every time the screen is rendered. On the GBA the screen Refresh, FPS and Game-loop are all synchronized. As long as you have complete control of the hardware as in the case of the GBA, this method is a very suitable way to time your game. Even If you don’t have control over the hardware, no-one will probably get on your case if you stick with this method if your game is fairly simple.

Technique #3 – Delta Time

This is where things start to get hairy. Depending on the language you use and the OS, getting current system time at a high resolution can be very different. One way to solve this is to use a High Resolution Timer Library where someone has done all the hard work.

The basic idea is that all systems are generally guaranteed to provide accurate time up to the second but no more. Access to the OS’s API probably reveals functions that aren’t very friendly to timing your games in tenths or hundredths of a second but probably in “Clock Ticks”,  and may even provide a clock ticks per second function. Although the thought of learning windows programming may be strike fear in the novice programmer, like I said before, there are other options: Java and C# have pretty good timer functions. For C++, there are many game and general utility libraries also provide a high-resolution timer function that is easy to use in game. The following is usually how it’s done if you get your time in milliseconds -

int last = System.getTimeMillisecond(); //our timing library function in milliseconds
int current = last;
while(!ending)
{
    runGame(current – last); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
    last = current;
    current = System.getTimeMillisecond();
}
void runGame(int delta)
{
    float secondsSinceLastFrame = delta / 1000.0;
    float unit = 4.5;
    xTransformSpriteUnitsPerSecond(unit *secondsSinceLastFrame);
}

And that’s it! I think Koray has done some Windows API timing so well see if that stuff makes it in here.

This is just a rough draft so please email me of missing/wrong information or what you would want in simulations 102 (particles anyone?).

Take a look around. Every game that is currently on the market — and probably 75% of all amateur games made — feature some kind of menu system. Oddly though, one of the most common questions that I come across from people looking to make their own games, is how exactly do you get that effect? And not just from a conceptual standpoint, how do you implement a menu system that can take care of loading systems, splash screens, menu options, and above all just rendering the game?

Well, the hope is that this tutorial will clarify just that. Most of the examples will be in pseduo-code format, but if you have any questions on implementation feel free to ask me or any of our officer team. Rest assured though, the examples that I will provide should be enough to start coding up your own game state system.

Primer

The basic premise behind any game, is that there’s a continuous loop constantly running throughout the program — and it’s basically up to you to decide what happens within it. This process is commonly referred to as the game loop, and it will normally handle all of the rendering, sound, music, physics, and whatever else is happening in your game.  Simply put, the game-state system is designed to allow control in what gets rendered, what inputs do and do not get processed, what music / sounds get played, and whatever else you might want to control throughout the life of your program.

Think of the game-state system as a giant switch-case block within your game loop. For example:

void Game::gameLoop()
{
	switch(gameState->gamestate)
	{
		case gameState->LOADINGSCREEN:
			break;

		case gameState->ENGINESCREEN:
			break;

		case gameState->INTROSCREEN:
			break;

		case gameState->MENUSCREEN:
			break;

		case gameState->SINGLEPLAYER:
			break;

		case gameState->MULTIPLAYER:
			break;

		case gameState->KIOSK:
			break;

		case gameState->CREDITS:
			break;
	}
}

The code above shows a skeleton function for a game-loop. The case’s obviously have no true implementation at the moment, but that is irrelevant. Somewhere outside of this statement in other game / engine code, another function could trigger the changing of a game-state. When that happens, something like this could occur:

void Game::gameLoop()
{
	switch(gameState->gamestate)
	{
		case gameState->LOADINGSCREEN:

			/*
			* The game runs a load functions for game components
			* When the function finishes, it triggers our gameState
			* object to go to the next game state which is ENGINESCREEN
			* as seen below
			*/

			break;

		case gameState->ENGINESCREEN:
			break;
	}
}

At this point, instead of rendering our loading screens, the game could now be rendering a splash screen, playing new music, and doing whatever else that was inside the next case statement. And there you go, you have your first state change withing your game.

In C++, the switch-case statement can only accept integer types for the switch case statement — lame. Lucky for us however, we treat anything we want as an enumeration, which is readable to us, and internally represented as an int value.

class GameState
{

public:
	static GameState* getInstance();

	enum State { LOADINGSCREEN, ENGINESCREEN, INTROSCREEN,
	 MENUSCREEN, SINGLEPLAYER, MULTIPLAYER, KIOSK,
	 CREDITS, INSTRUCTIONS};

	int gamestate;

	~GameState();

protected:
	GameState();

	GameState(const GameState&);
	GameState& operator= (const GameState&);

private:
	static GameState* instance;
};

The code above was taken directly from our PHASE project, so for now ignore everything in the code except for the enum State statement and int gamestate.

Whew, done

The great thing about the state system is that it can be applied to many problems in game programming. For example, a great way to manage weapons in a first person shooter, would be to make a state machine like our previous examples, but instead apply it to switching through an inventory of your arsenal using the mouse wheel or number keys. You could even have nested state systems to handle more complicated tasks — such as loading levels in a particular game-state (I.E. Singleplayer mode):

void Game::gameLoop()
{
	switch(gameState->gamestate)
	{
		case gameState->SINGLEPLAYER:
			switch(Level->level)
			{
				case mouse->LEVELONESELECT:
					levelOne->render();
					break;

				case mouse->LEVELTWOSELECT:
					levelTwo->render();
					break;

				case mouse->LEVELTHREESELECT:
					levelThree->render();
					break;
			}
			break;
	}
}

And there you have it folks, a working game-state system