256 THE GAME PRODUCTION HANDBOOK, 2/E
Documentation on the coding standards includes specifics on coding
conventions, hardware and software specifications, naming conventions, tech-
nologies used (including middleware), file types, data layout, and any other tech-
nical information that is necessary for developing the game. The documentation
should also provide an overview of what all the functions and data do and how
they interact with each other.
Technical design documentation is the counterpart to design documentation.
The engineers will read through the design documents and provide technical in-
formation on how the features will be coded for the game. This documentation is
disseminated to the appropriate engineers on the team for implementation.
Tools instructions provide information on how to use the tools. For example,
an engineer and designer will work together to document how the scripting tools
work. These tools instructions must be updated when any changes are made to
the tool functionality; otherwise, the documentation will quickly become un-
helpful and even obsolete.
CREATING TECHNICAL DOCUMENTATION
Tobi Saulnier, President
1st Playable
Part of the lead engineer’s responsibility on a project is to put together a tech-
nical design document (TDD) that describes the software systems that are needed
to produce the game, both existing systems and systems that need to be developed.
They are usually working on this document in parallel with the game design docu-
ments (GDD) being written by designers.
A detailed GDD is extremely useful for the engineers when they start working
on the TDD, as it assists them in identifying the list of in-game features and the
needs of the art and design pipelines required to develop those assets and integrate
them into the game. If some areas are missing from the GDD, this can cause prob-
lems for engineering, either resulting in an important feature not being included
in the upfront software planning or the engineers not fully understanding how a
feature is expected to work. For example, if one of the bosses (the enemy at the end
of a level or mission) does not have a detailed description of his expected behavior,
the engineers will not know how much time to plan for implementing his AI, or the
boss once implemented will not behave as the designer envisioned.
Detailed examples and mock-ups should be included in all documentation,
as words alone often can’t fully define what the desired functionality is. Use of
GAME REQUIREMENTS 257
15.7 RISK ANALYSIS
After you have defined the project requirements, conduct another in-depth risk
analysis with the team. You will find new risks to be aware of as production
starts, and other risks identified earlier can be neutralized or removed. Please
refer to Chapter 14, “Concept,” for detailed information on how to conduct a
risk analysis.
references from other games is extremely helpful, especially for complex concepts
like camera behavior and art style. For example, if you are describing how the cam-
era will move in the game, include reference examples of the desired and undesired
camera movements. It is also useful to mock-up a reference movie of how the char-
acter will move through the game world.
A final note is that the TDD should be user-friendly, which in this case means
easily reviewed by art and design, not just other software engineers. Writing the
GDD and TDD is usually an iterative process, which means the information from
each affects the other. For instance, the memory planning in the TDD will impact
things like the number of levels or the number of unique AI. Having all disciplines
involved in reviewing each document will help catch anything that is forgotten and
more quickly synch up the game design with the technical restrictions.
IDENTIFYING RISKS
Stuart Roch, Executive Producer
Activision
If I can get onto a project early enough, I’m a big fan of proactively identify-
ing any game features or new technology that pose a scheduling risk. After I’ve
identified these particular risks, I set lifeboat milestones to launch if things start
running behind schedule. The idea is to have your plan A and plan B worked out
ahead of time so you don’t have to scramble and make reactive decisions if things
go wrong. After you identify your at-risk features and set your plan B milestones,
it’s important to follow up regularly to help the at-risk features along and identify
the warning signs if things aren’t going as planned. If handled correctly, this method
will help keep the risky features on everyone’s radar, thus maximizing their chances
of success and in a worst-case scenario, reduce the impact of the feature cuts if the
original goals aren’t met.
258 THE GAME PRODUCTION HANDBOOK, 2/E
15.8 APPROVAL
After the game requirements are defined, present them to the stakeholders for
approval. As with the concept phase, the stakeholders might have feedback they
want implemented before they sign off on the requirements.
You don’t need to wait for all the requirements to be defined before seeking
approval. Instead, schedule regular meetings to present completed required de-
liverables for approval. This allows you to stagger out the deliverables. If there is
feedback to include, you can take a few days to implement it and then re-submit
it for approval. This keeps the process going during pre-production, and bottle-
necks are not created in the process while waiting for management approval.
Refer to Chapter 18, “Production Techniques,” for information on how to set up
an efficient approval process.
15.9 GAME REQUIREMENTS OUTLINE
Figure 15.5 (see following page) is a summary of each step that must be com-
pleted in the concept phase. This is based on a two-year development cycle.
15.10 CHAPTER SUMMARY
On a two-year development cycle, the game requirements phase will take about
two to three months to complete. However, this phase will not have a hard start
and end date; you might need to design an additional feature during production,
revamp the pipeline, or start production on some aspects of the game while
completing pre-production on other aspects.
The goal of the game requirements phase is to more fully flesh out the de-
sign, art, and technical needs of the game. This includes writing the documen-
tation; making decisions about the tools, pipeline, and milestone deliverables;
and conducting a risk analysis. All of this information will be used to create the
game plan in which all of these tasks are scheduled and a budget is created. The
next chapter presents details on what tasks to complete during the game plan
phase.
GAME REQUIREMENTS 259
O
N
T
H
E
C
D
FIGURE 15.5 Outline of game requirements phase.
Step Resources General Timeline Tasks
Define game
features Lead Designer 1 - 2 weeks
Core features are defined. Secondary and
Tertiary features also defined.
Define milestone
deliverables Producer
ongoing - each
milestone
deliverable list
completed about 4
weeks before the
official milestone
delivery.
Define the main project milestones and
what the deliverables are needed for each
milestone. Rough milestone estimates
based on desired ship date.
Evaluate technology Lead Engineer 4 - 6 weeks
Evaulate the technology needs for the game
and make a recommendation.
Define tools and
pipeline
Lead Engineer works
with other leads 2 - 3 weeks
Define the production pipeline that will
produce a playable build with updated
assets.
Create Concept Art Lead Artist 2 - 3 weeks
Generate concept for key characters and
settings in the game.
Design
documentation Lead Designer 6 - 8 weeks
Document the key features in the game,
include prototypes where possible.
Art documentation Lead Artist 6 - 8 weeks
Document the artistic look and feel of the
game, generate asset lists, and write up
instructions on how to use the art tools.
Technical
documentation Lead Engineer 4 - 6 weeks
Document the coding standards, techninal
design, and tools instructions for the game.
Risks Analysis Producer
Ongoing during
requirements phase
Assess risks on project, determine
resolution strategy, publish to the team.
Approval
Studio management,
publisher
2 - 3 months after
requirements phase
begins.
Present all major game play elements to
management for approval, incorporate their
feedback.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.