Tải bản đầy đủ (.pdf) (609 trang)

game design - theory and practice

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (34.61 MB, 609 trang )

TEAMFLY






















































Team-Fly
®

Game Design:
Theory & Practice
Richard Rouse III
Illustrations by

Steve Ogden
Atomic Sam character designed by
Richard Rouse III and Steve Ogden
Library of Congress Cataloging-in-Publication Data
Rouse, Richard.
Game design: theory & practice / by Richard Rouse III ; illustrations by Steve Ogden.
p. cm.
Includes bibliographical references and index.
ISBN 1-55622-735-3 (pbk.)
1. Computer games—Programming. I. Title.
QA76.76.C672 R69 2000
794.8'1526—dc21 00-053436
CIP
© 2001, 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-735-3
10987654321
0011
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
ii
Copyright Notices
Atomic Sam design document and images ™ and ©1999-2000 Richard Rouse III. Atomic Sam

character designed by Richard Rouse III and Steve Ogden. All rights reserved. Used with kind
permission.
Portions of Chapter 18: Interview: Jordan Mechner originally appeared in Inside Mac Games
magazine. Used with kind permission.
Images from Duke Nukem 3D ® and © 2000 3D Realms Entertainment. All rights reserved.
Used with kind permission.
Images from the 3D version of Centipede ® and © 2000 Atari Interactive, Inc. All rights
reserved. Used with kind permission. Though the game is referred to as “Centipede 3D” in this
book in order to differentiate it from the older game, its proper name is simply “Centipede.”
Images from Super Breakout, Asteroids, Centipede, Millipede, and Tempest
®
or ™ and © 2000
Atari Interactive, Inc. All rights reserved. Used with kind permission.
Images from WarCraft, WarCraft II, StarCraft, and Diablo II ® or ™ and © 2000 Blizzard Enter-
tainment. All rights reserved. Used with kind permission.
Images from Hodj ’n’ Podj and The Space Bar © 2000 Boffo Games. All rights reserved. Used
with kind permission.
Images from Pathways into Darkness, Marathon, Marathon 2, Marathon Infinity, and Myth: The
Fallen Lords ® or ™ and © 2000 Bungie Software Products Corporation. All rights reserved.
Used with kind permission.
Images from Balance of Power, Trust and Betrayal: The Legacy of Siboot, Balance of Power II:
The 1990 Edition, Guns & Butter, Balance of the Planet, and the Erasmatron ® or ™ and © 2000
Chris Crawford. All rights reserved. Used with kind permission.
Images from Myst ® and ©1993 Cyan, Inc. All rights reserved. Used with kind permission.
Images from Tomb Raider, Tomb Raider II, and Thief II ® or ™ and © 2000 Eidos Interactive.
All rights reserved. Used with kind permission.
Images from Unreal and Unreal Tournament ® or ™ and © 2000 Epic Games. All rights
reserved. Used with kind permission.
Images from Sid Meier’s Gettysburg! and Sid Meier’s Alpha Centauri ™ and © 2000 Firaxis
Games. All rights reserved. Used with kind permission.

Images from Doom, Doom II, Quake II, and Quake III Arena ® and © 2000 id Software. All
rights reserved. Used with kind permission.
Images from Spellcasting 101 © 1990 Legend Entertainment Company, Spellcasting 201 © 1991
Legend Entertainment Company, and Superhero League of Hoboken © 1994 Legend Entertain
-
ment Company. All rights reserved. Used with the kind permission of Infogrames, Inc.
iii
Images from Maniac Mansion, Loom, and Grim Fandango ® or ™ and © 2000 LucasArts Enter
-
tainment Company, LLC. All rights reserved. Used with kind authorization.
Images from SimCity, SimEarth, SimAnt, SimCity 2000, SimCopter, SimCity 3000, and The
Sims ® and © 2000 Maxis, Inc. All rights reserved. Used with kind permission.
Images from Karateka, Prince of Persia, and The Last Express ® or ™ and © 2000 Jordan
Mechner. All rights reserved. Used with kind permission.
Images from F-15 Strike Fighter, Pirates!, F-19 Stealth Fighter, Covert Action, Railroad Tycoon,
Civilization, and Civilization II ® or ™ and © 2000 Microprose, Inc. All rights reserved. Used
with kind permission.
Images from Gauntlet
®
, Gauntlet II
®
, Xybots™, San Francisco Rush: The Rock - Alcatraz Edi
-
tion™, San Francisco Rush: Extreme Racing
®
, San Francisco Rush 2049™, and Gauntlet
Legends
®
© 2000 Midway Games West, Inc. All rights reserved. Used with kind permission.
Images from Defender

®
, Robotron: 2048
®
, Joust
®
, and Sinistar
®
© 2000 Midway Amusement
Games, LLC. All rights reserved. Used with kind permission.
Images from Super Mario Bros., Super Mario 64, and The Legend of Zelda: Ocarina of Time ®
and © 2000 Nintendo of America. All rights reserved. Used with kind permission.
Images from Oddworld: Abe’s Oddyssee
®
and © 1995-2000 Oddworld Inhabitants, Inc. All
Rights Reserved. ® designate trademarks of Oddworld Inhabitants. All rights reserved. Used
with kind permission.
Images from Odyssey: The Legend of Nemesis™ and © 2000 Richard Rouse III. All rights
reserved. Used with kind permission.
Images from Damage Incorporated™ and © 2000 Richard Rouse III and MacSoft. All rights
reserved. Used with kind permission.
Images from the Riot Engine Level Editor © 2000 Surreal Software, Inc. All rights reserved.
Used with kind permission.
Images from The Next Tetris™ and © 1999 Elorg, sublicensed to Hasbro Interactive, Inc. by The
Tetris Company. Tetris © 1987 Elorg. Original Concept & Design by Alexey Pajitnov. The Next
Tetris™ licensed to The Tetris Company and sublicensed to Hasbro Interactive, Inc. All rights
reserved. Used with kind permission.
iv
Dedication
To my parents, Richard and Regina Rouse
v

Acknowledgments
Thanks to Steve Ogden for bringing Atomic Sam to life and providing the bril
-
liant illustrations which enliven these pages.
Thanks to James Hague, Ian Parberry, and Margaret Rogers for looking over
my work and providing me with the invaluable feedback and support which have
improved this book tremendously.
Thanks to Chris Crawford, Ed Logg, Jordan Mechner, Sid Meier, Steve
Meretzky, and Will Wright for graciously subjecting themselves to my endless
questioning. To quote Mr. Wright, I’m “pretty thorough.”
Thanks to Jim Hill, Wes Beckwith, Beth Kohler, Kellie Henderson, Martha
McCuller, Alan McCuller, and everyone at Wordware for making this book become
a reality.
For their help with this book, thanks to Benson Russell, John Scott Lewinski,
Ari Feldman, Laura J. Mixon-Gould, Jeff Buccelatto, Jayson Hill, Laura Pokrifka,
Josh Moore, Lisa Sokulski, Dan Harnett, Steffan Levine, Susan Wooley, Chris
Brandkamp, Kelley Gilmore, Lindsay Riehl, Patrick Buechner, Scott Miller, Greg
Rizzer, Lori Mezoff, Jenna Mitchell, Ericka Shawcross, Maryanne Lataif, Bryce
Baer, Bob Bates, James Conner, Lisa Tensfeldt, Paula Cook, Donald Knapp, and
Diana Fuentes.
Special thanks to Margaret Rogers, June Oshiro and Matt Bockol, Ben Young,
Alain and Annalisa Roy, Gail Jabbour, Amy Schiller, Katie Young & Eric
Pidkameny, Rafael Brown, Eloise Pasachoff, Mark Bullock and Jane Miller, Dave
Rouse, Linda, Bob and Grayson Starner, Jamie Rouse, Alan Patmore and everyone
at Surreal, the Leaping Lizard crew, Brian Rice, Lee Waggoner, Pat Alphonso, Clay
Heaton, Alex Dunne, Gordon Cameron, Tuncer Deniz, Bart Farkas, Peter Tamte,
Nate Birkholtz, Al Schilling, Cindy Swanson and everyone at MacSoft, Doug
Zartman, Alex Seropian, Jason Jones, Jim McNally, Jeff O’Connor, Ira Harmon,
Gordon Marsh, Chuck Schuldiner, Glenn Fabry, and Derek Riggs.
About the AuthorAbout the Author

Richard Rouse III is a computer game designer, programmer, and writer at Surreal
Software (www.surreal.com). Rouse has been designing games professionally for
over seven years and has played a lead design role in the development of games for
the PC, Macintosh, Sega Dreamcast, Sony PlayStation, and PlayStation 2. His
credits include Centipede 3D, Odyssey: The Legend of Nemesis, and Damage Incor
-
porated. At Surreal he currently spends all his waking hours working on a secret
PlayStation 2 action/adventure project, while also contributing where he can to
Drakan for PlayStation 2. Rouse has written about game design for publications
including Game Developer, SIGGRAPH Computer Graphics, Gamasutra, and
Inside Mac Games.
Your FeedbackYour Feedback
Your feedback to this book, including corrections, comments, or merely
friendly ramblings, is encouraged. Please mail them to the author at
You will also find the web page for this book,
which will be used to track corrections, updates, and other items of interest, at
www.paranoidproductions.com. See you there.
About the ArtistAbout the Artist
Steve Ogden has been an artist, illustrator, and cartoonist for almost 20 years, and
miraculously, his right hand shows no sign of dropping off. Among his projects in
the digital domain, he has worked on Bally’s Game Magic casino game as well as
Centipede 3D, and has just finished a stint as Art Director and Production Lead on
Cyan’s realMYST (while finishing the illustrations to this book during the few hours
he was supposed to be sleeping). He is now gearing up for work on Cyan’s next
game, if they can catch him and chain him to his desk again. To see more of his
work, both of the 2D and 3D variety, stop by his web site: www.lunaenter-
tainment.com. You can reach him at ogden@ lunaentertainment.com. He is now
going to crawl to a beach very far away and sleep for a while.
vii


Contents
Introduction xviii
Chapter 1 What Players Want 1
Why Do Players Play? 2
Players Want a Challenge 2
Players Want to Socialize 3
Players Want a Dynamic Solitaire Experience 5
Players Want Bragging Rights 5
Players Want an Emotional Experience 6
Players Want to Fantasize 7
What Do Players Expect? 8
Players Expect a Consistent World 8
Players Expect to Understand the Game-World’s Bounds 9
Players Expect Reasonable Solutions to Work 10
Players Expect Direction 10
Players Expect to Accomplish a Task Incrementally 12
Players Expect to Be Immersed 12
Players Expect to Fail 14
Players Expect a Fair Chance 14
Players Expect to Not Need to Repeat Themselves 15
Players Expect to Not Get Hopelessly Stuck 16
Players Expect to Do, Not to Watch 17
Players Do Not Know What They Want, But They Know It When They See It . 18
A Never-Ending List 19
Chapter 2 Interview: Sid Meier 20
Chapter 3 Brainstorming a Game Idea: Gameplay,
Technology, and Story 42
Starting Points 43
Starting with Gameplay 44
Starting with Technology 45

Starting with Story 47
Working with Limitations 50
Odyssey: The Legend of Nemesis 50
ix
Damage Incorporated 51
Centipede 3D 53
Embrace Your Limitations 54
Established Technology 55
The Case of the Many Mushrooms 55
The Time Allotted 57
If You Choose Not to Decide, You Still Have Made a Choice 58
Chapter 4 Game Analysis: Centipede 59
Classic Arcade Game Traits 62
Input 65
Interconnectedness 66
Escalating Tension 68
One Person, One Game 71
Chapter 5 Focus 73
Establishing Focus 74
An Example: Snow Carnage Derby 77
The Function of the Focus 79
Maintaining Focus 82
Fleshing Out the Focus 83
Changing Focus 84
Sub-Focuses 88
Using Focus 91
Chapter 6 Interview: Ed Logg 93
Chapter 7 The Elements of Gameplay 121
Unique Solutions 122
Anticipatory versus Complex Systems 122

Emergence 123
Non-Linearity 125
Types of Non-Linearity 125
Implementation 127
The Purpose of Non-Linearity 129
Modeling Reality 130
Teaching the Player 132
Rewards 134
Input/Output 136
Controls and Input 136
Output and Game-World Feedback 141
Basic Elements 145
Chapter 8 Game Analysis: Tetris 146
Puzzle Game or Action Game? 147
Tetris as a Classic Arcade Game 149
Contents
x
TEAMFLY























































Team-Fly
®

The Technology 151
Artificial Intelligence 153
Escalating Tension 154
Simplicity and Symmetry 155
Ten Years On, Who Would Publish Tetris? 157
Chapter 9 Artificial Intelligence 158
Goals of Game AI 160
Challenge the Player 161
Not Do Dumb Things 163
Be Unpredictable 164
Assist Storytelling 167
Create a Living World 169
The Sloped Playing Field 170
How Real is Too Real? 171
AI Agents and Their Environment 172
How Good is Good Enough? 175

Scripting 177
Artificial Stupidity 178
Chapter 10 Interview: Steve Meretzky 179
Chapter 11 Storytelling 214
Designer’s Story Versus Player’s Story 216
Places for Storytelling 218
Out-of-Game 219
In-Game 224
External Materials 227
Frustrated Linear Writers 228
Game Stories 230
Non-Linearity 232
Working with the Gameplay 233
The Dream 234
Chapter 12 Game Analysis: Loom 236
Focused Game Mechanics 238
User Interface 239
The Drafts System 241
Difficulty 243
Story 244
Loom as an Adventure Game 245
Chapter 13 Getting the Gameplay Working 248
The Organic Process 251
Too Much Too Soon 251
Keep It Simple 253
Contents
xi
Building the Game 254
Core Technology 254
Incremental Steps 255

A Fully Functional Area 256
Going Through Changes 257
Programming 259
When is It Fun? 261
Chapter 14 Interview: Chris Crawford 263
Chapter 15 Game Development Documentation 291
Document Your Game 293
Concept Document or Pitch Document or Proposal 293
Design Document 294
Flowcharts 295
Story Bible 295
Script 297
Art Bible 300
Storyboards 301
Technical Design Document 301
Schedules and Business/Marketing Documents 302
No Standard Documentation 302
The Benefits of Documentation 303
Chapter 16 Game Analysis: Myth: The Fallen Lords 304
Use of Technology 305
Game Focus 308
Storytelling 310
Hard-Core Gaming 311
Multi-Player 313
Overall 314
Chapter 17 The Design Document 316
The Writing Style 318
The Sections 321
Table of Contents 321
Introduction/Overview or Executive Summary 322

Game Mechanics 323
Artificial Intelligence 329
Game Elements: Characters, Items, and Objects/Mechanisms 331
Story Overview 334
Game Progression 335
System Menus 337
One Man’s Opinion 337
Inauspicious Design Documents 338
Contents
xii
The Wafer-Thin or Ellipsis Special Document 338
The Back-Story Tome 339
The Overkill Document 340
The Pie-in-the-Sky Document 341
The Fossilized Document 342
A Matter of Weight 343
Getting It Read 343
Documentation is Only the Beginning 344
Chapter 18 Interview: Jordan Mechner 346
Chapter 19 Designing Design Tools 378
Desired Functionality 380
Visualizing the Level 380
The Big Picture 382
Jumping into the Game 384
Editing the World 386
Scripting Languages and Object Behaviors 388
Us Versus Them 390
The Best of Intentions 392
A Game Editor for All Seasons 394
Chapter 20 Game Analysis: The Sims 395

Abdicating Authorship 396
Familiar Subject Matter 398
Safe Experimentation 399
Depth and Focus 400
Interface 401
Controlled Versus Autonomous Behavior 403
A Lesson to Be Learned 404
Chapter 21 Level Design 406
Levels in Different Games 408
Level Separation 409
Level Order 410
The Components of a Level 412
Action 413
Exploration 413
Puzzle Solving 415
Storytelling 415
Aesthetics 416
Balancing It All 418
Level Flow 418
Elements of Good Levels 421
Player Cannot Get Stuck 421
Contents
xiii
Sub-Goals 422
Landmarks 423
Critical Path 423
Limited Backtracking 423
Success the First Time 424
Navigable Areas Clearly Marked 424
Choices 424

A Personal List 425
The Process 425
step 1. Preliminary 425
step 2. Conceptual and Sketched Outline 427
step 3. Base Architecture 427
step 4. Refine Architecture Until It is Fun 428
step 5. Base Gameplay 429
step 6. Refine Gameplay Until It is Fun 430
step 7. Refine Aesthetics 430
step 8. Playtesting 431
Process Variations 431
Who Does Level Design? 432
Collaboration 433
Chapter 22 Interview: Will Wright 434
Chapter 23 Playtesting 472
Finding the Right Testers 473
Who Should Test 474
Who Should Not Test 477
When to Test 479
HowtoTest 481
Guided and Unguided Testing 482
Balancing 483
Your Game is Too Hard 485
The Artistic Vision 487
Conclusion 489
Art 489
The Medium 490
The Motive 491
Appendix Sample Design Document: Atomic Sam 493
Atomic Sam: Focus 495

Atomic Sam 496
Design Document 496
Table of Contents 496
I. Overview 499
Contents
xiv
II. Game Mechanics 500
Overview 500
Camera 501
In-Game GUI 502
Replaying and Saving 502
Control Summary 503
General Movement 503
Flying Movement 504
Surfaces 507
Picking Up Objects 507
Throwing Projectiles 508
Electric Piranha 510
Actions 510
Interactive Combat Environments 512
Looking 513
Friends 513
Speaking 514
Cut-Scenes 515
Storytelling 515
Levels 516
III. Artificial Intelligence 518
Enemy AI 519
Player Detection 519
Motion 519

Flying 520
Pathfinding 520
Taking Damage 520
Combat Attacks 520
Evading 521
Special Actions 521
Trash Talking 522
Falling into Traps 522
Non-Combatant Agents 523
Friends 523
IV. Game Elements 525
Items 525
Characters 527
V. Story Overview 536
VI. Game Progression 538
Setting 538
Introduction 540
Gargantuopolis 540
The Electric Priestess’ Bubble Home 540
Benthos 541
Contents
xv
Harmony 542
New Boston 543
The Electric Priestess’ Bubble Home 544
The Ikairus 545
VII. Bibliography 545
Glossary 546
Selected Bibliography 562
Index 565

Contents
xvi
Introduction
My earliest recollection of playing a computer game was when I stumbled upon a
half-height Space Invaders at a tiny Mexican restaurant in my hometown. I was per
-
haps six, and Space Invaders was certainly the most marvelous thing I had ever
seen, at least next to LegoLand. I had heard of arcade games, but this was the first
one I could actually play. Space Invaders, I knew, was better than television,
because I could control the little ship at the bottom of the screen using the joystick
and shoot the aliens myself instead of watching someone else do it. I was in love.
The irony of this story is that, at the time, I failed to comprehend that I had to stick
quarters into the game to make it work. The game was running in “attract” mode as
arcade games do, and my young mind thought I was controlling the game with the
joystick when I was actually not controlling anything. But the idea was still
mind-blowing.
This book is about developing original computer games that will hopefully
have the same mind-blowing effect on players that Space Invaders had on my
young brain. This book deals with that development process from the point of view
of the game designer. Many books have been written about the programming of
computer games, but I can remember my frustration in being unable to find a book
such as this one when I was an aspiring game designer. In some ways, I have writ
-
ten this book for myself, for the person I was a decade ago. I hope that other people
interested in designing games will find this book informative. In my humble opin
-
ion, it is the game designer who has the most interesting role in the creation of a
computer game. It is the game’s design that dictates the form and shape of the
game’s gameplay, and this is the factor which differentiates our artistic medium
from all others.

xvii
What is Gameplay?
I hear you asking, “But what is gameplay?” Many people think they know what
gameplay is, and indeed there are many different reasonable definitions for it. But I
have one definition that covers every use of the term you will find in this book. The
gameplay is the component of computer games which is found in no other art form:
interactivity. A game’s gameplay is the degree and nature of the interactivity that
the game includes, i.e., how the player is able to interact with the game-world and
how that game-world reacts to the choices the player makes. In an action game such
as Centipede, the gameplay is moving the shooter ship around the lower quadrant of
the screen and shooting the enemies that attack relentlessly. In SimCity, the
gameplay is laying out a city and observing the citizens that start to inhabit it. In
Doom, the gameplay is running around a 3D world at high speed and shooting its
extremely hostile inhabitants, gathering some keys along the way. In San Francisco
Rush, the gameplay is steering a car down implausible tracks while jockeying for
position with other racers. In StarCraft, the gameplay is maneuvering units around a
map, finding resources and exploiting them, building up forces, and finally going
head to head in combat with a similarly equipped foe. And in Civilization, the
gameplay is exploring the world, building a society from the ground up, discovering
new technologies, and interacting with the other inhabitants of the world.
Though some might disagree with me, the gameplay does not include how the
game-world is represented graphically or what game engine is used to render that
world. Nor does it include the setting or story line of that game-world. These aes-
thetic and content considerations are elements computer games may share with
other media; they are certainly not what differentiates games from those other
media. Gameplay, remember, is what makes our art form unique.
What is Game Design?
What, then, is game design? Having defined what exactly I mean when I refer to
gameplay, the notion of game design is quite easily explained: the game design is
what determines the form of the gameplay. The game design determines what

choices the player will be able to make in the game-world and what ramifications
those choices will have on the rest of the game. The game design determines what
win or loss criteria the game may include, how the user will be able to control the
game, and what information the game will communicate to him, and it establishes
how hard the game will be. In short, the game design determines every detail of
how the gameplay will function.
Introduction
xviii
Who is a Game Designer?
By this point it should be obvious what a game designer does: she determines what
the nature of the gameplay is by creating the game’s design. The terms “game
designer” and “game design” have been used in such a wide variety of contexts for
so long that their meaning has become dilute and hard to pin down. Some seem to
refer to game design as being synonymous with game development. These people
refer to anyone working on a computer game, be they artist, programmer, or pro
-
ducer, as a game designer. I prefer a more specific definition, as I have outlined
above: the game designer is the person who designs the game, who thereby estab
-
lishes the shape and nature of the gameplay.
It is important to note some tasks in which the game designer may be involved.
The game designer may do some concept sketches or create some of the art assets
that are used in the game, but he does not have to do so. A game designer may
write the script containing all of the dialog spoken by the characters in the game,
but he does not have to do so. A game designer may contribute to the programming
of the game or even be the lead programmer, but he does not have to do so. The
game designer may design some or all of the game-world itself, building the levels
of the game (if the project in question has levels to be built), but he does not have to
do so. The game designer might be taking care of the project from a management
and production standpoint, keeping a careful watch on the members of the team to

see that they are all performing their tasks effectively and efficiently, but he does
not have to do so. All someone needs to do in order to justifiably be called the
game’s designer is to establish the form of the game’s gameplay. Indeed, many
game designers perform a wide variety of tasks on a project, but their central con
-
cern should always be the game design and the gameplay.
What is in This Book?
This book contains a breadth of information about game design, covering as many
aspects as possible. Of course, no single book can be the definitive work on a partic
-
ular art form. What this book certainly is not is a book about programming
computer games. There are a wealth of books available to teach the reader how to
program, and as I discuss later in this book, knowing how to program can be a great
asset to game design. However, it is not a necessary component of designing a
game; many fine designers do not know how to program at all.
The chapters in this book are divided into three categories. First are the twelve
core chapters which discuss various aspects of the development of a computer
game, from establishing the game’s focus, to documenting the game’s design, to
establishing the game’s mode of storytelling, to playtesting the near-final product.
Introduction
xix
These chapters discuss the theory behind game design, and what a designer should
strive for in order to create the best game possible. The chapters also include dis
-
cussions of the reality of game development, using examples from my own
experience, to delve into the actual practice of game design.
There are five analysis chapters included in this book, covering five excellent
games in five different genres. One of the most important skills a game designer
must have is the ability to analyze games that she enjoys in order to understand
what those games do well. By understanding these other games, the designer may

then attempt to replicate those same qualities in her own projects. That is not to
suggest that good game designers merely copy the work of other game designers.
Understanding the reasons why other games succeed will bring the designer a more
complete understanding of game design as a whole. Every game designer should
take the games that she finds most compelling and try to examine what makes them
tick. The examples I include in this book, Centipede, Tetris, Loom, Myth: The
Fallen Lords, and The Sims, are all very unique games. And though a given project
you are working on may not be similar to any of these games, a lot can be learned
from analyzing games of any sort. First-person shooter designers have had great
success in revitalizing their genre by looking at adventure games. Certainly,
role-playing game designers have recently learned a lot from arcade game design-
ers. Melding in techniques from other genres is the best way to advance the genre
you are working on and to create something truly original.
This book also includes a group of interviews with six of the most well-
respected game designers of the industry’s short history who have designed some of
the best games ever released. These are lengthy interviews that go deeper than the
short press kit style interviews one finds on the Internet or in most magazines. In
each interview the subject discusses the best titles of his career and why he believes
they turned out as well as they did. The designers also talk at length about their own
techniques for developing games. Throughout my own career in game develop
-
ment, I have found interviews with other computer game designers to be
exceedingly helpful in learning how to perfect my craft. There is much information
to be gleaned from these chapters, ideas that can help any game designer, regardless
of how experienced he may be.
At the end of the book you will find a glossary. Though it is far from a com
-
plete listing of game design terminology, it does cover many of the more esoteric
terms I use in the book, such as a personal favorite of mine, “surrogate.” Every
game designer has a set of jargon she uses to refer to various aspects of her craft,

and this jargon is seldom the same from one designer to the next. If nothing else,
the glossary should help you to understand my own jargon. For instance, it will tell
you the difference between gameplay and game mechanics. Furthermore, readers
who may find the content of this book to assume too much knowledge may find the
Introduction
xx
TEAMFLY























































Team-Fly
®

glossary helpful in sorting out what an RTS game is and what the two different
meanings for FPS are. Often, discussions of game design can degrade into ques
-
tions of semantics, with no two sides ever meaning exactly the same thing when
they refer to a game’s “engine.” I hope that the glossary will help readers to avoid
that problem with this book.
Who This Book is For
This book is for anyone who wants to understand the computer game development
process better from a strictly game design standpoint. As I stated earlier, there are
plenty of books available to teach you how to program, or how to use Photoshop
and 3D Studio Max. This book will do neither of these things. Instead it focuses on
the more elusive topic of game design and how you can ensure that your title has
the best gameplay possible. Though solid programming and art are both central to a
game’s success, no amount of flashy graphics or cutting-edge coding will make up
for lackluster game design. In the end, it is the gameplay that will make or break a
project.
I have written this book in such a way as to encompass projects of different
scopes and sizes. It does not matter if the game you are working on is destined for
commercial release, if you hope to someday release it as shareware, or if you are
only making a game for you and your friends to play; this book should be helpful to
a game designer working in any of those circumstances. Furthermore, it does not
matter if you are working on the game with a large team, with only a few accompli-
ces, or going completely solo. In the book I often make reference to the “staff” of
your project. When I refer to “your programming staff” I may be referring to a team
of ten seasoned coders commanding massive salaries and pushing the boundaries of
real-time 3D technology, or I may be referring to just you, coding up every last
aspect of the game yourself. When I refer to “your playtesting staff” I may be refer

-
ring to an experienced and thoroughly professional testing staff of fifteen who will
pride themselves on giving your game a thorough going-over, or I may be referring
to your cousins Bob and Judith who, like you, enjoy games and would love to play
your game. Good games certainly do not always come from the biggest teams.
Even today, when multi-million dollar budgets are the norm, the best games still
often result from the vision and determination of a lone individual, and he need not
always surround himself with a massive team to see that vision through to
completion.
Many places in this book make reference to you leading the design on the pro
-
ject on which you are working. Of course, not every designer can be in the lead
position on every project, and even if you are the lead, you will often find yourself
without the absolute final say on what takes place in the game. In this regard, this
Introduction
xxi
book is written from a somewhat idealistic point of view. But regardless of how
much authority you actually have over the direction of the project, the important
point is to always know what you would do with the project if you could do what
-
ever you wanted. Then you should campaign for this direction with the other people
on the team. If you are persuasive enough and if you are, in fact, correct in your
instincts, you have a good chance of convincing them to do it your way. Projects
are often led not by the people with the most seniority or who have the right title on
their business card; projects are lead by the people who “show up” to the task, who
care about their projects and are committed to them, and who are willing to put in
the time and effort to make the game the best it can be.
Theory and Practice
Every medium has a unique voice with which it can speak, and it is the responsibil
-

ity of the user of a medium to find that voice. Computer games have a voice that I
firmly believe to be as strong as that available in any other media. Computer games
are a relatively young form when compared with the likes of the printed word,
music, the visual arts, or the theater, and I think this currently works against the
likelihood of computer games truly finding their most powerful voice. This book is
an attempt to help readers find that voice in their own projects. This can come in
both the more theoretical form of questioning why it is that players play games, but
also in the entirely more practical form of how to most effectively work with
playtesters. To have any chance of producing a great game, the game designer must
understand both the theoretical aspects and the practical necessities of game design.
Introduction
xxii
Chapter 1
What Players Want
“But when I come to think more on it, the biggest reason it has be
-
come that popular is Mr. Tajiri, the main developer and creator of
Pokemon, didn’t start this project with a business sense. In other words,
he was not intending to make something that would become very pop
-
ular. He just wanted to make something he wanted to play. There was
no business sense included, only his love involved in the creation.
Somehow, what he wanted to create for himself was appreciated by
others in this country and is shared by people in other countries.
. And that’s the point: not to make something sell, something very
popular, but to love something, and make something that we creators
can love. It’s the very core feeling we should have in making games.”
— Shigeru Miyamoto, talking about the creation of Pokemon
1
G

ame designers spend a lot of time concerning themselves with what game
players are looking for in a computer game. What can they put in their
computer games that has not been done before and will excite players?
Often game designers are so bereft of an idea of what gamers want that they instead
only include gameplay ideas that have been tried before, rehashing what was popu
-
lar with game players last year. Surely if players liked it last year, they will like it
this year. But therein lies the rub. Gamers generally do not want to buy a game that
is only a clone of another game, a “new” game that only offers old ideas and brings
nothing original to the table. Nonetheless, successful games can be useful, not for
cloning, but for analysis. As game designers, we can look at the games that have
come out previously, that we have enjoyed in years past, and try to determine a set
of directives that explain what compelled us to try those games in the first place,
and why they held our interest once we started playing them.
Why Do Players Play?
The first question we should consider is: why do players play games in the first
place? Why do they choose to turn on their computer and run Doom instead of visit-
ing the art museum or going to see a movie? What is unique about computer games
versus other human entertainment pursuits? What do games offer that other activi-
ties do not? It is by understanding what is attractive about games that other media
do not offer that we can try to emphasize the differences, to differentiate our art
form from others. To be successful, our games need to take these differences and
play them up, exploit them to make the best gameplay experience possible.
Players Want a Challenge
Many players enjoy playing games since they provide them with a challenge. This
provides one of the primary motivating factors for single-player home games, where
social or bragging rights motivations are less of an issue. Games can entertain play
-
ers over time, differently each time they play, while engaging their minds in an
entirely different way than a book, movie, or other form of art. In somewhat the

same way someone might fiddle with a Rubik’s Cube or a steel “remove the ring”
puzzle, games force players to think actively, to try out different solutions to prob
-
lems, to understand a given game mechanism.
When a person faces a challenge and then overcomes it, that person has learned
something. It does not matter if that challenge is in a math textbook or in a com
-
puter game. So, challenging games can be learning experiences. Players will learn
from games, even if that learning is limited to the context of the game, such as how
to get by level eight, and so forth. In the best games, players will learn lessons
through gameplay that can be applied to other aspects of their life, even if they do
2 Chapter 1: What Players Want

×