Game programming

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Game programming, a subset of game development, is the software development of video games. Game programming requires substantial skill in software engineering as well as specialization in one or more of the following areas, which overlap heavily to create a game: simulation, computer graphics, artificial intelligence, databases, stage design, physics, audio programming, and input. Though often engaged in by professional game programmers, many novices may program games as a hobby.

Development process[edit]

Professional game development usually begins with a game design, which itself has several possible origins. Occasionally the game development process starts with no clear design in mind, but as a series of experimentation. For example, game designer Will Wright began development of The Sims by getting programmers to experiment with several ideas.


Programmers are often required to produce prototypes of gameplay ideas and features. A great deal of prototyping may take place during pre-production, before the design document is complete, and may help determine what features the design specifies.

Prototypes are developed quickly with very little time for up-front design and mostly act as a proof of concept or to test ideas.

Game design[edit]

Though the programmer's main job is not to develop the game design, the programmers often contribute to the design, as do game artists. The game designer will solicit input from both the producer and the art and programming lead for ideas and strategies for the game design. Often individuals in non-lead positions also contribute, such as copywriters and other programmers and artists.

Programmers often closely follow the game design document. As the game development progresses, the design document changes as programming limitations and new capabilities are discovered and exploited.


During production, programmers churn out a great deal of source code to create the game described in the game's design document. Along the way, the design document is modified to meet limitations or expanded to exploit new features. The design document is very much a "living document" much of whose life is dictated by programmer's schedules, talent and resourcefulness.

While many programmers have some say in a game's content, most game producers solicit input from the lead programmer as to the status of a game programming development. The lead is responsible for knowing the status of all facets of the game's programming and for pointing out limitations. The lead programmer may also pass on suggestions from the programmers as to possible features they'd like to implement.

With today's visually rich content, the programmer must often interact with the art staff. This very much depends on the programmer's role, of course. For example, a 3D graphics programmer may need to work side by side with the game's 3D modelers discussing strategies and design considerations, while an AI programmer may need to interact very little, if at all, with the art staff. To help artists and level designers with their tasks, programmers may volunteer or be called upon to develop tools and utilities. Many of these may be for a specific purpose and can be buggy due to time constraints (time for development of such tools is often not included in a game's schedule) as well as because they are only for in-house use anyway. Many game tools are developed in RAD languages for quicker development and may be discarded after the completion of the game.


The formal quality assurance testing process, performed by professional game testers, begins well into game development. High-budget titles may begin testing with the first playable alpha, while low-budget and casual games might not enter testing until a release candidate is ready. The programmers' task is to fix errors and bugs as such are discovered by the QA teams.

Nearing completion[edit]

Final tasks include "polishing" the game, such as programmers fixing occasional bugs—from minor to catastrophic—that may arise during the last phases of testing.

Game developers may have a beta testing period, but the definition of such varies from developer to developer. Often a beta contains all of the game's features, but may have a few bugs or incomplete content. Few games are given a public beta period, for example, to measure stress tolerance for game servers.

When the game is deemed complete, it is said to have "gone gold" and is shipped off to the publisher. Depending on circumstances, the publisher may then subject it to its own quality assurance or may begin pressing the game from the gold master.


Once a game ships, the maintenance phase for the video game begins. Programmers wait for a period to get as many bug reports as possible. Once the developer thinks they've obtained enough feedback, the programmers start working on a patch. The patch may take weeks or months to develop, but it's intended to fix most bugs and problems with the game. Occasionally a patch may include extra features or content or may even alter gameplay.


Most modern games take from one to three years to complete. The length of development depends on a number of factors, but programming is required throughout all phases of development except the very early stages of game design.


Like other software, game development programs are generated from source code to the actual program (called the executable) by a compiler. Source code can be developed with almost any text editor, but most professional game programmers use a full integrated development environment (IDE). Once again, which IDE one uses depends on the target platform. Popular ones for Xbox and Windows development are Microsoft Visual Studio and CodeWarrior.

In addition to IDEs, many game development companies create custom tools developed to be used in-house. Some of these include prototypes and asset conversion tools (programs that change artwork, for example, into the game's custom format). Some custom tools may even be delivered with the game, such as a level editor.

Game development companies are often very willing to spend thousands of dollars to make sure their programmers are well equipped with the best tools. A well outfitted programmer may have two to three development systems and multiple monitors dominating their office or cubicle.

Programming languages[edit]

Language Strengths Weaknesses
Assembly Potentially minimal CPU overhead Error-prone, slow development, difficult to learn, not portable
C Widely known, numerous tools Lack of object-oriented functionality, difficult for large projects or multiple platforms
C++ Object-oriented, widely used, numerous tools Development costs of manual memory management, "boilerplate" code[citation needed], and potentially long compilation times
C# Object-oriented, automatic memory management, offers reflection Generally limited to Microsoft platforms (Windows and Xbox), garbage collection overhead, easily reverse-engineered
Java Object-oriented, automatic memory management, widely portable, offers reflection Lack of user-defined value-types, garbage collection overhead, memory overhead, unavailable on major gaming consoles, easily reverse-engineered
Eiffel, Smalltalk, Ada, etc. Fringe game languages, few game development tools
Scripting languages like Lua, Python, etc. Often used for gameplay scripting, but not for the bulk of the game code itself

Once the game's initial design has been agreed upon, the development language must be decided upon. The choice depends upon many factors, such as language familiarity of the programming staff, target platforms (such as PlayStation or Microsoft Windows), the execution speed requirements and the language of any game engines, APIs or libraries being used.

Today, because it is object oriented and compiles to binary (the native language of the target platform), the most popular game development language is C++[citation needed]. However, Java and C are also popular, but inappropriate for some projects. Assembly language is necessary for some video game console programming and in some routines that need to be as fast as possible[dubious ], or require very little storage space (e.g. very old systems).

High-level scripting languages are increasingly being used as embedded extensions to the underlying game written in a low or mid-level programming language such as C++. Many developers have created custom languages for their games, such as id Software's QuakeC and Epic Games' UnrealScript. Others have chosen existing ones like Lua and Python in order to avoid the difficulties of creating a language from scratch and teaching other programmers a proprietary language.

Vertex and pixel shaders are increasingly used in game development as programmable GPUs have become more prevalent. This has led to the increasing use of high level shading languages in game programming, such as nVidia's Cg, though it cannot be used for all of game logic.

APIs and libraries[edit]

A key decision in game programming is which, if any, APIs and libraries to use. Today, there are numerous libraries available which take care of key tasks of game programming. Some libraries can handle sound processing, input, and graphics rendering. Some can even handle some AI tasks such as pathfinding. There are even entire game engines that handle most of the tasks of game programming and only require coding game logic.

Which APIs and libraries one chooses depends largely on the target platform. For example, libraries for PlayStation 2 development may not be available for Microsoft Windows and vice-versa. However, there are game frameworks available that allow or ease cross-platform development, so programmers can program a game in a single language and have the game run on several platforms, such as the Wii, PlayStation 3, Xbox 360, PSP and Microsoft Windows.

Graphic APIs[edit]

Today, graphics are a key defining feature of most games. While 2D graphics used to be the norm for games released through the mid-1990s, most games now boast full 3D graphics. This is true even for games which are largely 2D in nature, such as Civilization III.

The most popular personal computer target platform is Microsoft Windows. Since it comes pre-installed on almost ninety percent of PCs sold, it has an extremely large user base. The two most popular 3D graphics APIs for Microsoft Windows are Direct3D and OpenGL. The benefits and weaknesses of each API are hotly debated among Windows game programmers. Both are natively supported on most modern 3D hardware for the PC.

DirectX is a collection of game APIs. Direct3D is DirectX's 3D API. Direct3D is freely available from Microsoft, as are the rest of the DirectX APIs. Microsoft developed DirectX for game programmers and continues to add features to the API. The DirectX specification is not controlled by an open arbitration committee and Microsoft is free to add, remove or change features. Direct3D is not portable; it is designed specifically for Microsoft Windows and no other platform (though a form of Direct3D is used on Microsoft's Xbox, Windows Phone 7.5 smartphones and mobile devices which run the Pocket PC operating system).

OpenGL is a portable API specification. Code written with OpenGL is easily ported between platforms with a compatible implementation. For example, Quake II, which uses OpenGL, was ported from Windows to Linux by a fan of the game. OpenGL is a standard maintained by the OpenGL Architecture Review Board (ARB). The ARB meets periodically to update the standard by adding emerging support for features of the latest 3D hardware. Since it is standards based and has been around the longest, OpenGL is used by and taught in colleges and universities around the world.[citation needed] In addition, the development tools provided by the manufacturers of some video game consoles (such as the Nintendo GameCube, the Nintendo DS, and the PSP) use graphic APIs that resemble OpenGL. OpenGL often lags behind on feature updates due to the lack of a permanent development team and the requirement that implementations begin development after the standard has been published. Programmers who choose to use it can access some hardware's latest 3D features, but only through non-standardized extensions. The situation may change in the future as the OpenGL architecture review board (ARB) has passed control of the specification to the Khronos Group in an attempt to counter the problem.[1]

Other APIs[edit]

For development on Microsoft Windows, the various APIs of DirectX may be used for input, sound effects, music, networking and the playback of videos. Many commercial libraries are available to accomplish these tasks, but since DirectX is available for free, it is the most widely used.

For console programming, the console manufacturers provide facilities for rendering graphics and the other tasks of game development. The console manufacturers also provide complete development systems, without which one cannot legally market nor develop games for their system. Third-party developers also sell toolkits or libraries that ease the development on one or more of these tasks or provide special benefits, such as cross-platform development capabilities.

Game structure[edit]

The central component of any game, from a programming standpoint, is the game loop. The game loop allows the game to run smoothly regardless of a user's input or lack thereof.

Most traditional software programs respond to user input and do nothing without it. For example, a word processor formats words and text as a user types. If the user doesn't type anything, the word processor does nothing. Some functions may take a long time to complete, but all are initiated by a user telling the program to do something.

Games, on the other hand, must continue to operate regardless of a user's input. The game loop allows this. A highly simplified game loop, in pseudocode, might look something like this:

while( user doesn't exit )
  check for user input
  run AI
  move enemies
  resolve collisions
  draw graphics
  play sounds
end while

The loop may be refined and modified as game development progresses, but most games are based on this basic idea.[2]

Game loops differ depending on the platform they are developed for. For example, games written for DOS and many consoles can dominate and exploit available processing resources without restraint. However, game for a modern PC operating system such as Microsoft Windows must operate within the constraints of the process scheduler. Some modern games run multiple threads so that, for example, the computation of character AI can be decoupled from the generation of smooth motion within the game. This has the disadvantage of (slightly) increased overhead, but the game may run more smoothly and efficiently on hyper-threading or multicore processors and on multiprocessor platforms. With the computer industry's focus on CPUs with more cores that can execute more threads, this is becoming increasingly important. Consoles like the Xbox 360 and PlayStation 3 already have more than one core per processor, and execute more than one thread per core.


The only platforms widely available for hobbyists to program are consumer operating systems. This is because development on game consoles requires special development systems that cost thousands of dollars. Often these must be obtained from the console manufacturer and are only sold or leased to professional game development studios. However, Microsoft used to distribute a game development framework, XNA, which runs on both Microsoft Windows and Xbox 360. XNA was discontinued, but other projects like MonoGame and SharpDX are trying to allow the same access for game coding. Games written for Windows often can be ported to Xbox with few changes. This allows individuals and small teams to develop games for consoles. Some hobbyists also develop homebrew games, especially for handheld systems or obsolete consoles.

Some software engineering students program games as exercises for learning a programming language or operating system.

Some hobbyists may use software packages that help with game development, such as Adobe Flash, Unity, pygame, Adventure Game Studio, GameMaker: Studio, Godot, or Construct.

See also[edit]


External links[edit]