I think I found this on wikipedia last year. Just sharing what I have found helpful.
Waterfall Development Basics / Game Development
The waterfall development process is the one commonly used in game development. It has distinct phases that need to be completed in a certain order. Once a phase has been complete there is no turning back and it is on to the next phase. Waterfall processes occur at various levels of complexity. The following are the larger categories found in game development, described in a common sequence of execution. Conception The business analysts, product managers, and senior development personnel get together and discuss what the game should be.
Among other issues, they may discuss the following: Audience Platform Development time frames. Some of the features of the game. Some of the high-level technical and artistic challenges. The group may (or may not) produce a document describing all of the expectations for the game and some of the detail about how a group might approach development. In some cases a series of discussions results in a go or no-go decision. Game specification: If the team gets the go ahead to proceed, a document is crafted by the product manager and/or producer that describe what the user experience will be in the game. This involves play characteristics, platform decisions, and potential artistic mockups of the game. It is a description of the game from the end user’s perspective.
This document is circulated to high-level art directors, game designers, and architects. Art bible/story bible I have compressed the art and story bible into one phase. They are different but they are executed at about the same time in the process and are linked because the producers and artists need to work together to create these documents. The art bible contains what the name implies. It defines the overriding art style that will be used, the tools to develop this art, and mock-ups to validate that approach. The story bible describes how the game will flow. It discusses the overriding objective of the game and how that objective will be expressed in various scenarios.
Technical specifications: In this document the engineers detail the architecture of the game. It could be expressed in unified modeling language (UML) or with system diagrams. If development is to be object oriented, high-level objects and their interactions are defined. Core fundamental tools are defined and a platform for the game is recommended. The interactions between art assets and programming code are defined. Security and access methods might be part of the game technical specification. Construction The decision is made to go ahead; architecture and concept documents are completed; the platforms have been established; the full team is hired; and the development environment is up and running. Then people begin to construct the game. The producers, managers, and project leads form the organizational glue within their respective disciplines and across organizational lines. The artists and developers begin to develop the game using all of the documents that have been previously developed.
QA system test: Upon completion, pieces of the game go to the quality assurance (QA) organization, which takes all of the previously mentioned documents and tests the game against these documents. Any problems that are found are logged and reported back to the development teams. The development team responds by fixing the problems, redesigning certain key modules, or adding additional functionality. Play testing: Once the QA organization has an opportunity to give feedback to the development teams and the game is up in some working order, play testing begins. In this exercise, producers organize group sessions to demonstrate the play characteristics of the game. These sessions are usually attended by product and marketing managers as well as members of the development staff. The goal is to validate or critique the play characteristics of the game at that point in time.
These sessions may occur a number of times during the testing cycle. Each play test session involves feedback that must be addressed by developers. The feedback can require cosmetic or fundamental changes to the game. Alpha testing: When producers, product managers, and developers agree that the game is ready for a wider audience, the producer will release the product to a select group of evaluators that provide feedback on the game. This feedback can result in required changes to the game. Some of these changes could be substantial.
The assumption is that the changes will not be drastic in nature. Beta testing: In this phase the game is released to a much wider audience with little knowledge of the game. People play the game and provide feedback on problems that occur, features they like or dislike, and the overall game experience. For console games it is difficult to get a comprehensive beta test because the game is usually kept inside the company that is making it. On the Web the first release of a game is frequently considered the beta test. Sometimes this is called release 1.0 and is quickly followed by a subsequent more robust release. Golden master or final release: With all the feedback received and changes made, the game is released to the general public. Overview
Development of video games is undertaken by a developer, which may be a single person or a large business. Typically, large-scale commercial games are created by development teams within a company specializing in computer or console games. A typical modern video game can costs from USD$1,000,000 to over $20,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.
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. However the development of a modern, commercially-viable video game 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
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.
Often the development team is overseen by managers such as art directors, technical directors and design directors. Directors work mainly as personnel managers and usually do not directly influence the product, but more to ensure that everyone in the team works coherently. Directors usually do resourcing but can also be considered people to consult with regarding various issues during game development.
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.
Early phases of game development are often characterized by poor quality of graphics. This is especially true of various game prototypes.
Normally before any game can begin development, the idea for the game is created and must be approved (given the “green light”) by the publisher/developer.
In the common case in which developer and publisher are separate companies, pitches are made to management at the developer, and then it needs to be shopped around to publishers. Demos are often used but sometimes unnecessary for established developers with good track records. Production can begin once (and if) an interested publisher is found. Games rarely progress far without an interested publisher.
If the developer is also a publisher, or both are subsidiaries of a single company, only the upper management needs to give approval. Depending on the size of the publisher, this may require several rounds of pitches as the idea makes its way up through the layers of management.
Game designers often present the project, but the presenter could be any role in the video game industry. Before full-scale production begins, the development team produces a design document, which describes the concept and major game play elements in detail. Design documents may also include preliminary sketches of various aspects of the game. These are sometimes accompanied by functional prototypes of some sections of the game. Design documents generally incorporate all or most of the material from the initial pitch. Design documents are always “living documents”—it is never truly complete while the game is in development. It often changes weekly or even daily. So while the design document needs to exist in some form before full-scale production begins, it is almost never a complete design, though most elements of the projected game are described (in varying level of detail).
Before an approved design is completed, a skeleton crew of programmers and artists usually begins work. Programmers may develop “quick and dirty” prototypes showcasing one or more features some stakeholders would like to see incorporated in the game. Or they may begin developing the technical framework the game will eventually use. Artists may develop volumes of sketches as a springboard for developing real game assets. Producers may work part-time on the game at this point, scaling up for full time commitment as development progresses.
Mainstream production is usually defined as the period of time when the project is fully staffed. Programmers write much new 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 cut scenes and NPCs.
All the while, the game designer implements and modifies the game design to reflect the current vision of the game. Features and levels are often removed or added. The art treatment may evolve and the back-story may change. A new platform may be targeted as well as a new demographic. All these changes need to be documented and dispersed to the rest of the team. Most changes occur as updates to 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 quicker and higher quality development. Newly introduced features may cause old levels to become obsolete, so the levels developed early on may be repeatedly developed and discarded. Because of the dynamic environment of game development, the design of early levels may also change over time. It is not uncommon to spend upwards of twelve months on one level of a game developed over the course of three years. Later levels can be developed much more quickly as the feature set is more complete and the game vision is clearer and more stable.
Testers start work once anything is playable. This may be one level or subset of the game software that can be used to any reasonable extent. Early on, testing a game occupies a relatively small amount of time. Testers may work on several games at once. As development draws to a close, a single game usually employs many testers full time (and often with overtime). They strive to test new features and regression test existing ones. Testing is vital for modern, complex games as single changes may lead to catastrophic consequences.
Commercial game development projects are usually required to meet milestones. Milestones represent interim project goals while also being 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 delay installment payments (in the case of third-party developers).
Shortly before a milestone, many development teams go into “crunch mode”—extended overtime 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. After a deliverable is completed, some companies give their teams “comp time” (compensation time) of a few paid days off.
There are many types of deliverables, but one for an installment payment described above is the most common. For example, one major milestone may be an 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.
The weeks leading to completion of a game are intense, with most team members putting in a great deal of—mostly unpaid—overtime. Unsurprisingly, this may lead to short tempers and a great deal of exhaustion. The extra effort is required for most games as unforeseen problems regularly arise and last-minute features are hastily added.
The testing staff is most heavily relied upon at the end of a project, 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. This is also often the time when features and levels are being finished at the highest rate, so there is more new material to be tested than any other time in the project.
Regression testing is one of the most vital tasks required for effective software development. As new features are added, subtle changes to the codebase can impact seemingly unrelated portions of the game. This task is often overlooked, for several reasons. Some inexperienced developers may feel that once a feature works, it will always work. Also, since features are often added late in development, there isn’t sufficient time to test existing features: testing new features takes precedence. Proper regression testing is also increasingly expensive and often not scheduled for correctly ahead of time.
Despite the dangers of not completely regression testing, 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 blows to their reputation.
After the game goes gold and ships, some developers will give team members comp time (perhaps up to a week or two) to compensate for the overtime put in to complete the game, though this compensation is anything but standard.
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 Playstation 3 and Xbox 360, a large proportion of games are receiving patches and fixes after the game shipped due to bugs and glitches, 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. It is common practice for computer game developers to release patches for games after they ship (often months or even years later). 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 by normal business standards. Many game developers are strongly individualistic and usually tolerant of divergent personalities. Despite the casual culture, game development is taken seriously by its practitioners, who may take offense if it is suggested that they don’t have “a real job.”
|What’s an asset?|
|Game assets are the “things” that go into a game. Some examples of assets are artwork (including textures and 3D models), sound effects and music, text, dialogue and anything else that is presented to the user. Sometimes the terms content or objects are used interchangeably with the term assets.|
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.
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 heavily impacts game development time. A puzzle game, for example, will normally have far fewer assets than a 3D role-playing game. Sometimes it is possible to use assets originally 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, Chicago, Illinois 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 Lucas film 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.