GAME
R
EQUIREMENTS
In This Chapter
• Define Game Features
• Define Milestones and Deliverables
• Evaluate Technology
• Define Tools and Pipeline
• Documentation
• Risk Analysis
• Approval
• Game Requirements Outline
15.1 I
NTRODUCTION
W
hen the initial concept deliverables are completed and approved, the
team needs to determine the game’s requirements. The requirements
detail how the concept will be turned into a real game. Decisions are
made about the main project goals, the core feature set, and the milestone de-
liverables. In addition, the core technology and production pipeline must be
established. Finally, all documentation needs to be written and finalized. After
these items are completed, you have a clear idea of what needs to be done to
create the game. These items are then used to further determine the budgeting,
scheduling, and staffing needs for the game.
Chapter 15Chapter 15
242 THE GAME PRODUCTION HANDBOOK, 2/E
15.2 DEFINE GAME FEATURES
During pre-production, everyone has an idea about what cool features can be in-
cluded in the game. Obviously, you can’t include every single feature request: some
won’t fit with the game’s vision; the team won’t have enough time to get everything
in; or the technology cannot support the functionality. Therefore, you need to pri-
oritize the features into different tiers for implementation. For example, tier one
features are the core features of the game; tier two features add value to the core
features; and tier three designates features that would be nice to include. Ideally,
all the tier one features are included, and you might find time to add many (or all)
of the tier two features. Usually, the tier three features are considered for the next
version of the project and will not make it into the final game.
To begin with, involve the team in a brainstorming session as to what fea-
tures should be included in the game. Conduct these sessions over the course of
two to three days. Brainstorm about multiplayer features, single-player features,
gameplay mechanics, sound, and any other aspects of the game. Gather all the
feature ideas in a single list and then categorize them by type. Doing this will
help the producer and leads to better prioritization of the features. Some catego-
ries to consider are as follows:
Process: These features revolve around improving the development pro-
cesses. This includes improving the formats of the design documentation,
establishing an approval process for multiplayer levels, and setting up mini-
tutorials to teach people how to use the development tools.
Production: These features involve improvements to the tools and technol-
ogy used to make the game. For example, adding cut and paste functional-
ity to the scripting tool, improving how destructible objects function in the
game, and adding enhanced lighting functionality to the art tools.
Gameplay: These features consist of gameplay elements that will directly
impact the player’s experience and be visible to the player. This includes the
ability of the player to control vehicles, functionality for changing options
on-the-fly, and the ability of the player to customize his avatar.
You could also create categories around specific gameplay elements, or by
discipline, or any other grouping that will help you get a better handle on the
types of features being requested. Figure 15.1 is an example of what this catego-
rized master feature list looks like.
After this list is generated and categorized, the producer sends the list to
the leads and asks them to each assign a priority to every feature on the list. The
leads should base their priorities on the known project constraints. For example,
if the game is a time to market game, the final code release deadline is the main
constraint, and all of the core features must be doable within the limited time on
GAME REQUIREMENTS 243
the project. If the game is a sequel to a best-selling franchise, the constraint is to
create a game that lives up to its predecessor, so more time might be added to
the schedule to ensure that the game has all the key features.
The leads also need to consider the overall art, engineering, design, and
testing concerns when assigning priorities. For example, the lead artist might be
tempted to assign the highest priority to all the art feature requests and a lower
priority to all the design feature requests. However, if the lead artist does not
fairly consider the overall game needs, the game might end up with stunning
graphics but so-so gameplay. Experienced leads will know how to strike a bal-
ance among the art, design, engineering, and gameplay needs on a project.
After each lead has assigned a ranking to the features (with 3 being high-
est priority and 1 being lowest priority), collect all of the data and add it to the
master feature list. Include a column for each person’s rankings and make the
last column an average for the rankings. After calculating the average ranking,
use this value to sort the entire list. Figure 15.2 is an example of what the feature
ranking spreadsheet will look like after sorting it by the average ranking.
Category Feature
Gameplay dynamic missions objectives
Process mission review process should also include multiplayer levels
Process
establish a system for circulating design documents and updates to documents
to the team
Gameplay easy to understand user-interface
Gameplay replayable missions
Production improve physics so explosions look more realistic
Gameplay ability for player to customize character appearance
Production support cut and past functionality in scripting tool
FIGURE 15.1 Categorized master feature list.
O
N
T
H
E
C
D
O
N
T
H
E
C
D
FIGURE 15.2 Feature ranking spreadsheet sorted by average ranking.
Category Feature Prod. Art Design Eng. QA Average
Gameplay dynamic missions objectives 3 3 3 3 3 3
Process
establish a system for circulating design documents
and updates to documents to the team
33 3 33 3
Gameplay easy to understand user-interface 3 3 3 3 3 3
Process
mission review process should also include
multiplayer levels
33 3 23 2.8
Production improve physics so explosions look more realistic 2 3 1 3 1 2
Gameplay replayable missions 2 2 2 1 2 1.8
Gameplay ability for player to customize character appearance 1 2 3 1 1 1.6
Production support cut and past functionality in scripting tool 1 1 3 1 1 1.4
3 = MUST HAVE
2 = LIKE TO HAVE
1 = NICE TO HAVE
244 THE GAME PRODUCTION HANDBOOK, 2/E
FEATURE CREEP
Clint Hocking, Creative Director
Ubisoft
Part of the problem is that features are not discrete—basically any new feature could
be called an improvement or a bug fix for an existing feature, so there can be no rigid
definition of when the rule has been broken. My feeling is that if you design correctly,
this should not be a problem. If you start with a concept for the entire game and then you
specify the mechanics and dynamics that support that concept, you won’t be in a feature-
hunt. You won’t be looking to copy random sexy features from other games because your
game won’t be a random collection of features, it will be a unified whole. That’s pretty
idealized, and there’s no way any game development is going to work like that, but it’s a
good place to start. Limit your scope to what is meaningful under the creative concept of
the game. Anything outside that (even if it’s awesome) is feature creep.
After this is completed, schedule a meeting with the leads to discuss the results.
This meeting might last a few hours as you will need to go through each feature,
assess its overall ranking, and finalize whether it is a “must have,” “like to have,” or
“nice to have” feature. Even though everyone might not be in 100 percent agree-
ment about the rank for each feature on the list, this exercise provides a good way
to garner consensus on what features are most important for the game. When the
meeting is over, publish the final ranked feature list to the team. This feature list
will provide the basis for defining the milestones and deliverables.
15.3 DEFINE MILESTONES AND DELIVERABLES
After the core features are determined, the producer can put together initial
documentation on the milestones and deliverables. Milestones mark a major
event during game development and are used to track the project’s progress.
They provide the team smaller, more manageable goals to work toward and can
be easily defined by listing what deliverables are expected for each milestone.
Each development team will have a different set of milestones to mark the
game’s progress. Some teams establish monthly milestones, and other teams
work toward bigger milestones every few months. When working on a two-year
development cycle, a common set of milestones is as follows:
First playable: This is the first major milestone for the game. It contains
representative gameplay and assets. Often, it is based on the prototype that
GAME REQUIREMENTS 245
was created in pre-production. This milestone is usually scheduled to occur
12 to 18 months before code release.
Alpha: At this milestone, key gameplay functionality is implemented, as-
sets are 40 to 50 percent final (the rest are placeholders), the game runs on
the correct hardware platform in debug mode, and there is enough working
that you can start to get a feel for the game. Features might undergo major
adjustments at this point, based on play testing results and other feedback.
Alpha occurs 8 to 10 months before code release.
Code freeze: At this point, the game is code complete, and the engineers
are only fixing bugs from this point forward. No additional features are added
so that the code has time to stabilize, and the critical bugs can be identified
and fixed. This milestone happens about 3 to 4 months before code release.
Beta: By beta, the game is code and asset complete. Art, design, and engi-
neering only focus on fixing bugs that are listed in the bug database. No new
assets are generated; no new features are coded; and no changes are made to
existing features and functionality unless it is identified as a bug. Beta occurs
about 2 to 3 months before code release.
Code release candidate: At this milestone, all the bugs have been ad-
dressed, and the developers are confident that the build is ready to be
shipped or submitted to the console manufacturer for approval. The code
release candidate is tested against the QA test plan, and any crash bugs or
other critical issues are fixed as necessary. The team is not actively making
any fixes. The first code release candidate should be ready for QA testing
about 3 to 4 weeks before the code release date.
Figure 15.3 is a table with more details about each of these development
milestones.
After you have determined which milestones to include in the production
schedule, define in as much detail as possible what the expected deliverables are
for each one. Doing this is important so that there is a clear way for the team to
determine whether the milestone is completed. If nothing is defined, how will
the team know whether the milestone is completed? This list is also useful for
the QA department, since they know exactly what parts of the game need to be
checked for functionality. These lists are also a great way to track the game’s
progress to ensure that nothing important is omitted.
A simple way to define the milestones is to establish a list of deliverables for
each one. These lists can be started in pre-production and updated as information
about the game is defined. Include information about what is completed and ready
for testing on each aspect of the game. If an asset or feature is not 100 percent
complete, state what should be completed and viewable in the game for each
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.