246 THE GAME PRODUCTION HANDBOOK, 2/E
FIGURE 15.3 Common development milestones.
O
N
T
H
E
C
D
First Playable Alpha Code Freeze Beta Code Release
Third Party Submission -
CONSOLE ONLY
Time Frame
12 - 18 months before
code release
8 - 10 months before
code release
3 - 4 months before
code release
2 - 3 months before
code release
First code release
candidate available to
QA 3 weeks before
final code release
deadline.
Submit code release
candidate at least 8 - 12
weeks before desired ship
date.
Engineering
Basic functionality for a
few key features are in to
demostrate very basic
game play.
Key game play
functionaltiy is in for all
game features.
Features work as
designed, but may be
adjusted and changed
based on feedback.
Game runs on target
hardware platform.
Code complete for all
features. Only bug-
fixing from this point
forward. No new
features are added,
unless approved by
senior management.
Code complete, only
bug fixing from this
point forward.
Full code freeze.
During this phase only
crash bugs can be
fixed. Critical bugs
can be fixed with
approval.
Code final. If submission is
rejected, only specific bugs as
requested by the third party
will be fixed for re-submission.
Art
Two to three key art
assets are created and
viewable in the build. The
assets demonstrate the
look and feel of the final
version of the game.
Assets are 40 - 50%
final, with placeholder
assets for the rest of
the game.
Assets are 80 - 90%
final, with placeholder
assets for the rest of
the game.
All art assets are final
and working in game.
Only major bug-fixes
from this point
forward.
Full art freeze. No art
fixes, unless it is to fix
a crash bug.
Art final. If submission is
rejected, only specific bugs as
requested by the third party
will be fixed for re-submission.
Design
Basic features are defined,
key game play mechanics
have basic documentation
and a playable prototype if
possible.
All design
documentation is
completed. Feature
implementation is in
progress. 40 - 50% of
design production tasks
are completed. Major
areas of game are
playable as designed.
Game is 80 - 90%
playable. Playtesting
feedback is being
incorporated
All design assets are
final and working in
the game. Only
major bug fixes from
this point forward.
Minor game play
tweaks can be done,
based on playtest
feedback.
Full design freeze.
No design fixes,
unless it is to fix a
crash bug.
Design final. If submission is
rejected, only specific bugs as
requested by the third party
will be fixed for re-submission.
Sound
The sound of the game is
determined, including
voiceover, music, sound
effects. Samples are
available to communicate
the sound vision of th
game.
40 - 50% of sound
effects are in a working.
Voiceover design is in
progress, placeholder
VO files are recorded.
Music in process of
being composed.
Final voiceover is
recorded and in-game.
Final music is in game.
Sound effects are 80 -
90 % implemented.
All final sound assets
are in and working in
the game.
Full sound freeze.
Sound final. If submission is
rejected, only specific bugs as
requested by the third party
will be fixed for re-submission.
Localization
Work with publisher to
determine which
languages are needed.
Select localization vendor
and send them design
documents and first
playable. Define
localization pipeline.
Work with vendor to
determine asset
delivery schedule.
Send glossaries, cheat
codes, walkthroughs to
vendor. Test
localization pipeline to
ensure translations are
displayed correctly.
Final text and VO
assets are sent for
translation.
Translations are
completed and
returned to developer
for integration.
Final language
assets are integrated
into the game.
Linguistic testing is
completed. Send
builds to appropriate
age ratings boards to
secure final rating.
Full localization
freeze.
Localization final. If
submission is rejected, only
specific bugs as requested by
the third party will be fixed for
re-submission.
Production
Basic game requirements
and game plan are
completed.
Full production has
begun. The game
requirments and game
plan are fully completed
and approved If
working with licenses,
all licenses are secured
and an approval
process is in place.
Localizations have
started. Manual is in
process of being
written. Marketing
assets are being
generated.
Localizations are
complete, only bug
fixes from this point
forward. Manual is
complete. External
vendors are finished
with work. All
approvals for licenses
are secured.
Development team
can start rolling off
project.
All production tasks
are completed. If
submitting game to
console manufacturer,
the submission forms
are filled in and ready
to go.
Production final. Only
managing submission
process.
QA
Can test game against the
first playable milestone
deliverables defined in the
game requirements phase.
Game is now playable
as a full game,
although there are
some rough edges and
holes in some of the
functionaltiy.
Playtesting can begin.
Can test against the
alpha deliverables
expected for this
milestone.
Test plan is 100%
complete. Full game
funcationality can be
tested and bugged.
Play testing continues.
Can test against the
code freeze milestone
deliverable list.
All aspects of game
can be fully tested
and bugged. Some
playtesting continues
in order to for design
to put the final polish
on the game.
Test code release
candidates for any
crash bugs that will
prevent the game
from shipping.
Testing continues on
submission candidate(s) until
game recieves final approval.
GAME REQUIREMENTS 247
milestone delivery, as some items are so large they might span several milestones
before they are fully complete. Use categories such as the following:
■
Characters, objects, levels
■
Cinematics
■
Gameplay features
■
Engineering features
■
UI
■
Sound
■
Localization
■
Scripting
■
General
You might not be able to fill in all of information at the beginning of the project,
as there are many decisions still to be made, but fill in what you can. After the
initial lists are established, send them to the leads for review so they can check that
the goals for each milestone are attainable. Publish these lists to the team so they
clearly understand the expectations for each milestone. Also, get into the habit of
checking the lists for updates on a regular basis. However, don’t make changes to
a set of milestone deliverables that are due in a few days—that is, don’t add things
to the alpha deliverable list one week before the milestone is due. Figure 15.4 is an
example of a partial deliverable list for the Justice Unit alpha milestone.
DEFINING MILESTONES
Don Daglow, President and CEO
Stormfront Studios
I have become a convert to agile development, but I still believe in using the
waterfall method to plan overarching milestones for projects as a whole. Think
about it this way: Lewis and Clark knew they were going West on their expedition to
map North America, and they knew approximately how far away the Pacific Ocean
was located. But they didn’t have a detailed map showing them exactly what path
to follow. You can follow a similar concept for your production schedule: produce
a general waterfall-based schedule for your trip westward, then look at the first es-
sential steps and use an agile process to plan a 30 day sprint to get you there. Make
sure you have something that actually works and you are able to demo on screen at
the end of those 30 days, and that the assets, code, and lessons learned from the first
sprint make planning the subsequent 30 days possible.
Our basic process for putting together a schedule begins with the concept phase,
where we decide what the key elements of the game are going to be in really broad
248 THE GAME PRODUCTION HANDBOOK, 2/E
JUSTICE UNIT
Alpha Deliverable for March 30, 2007
Last Updated February 10, 2007
Levels
-The following levels are asset complete, with game play scripting:
*Justice Hall
*Villain’s Lair
-The following levels are have basic geometry and are viewable in game, but have no game play scripted:
*City Hall
*Office Complex
Characters
-The following characters are asset complete:
*Bulletpoint
*Montezuma
-The following characters are viewable in game, but don’t have final textures
*Caribou
UI
-UI color scheme and font are final and approved
-UI flow is prototyped in Macromedia Flash
-Basic UI screens are implemented and functioning:
*Start screen
*Profile screen
*Options screen
-In-game UI has placeholder art with basic functionality for:
*Health bar
*Inventory
Sound
-Placeholder VO cues and sound designs are implemented for the following levels:
*Justice Hall
*Villain’s Lair
-Sound designs completed for remaining levels in the game
Engineering
-Scripting tools completed and functioning
-Art tools completed and functioning
-Networking APIs are implemented
-Build process finalized and in place
FIGURE 15.4 Partial alpha deliverable list for Justice Unit.
O
N
T
H
E
C
D
strokes. Then we plan exactly how the game will work and be played in the pre-produc-
tion phase, and produce a demo that addresses the big risks in the project. Is the game-
play mechanic fun? Can you get a 60 fps frame rate when you have 101 dogs and one
aardvark all moving on screen? With this planning done, you can then enter into the
production phase, where the team’s size will grow and the bulk of the work gets done.
Finally, you go through the test phase, where the game is tested and debugged and
final balancing and tuning is done. It is good to have milestones at least once a month,
although the distant milestones may not have a lot of definition early in a project.
GAME REQUIREMENTS 249
15.4 EVALUATE TECHNOLOGY
During the game requirements phase, the lead engineer is evaluating the tech-
nology needs of the project. Decisions must be made on what game engine, art
tools, scripting tools, AI systems, physics systems, and other technical elements
are needed to provide the desired game functionality. The technology used will
depend on the schedule, the resources, the desired features, and the quality of
these features. For example, if the main goal of the game is to have cutting-edge
graphics, the lead engineer will spend some time evaluating what graphics tech-
nology is necessary.
The lead engineer must also research how this technology will be obtained:
will it be coded by in-house engineers, or will an existing software package be
licensed and modified for use in the game? There are pros and cons of each
choice, and larger games will probably use a combination of in-house technology
and licensed technology.
The benefits of creating the technology in-house are that it is owned by the
studio and, therefore, has no licensing fee; in-house experts are readily available
to bug-fix and add feature enhancements; and the technology can be specifically
tailored to the game. One con is that the engineers have to spend valuable de-
velopment time re-inventing the wheel for basic technical functionality (such as
physics, AI, and animation), meaning that they have less time to focus on game-
specific functionality. Also, using a team of in-house engineers to code basic
functionality, such as a physics system, might be more expensive in the long run
instead of licensing a middleware solution, such as Havok.
The main benefit of licensing an existing technology is that it provides a
basic framework for common technologies, meaning the engineers can focus on
game-specific functionality. The drawbacks can be costs (especially if the bud-
get is small), limited technical support from the vendor, and the need to alter
the code to fit the game’s functionality. However, these drawbacks might be
worth the trouble if licensing saves time and/or money during the development
process.
After the lead engineer has researched the available technologies, he will
make a recommendation to the producer. The producer can use this informa-
tion when creating the budget and schedule and will work closely with the lead
engineer to determine the best technology solutions for the game.
15.5 DEFINE TOOLS AND PIPELINE
In addition to evaluating which technologies will be used for the game, the lead
engineer will work with the other leads to define the production pipeline. The
production pipeline refers to the series of steps that are needed to get code and
250 THE GAME PRODUCTION HANDBOOK, 2/E
assets working in a playable version of the game. It must smoothly incorporate
the tools, assets, and production needs of the game. It is very rare that an asset
can be created and be instantly useable in the game; the asset might need to be
converted to a specific file format or compiled into the code. The game is not in-
stantly playable with the new updates and assets; the engineers have to compile
the code and build a new executable first. Key things to consider when defining
the pipeline are the following:
What tools and software are needed? Software tools are needed to con-
vert the file formats, and source control software must be used to check assets
in and out of the build. Decisions must also be made on which compilers and
coding languages are used.
Can the pipeline support two-way functionality? The pipeline should
support functionality for assets to be converted for game use and the ability
to convert game assets back into their original source assets. This allows asset
changes to be made more readily.
What is the critical path? Are there any bottlenecks? Make sure that
no one person has a disproportional amount of work in the pipeline and
becomes a bottleneck for getting assets converted. Also, limit the number
of steps in the pipeline; assets should be viewable and playable in a build as
quickly as possible.
When does the system need to be fully functioning? In order to create
a playable build of the game with the correct assets, the pipeline must be
functioning. Partial functionality is useable for a few months, as long it is
does not prevent people from creating assets and seeing them in the game.
How are assets managed and tracked in the system? Decide which
source control software to use, so that people can check out assets before
working on them. Everything should be kept under version control to pre-
vent multiple versions of a file from causing confusion in the pipeline.
Which areas of the system can be automated? Automate as much of the
pipeline as possible in order to reduce time and human error.
After these questions are answered, the leads can determine what pipeline
will best work for the game. The Game Asset Pipeline by Ben Carter is an excellent
resource for more details about setting up a production pipeline. For example,
the production pipeline for Justice Unit requires the artists to create their charac-
ter models in 3DSMax, convert them to a proprietary file format, and check them
into the build. The build is set up so the artist can copy over the model to a build
of the game on his personal development kit and instantly see how it looks in the
game. However, in order for the character model to be fully viewable in an official
build, the engineers must create a new build and publish it to the team.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.