Game programming
|
|
John_Carmack_working.jpg
Game programming is a subset of game development. It deals with programming computer, console or arcade games. Though often engaged in by professional game programmers, many novices may program games as a hobby. Most software engineering students program games as exercises for learning a programming language or operating system. In fact, the Unix operating system and the C programming language exist because the original programmers wanted to play games.
| Contents |
The development process
Professional game development usually begins with a game design, which itself has several possible origins. The occasional game starts development with no clear game design, but as a series of experimentations. The best selling computer game of all time, The Sims, was developed by the game designer, Will Wright, by getting programmers to experiment with several different ideas he had.
Prototyping
Writing prototypes of gameplay ideas and features are an important activity that allows programmers and game designers to experiment with different algorithms and usability scenarios for a game. A great deal of prototyping may take place during pre-production before the design document is complete and may, in fact, help determine what features the design specifies. Prototyping may also take place during active development to test new ideas as the game emerges.
Prototypes need not be developed in the target language for the game. They are meant only to act as a proof of concept or to test ideas. Most algorithms and features debuted in a prototype may be ported to the implementation language of the game once they have been completed.
Often prototypes need to be developed quickly with very little time for up-front design. Therefore usually very prolific programmers are called upon to quickly code these testbed tools. RAD tools may be used to aid in the quick development of these programs.
Game design
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.
A game design is a "living document" and may go through numerous revisions before a final initial design is agreed upon. As the game development progresses, the design document changes as programming limitations and new capabilities are discovered and exploited.
Language
| Language | Strengths | Weaknesses |
|---|---|---|
| C | Extremely fast, widely known, numerous tools | No OO or GC, prone to memory leaks |
| C++ | OO, very fast, widely used, numerous tools | No GC, prone to memory leaks, compiler compliance to language standard can vary |
| Java | Very OO, easy to use, portable | Can be slow, not suitable for console programming |
| Assembly | Fastest, low overhead | Error-prone, slow development, difficult for novices, not portable |
| C# | Very OO, RAD language, easy to use | Must be JITted when run, not portable (Microsoft Windows specific) |
| Python, Ada, etc. | Fringe game languages, few game development tools | |
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 Sony PlayStation or Microsoft Windows), the execution speed requirements and the language of any game engines, API's 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++. However, Java and C are also popular. Assembly language is necessary for some video game console programming and in some routines that need to be as fast as possible, or require very little overhead. Fringe languages such as C#, Ada and Python have had very little impact upon the industry and are primarily used by hobbyists familiar with the languages.
High-level scripting languages are increasingly being used as embedded extensions to the underlying game written in a lower-level 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 or 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 Shader Languages in game programming, such as nVidia's Cg.
APIs and libraries
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 even can handle some AI tasks such as pathfinding. There are even entire game engines that handle almost all tasks of game programming and only require customization.
Which APIs and libraries one chooses depends largely on the target platform. For example, libraries for Sony 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 Nintendo GameCube, PS2, Xbox and Microsoft Windows. Using a portable language can also provide portability.
Graphic APIs
Civ3.jpg
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, almost all 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 enormous user base. The two most popular 3D graphics APIs for Microsoft Windows are DirectX 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, in short, is not an API at all, but a collection of game APIs. Direct3D (sometimes called DirectX Graphics) is DirectX's 3D API. Direct3D, as well as the rest of the APIs of DirectX, is freely available from Microsoft. Microsoft developed DirectX for game programmers and continues to add features to the API. And to DirectX critics, herein lies the problem with Direct3D: Microsoft "owns" Direct3D. The changes to Direct3D are not controlled by an open arbitration committee and Microsoft is free to add, remove or change features as it sees fit. Also 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 and portable devices which run the PocketPC operating system). One advantage Direct3D has over OpenGL is that it is revised much more often. As a result, new features of the latest 3D cards are included in the API much faster than with OpenGL.
OpenGL, in short, is a portable 3D API. Code written with OpenGL is easily ported from Windows to the Apple Macintosh or Linux. Quake II was, in fact, ported from Windows to Linux by a fan of the game. OpenGL is standardized and not "owned" by any one entity. The OpenGL Architecture Review Board (ARB) meets periodically to update the standard by adding emerging support for features of the latest 3D hardware. Since it has been around the longest, OpenGL is used by and taught in colleges and universities around the world. Therefore, many game programmers with degrees choose to use because they are already familiar with it. A disadvantage of OpenGL is that it is not revised very often. Programmers who choose to use it can access some hardware's latest 3D features, but only through non-standardized extensions.
Other APIs
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 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 which, without which, one cannot 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 are cross-platform development capabilities.
The game loop
The key component of any game 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 it to do something.
Games, on the other hand, must continue to operate regardless of a users 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 game loop may be refined and modified as game development progresses, but most games programming doesn't start without one.
Game loops differ depending on the platform they are developed for. For example, a game for DOS and most consoles can dominate all processing time and exploit it as it wishes. However, a game for any modern PC operating system such as Microsoft Windows must operate within the constraints of the process scheduler. More sophisticated 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. However, the game may run more smoothly, and will definitely run more efficiently on multiprocesser platforms. This is not as important in PC games, since few home users have machines with more than a single processor, but it is becoming more important for console games, as some consoles already have more than one processor and future consoles are expected to continue this practice.
Production
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, 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 modellers 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 ad-hoc and buggy due to time constraints (time for development of such tools is often not included in a game's schedule) as well as due to the fact that 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.
Milestones
| What's an asset? |
|---|
| Game assets are the "things" that go into a game, whereas game code is that which operates on them. Some examples of assets are artwork (including textures and 3D models), sound effects and music, text, dialog and anything else that is presented to the user. Sometimes the terms content or objects are used interchangeably with the term assets. |
Most game development is tracked via milestones. A milestone is a point in development where the emerging game will have an agreed upon set of features and assets. Third-party developers are often paid (by the publisher) when milestones are delivered, therefore it is critical to meet them.
Sometimes features promised for a milestone are more difficult or time-consuming to implement than originally planned for and development slips into crunch time in order to implement them in time. Sometimes some slippage is permissible and allowances for such are worked into the game development contract beforehand.
Games developed internally by a publisher also have milestones, but they are, obviously, not required for any sort of payment or reimbursement. Rather the milestones are used for development tracking purposes. Usually, if the game development staff, including programmers, can provide reasonable justifications for the slippage (such as, some unplanned features were added that added significantly to the game), no penalties are incurred. However, often and frequent slippage of internal titles may result in cancellation of a title and—possibly—a RIF.
Crunch time
Crunch time, or crunching, is another term for extended periods of consecutive overtime. The extra hours worked during crunch time are often unpaid, although some companies give the time back in the form of extra holiday time (often called "comp time").
During crunch periods, project managers often provide:
- Temporary local accommodation for commuters
- Meals on site
- Administration staff to field calls and run errands
- Extra staff (transferred from other projects to help)
In the short term, crunching can increase the productivity of a team. But the increase in productivity is not normally proportional to the extra hours; twice the hours is unlikely to produce twice the productivity, due to diminishing returns. Adding extra staff is also not guaranteed to significantly increase productivity at this stage, and can often actually decrease productivity, as noted in The Mythical Man Month by Fred Brooks.
As crunch time continues, productivity drops. Frequently, productivity at the end of a crunch is less than would be expected from normal working hours. Quality also suffers as tired developers make more mistakes. Extended periods of crunch time also raise health issues such as: stress, fatigue, exhaustion and poor diet (some company-provided meals are junk food or fast food take-out and developers often increase their consumption of stimulants such as caffeine due to lack of sleep.)
Crunch time is frequently misused in game development projects. Many projects are scheduled with overtime throughout. The International Game Developers Association (IGDA) surveyed nearly 1,000 game developers in 2004 and produced a report to highlight the many problems caused by bad practice.[1] (http://www.igda.org/qol/whitepaper.php)
The E³ demo
As a game nears completion, the publisher will want to showcase a demo of the title at trade shows. The largest and most important of these is E³. Therefore, most games will have an "E³ demo" worked into the schedule.
Depending on the stage of development, the E³ demo will either be full of "hacks" or a scaled-down version of the game, such as containing all of the game's features, but just one special level. Sometimes the demo can just consist of a video of potential gameplay and features.
At the 1999 E³, for example, Blizzard showcased the highly anticipated Diablo II and allowed a small number of attendees to play the nearly completed game. On the other hand, Electronic Arts showcased the upcoming The Sims with a looping video of segments of the game.
Since the E³ demo is so critical, its development can halt all normal programming efforts as it branches off in the development of the demo. Depending on the stage of development, the demo can contain illusions of features and hacks that will crash the game if used wrong. But a game near completion can portray an accurate representation of the game with a great deal of polish. The E³ demo is often responsible for a great deal of crunch time.
Nearing completion
As a game nears completion, nerves are frayed and tempers short as most programmers—and much of the rest of the staff—have most likely been engaged in crunch time for weeks. Programmers must be on call at all times to fix the occasional bug—from minor to catastrophic—that may arise during the last phases of testing.
Game developers have a beta testing period, but the definition of such varies from developer to developer. Often a "Beta" is "feature complete" (it contains all of the game's features), but may have a few bugs or incomplete content. Few games are given a public beta period, but the occasional game does to measure stress tolerance for game servers, for example.
When the game is deemed complete and bug-free, 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.
Maintenance
Once a game ships, the maintenance phase for the game begins.
Games developed for video game consoles have almost no maintenance period: the shipped game has as many bugs fixed and features as it's ever going to have. This is the norm for consoles since all consoles have identical or nearly identical hardware.
For PC development, however, it is a different story. Game developers try to account for as many configurations and the most common hardware, but there are so many different possible configurations of hardware and software that it is almost inevitable that someone, somewhere—especially for a popular game—will find systems or circumstances the programmers didn't account for.
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.
In the case of a massively multiplayer online game (MMOG), such as a MMORPG or MMORTS, the shipment of the game is just the beginning. Such online games are in continuous maintenance as the gameworld is continuously carried out and new features are added. The maintenance staff for a popular MMOG can number in the dozens. This staff may or may not include members of the original programming team.
Culture
The game programming culture always has been and continues to be very casual. Most game programmers are individualistic and, usually, tolerant of divergent personalities. Despite the casual culture, game programming is taken seriously by its practitioners, who can take offense when it is suggested that they don't have "a real job."
Tools
Game development programs are generated from source code to the actual program (called the executable) by a compiler. Source code can be generated by 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 .NET 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, however, may 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. A well outfitted programmer may have two to three development systems dominating his office or cubicle.
See also: Tools from game programmer.
Duration
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.
Hobbyists
For hobbyists, usually the only platforms available to program on are consumer operating systems. This is because development on consoles require special development systems which cost thousands of dollars, must be obtained from the console manufacturer and are only sold (or licensed) to professional game development studios. Of the consumer operating systems, Linux, Mac OS and Microsoft Windows, Microsoft Windows is the most popular since it comes pre-installed on 90% of PCs sold. This is actually fortunate since numerous tools exist for game programming on Windows.
See also
External links
- International Game Developers Association (IGDA) (http://www.igda.org/)
- Game Programming Wiki (http://gpwiki.org)
- GameDev.net (http://www.gamedev.net/), a leading resource for game development
- FlipCode (http://www.flipcode.com), Daily Game Development News & Resources with an emphasis on programming
- DevMaster.net (http://www.devmaster.net/), Another popular game development resource
- Game industry veteran Tom Sloper's game biz advice (http://www.sloperama.com/advice.html)fr:Programmation de jeux vidéo