How video games are programmed

Programming a modern video game is a major software engineering effort, usually requiring the work of a large team of programmers.

  • The art pipeline

    The programming tasks can be broken into two parts, code that runs the game (the game engine) and tools that process the data into a form the engine can use. Most often, off the shelf tools are used to create the art for the game. A variety of 3d modeling, animation and image processing tools are used by artists to create the raw materiels for the game

  • Tools programming
    Some teams use a custom tool to actually build the levels in the game and such a tool usually includes a limited ability to manipulate the 3d objects generated by the artists. This tool also puts the world, the objects, animations, textures into a level file. This file is ready to load into the game.

    So why do you need to process the data? Well there are a few reasons. Alot of times you can pre-process the data to do some time consuming calculations on the tool side, so your game doesn't have to spend valueable CPU time, when it doesn't need to. Also, the format that the 3d modeler and animation programs produce are probably not going to be the best data for the hardware to display. These tools massage the data into the ideal form for the game to draw at optimum speed. Sometimes it's also possible to compress the data, to decrease the time it takes to load and the amount of ram it takes up once it's loaded.

  • Scripting Vs. programming
    Some might argue that scripters are programming the game and this is perhaps a valid arguement. The complexity of a scripting system can easily approach the complexity of the actual language used to program the game. On the other hand, some systems have little or no scripting at all, limited to placement of game elements and simple activation of the placed objects based perhaps on where the players character walks.

  • The game engine
    It is at this point that the engine programmers job begins. The actual game code is ideally content free. In other words the game is made mostly by the level designers, artists, and scripters. So if the content isn't in the engine, what is in the engine? The engine contains the code that draws the world and the objects in it, animates those objects, checks for user input via the joypad, checks for object collisions, handles loading and unloading of level data, manages the score, plays music and sound effects, and runs the scripts and game ai. Usually a code module will exist that handles the players character, causing the player's avatar to run, jump, swim, fight or do whatever it is the player is able to do.

  • Sound and music Usually a module for sound and a module for music is created. The sound module handles allocation of the hardware resources or voices. The music module for modern games is usually responsible for streaming small chunks of the song into sound ram. See how video game music is created for an in depth look at this process.

  • Physics
    You shoot the glass, and it shatters - in an absolutly 100% accurately modeled way. In a PC simulation, this is probably a good thing. Sim heads love this kind of stuff. In a video game most gamers probably won't notice. But, the programmer was way into it, very proud of it, and probably had a blast coding it. So who's to say it's a bad idea? Except for the fact that the game isn't fun. Or it didn't ship on time (Did it ship at all?). Or it had too many bugs.

  • Debugging
    This is usually a big challange on any project, video game or otherwise. But it becomes an even bigger challange when the hardware you're developing for is beta (not yet finished) and your development system may have problems, both hardware and software. It could very well end up that there's limited debugging capabilities(like no debugger, just printf), incomplete or just plain wrong documentation, and hardware that actually changes on you. Even if the developement environment is good, eventually you'll run into a bug that only happens on the actual game system.It's a little bit like doing embedded systems programming. This sucks.

Just ship it.
One of the most difficult and nebulous concepts in video game programming is sometimes refered to as fun factor. In this age of lightening fast supercomputer video game systems, in the midst of flashy graphics, sound effect, cinematic musical scores, it's easy to overlook. It's also impossible to quantify. What is it that makes a game fun? If I knew the answer, I'd be rich. But I think you can get a clue about how much fun it's going to be, by whether the people who made the game enjoyed making it.