From Wikipedia, the free encyclopedia
- This article is about computer and video game development, and does not deal with the development of other forms of game, such as board games and card games
Game development is the process by which a game is produced. Today this term almost exclusively refers to the development of computer or video games.
Development of computer and video games is undertaken by a developer, which may be a single person or a business. Typically, large-scale commercial games are developed by development teams within a company specializing in computer or video games. A typical modern video or computer game costs from US$1,000,000 up to US$50,000,000 to develop. Development is normally funded by a publisher. A contemporary game can take from one to three years to develop, though there are exceptions.
While in the early era of home computers and video game consoles in the early 1980s, a single programmer could handle almost all the tasks of developing a game, the development of modern commercial video games involves a wide variety of skill-sets and support staff. As a result, entire teams are often required to work on a single project. A typical present-day development team usually includes:
- One or more producers to oversee production
- At least one game designer
- Level designers
- Sound engineers (composers, and for sound effects)
Some members of the team may handle more than one role. For example, the producer may also be the designer, or the lead programmer may also be the producer. However, while common in the early video game era, this is increasingly more uncommon now for professional games.
The development process
The development process of a game varies depending on the company and project. However development of a commercial game usually includes the following stages.
Normally before any game can begin development, a pitch must be made and given a "green light" by the publisher/developer.
In the (rather frequent) case in which developer and publisher are separate companies, the pitch must be made to management, approved and then it needs to be shopped about to various publishers. For this activity, a running demo is helpful, but not necessary for an established developer with a good track record. If an interested publisher is found, production can begin. Today, a game idea is rarely worked on without an interested publisher.
If the developer is also a publisher, or if both are subsidiaries of a single company, only the upper management needs to give approval. Depending on the size of the publisher, however, this may require several rounds of pitches as the idea makes its way up through the layers of management.
The person presenting the project is normally a game designer, but is possibly one in any role in the video game industry. Before full-scale production can begin, the game designer must produce the design document, a detailed document describing the concept and gameplay. It may also have some preliminary sketches of various aspects of the game. Some game designers even include a sample running prototype of one or more aspects of the game in the design document. Most design docs incorporate all or most of the material from the initial pitch. The most important aspect of the design document is that it is a "living document"—it is never truly complete while the game is in development. It can change weekly or, sometimes, daily. So even though the design document needs to exist in some form before full-scale production begins, it is almost never a complete design, though many aspects of all stages of the projected complete game may be described.
Before an approved design is completed, a skeleton crew of programmers and artists may begin working on ideas. Programmers may develop "quick and dirty" prototypes that showcase one or more features some stakeholders may like to see incorporated in the game. Or they may begin developing the framework that the game will eventually use. Artists may develop volumes of sketches as a springboard for developing real game assets. The producer may work part-time on the game at this point, scaling up for full time commitment as development progresses.
During mainstream production, a great deal of work is accomplished. Programmers churn out volumes of source code, artists develop game assets such as sprites or, more often today, 3D models of game elements. Sound engineers develop sound effects and composers develop music for the game. Level designers create advanced and eye-catching levels, and writers write dialog for cutscenes and NPCs.
All the while, the game designer implements and modifies the game design to reflect the current vision of the game. Some features or levels may be removed, others added. The art treatment may evolve and the backstory may change. A new platform may be targeted as well as a new demographic. All these changes need to be documented, and most of them need to appear in the design document.
From a time standpoint, the game's first level takes the longest to develop. As level designers and artists use the tools for level building, they request features and changes to the in-house tools that allow for higher resolution development. Newer features may render older levels obsolete, so many revisions of the game's first level may be developed and discarded. In addition, because of the dynamic environment of game development, the designers' vision of the first level may change over time. It is not uncommon to spend upwards of 12 months on the first level of a game developed over the course of 3 years. Later levels can be developed much more quickly as the feature set is more complete and the game vision is clearer.
Testers are assigned to games once there is anything playable. This may be one level or subset of the game that can be used to any reasonable extent. Early on, testing for a game occupies a relatively small segment of a single tester's time; testers may have several games they are responsible for at any given time. Once development draws to a close, a single game may occupy all of a tester's time—stretching into overtime—as they strive to test new features and regression test existing ones. Today testing is vital for a game as most games' complexity can cause one single change to have catastrophic consequences.
Almost all commercial game development projects have milestones they are required to meet. Milestones are project goals and are synonymous with deadlines. Milestones include a pre-release version of the game with an agreed upon set of features. The consequences of missing a milestone vary from project to project, but usually include an installment payment (in the case of third-party developers).
Shortly before a milestone, many development teams go into "crunch mode"—extended work weeks meant to catch up on any work that has slipped during regular development or to fix "killer bugs" that could jeopardize the future of the project. During these periods, many team members may put in long hours, especially key team members such as the producer, principal game designer and programming and art leads. After a deliverable is completed, some companies give their teams "comp time" of a few paid days off.
Today there are many types of deliverables, but one for an installment payment described above is the most common. One major milestone for contemporary games is the E³ demo. E³ — which as of 2006 used to be the game industry's biggest trade show before downgrading to a more intimate showing of individual press screenings — is the place to market an upcoming game. The E³ demo is such a major effort that it may halt all normal development as the team prepares a small-scale, polished version of the game. Special assets are usually required for such a demo and team members are normally pulled off mainstream production for the demo development. As time draws nearer to the trade show, more team members may be drawn in to complete the demo on time. Later, this demo may be used as the game's official demo when the game is released.
Near the end of a game development project, tempers are short and exhaustion complete. The weeks leading to completion of a game are intense, with most team members putting in a great deal of—mostly unpaid—overtime. The extra effort is required for almost all games as unforeseen problems arise and last-minute features are hastily added.
During this time the testing staff is heavily tasked as they not only need to test newly added features, levels and bug fixes, but they also need to carry out regression testing to make sure that features that have been in place for months still operate correctly.
Regression testing is one of the most vital, though often overlooked, tasks of effective game development. As new features are added, subtle changes to the codebase can impact seemingly unrelated portions of the game. This task is often overlooked, however, for several reasons. First, some inexperienced developers feel that once a feature works, it will always work. Next, since features are often added late in development, there isn't sufficient time to test existing features: new feature testing almost always takes precedence.
Despite the dangers of skipping this important step, many game developers and publishers fail to regression test a game’s full feature suite. One recent high-profile case of insufficient regression testing occurred with Firaxis’ Civilization III. Though the game worked for weeks before going gold, late changes to the code made the game unplayable past the industrial age. Understandably, this angered customers and fans of the game. Firaxis was quick to release a patch for the game, but not before suffering significant blows to their reputation.
After the game goes gold and ships, some developers will give team members around a week of comp time to compensate for all the overtime put in to complete the game, though this practice is far from universal.
Console games used to be considered 100% complete when shipped and could not be changed. However, with the introduction of online-enabled consoles such as the Xbox 360, a large proportion of games are receiving patches and fixes after the game shipped, much like PC games.
PC games, on the other hand, can have numerous conflicts with hardware and configurations. Developers try to account for the most prevalent configurations, but cannot anticipate all systems that their game may be tried on. Therefore, it has become common practice for computer game developers to release patches for their games after they ship. These patches used to be mailed to users via floppy disk, but are now generally available for download via the developer's website. If a game goes into a second printing, the patched version is used as the new master.
Game development culture always has been and continues to be very casual. Many game developers are individualistic and, usually, tolerant of divergent personalities. Despite the casual culture, game development is taken seriously by its practitioners, who can take offense when it is suggested that they don't have "a real job."
Most modern games take from one to three years to complete. The length of development depends on a number of factors, such as genre, scale, development platform and amount of assets.
For example, a simple puzzle game using 2D graphics will take far less time to develop than a computer role-playing game with a full-blown 3D engine.
Another consideration is the use of middleware game engines. Developing a 3D engine from the ground up takes far more time than using a COTS (commercial, off-the-shelf) existing middleware package (such as Gamebryo or RenderWare). For example, Gas Powered Games developed a custom 3D engine for their game Dungeon Siege. Development took three years. Firaxis used the Gamebryo game engine for their game Sid Meier's Pirates! which was developed in just under two years.
The number of assets also impacts game development time. A puzzle game, for example, will normally have far fewer assets than a 3D role-playing game. Also it may be possible to use assets that were developed for another game (that the developer owns the copyright to) or assets that are in the public domain.
So, for the example puzzle game, developing it from the ground up with no pre-existing code or assets, could take a year. However, using a middleware package and existing assets, development could be sliced down to six months or less.
Due to its software-based nature, game development can occur in almost any locale. Despite this, in the United States a few game programming "hot spots" have developed with a high concentration of game development ventures. Often these areas are adjacent to major universities such as Stanford, the University of Texas at Austin and the University of Washington.
In the very early days of video games, almost the only locale for game development was the corridor from San Francisco to Silicon Valley in California due to the era's high-tech growth in the area, and it remains an important development center. Currently, the Austin, Texas, Seattle, Washington, Orlando, Florida, Los Angeles, California and most recently, Montreal, Quebec, areas have large numbers of game development companies. Smaller hot spots exist in other areas of the US and Canada, including suburban areas such as Marin County, California (in particular San Rafael), where Lucasfilm was headquartered from 1980-2005. In the late 1990s, Boston, Massachusetts and Salt Lake City, Utah had a number of game development companies, but this number has since declined.
Despite the popularity of video games, work in this area is very volatile. Scores of game development studios crop up, work on one game, and then quickly go under. This may be one reason why game developers tend to congregate in one geographic area—once their current studio goes under, they flock to an adjacent one or start another from the ground up.
In an industry where only the top 5% of products make a profit, it's easy to understand this fluctuation. Numerous games go into development and are either canceled or completed, but never published. Some experienced game developers who have been in the industry for dozens of years may have never worked on a title that ever made it to publication: such is the nature of the business. This volatility isn't likely to change soon.
Indie game development
Indie (short for 'independent') game developers are game developers that are not controlled by a publisher. They are usually self-funded small teams that operate over the Internet. Since they don't rely on external funds, they usually retain creative control over their games. Their products are then self-published over the Internet or, at times, sold to a publisher once it is finished.
In this day and age of Hollywood budgets for most high profile games, it is increasingly difficult for indie game developers to compete because of limited resources. Most indie game developers do not even make any money because the cost of development is higher than their sales (often because of the lack of marketing or because they are taken advantage of by some unscrupulous publishers).
- Software development
- Software development process
- Agile software development
- List of gaming topics
- List of indie game developers
- Video game controversy
- Salen, Katie; Eric Zimmerman (2005). The Game Design Reader: A Rules of Play Anthology. The MIT Press. ISBN 0-262-19536-4.
- Salen, Katie; Eric Zimmerman (2003). Rules of Play: Game Design Fundamentals. The MIT Press. ISBN 978-0-262-24045-1.
- International Game Developers Association (IGDA)
- Breaking into the game industry from the IGDA
- Game industry veteran Tom Sloper's game biz advice
- One ex-game programmer's experience in the game development industry
- Gamasutra.com, articles on game development
- GameDev.net, a leading resource for game development
- DevMaster.net, a game development resource