Game programming
From Wikipedia, the free encyclopedia
 |
| Part of a series on: |
| Video game industry |
|
Activities/Jobs
|
|
Topics
|
Game programming, a subset of game development, is the programming of computer, console or arcade games. Though often engaged in by professional game programmers, many novices may program games as a hobby. Some software engineering students program games as exercises for learning a programming language or operating system.[citation needed]
Contents |
[edit] 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 PC 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.
[edit] Prototyping
Writing prototypes of gameplay ideas and features is 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.
[edit] 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.
[edit] Language
| Language | Strengths | Weaknesses |
|---|---|---|
| Assembly | Low overhead | Error-prone, slow development, difficult for novices, not portable |
| C | Widely known, numerous tools | Not OO, no GC, prone to memory leaks |
| C++ | OO, widely used, numerous tools | No GC, prone to memory leaks |
| C# | Very OO, RAD language, easy to use | Must be just-in-time compiled when run, high memory usage |
| Java | Very OO, easy to use, portable | Not suitable for console programming |
| 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 Sony 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. 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, though C# is popular for developing game development tools. That may change soon, XNA being strictly for C#.
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 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.
[edit] 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 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 are not 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, Xbox, PSP and Microsoft Windows. Using a portable language can also provide portability.
[edit] Graphic APIs
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 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 and portable devices which run the PocketPC operating system). The DirectX API is updated far more often that OpenGL implementations. As a result, new features of the latest 3D cards are included in the API much faster than with OpenGL.
OpenGL is a portable API specification. Code written with OpenGL is easily ported between platforms with a compatible implementation. Quake II was, in fact, 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 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 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]
[edit] 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 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.
[edit] The game loop
The key 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 game 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, 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. 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. However, the game may run more smoothly, and will definitely run more efficiently on hyperthreading or multicore processors, and on multiprocessor platforms. With the computer industry's focus on CPU's with more cores that can execute more threads, this will become 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.
[edit] 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, 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 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 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.
[edit] 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 complete them on schedule. 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 termination of employment.
[edit] 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.[3]
[edit] Trade show demo
As a game nears completion, the publisher will want to showcase a demo of the title at trade shows. Therefore, many games will have an "Trade Show demo" worked into the schedule.
Depending on the stage of development, the 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 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 demo is often responsible for a great deal of crunch time.
[edit] 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.
[edit] Maintenance
Once a game ships, the maintenance phase for the video game begins.
Games developed for video game consoles have had, in the past, almost no maintenance period: the shipped game had as many bugs fixed and features as it was ever going to have. This was the norm for consoles since all consoles have identical or nearly identical hardware. In this case, maintenance enters the picture only in the case of a port, sequel, or enhanced remake that reuses a large chunk of the engine and assets.
However, in recent times because of the growing popularity of online console games, online capable video game consoles and online services such as Xbox Live for the Microsoft Xbox, developers can maintain their software through downloadable patches. These changes would not have been possible in the past without the widespread availability of the Internet.
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.
[edit] Culture
 |
This section requires expansion. |
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 very seriously by its practitioners.
[edit] 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 with the best tools. A well outfitted programmer may have two to three development systems dominating his office or cubicle.
[edit] 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.
[edit] Hobbyists
For hobbyists, usually the only platforms available to program on are consumer operating systems. This is because development on consoles requires special development systems which cost thousands of dollars, must be obtained from the console manufacturer and are only sold or leased to professional game development studios. However, recently Microsoft has released a new game development platform - XNA, which can be run both on the PC and the Xbox 360. The game written for PC can be ported to Xbox with almost no or slight changes. This allows individual game programmers and small teams to develop games for consoles. However, some hobbyists prefer to develop homebrew games, especially for handheld systems or obsolete consoles.
[edit] See also
[edit] References
[edit] External links
- GameDev.net, a leading resource for game development
- DevMaster.net, another popular game development site
- International Game Developers Association (IGDA)
- One ex-game programmer's experience in the game development industry
- Game industry veteran Tom Sloper's advice on game programming
[edit] Wikis
- 2D Game Development wiki
- Game Programming Wiki -GPWiki
- Game Development Wiki -GDwiki
- Game Development wiki at DevMaster.net
|
|||||||||||||||||
