TEAMFLY

Wordware Publishing, Inc.
Library of Congress Cataloging-in-Publication Data
Bethke, Erik.
Game development and production / by Erik Bethke.
p. cm.
ISBN 1-55622-951-8
1. Computer games--Design. 2. Computer games--Programming.
3. Project management. I. Title.
QA76.76.C672 B47 2002
794.8'1526--dc21 2002153470
CIP
© 2003, Wordware Publishing, Inc.
All Rights Reserved
2320 Los Rios Boulevard
Plano, Texas 75074
No part of this book may be reproduced in any form or by any means
without permission in writing from Wordware Publishing, Inc.
Printed in the United States of America
ISBN 1-55622-951-8
10987654321
0301
Product names mentioned are used for identification purposes only and may be trademarks of their respective
companies.
All inquiries for volume purchases of this book should be addressed to Wordware Publishing,
Inc., at the above address. Telephone inquiries may be made by calling:
(972) 423-0090
Contents
Foreword ...............................xvii
Preface ................................xix
Acknowledgments ..........................xxi

The Scope of the Game Must Match Financial Parameters ...17
Why Your Game Should Profit ....................18
Feature Storm ...........................18
If the Game Is Worth Making, Make It Excellent ........19
iii
Excellence in Spades .........................19
Game Making Is a Long Race of Many Game Projects .......20
A Brief History of Software Development..............21
Overly Long Game Projects Are Disastrous ............21
What Late Games Do to the Publisher ..............22
Our Project Plan Behind Starfleet Command ............22
The Vision for Starfleet Command ................23
Constraints Give Much Needed Focus................24
On Bugs Shipped in Starfleet Command...............24
Well-Met Goals Enable Future Successes ..............25
Strong Game Developers Have Strong Foundations ........25
The Tension between Preproduction and Production........25
The Power of the Console ......................26
Why Aren’t All Publishers Using Preproduction?..........27
The Process Is Changing .....................27
A Strong Plan Makes Game Development Easy ..........28
The Gravitational Pull of Feature Creep ...............28
Task Visibility for Team Motivation and for Progress Tracking . . 29
Use Your Core Competencies and Outsource the Rest .......29
A Pitfall of Success—Fan-Requested Features and Changes....29
The Relentless Pace of Technology .................30
The Art of War and Games ......................32
Chapter 4
Game Project Survival Test .............33
The Game Project Survival Test ...................33

Concept Artist ..........................46
2D Artist/Interface Designer ..................47
3D Modeler ...........................47
Character Modeler .......................47
Texture Artist ..........................48
Animator/Motion Capture Studio ...............48
Storyboarder...........................49
Audio Parts .............................49
Voice-Overs ...........................49
Sound Effects ..........................49
Music ..............................50
Management Parts .........................50
Line Producer ..........................50
Associate Producer .......................50
Studio Head/Executive Producer................51
Producer .............................51
Quality Assurance Parts .......................52
Publisher QA Parts.........................52
QALead.............................52
Main Team ............................53
Multiplayer Team ........................53
Fresh Teams ...........................53
Compatibility Team .......................53
Localization Team ........................53
Beta Testing ............................54
Beta Testers ...........................54
Beta Testing Program Manager ................54
Business Parts.............................55
Business Development Parts ...................55
Business Development Executive ...............55

High-Profile/High-Quality Projects ..............73
WalkAway...............................74
Chapter 7
Key Design Elements ................75
Business Context Shapes Design, or Does Design Shape
the Business Context? ........................76
Reconcile the Business Context and Game Idea Early .......76
The Effects of a Slipped Game .................77
Methods and the Unified Development Process ..........81
What Is a Development Method? .................81
Why Use the Unified Software Development Process? .....81
Requirements Capture.......................82
Use Cases .............................82
Case Studies ..............................87
Case Study I—Diablo .......................87
Use Cases of Diablo .......................88
Quick Analysis of the Use Cases of Diablo ..........89
Case Study II—Gran Turismo ...................90
Use Cases of Gran Turismo...................92
Quick Analysis of the Use Cases of Gran Turismo ......93
The Key Design Elements of Your Game ............94
The Battle of the Counterterrorists Games ...........94
The Key Design Elements of Rainbow Six ..........95
vi Contents
Are We Playing a Mission or Planning a Mission?.......95
The Key Design Elements of Counter-Strike .........96
Most Popular Multiplayer Game ................96
Of Intersecting Sets and Elite Forces .............97
Some Straight Questions to Ask Yourself ..............99
What Genre or Genres Does Your Game Feature? ......99

2D Sprites or 3D Models ...................115
Missions, Levels, or Areas ..................115
Voice ..............................116
Key Framing and Motion Capture ..............117
Sound Effects .........................121
Music ..............................121
Special Effects .........................125
Stepping Back a Bit .........................127
Contents vii
Chapter 9
The Technical Design Document .........129
Object-Oriented Design .......................129
Purpose of the Technical Design Document ............130
Why Have a Software Development Process? .........132
The Unified Software Development Process ..........133
Core Workflows of the Unified Process............134
Phases of a Workflow in the Unified Process.........134
When Should the Technical Design Document Be Written? . . 135
What Goes into the Technical Design Document?.........136
Requirements Capture ......................136
Reverse Engineering .....................143
Nonobvious Requirements ..................143
Requirements Analysis ......................144
Class Diagram...........................145
Relationships..........................146
Drawing “is a” and “has a” Relationships and
Ordinalities...........................146
Adding Annotation .......................147
Other UML Diagram Types ...................147
Dynamic Modeling .......................148

Production Begins—Now What? ..................177
Task Visibility ............................177
TheWall...............................177
Journals ................................179
The Cult of the Yellow Notebook ................179
Walk Around .............................180
Milestone Orientation Meetings ..................180
Praise People Publicly ......................180
Maintain the Gantt Chart ......................181
Update the Risks Chart .......................182
Chapter 12
Outsourcing Strategies...............183
Why Outsource? ...........................183
When to Think About Outsourcing .................184
What to Outsource ..........................185
Do Not Outsource Programming—Exceptions Noted .....185
On Outsourcing Art........................186
Movies, Cut Scenes, or Full Motion Video ..........186
3D Models—Modeling.....................187
Animation and Motion Capture ................187
User Interface Art .......................188
Audio................................188
Music ..............................188
Sound Effects .........................189
Voice-Over ...........................190
What Else to Outsource .....................190
Chapter 13
Shipping Your Game ................191
Shipping Is a Phase .........................191
How Do You Ship a Great Game? ..................191

Requirements Gathering ..............211
The Flavors of Requirements ..................211
Creative/License Requirements ...............211
Technical Requirements ....................212
Fiscal and Temporal Requirements ..............213
Use Case Diagrams ........................213
Chapter 16
The Design Document ...............215
What Does the Game Design Document Do? ...........215
The Game Design Document as a Process.............216
Game Concept ..........................216
Brainstorm ...........................216
Delegate Design ........................217
Managing the Design Document ...............218
60 Seconds of Gameplay....................218
Core Gameplay.........................219
The Walkthrough .......................220
Asset Lists ...........................221
Use of Other Games ......................222
Menu Design ..........................222
Game Mechanics Detail ....................223
Write the Manual? .......................223
Concept Sketches and Art Style Guide ............224
On Completeness and Uncertainty ..............224
Cut Features Even Before Considering the Schedule .....224
Maintain the Game Design Document .............225
On Fulfilled Expectations ......................225
x Contents
TEAMFLY



Team-Fly
®

Chapter 17
Unified Modeling Language Survival Guide ...227
Use Cases Deliver Requirements..................227
Class Diagrams Are the Keystone of Design............228
Detailed Syntax of the Class Diagram ...............230

Time Estimates ...................259
Two Ways to Estimate a Task ....................260
Time Boxing ...........................260
Task Estimating..........................261
Art...............................261
Design .............................261
Programming..........................262
Each Shall Estimate Thy Own Tasks ..............264
Save Your Plans and Compare ..................264
Making the Plan ...........................264
Contents xi