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?).

Coming Soon

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

The Three Questions

Do I have a portfolio?

This is probably one of the most important parts of getting a job in the game industry. If you don’t have a portfolio, the other guy will, and that’s a problem. Portfolio’s are meant to show off your previous work done. In this day and age, employers expect that you have already done your homework in whatever discipline you aspire to take on as a career.

Programming – Example Portfolio Site

Programmers need to make games that showcase what it is they want to do. For example, if you want to create AI systems in the industry, create something that showcases your knowledge on exactly that! Another example would be a graphics programmer making a game that showcased their knowledge of shaders. Your future employer does not want to be confused on your ambitions, so make it extremely clear what it is you want to do through your work, and your website.

Art – Example Portfolio Site

Same goes for artists as it does for programmers — specialization is key. Becoming a conceptual artist require different preparation than becoming a 3D animator or level designer. Whatever your niche may be, you still need many examples of your work.

Design – Example Portfolio Site — Game Career Guide Information

Becoming a game designer is not easy. Normally game design positions are really allocated to those with industry experience, but there are exceptions to anything. If you want to become a game designer you need full work games. A common misconception is that creating a game design document is what employers are looking for. This is very wrong, your peers want to see working games that they can play and analyze — such as a complete board game — although you will need to refer to the link posted above for more clarification.

Do I have connections?

Game Developers Conference – Survival Guide for GDC

Every year our officer team goes to GDC in San Francisco. If you are serious about entering this industry as a professional, this is a must go event. Contacts are everything in this game, and you can attain 40+ more actual game industry contacts just by showing up here and handing your resume / business card out like a mad-man.

IGDA Chapter meetings

Find your local IGDA chapter and go! Plenty of industry members and enthusiasts are bound to be found in or around it. Google is your friend for finding out this sort of information in specifics.

Do I have a degree?

You need to get a degree. Essentially a company has no reason to hire you if you don’t have a degree — unless you are a savant. But if you aren’t a savant, get your degree in whatever discipline you’re interested in. Here is a list of appropriate degrees for Cal Poly students.

Programming

B.S. in Computer Science
B.S. in Computer Engineering

Art and Design

B.F.A in Graphic Design

If…

and when you have answered all these questions with a big Yes, then it is time to start applying for jobs and internships. Below you will find a list of links in which to get started with the next part of your journey. Think of this whole process like a quest chain.

Game Jobs

Gamasutra Listings

EA Listings

Blizzard Listings

Game Internships

Gamasutra Guide

For all other Information (for the most part)

Tom Sloper has put together an amazing questionnaire that should be review by any aspiring game developer. It is probably the most truthful guide I have ever read, and will definitely put you in a good direction in case you don’t believe anything that I am saying. In any case, enjoy:

Game Engines

Irrlicht Engine — free

• One of the biggest benefits of Irrlicht is the amount of starter tutorials that have been documented
• It has language bindings with .Net, Java, C++, Python, Ruby, and Lua
• Supports a wealth of level and model formats
• 3D rendering support with OpenGL, DirectX 8/9, and a custom software rasterizer

Ogre 3D Engine — free

• A very robust 3D graphics engine written in and for C++
• Not a game engine like Irrlicht — is purely for rendering in OpenGL or DirectX 9
• Support handling for most 3D modeling export tools such as Maya, 3D Studio Max and Milkshape

GarageGames Torque Engine Series — ranging from $150 – 350 for students

• Fully capable game engines complete with Audio/Input/GUI/3D and 2D rendering components
• Some of the newer engines do not have full documentation and can be hard to use
• The more successful engines such as Torque3D and Torque2D are widely support and have a very large user base
• Come with many custom-made tools, and many books have been written on their engines

Game Libraries

OpenGL – graphics / input

• cross-platform API for 2D and 3D graphics
• hides the complexities of interfacing with different 3D accelerators
• highly documented, many tutorials, many, many books on how to use it

DirectX — graphics / sound / input

• a collection of many API’s for handling tasks related to game programming
• if you use pure DirectX for your projects, the dependencies are much easier to manage
• Has language bindings for C++ and C#
• has a lot of documentation which has been come in form of books / articles / tutorials

SDL – graphics / sound / input

• has the largest amount of available language bindings (refer to site for list)
• is an abstraction of OpenGL, making it a bit easier to read and code with
• highly documented in the form of books / tutorials / articles

Allegro– graphics / sound / input

• game programming library for C/C++ developers distributed freely
• Supports DOS, Unix (Linux, FreeBSD, Irix, Solaris, Darwin), Windows, QNX, BeOS and MacOS X
• Very old and stable with lots of projects and tutorials
• Simple API for graphics sound and input

Physics Libraries

PAL – Physics Abstraction Layer

• Uniform API which has Plug and Play for almost all the major physics engines
• Complete list here

Art, Modeling, and Sound

Blender — all purpose model creation tool for games

• Can be used for modeling, UV unwrapping, texturing, rigging, water simulations, skinning, animating, rendering, particle and other simulations, non-linear editing, compositing, and creating interactive 3D applications.

Gimp — graphics tool

• It’s like Photoshop, but free

Audacity — audio creation and editing tool

• cross-platform and is available for Windows, Mac OS X, Linux and BSD
• many features, including multi-track mixing, amplitude envelope editing, selective noise removal, etc.

Milkshape3D – low polygon modeling tool

• famous for its large repertoire of export capabilities (70 file formats)
• can also act as a skeletal animator and viewer

Software Engineering

Subversion — version control

• allows you to perform the most common version control operations directly from inside the Microsoft Visual Studio IDE
• requires a web server for installation

MSDN Academic Alliance for Cal Poly Pomona students

• Free Microsoft software for Cal Poly Pomona students
• requires your Cal Poly Pomona login information to access

Eclipse IDE – software development tool

• Allows you to build programs in Java, C++, C, COBOL, Python, Perl and PHP
• Supports many user-created plugins for the Eclipse Framework

Doxygen – automatic API generation for projects

• generates documentation for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#,