Game Design:

Theory & Practice

Second Edition

Richard Rouse III

Illustrations by
Steve Ogden

Foreword by
Noah Falstein

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.—2nd ed.
p. cm.
Includes bibliographical references and index.
ISBN 1-55622-912-7 (pbk.)
1. Computer games—Programming. I. Title.
QA76.76.C672R69 2004
794.8'1526—dc22 2004015102
CIP

© 2005, 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-912-7

10 9 8 7 6 5 4 3 2
0406

All brand names and product names mentioned in this book are trademarks or service marks of their respective
companies. Any omission or misuse (of any kind) of service marks or trademarks should not be regarded as intent
to infringe on the property of others. The publisher recognizes and respects all marks used by companies,
manufacturers, and developers as a means to distinguish their products.

This book is sold as is, without warranty of any kind, either express or implied, respecting the contents of this book
and any disks or programs that may accompany it, including but not limited to implied warranties for the book’s
quality, performance, merchantability, or fitness for any particular purpose. Neither Wordware Publishing, Inc. nor
its dealers or distributors shall be liable to the purchaser or any other person or entity with respect to any liability,
loss, or damage caused or alleged to have been caused directly or indirectly by this book.

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
Copyright Notices
Atomic Sam design document and images ™ and ©1999-2004 Richard Rouse III. Atomic Sam
character designed by Richard Rouse III and Steve Ogden. All rights reserved. Used with kind
permission.
The Suffering design document ©2004 Midway Home Entertainment. 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 Max Payne ® and © 2004 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, WarCraft III, StarCraft, and Diablo II ® or ™ and © 2004 Bliz-
zard Entertainment. 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, Myth: The
Fallen Lords, and Halo ® 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 Battlefield 1942 ™ and © 2004 Digital Illusions CE. All rights reserved. Used with
kind permission.
Images from Tomb Raider, Tomb Raider II, Thief, Thief II, Thief: Deadly Shadows, and Deus Ex
® or ™ and © 2004 Eidos Interactive. All rights reserved. Used with kind permission.
Images from Ultima Online © 2004 Electronic Arts Inc. Ultima and Ultima Online are trademarks
or registered trademarks of Electronic Arts Inc. in the U.S. and/or other countries. All rights
reserved. Used with kind permission.
Images from Unreal, Unreal Tournament, and Unreal Tournament 2004 ® 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.

iii
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.
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, The Sims,
and The Sims Online ® and © 2004 Maxis, Inc. All rights reserved. Used with kind permission.
Images from Karateka, Prince of Persia, and The Last Express ® or ™ and © 2004 Jordan
Mechner. All rights reserved. Used with kind permission.
Images from Prince of Persia: The Sands of Time ® and © 2004 Jordan Mechner/Ubisoft Enter-
tainment. 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 Smash TV®, Dr. Muto™, and The Suffering™ © 2004 Midway Amusement Games,
LLC. All rights reserved. Used with kind permission.
Images from Dark Age of Camelot™ and © 2004 Mythic Entertainment, Inc. All rights reserved.
Used with kind permission.
Images from Super Mario Bros., Super Mario 64, The Legend of Zelda: Ocarina of Time, Super
Mario Sunshine, Metroid Prime, and Mario Kart: Double Dash ® and © 2004 Nintendo of Amer-
ica. All rights reserved. Used with kind permission.
Images from Oddworld: Abe’s Oddysee® 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
In memory of Jamie.

v
Acknowledgments
Thanks to Steve Ogden for coming back to Atomic Sam and breathing life into the
little kid once again.
Thanks to Noah Falstein, James Hague, Damion Schubert, Ian Parberry, and Mar-
garet Rogers for looking over my work and providing me with invaluable feedback and
support, which have improved this book tremendously.
Thanks also to Tom Hall, Katherine Isbister, Darius Kazemi, and Michael Eilers for
their comments on this book and how it might be made better the second time around.
Thanks to Doug Church, Chris Crawford, Ed Logg, Jordan Mechner, Sid Meier,
Steve Meretzky, and Will Wright for graciously subjecting themselves to my nearly
endless questioning.
Thanks to Wes Beckwith, Beth Kohler, Martha McCuller, Alan McCuller, Denise
McEvoy, Tim McEvoy, and everyone at Wordware for making this book once again
become a reality.
For their help with this book, thanks to Jim Hill, Steve Crane, Ken Fedesna, George
Gomez, Rob Gustafson, Reilly Brennan, Robin Hunicke, Matt Bertz, Scott Miller, Jenny
Huldschiner, Tyrone Miller, Carol Quito, Rannie Yoo, Loretta Stevens, Jason Wonacott,
Doug Zartman, 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, 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.
Thanks to Jamil Moledina, Jennifer Olsen, Alex Dunne, & everyone at Game Devel-
oper/Gamasutra, Gordon Cameron, Tuncer Deniz, Bart Farkas, Andy Eddy, Brian
Moriarty, Scott McCloud, Ed Magnin, Bernd Kreimeier, Andrew Rollings, George
Broussard, Jason Della Rocca, Dave Astle, Tom Russo, Kevin Toyama, Greg Orlando,
George Jones, Owain Bennallack, Matthew Percival, Dishad Husain, Julie Perkins,
Angie Cox & everyone at Gamer.tv, Jon Goodwin, Christopher Erhardt, Jonathan Kay,
Neil Morton, Stephen Granade, Jeff Vogel, Laura Heon, Kaarin Lemstrom-Sheedy &
MassMOCA, Troy Dunniway, Clay Heaton, Rich Carlson, Iikka Keranen, Curt Feldman
& everyone at E3, Alan Patmore, Nick Radovich & everyone at Surreal, David Zucker
& everyone at Midway, Mark Bullock, the Leaping Lizard crew, Brian Rice, Lee
Waggoner, Pat Alphonso, Peter Tamte, Nate Birkholtz, Al Schilling, Cindy Swanson &
everyone at MacSoft, Alex Seropian, Jason Jones, Jim McNally, Jeff O’Connor, Ira
Harmon, Gordon Marsh, Glenn Fabry, Derek Riggs, and Chuck Schuldiner.
Special thanks to Richard & Regina Rouse, Dave Rouse, Linda Rouse, Grayson
Starner, Margaret Rogers & the Rogers clan, June Oshiro & Matt Bockol, Ben Young,
Alain, Annalisa, & Alexandria Roy, Katie & Eric Pidkameny, Gail Jabbour, Amy & Jason
Schigelone, Rafael & Belinda Brown, Eloise Pasachoff, Kristin Kane, and Christian &
Logan Bell.
vi
About the Author
Richard Rouse III is Design Director at Surreal Software, a Midway Home Entertain-
ment studio. Most recently, he was project lead, lead designer, and writer on the
action-horror title The Suffering. Rouse has been developing games professionally for
over a decade, during which he has worked on games for the PC, Macintosh, Sega
Dreamcast, Sony PlayStation, PlayStation 2, and Microsoft Xbox. In addition to The
Suffering, his credits include Drakan: The Ancients’ Gates, Centipede 3D, Damage Incor-
porated, and Odyssey: The Legend of Nemesis. Rouse has written about game design for
publications including Game Developer, SIGGRAPH Computer Graphics, Develop,
Gamasutra, MyVideoGames.com, and Inside Mac Games, and has spoken on game
development several times at the Electronic Entertainment Expo.

Your Feedback
Your feedback to this book, including corrections, comments, or merely
friendly ramblings, is encouraged. Please mail them to the author at
gdtp@paranoidproductions.com. 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/gamedesign. See you there.

About the Artist

Steve Ogden has been scribbling on paper forever and working in the game industry
almost that long. He met Richard Rouse III a lifetime ago while they were working
together on Hasbro’s Centipede 3D. Later, the two men cooked up Atomic Sam as a
character to illustrate a book on game design principles, the precursor to the tome you
now hold in your hands. Ogden drew the pictures for that book while at Cyan working
on realMYST and URU. He is now happy to be back in the green hills of home in Mary-
land’s hunt country, working at Firaxis. It was while finishing up work on Sid Meier’s
Pirates! and beginning work on Civilization IV that he was asked once again to scribble
some Atomic Sam illustrations for this new edition, including a shiny new full-color
cover! To say he jumped at the chance is to indulge in understatement. Ogden finds
Sam to be a fun subject and his universe intriguing, and wonders aloud if Atomic Sam
will one day become an actual game, not just a character in a book about games . . .

vii
Contents Summary
Chapter 1 What Players Want . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 2 Interview: Sid Meier. . . . . . . . . . . . . . . . . . . . . . 20
Chapter 3 Brainstorming a Game Idea: Gameplay, Technology,
and Story . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapter 4 Game Analysis: Centipede . . . . . . . . . . . . . . . . . . 57
Chapter 5 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Chapter 6 Interview: Ed Logg . . . . . . . . . . . . . . . . . . . . . . 87
Chapter 7 The Elements of Gameplay . . . . . . . . . . . . . . . . . 115
Chapter 8 Game Analysis: Tetris . . . . . . . . . . . . . . . . . . . . 141
Chapter 9 Artificial Intelligence . . . . . . . . . . . . . . . . . . . . . 151
Chapter 10 Interview: Steve Meretzky . . . . . . . . . . . . . . . . . 172
Chapter 11 Storytelling. . . . . . . . . . . . . . . . . . . . . . . . . 202
Chapter 12 Game Analysis: Loom . . . . . . . . . . . . . . . . . . . 227
Chapter 13 Multi-Player . . . . . . . . . . . . . . . . . . . . . . . . 237
Chapter 14 Interview: Chris Crawford . . . . . . . . . . . . . . . . . 257
Chapter 15 Getting the Gameplay Working . . . . . . . . . . . . . . 281
Chapter 16 Game Analysis: Myth: The Fallen Lords . . . . . . . . . . . 296
Chapter 17 Game Development Documentation . . . . . . . . . . . . 306
Chapter 18 Interview: Jordan Mechner . . . . . . . . . . . . . . . . . 320
Chapter 19 The Design Document . . . . . . . . . . . . . . . . . . . 355
Chapter 20 Game Analysis: The Sims . . . . . . . . . . . . . . . . . . 382
Chapter 21 Designing Design Tools. . . . . . . . . . . . . . . . . . . 392
Chapter 22 Interview: Will Wright . . . . . . . . . . . . . . . . . . . 408
Chapter 23 Level Design . . . . . . . . . . . . . . . . . . . . . . . . 449
Chapter 24 Game Analysis: Grand Theft Auto III . . . . . . . . . . . . 475
Chapter 25 Playtesting . . . . . . . . . . . . . . . . . . . . . . . . . 483
Chapter 26 Interview: Doug Church . . . . . . . . . . . . . . . . . . 500
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Appendix A Sample Design Document: Atomic Sam. . . . . . . . . . . 535
Appendix B Sample Design Document: The Suffering . . . . . . . . . . 579
Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Selected Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

viii
Contents
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Introduction to the Second Edition . . . . . . . . . . . . . . . . . . . . . xvii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

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 Solitary Experience . . . . . . . . . . . . . . . 5
Players Want Bragging Rights . . . . . . . . . . . . . . . . . . . . . . . 5
Players Want an Emotional Experience . . . . . . . . . . . . . . . . . . 6
Players Want to Explore . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Players Want to Fantasize . . . . . . . . . . . . . . . . . . . . . . . . . 7
Players Want to Interact . . . . . . . . . . . . . . . . . . . . . . . . . . 8
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. . . . . . . . . . . 11
Players Expect to Be Immersed . . . . . . . . . . . . . . . . . . . . . 12
Players Expect Some Setbacks . . . . . . . . . . . . . . . . . . . . . . 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 When
It Is Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A Never-Ending List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 2 Interview: Sid Meier. . . . . . . . . . . . . . . . . . . . 20

Chapter 3 Brainstorming a Game Idea: Gameplay, Technology,

and Story. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Starting Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Starting with Gameplay . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Starting with Technology . . . . . . . . . . . . . . . . . . . . . . . . . 43
Starting with Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Working with Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Odyssey: The Legend of Nemesis . . . . . . . . . . . . . . . . . . . . 48
Damage Incorporated . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ix
Contents

Centipede 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
The Suffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Embrace Your Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Established Technology . . . . . . . . . . . . . . . . . . . . . . . . . . 53
The Case of the Many Mushrooms . . . . . . . . . . . . . . . . . . . . 54
The Time Allotted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
If You Choose Not to Decide, You Still Have Made a Choice . . . . . . . . 56

Chapter 4 Game Analysis: Centipede . . . . . . . . . . . . . . . . 57

Classic Arcade Game Traits . . . . . . . . . . . . . . . . . . . . . . . . . 59
Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Interconnectedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Escalating Tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
One Person, One Game. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Chapter 5 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Establishing Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
An Example: Winter Carnival Whirlwind . . . . . . . . . . . . . . . . . 72
The Function of the Focus. . . . . . . . . . . . . . . . . . . . . . . . . 74
Maintaining Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Fleshing Out the Focus . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Changing Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Sub-Focuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Using Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Chapter 6 Interview: Ed Logg . . . . . . . . . . . . . . . . . . . . 87

Chapter 7 The Elements of Gameplay . . . . . . . . . . . . . . . 115

Unique Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Anticipatory versus Complex Systems . . . . . . . . . . . . . . . . . 116
Emergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Non-Linearity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Types of Non-Linearity. . . . . . . . . . . . . . . . . . . . . . . . . . 119
Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
The Purpose of Non-Linearity . . . . . . . . . . . . . . . . . . . . . . 123
Modeling Reality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Teaching the Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Input/Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Controls and Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Output and Game-World Feedback . . . . . . . . . . . . . . . . . . . 136
Basic Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Chapter 8 Game Analysis: Tetris . . . . . . . . . . . . . . . . . . 141

Puzzle Game or Action Game? . . . . . . . . . . . . . . . . . . . . . . . 142
Tetris as a Classic Arcade Game . . . . . . . . . . . . . . . . . . . . . . 144
The Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

x
 Contents

Artificial Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Escalating Tension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Simplicity and Symmetry . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Fifteen Years On, Who Would Publish Tetris? . . . . . . . . . . . . . . . 150

Chapter 9 Artificial Intelligence. . . . . . . . . . . . . . . . . . . 151

Goals of Game AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Challenge the Player . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Not Do Dumb Things . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Be Unpredictable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Assist Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Create a Living World . . . . . . . . . . . . . . . . . . . . . . . . . . 162
The Sloped Playing Field . . . . . . . . . . . . . . . . . . . . . . . . . . 162
How Real Is Too Real? . . . . . . . . . . . . . . . . . . . . . . . . . . 163
AI Agents and Their Environment . . . . . . . . . . . . . . . . . . . . . 164
How Good Is Good Enough? . . . . . . . . . . . . . . . . . . . . . . . . 167
Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Artificial Stupidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Chapter 10 Interview: Steve Meretzky . . . . . . . . . . . . . . . 172

Chapter 11 Storytelling . . . . . . . . . . . . . . . . . . . . . . . 202

Designer’s Story Versus Player’s Story . . . . . . . . . . . . . . . . . . 203
Places for Storytelling. . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Out-of-Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
In-Game. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
External Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Linear Writing Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Player Character Personality . . . . . . . . . . . . . . . . . . . . . . 218
Game Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Non-Linearity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Working with the Gameplay . . . . . . . . . . . . . . . . . . . . . . . 224
The Dream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Chapter 12 Game Analysis: Loom. . . . . . . . . . . . . . . . . . 227

Focused Game Mechanics. . . . . . . . . . . . . . . . . . . . . . . . . . 228
User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
The Drafts System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Difficulty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Loom as an Adventure Game . . . . . . . . . . . . . . . . . . . . . . . . 235

Chapter 13 Multi-Player. . . . . . . . . . . . . . . . . . . . . . . 237

Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
The Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Single System Multi-Player . . . . . . . . . . . . . . . . . . . . . . . 239
Online Multi-Player . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

xi
Contents

Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Playing to Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Protect Newbies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Socialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Development Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Playtesting and User Feedback . . . . . . . . . . . . . . . . . . . . . 253
A World of Their Own . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Chapter 14 Interview: Chris Crawford . . . . . . . . . . . . . . . 257

Chapter 15 Getting the Gameplay Working . . . . . . . . . . . . 281

The Organic Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Too Much Too Soon . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Keep It Simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Building the Game. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Core Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Incremental Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
A Fully Functional Area . . . . . . . . . . . . . . . . . . . . . . . . . 288
Going Through Changes . . . . . . . . . . . . . . . . . . . . . . . . . 290
Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
When Is It Fun? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Chapter 16 Game Analysis: Myth: The Fallen Lords . . . . . . . . 296

Use of Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Game Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Hard-Core Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Multi-Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
A Cohesive Whole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Chapter 17 Game Development Documentation . . . . . . . . . . 306

Document Your Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Concept Document, Pitch Document, or Proposal . . . . . . . . . . . 308
Competitive Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Flowcharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Story Bible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Art Bible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
The Game Minute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Storyboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Technical Design Document . . . . . . . . . . . . . . . . . . . . . . . 317
Schedules and Business/Marketing Documents . . . . . . . . . . . . 318
No Standard Documentation . . . . . . . . . . . . . . . . . . . . . . . 319
The Benefits of Documentation. . . . . . . . . . . . . . . . . . . . . . . 319

xii
 Contents

Chapter 18 Interview: Jordan Mechner . . . . . . . . . . . . . . . 320

Chapter 19 The Design Document . . . . . . . . . . . . . . . . . 355

The Writing Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
The Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Table of Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Introduction/Overview or Executive Summary. . . . . . . . . . . . . 360
Game Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Artificial Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Game Elements: Characters, Items, and Objects/Mechanisms . . . . 369
Story Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Game Progression . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
System Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
One Man’s Opinion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Inauspicious Design Documents . . . . . . . . . . . . . . . . . . . . . . 374
The Wafer-Thin or Ellipsis Special Document . . . . . . . . . . . . . 374
The Back-Story Tome . . . . . . . . . . . . . . . . . . . . . . . . . . 375
The Overkill Document . . . . . . . . . . . . . . . . . . . . . . . . . 376
The Pie-in-the-Sky Document. . . . . . . . . . . . . . . . . . . . . . 377
The Fossilized Document . . . . . . . . . . . . . . . . . . . . . . . . 378
A Matter of Weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Getting It Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Documentation Is Only the Beginning . . . . . . . . . . . . . . . . . . . 380

Chapter 20 Game Analysis: The Sims . . . . . . . . . . . . . . . . 382

Abdicating Authorship. . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Familiar Subject Matter . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Safe Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Depth and Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Controlled Versus Autonomous Behavior . . . . . . . . . . . . . . . . . 389
A Lesson to Be Learned . . . . . . . . . . . . . . . . . . . . . . . . . . 390

Chapter 21 Designing Design Tools. . . . . . . . . . . . . . . . . 392

Desired Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Visualizing the Level . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
The Big Picture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Jumping into the Game. . . . . . . . . . . . . . . . . . . . . . . . . . 397
Editing the World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Scripting Languages and Object Behaviors . . . . . . . . . . . . . . . . 400
Us Versus Them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
The Best of Intentions . . . . . . . . . . . . . . . . . . . . . . . . . . 405
A Game Editor for All Seasons . . . . . . . . . . . . . . . . . . . . . . . 406

xiii
Contents

Chapter 22 Interview: Will Wright . . . . . . . . . . . . . . . . . 408

Chapter 23 Level Design . . . . . . . . . . . . . . . . . . . . . . 449

Levels in Different Games . . . . . . . . . . . . . . . . . . . . . . . . . 450
Level Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Level Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
The Components of a Level. . . . . . . . . . . . . . . . . . . . . . . . . 454
Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Exploration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Puzzle Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Aesthetics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Balancing It All . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Level Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Elements of Good Levels . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Players Cannot Get Stuck . . . . . . . . . . . . . . . . . . . . . . . . 463
Sub-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Landmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Critical Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Limited Backtracking . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Success the First Time. . . . . . . . . . . . . . . . . . . . . . . . . . 465
Navigable Areas Clearly Marked . . . . . . . . . . . . . . . . . . . . 466
Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
A Personal List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
The Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Step 1. Preliminary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Step 2. Conceptual and Sketched Outline . . . . . . . . . . . . . . . . 468
Step 3. Base Architecture/Block Out . . . . . . . . . . . . . . . . . . 469
Step 4. Refine Architecture Until It Is Fun . . . . . . . . . . . . . . . 469
Step 5. Base Gameplay. . . . . . . . . . . . . . . . . . . . . . . . . . 470
Step 6. Refine Gameplay Until It Is Fun. . . . . . . . . . . . . . . . . 471
Step 7. Refine Aesthetics . . . . . . . . . . . . . . . . . . . . . . . . 471
Step 8. Playtesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Process Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Who Does Level Design? . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Collaboration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

Chapter 24 Game Analysis: Grand Theft Auto III . . . . . . . . . . 475

Believable Game-World . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
A Living City. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Actions and Consequences . . . . . . . . . . . . . . . . . . . . . . . . . 480
Storytelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481

Chapter 25 Playtesting . . . . . . . . . . . . . . . . . . . . . . . 483

Finding the Right Testers . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Who Should Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

xiv
 Contents

Who Should Not Test. . . . . . . . . . . . . . . . . . . . . . . . . . . 487

When to Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
How to Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Guided and Unguided Testing. . . . . . . . . . . . . . . . . . . . . . . . 492
Balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Your Game Is Too Hard . . . . . . . . . . . . . . . . . . . . . . . . . 495
The Artistic Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

Chapter 26 Interview: Doug Church . . . . . . . . . . . . . . . . 500

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
The Medium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
The Motive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

Appendix A Sample Design Document: Atomic Sam . . . . . . . . 535

I. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
II. Game Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
III. Artificial Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . 555
IV. Game Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
V. Story Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
VI. Game Progression . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
VII. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578

Appendix B Sample Design Document: The Suffering. . . . . . . . 579

Section I: Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Section II: Game Mechanics . . . . . . . . . . . . . . . . . . . . . . . . 588
Controls Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Section III: Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Section IV: NPCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Section V: Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Section VI: Gameflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Section VIII: Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

Selected Bibliography . . . . . . . . . . . . . . . . . . . . 672

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

xv
Foreword
Just a few years ago, books about computer game design were as rare on the book-
shelves as silk ties in the wardrobe of a game programmer. Then, around the turn of the
millennium, a trickle of new books began to appear. One of the early ones that caught
my eye was the first edition of this book, Game Design: Theory & Practice by Richard
Rouse III. I noted that Richard has design credits on published games and the hard-won
insights that conveys, as well as the descriptive skills to articulate those insights. I also
appreciated the literal truth of the title of the book; it covers both the underlying theo-
ries behind game design while providing practical guidance on how to put those
theories to use. But my favorite chapters of the book were the interviews. Richard per-
suaded an impressive array of talented and influential game designers to answer his
thorough and insightful questions. So when Richard asked me to review and comment
on this latest revision of his book and write an introduction, I jumped at the chance.
Game design is still a young craft, but a rapidly maturing one. No longer in its
infancy certainly, computer and video games have been around for over 30 years, and
despite a generous helping of Peter Pan Syndrome they’ve achieved a virtual adoles-
cence at least. This means that game designers have graduated from the trial-and-error
stages of the early years and learned what works and what doesn’t. In turn that has
resulted in a growing shared knowledge base of universal principles of game design. My
own quarter-century of experience in game development and research into the under-
lying rules of good game design have indicated that it is possible to both identify and
teach the rules that have influenced every successful game for decades, and this book is
a worthy contributor to that body of knowledge.
But the video games of the Pong era bear a pretty tenuous resemblance to the
multi-million dollar extravaganzas of the current day, and many of the skills necessary
to design a game have likewise changed and matured. Furthermore, games present a
widely varied face to the world. Superficially, games like Centipede or Tetris are vastly
different from The Sims or Civilization. So it is impressive that this book manages to
identify many qualities that are common to all good games and the skills needed to cre-
ate design documents for them, while doing a credible job of covering elements specific
to certain types of games as well, such as storytelling, scripting, AI, and multiplayer
design. The game analysis chapters dissect and appraise the internal qualities of games
and so grant insight into both the games highlighted as well as the process of analysis
itself. And the interviews delve into both the shared knowledge of renowned designers
and their individual quirks and unique histories.
In short, I’ve found this book to be remarkable at revealing the range of the cre-
ative game design process, as well as just plain fun to read. And I hope you will as well!

Noah Falstein
Greenbrae, CA

xvi
Introduction to the Second
Edition
It has been four years since the release of the first edition of the book you now hold in
your hands. It is interesting to reflect on what has changed in the industry during the
intervening time, or, more specifically, what has not changed. In many ways we have
seen a continuation of the trends that were well underway when this book was first
written. Games continue to get bigger and prettier but not necessarily any more fun.
Licenses have become more prevalent than ever, whether in the form of a movie tie-in
or just having a quasi-famous personality attached to a project. The line between a com-
puter game and a console game has become more and more blurred, with the largest
games typically coming out on both, some under the same name but in different forms,
but most providing almost exactly the same experience. In general, boldly original
titles have become fewer and farther between.
A lot has happened to me since the first edition, and where appropriate I have
woven that experience into this revision. The game that I was working on during the
writing of the first edition, a western called Gunslinger, died out from under me.
Though it had a number of problems, in the end it fell prey to the industry’s more and
more risk-averse nature. Following that, I managed to do quite a bit of work on Drakan:
The Ancients’ Gates and then developed The Suffering from conception through to local-
ization. New examples from the practice of game development on The Suffering are
integrated throughout this edition’s chapters. Also, in addition to the Atomic Sam docu-
ment that appeared in the original book, the complete design document for The
Suffering has been included as an appendix. I sincerely hope this design document will
be of particular interest to readers since it was used for a title that actually shipped.
Since the first book came out, two games have achieved greater popular success
than anyone could have predicted. Those games are The Sims (which was analyzed in
the first edition) and Grand Theft Auto III (which is analyzed in this new edition). In the
intervening time, all of the game designers who were interviewed in the original edi-
tion completed new works in the industry, with five out of the six shipping new games,
while Chris Crawford released two books. For this edition, I was fortunate enough to
talk once again with most of these designers to update their interviews to reflect their
most recent accomplishments (with the notable exception of Sid Meier, who as of this
writing is busily trying to ship the new version of Pirates!). Also, the second edition
gave me the opportunity to do an in-depth interview with a game designer I quoted
extensively in the first book, Doug Church. Church is one of the most forward-looking
designers working today, and I hope reading his thoughts prove inspirational for any
designer.
As well as adding more examples from the games of the last four years, for the sec-
ond edition I wanted to improve on what the book did well the first time, while filling in

xvii
Introduction to the Second Edition

a few of the gaps. Multi-player games have become significantly more prevalent since
the first edition and were woefully underrepresented in the book before; now
multi-player gaming is the subject of an entire chapter. Though the storytelling and
artificial intelligence chapters are among the most expanded in the book, all of the chap-
ters have been revised and updated significantly. Even the bibliography and glossary
have been reworked and expanded.
When working on the second edition of Game Design: Theory & Practice, I revisited
a lot of the feedback I received from the first edition, and did my best to address some of
the concerns that were brought up. Nevertheless, I can say the views contained herein
are still distinctly my own and represent my personal views on game development.
Often my thoughts fall in line with the commonly held wisdom in the industry, but other
times you will find I disagree with what everyone else seems to be doing. Who is right?
No one is right, per se. In the creation of art there are no easy absolutes. As a game
designer you need to balance going with the prevailing wisdom with what you feel in
your heart. If you always make decisions based on popular opinion or on the flavor of the
moment, you will always make average, predictable games. As a game designer, you
should take what I say in this book, reflect on it, and decide where you stand and how
you want to proceed on your own projects. It is my sincere hope that your views of
game design end up substantially different from mine, so that when you make a game
and I make a game we do not end up with exactly the same player experience. Variety,
after all, is not only the spice of life, it is life.
One of the most frequent comments I heard about the first edition of the book was
that it seemed dated. I would argue that it was not dated, merely that it attempted to
look at game development over the entire history of the medium, not just the three
years preceding the book’s publication. The book contained examples and discussion of
current games proportionate to classic games. Indeed, if I had focused more on what
was current in the industry when I wrote it, the book might have seemed relevant on its
release, but within a few years truly would have been horribly dated. If one looks at the
first edition today, four years after it came out, one will find it is nearly just as relevant
today as it was then. Thus, in making a new edition, I strove less to bring the book “up
to date” and more to expand on what it was already doing. Yes, I’ve included references
to newer games, since many great new games have come out since the book was first
published, but I’ve kept just as many discussions of the classics from the last three
decades. Anyone who has worked with me knows that, when in the heat of game devel-
opment, I am as likely to pull inspiration from a game made in 1983 as a game made in
2003. I would argue that to be a great game designer, you need to understand the past
just as well as the present. As a game designer, if you cannot see the value and lessons
to be learned from a classic game made in 1983, then you have a long way to go before
you truly understand our medium.
In truth, I have always seen this book as something of a history lesson for game
developers and enthusiasts alike. In addition to the game analysis chapters, this espe-
cially comes through in the interviews, which I hope readers enjoy as much for what
they tell us about game history as they do for their specific insights into game develop-
ment. If a reader sees a reference in this book to a game that they are unfamiliar with, it
is my hope that they might seek out that title in order to play it. Almost all the games I
xviii
 Introduction to the Second Edition

refer to in this book are titles that I consider to be worth anyone’s time to play. That
said, a big problem for game historians and developers alike is that actually playing a
game from twenty or even ten years ago can be quite difficult. If you are an aspiring
filmmaker, tracking down almost all the cinema classics stretching back a hundred
years is fairly easy. Not so with computer and video games. Emulators have done a lot
to help this, but many games that are quite well known and respected are all but unplay-
able for most people because the systems they worked on no longer run, because the
games themselves are out of print, or both. I believe that our ability to grow as an indus-
try is directly proportional to our ability to understand our past: if we cannot understand
it because we cannot play it, our evolution may well be stunted.
Throughout this book I discuss what I believe a game designer should think about
when developing a game. I have found that one way to improve your game design meth-
odology is to write a book about it. Though I might not recommend this technique to
everyone (after all, the bookstores can only bear so many different volumes on the sub-
ject), I can testify that it can be quite helpful to take your nose off the grindstone every
once in a while and think about games and their development a step or two removed
from the day-to-day process of making it happen. I should warn that one unfortunate
side effect to writing a book is having your coworkers point out to you whenever you
are failing to follow one of the techniques you advocated in print. And therein lies the
fundamental problem: regardless of how much you think about game design or try to do
everything the best way possible, at the end of the day modern computer games are
still incredibly hard to create. I certainly don’t pretend to have all the answers, but my
hope is that this book will make things a little bit easier, not just for me, but for you as
well.

Richard Rouse III

Seattle, Washington

xix
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 perhaps
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 written this book for myself, for the per-
son I was a decade ago. I hope that other people interested in designing games will find
this book informative. In my humble opinion, 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 that differentiates our
artistic medium from all others.

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 that 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 players are able to interact with the game-world and how that
game-world reacts to the choices players make. 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, gather-
ing 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
xx
 Introduction

equipped foe. And in Civilization, the gameplay is exploring the world, building a soci-
ety 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 aesthetic
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 play-
ers 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.

Who Is a Game Designer?

By this point it should be obvious what a game designer does: he 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 meanings have become diluted 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, whether artist, programmer, or producer, 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 establishes 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

xxi
Introduction

gameplay. Indeed, many game designers perform a wide variety of tasks on a project,
but their central concern 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 particular
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 dis-
cuss 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 thirteen
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. 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 discussions of the reality of
game development, using examples from my own experience, to delve into the actual
practice of game design.
There are six analysis chapters included in this book, covering six excellent games
in six different genres. One of the most important skills a game designer must have is
the ability to analyze games that he 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 his own projects. That is not to suggest that good game design-
ers 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 he finds most com-
pelling and try to examine what makes them tick. The examples I include in this book,
Centipede, Tetris, Loom, Myth: The Fallen Lords, The Sims, and Grand Theft Auto III, are
all very unique games. And though a given project you are working on may not be simi-
lar 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 designers. Grand Theft Auto III improved over its pre-
decessors by cribbing from racing games. 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 seven 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 development, I
xxii
 Introduction

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 complete list-
ing 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 he uses to refer to various aspects of his 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 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 questions 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 pro-
cess 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 pos-
sible. 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 accomplices, or going com-
pletely 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 referring 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 what you have made. Good games certainly do not
always come from the biggest teams. Even today, when multimillion-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.
xxiii
Introduction

Many places in this book make reference to you leading the design on the project
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 abso-
lute final say on what takes place in the game. In this regard, this 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 whatever you wanted. Then you should cam-
paign 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 led 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 responsibility 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 rela-
tively 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.

xxiv
Chapter 1
What Players Want

“But when I come to think more on it, the biggest reason it has become 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 popular. 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

I t may seem too simple a question to even ask, but determining what players want
out of a game is a question all game designers must contemplate if they want to
make great games. Further complicating matters, understanding what is enjoyable
about a game experience is not knowledge that can be taught; on some level it must be
an innate sense that a designer possesses. Designers must have the ability to assess
whether something is fun for themselves, combined with the ability to listen to the
opinions of others. Frank Capra, one of the most popular film directors from the golden
age of Hollywood, often said that he was simply making films that appealed to his own
tastes, and that it was luck they were enjoyed by so many other people. Similarly, one
cannot simply look at the problem of “what players want” purely from a market-driven
1
2 Chapter 1: What Players Want

standpoint and declare, “I don’t understand it, but if they want it, I’m going to give it to
them.” In order to make a great game, you must first find it fun yourself, and hopefully
this can be used to build something that appeals to others as well. But in the end, the
spark must come from within.
Game designers spend a lot of time concerning themselves with what game play-
ers are looking for in a computer game. What can they put in their computer game that
has not been done before and will excite players? Often game designers are so bereft of
an idea of what will be fun and what gamers want that they instead only include
gameplay ideas that have been tried before, rehashing what was popular 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 com-
pelled 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? Why do they
choose to turn on their computer or console and run Halo instead of visiting the art
museum or going to see a movie? What is unique about computer games versus other
human entertainment media? What do games offer that other activities 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 that separate our art form from others. To be success-
ful, our games need to take these differences and play them up, exploiting them to make
the best gameplay experience possible.

Players Want a Challenge

Many players enjoy playing games because they provide a challenge. This provides one
of the primary motivating factors for single-player home games, where social or brag-
ging rights motivations are less of an issue. Games can entertain players 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 fid-
dle with a Rubik’s Cube or a steel “remove the ring” puzzle, games force players to
think actively, to try out different solutions to problems, 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 computer
game. 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 navigate
through the forest, survive a particularly hairy battle, or convince the duke that their
intentions with his daughter are honorable. In the best games, players will learn les-
sons through gameplay that can be applied to other aspects of their life, even if they do
not realize it. This may mean that they can apply problem solving methods to their
 Chapter 1: What Players Want 3

work, use their improved spatial skills to better arrange their furniture, or perhaps
even learn greater empathy through role-playing. Many players thrive on and long for
the challenges games provide, and are enriched by the learning that follows.

Players Want to Socialize

I have a friend who maintains that games are antisocial. This is, of course, absurd, as
nearly all non-computer games require a social group in order to function. Games arose
as a communal activity many millennia ago out of a desire to have a challenging activity
in which a group of friends and family could engage. Computer game designers need to
remember that the origin of games is tied to a social experience, and that this commu-
nal component is central to their appeal.
For most people, the primary reason they play games is to have a social experience
with their friends or family. I am not talking about computer games here, but rather
board and card games like chess, Monopoly, bridge, Scrabble, Diplomacy, or The Settlers
of Catan. People like to play these games because they enjoy spending time with their
friends and want to engage in a shared activity that is more social than going to a movie
or watching TV. It is true that lots of people enjoy playing solitaire card games as well,
but there are many more multi-player games than there are single-player. This is
because people enjoy a social gameplaying experience.
But how does this apply to computer games? If one considers all the computer
games ever created, the majority of them are single-player only experiences. But of
course there are plenty of multi-player games, ranging from the “death-matches” found
in Doom and its legion of imitators, to the classic M.U.L.E. game of wheeling and deal-
ing, to the persistent worlds founds in MUDs (Multi User Dungeons) or their
commercial equivalent, massively multi-player games such as Ultima Online and
EverQuest. It is telling about the popularity of multi-player games that from the very
inception of gaming there were multi-player games, ranging from Pong to some of the
very first games developed on university mainframes that eventually evolved into
MUDs.
Many death-match style multi-player games are basically adaptations of sin-
gle-player games into multi-player incarnations, such as Doom, Half-Life, and Halo.
These games typically provide a single-player game in addition to a multi-player game,
both played with nearly the same set of rules and game mechanics. But even in these
single-player-turned-multi-player games, players like to socialize while playing. Any-
one who has ever played one of these games over a LAN in a room with a bunch of their
friends can testify to this. These LAN-fests are usually rich with conversation as play-
ers shout back and forth to each other, bragging over their most recent “frag” or
proclaiming how close they came to being killed. Games such as Unreal Tournament
can also be played over the Internet, where the experience is quite a bit less social,
since players may be miles apart and are thus only able to communicate through the
computer. Indeed, lots of death-match or Counter-Strike enthusiasts have been known
to use their office telephone systems to allow players who are not in the same building
or even the same state to talk freely to each other while playing. Those not so well
equipped still try to communicate by typing messages into the computer. Unfortu-
nately, the high-intensity, fast-action nature of these games doesn’t leave players much
time to type messages to their opponents, if they hope to survive for long. But these
4 Chapter 1: What Players Want

Death-match style
multi-player games
are adaptations of
single-player shooter
experiences. Halo
comes with both
single-player and
multi-player modes.

games do still provide chat functionality, and players, when they are in a safe corner,
after they have died, or between games, can send conversational messages to each
other. At more hectic points in the gameplay the messages are short and typed on the
fly, consisting of only a couple of letters. The fact that players still try to chat with each
other in these high-velocity games is testament to the players’ desire to socialize.
A separate category of multi-player games is what has come to be called “persis-
tent universe” or “massively multi-player” games. These games tend to be more in the
style of role-playing games, where players wander around “virtual worlds” and meet
and interact with the other characters in these worlds, characters that are controlled by
other players. These games tend to be played over large networks such as the Internet,
instead of over LANs, and as a result players only socialize with each other through
what they type into the computer. Since these games are considerably slower paced
than death-match games, there is a much greater opportunity for players to chat with
each other while playing. MUDs were the first popular incarnation of this style of game,
and were played primarily by college students from the late 1980s on. At the time, these
students were the main group of people with ample free time who had access to the
Internet. These games are text-only, and provide their players with quests to accom-
plish in mostly fantasy settings. The quests, however, take a backseat to the
socialization and role-playing, with players spending the vast majority of their time
chatting with other players. A lot of people are drawn into playing these games as a way
to interact with their friends, despite the fact that these friends are people they met
online and who they have never seen in person. Indeed, the persistent worlds, MUDs
in particular, draw in a legion of players who are not interested in playing any sin-
gle-player computer games. These people play games in order to meet and talk to other
people. The games are merely a compelling activity these people can engage in
together while socializing.
 Chapter 1: What Players Want 5

As multi-player games have become more and more common, many game develop-
ers have been quick to point out their advantages in terms of competitive AI. Human
opponents are much more unpredictable and challenging than any AI that could be rea-
sonably created for most games. This, they suggested, is why people are drawn to
multi-player games. Though this may be true, the biggest advantage of these multi-
player games is that they transform computer games into truly social experiences,
which is one of the largest motivating factors for people to play games.

Players Want a Dynamic Solitary Experience

Perhaps I have confused the reader by saying first that players want to socialize and
then suggesting that players want a solitary experience. Of course the two do not hap-
pen at the same time; some game players are looking for a social experience, while
others are looking for something dynamic that they can engage in by themselves.
Sometimes friends are not available to play, or players are tired of their friends, or sim-
ply are tired of having to talk to other people all the time. Similar to the difference
between going to a movie theater with an audience versus renting a video alone at
home, the antisocial nature of single-player games attracts a lot of people who have had
enough of the other members of the human race.
But games are distinct from other solitary experiences such as reading a book or
watching a video since they provide the players with something to interact with, an
experience that reacts to them as a human would, or at least in a manner resembling a
human’s reactions. The players are always in control, and can start and stop playing at
any time. Thus the computer game “fakes” the interesting part of human interaction
without all of the potential annoyances. In this way, people are able to turn to computer
games for a dynamic and interactive yet unsocial experience.

Players Want Bragging Rights

Particularly in multi-player gaming, players play games to win respect. Being able to
frag all of your friends in Unreal Tournament will force them to have a grudging respect
for you: “Bob isn’t very good in algebra class, but he sure can annihilate me in a death-
match.” Even in single-player games, players will talk with their friends about how
they finished one game or about how good they are at another. Players will brag about
how they played the whole game through on the hardest difficulty in only a few hours. If
one looks at arcade games both old and new, the high-score table and the ability to enter
one’s name into the game, even if only three letters, provides a tremendous incentive
for people to play a game repeatedly. Players who may not have much to brag about in
their ordinary lives, who may not be terribly physically coordinated at sports or bookish
enough to do well in school, can go down to the arcade and point out to all their friends
their initials in the Centipede game. Gaming forums are full of people bragging about
how they beat hot new game X in only five hours, and then taking pride in doling out
advice to those who have not made it as far. Even without telling anyone, players can
feel a tremendous sense of self-satisfaction when they beat a particular game. When
players are victorious at a challenging game, they realize they can do something well,
probably better than most people, which makes them feel better about themselves.
6 Chapter 1: What Players Want

Players Want an Emotional Experience

As with other forms of entertainment, players may be seeking some form of emotional
payoff when they play a computer game. This can be as simple as the adrenaline rush
and tension of a fast-action game like Doom. It can be the great satisfaction of having
built up a massive metropolis in SimCity. Or it can be considerably more complex, such
as players’ feeling of loss when their friendly robot companion sacrifices himself for
them in Steve Meretzky’s Planetfall. The emotions that games are able to evoke in
players are much stronger than what can be experienced in other media where the
experience is less immersive and considerably less personally involving. Unfortu-
nately, many games’ emotional ranges are limited to excitement/tension during a
conflict, despair at repeated failure at a given task, and then elation and a sense of
accomplishment when the players finally succeed. It may seem strange that players
would play a game in order to feel despair, but many people enjoy watching plays that
are tragedies or movies that have sad endings, or listening to music that is out-and-out
depressing. People want to feel something when they interact with art, and it does not
necessarily need to be a positive, happy feeling. Perhaps the sense of catharsis people
obtain from these works makes them worth experiencing. Many classic arcade games,
such as Centipede or Space Invaders, are unwinnable. No matter what players do, even-
tually the game will beat them. These games are, in a sense, lessons in defeat —
tragedies every time players play them. Yet the players keep pumping in their quarters.
This is why players’ feelings of hopelessness as a game repeatedly bests them are not
to be ignored. The players are feeling something, and at the highest level that is the goal
of all art.
Emotional range is not something computer games have explored as much as they
could. The example from Planetfall I cited above is one of the very few examples in
computer games of players becoming attached to a character in a game, only to have
him killed later on. Many developers are wary of making a game too sad. But in the case
of Planetfall, the tragic story twist of that game was exploited for all the pathos it was
worth by designer Steve Meretzky. It is a moment of tragedy that has stuck in many
gamers’ memories. Game designers would be wise to concentrate on expanding the
emotional experience in games beyond excitement and accomplishment, into more
unexplored and uncharted emotional territory.

Players Want to Explore

One of the main motivating forces that propels players through many level-based
games is the desire to explore new spaces and see new environments. Anyone who has
played a progression-based game like Super Mario 64 or Morrowind knows the feeling
of getting to a new and different level and wanting to just look around for a few moments
before taking on the objectives at hand. And game exploration is not limited to spatial
exploration. There is the exploration of different strategic choices in a game like Civili-
zation, different types of resources to manipulate and combine in a game like Magic: The
Gathering, and the exploration of the personalities of the characters you meet in RPGs
such as Wasteland or Fallout. Though exploration is not completely integral to a pure
gaming experience, the investigation of a fantastic world on one’s own terms can be a
rich experience that games excel at in a way no other media can.
 Chapter 1: What Players Want 7

Players Want to Fantasize

A major component of the popularity of storytelling art forms is the element of fantasy.
Whether one considers novels, films, or comic books, many people experience these
works to “get away” from their own “mundane” lives and escape to an altogether differ-
ent world, one filled with characters that engage in exciting, interesting activities,
travel to exotic locales, and meet other fascinating people. Certainly not all storytelling
works portray exciting and glamorous protagonists, but there is certainly a large seg-
ment of works that is labeled “escapist.” Some critics deride such escapist pieces of art,
and indeed a lot of very good books, movies, and comics deal with more realistic set-
tings and topics to great effect. The fact remains, however, that many people want to be
transported to a world more glamorous than their own.
Computer games, then, have the potential to be an even more immersive form of
escapism. In games, players get the chance to actually be someone more exciting, to
control a pulp-fiction adventurer, daring swordsman, or space-opera hero. While in
books or films the audience can merely watch as the characters lead exciting lives, in a
well-designed computer game players will actually get the chance to live those lives
themselves. Even better, these fantasy lives are not weighed down with the mundane
events of life. In most games, players do not have to worry about eating, needing to get
some sleep, or going to the bathroom. Thus, a game can create a fantasy life without the
tedious details. And, most importantly, the level of fantasy immersion is heightened
from that of other art forms because of the interactive nature of gaming.
Another part of the fantasy fulfillment element of computer games is enabling play-
ers to engage in socially unacceptable behavior in a safe environment. Many popular
games have allowed players to pretend they are criminals or assassins. Driver is a good
example of this. Though the back-story explains that the player character is actually
playing an undercover police officer, players get to pretend they are criminals who must
evade the police in elaborate car chases. There is a devilish thrill to outrunning police
cars, especially for anyone who has ever been pulled over by the police. Though most
players would never consider participating in car chases in real life, there’s something
tempting and enticing about engaging in taboo activities. The massive popular success
of the Grand Theft Auto series is another testament to gamers’ desire to break society’s
rules during gameplay. Computer games provide a good medium for players to explore
sides of their personality that they keep submerged in their daily lives.
Players may also fantasize about events in history. If the player could have been
Napoleon, would Waterloo have turned out differently? If the player were a railroad
baron in the twentieth century, would he be able to create a powerful financial empire?
A whole line of historical games, from wargames to economic simulations, allow play-
ers to explore events in history, and see how making different choices than those made
by the historical figures involved will result in wildly different outcomes. While many
people spend their time dwelling on the past, wondering how events could have tran-
spired differently if alternate decisions had been made, games can give players a chance
to actually find out how history might have been different.
Even without the elements of excitement and glamour, even if another person’s
life is not actually that exciting, it can be interesting to spend time as that person. Good
computer games can provide players with the otherwise unavailable opportunity to see
8 Chapter 1: What Players Want

the world through someone else’s eyes. As millions of gamers can attest, it is fun to
role-play and it is fun to fantasize.

Players Want to Interact

At the beginning of this discussion of what players want, I suggested that it was impor-
tant to create an experience that players would choose over one of the many other
entertainment options presented to them, such as watching television, reading a book,
or going to a concert. The one common thread running through all of the “wants” I
mentioned above is what our art form can do better than any other: provide an interac-
tive experience. Though we may be envious of a film’s special effects budget, a novel’s
ability to tell a gripping narrative, or the emotive power of a great piece of music, no
other form allows the audience to be the guiding force in the experience they are hav-
ing. Games have found their greatest successes when they have played up the
interactive nature of the experience and provided our audience with something they
cannot get anywhere else. Game designers need to constantly keep this in mind as they
are developing their games if they are to have any chance of winning players’ attention.

What Do Players Expect?

Once players have decided they want to play a given game because of one motivating
factor or another, they will have expectations for the game itself. Beyond the game not
crashing and looking reasonably pretty, players have certain gameplay expectations,
and if these are not met, they will soon become frustrated and find another game to play.
It is the game designer’s job to make sure the game meets these expectations. Indeed,
player frustration is the nemesis of every game designer, and it is important that game
designers do everything possible to eliminate it. So once the gameplay begins, how do
game designers minimize player frustration? Exactly what is it that players expect?

Players Expect a Consistent World

As players play a game, they come to understand what actions they are allowed to per-
form in the world, and what results those actions will produce. Few things are more
frustrating than when players come to anticipate a certain result from an action and
then the game, for no perceivable reason, produces a different result. Worse still is
when the consequences of the players’ actions are so unpredictable that players cannot
establish any sort of expectation. Having no expectation of what will happen if a certain
maneuver is attempted will only frustrate and confuse players, who will soon find a dif-
ferent, more consistent game to play. It is the consistency of actions and their results
that must be maintained, for an unpredictable world is a frustrating one to live in.
Fighting games are a particularly appropriate example of the importance of predict-
able outcomes from actions. Players do not want a maneuver to work sometimes and
fail other times, without a readily apparent reason for the different outcomes. For
instance, in Soul Calibur, if players miss an attack, it has to be because their opponent
jumped, blocked, was too far away, or some other reason that players can perceive. The
players’ perception of the reason for the move’s failure is important to emphasize. It
may be that the internal game logic, in this case the collision system, will know why the
attack missed, but it is as bad as having no reason if players cannot easily recognize why
 Chapter 1: What Players Want 9

the maneuver failed. Furthermore, if only expert players can understand why their
action failed, many novices will become frustrated as they are defeated for no reason
they can understand. If a sword slash fails in a situation that closely resembles another
situation in which the same slash succeeded, players will throw their hands up in
frustration.
Pinball games are another interesting example. Of course, a pinball game is a com-
pletely predictable game-world, since it is based on real-world physics. Expert pinball
players know this, and will use it to their advantage. But a problem arises with novices.
Inexperienced players will often fail to see what they “did wrong” when the ball goes
straight between their flippers or rolls down one of the side gutters. These players will
curse the pinball game as a “game of luck” and not want to play anymore. Of course, the
fact that players of different skill levels will have radically different levels of success at a
given pinball game proves that it is not just a game of luck. But only those players who
stick with the game through numerous early failures will find this out. I am not suggest-
ing that pinball games should be abandoned or radically simplified, but one of their
shortcomings is that they alienate new players who cannot see the connections
between their actions and the outcome of the game.

Players Expect to Understand the Game-World’s Bounds

When playing a game, players want to understand which actions are possible and which
are not. They do not need to immediately see which actions are needed for a given situ-
ation, but they should understand which actions are possible to perform and which are
outside the scope of the game’s play-space.
In Doom II, the
player will not expect
to be able to start a
conversation with the
monsters he
is attacking.

For instance, in Doom, players will intuitively figure out that they are not going to
be able to hold a discussion with the demons they are fighting. Players will not even
want to initiate a conversation with a demon during which they suggest surrender as its
best course of action. Players understand that such interpersonal discussion is out of
the scope of the game. Suppose that Doom had included a monster late in the game, a
10 Chapter 1: What Players Want

foe that could only be defeated if players were friendly to it, winning it over with their
witty conversation. Players would have been frustrated, since they came to under-
stand, through playing the levels that led up to that level, that in Doom all that is needed
for victory is to blast everything that moves, while avoiding getting hit. Talking is com-
pletely out of the scope of the game.
Of course, a chatty monster in Doom is an extreme example of a game having
unpredictable bounds, but plenty of games break this design principle. These games
have players performing actions and completing levels using a certain type of game
mechanism, and then later on insert puzzles that can only be solved using an entirely
new mechanism. The problem is that the players have been taught to play the game a
certain way, and suddenly the game requires players to do something completely differ-
ent. Once players come to understand all of the gameplay mechanisms that a game
uses, they don’t want new, unintuitive mechanisms to be randomly introduced.

Players Expect Reasonable Solutions to Work

Once players have spent some time playing a game, they come to understand the
bounds of the game-world. They have solved numerous puzzles, and they have seen
what sorts of solutions will pay off. Later in the game, then, when faced with a new puz-
zle, players will see what they regard as a perfectly reasonable solution. If they then try
that solution and it fails to work for no good reason, they will be frustrated, and they will
feel cheated by the game.
This sort of difficulty in game design is particularly true in games that try to model
the real-world to some degree. In the real-world there are almost always multiple ways
to accomplish a given objective. Therefore, a computer game set in the real-world must
also try to allow reasonable and logical solutions to a problem to result in success. Of
course, a designer always provides at least one solution to a puzzle, and that solution
may be perfectly reasonable. But there may be other equally reasonable solutions, and
unless the designer makes sure those solutions work as well, players will discover and
attempt these non-functioning alternate solutions and will be irritated when they do
not work. It is the game designer’s task to anticipate what players will try to do in the
game-world, and then make sure that something reasonable happens when players
attempt that action.

Players Expect Direction

Good games are about letting the players do what they want, up to a point. Players want
to create their own success stories, their own methods for defeating the game, some-
thing that is uniquely theirs. But at the same time, players need to have some idea of
what they are supposed to accomplish in this game. Not having direction is a bit too
much like real life, and players already have a real life. As I have discussed, many
gamers are probably playing the game in order to get away from their real lives, to fanta-
size and escape. They usually do not play games in order to simulate real life on their
computer.
Thus, players want to have some idea of what their goal is and be given some sug-
gestion of how they might achieve that goal. With a goal but no idea of how to achieve it,
players will inevitably flail around, try everything they can think of, and become frus-
trated when the maneuvers they attempt do not bring them any closer to their goal. Of
 Chapter 1: What Players Want 11

course, without an idea of what their goal is, players are left to wander aimlessly, per-
haps enjoying the scenery and marveling at the immersive game-world. Yet without
something to do in that game-world, it has failed as a game. If players do not know what
their goal is, the goal might as well not exist.
SimCity 3000 is the
third in a series of city
simulation “software
toys,” which let users
play without giving
them a specific goal.

The classic example of the goal-less game is SimCity. In fact, Will Wright, the
game’s creator, calls it a “software toy” instead of a game. SimCity is like a toy with
which players can do whatever they want, without ever explicitly being told that they
have failed or succeeded. In some ways SimCity is like a set of Legos, where players
can build whatever they desire just for the thrill of creation. The trick, however, is that
SimCity is a city simulator, wherein players are allowed to set up a city however they
want. But since the game simulates reality (constructing and running a city), and play-
ers know what is considered “success” in reality (a booming city full of lovely stadiums,
palatial libraries, and happy citizens), they will naturally tend to impose their own rules
for success on the game. They will strive to make their idea of the perfect city, and keep
its citizens happy and its economy buoyant. In a subtle way, players are directed by their
own experience with reality. If SimCity had been a simulation of a system that players
were completely unfamiliar with, it would certainly have been less popular. Indeed,
Wright’s games that are based in concepts average users are considerably less familiar
with (such as SimAnt and especially SimEarth) have found considerably less popular
success. Though SimCity does not explicitly have a goal, the very nature of the game
and its grounding in a widely understood reality encourages players to come up with
their own goals. And so, what starts out as a toy becomes a game, and thus players are
compelled to keep playing.

Players Expect to Accomplish a Task Incrementally

Once players understand what their goal in the game-world is, they like to know that
they are on the right track toward accomplishing that goal. The best way to do this is to
provide numerous sub-goals along the way, which are communicated to players just as
12 Chapter 1: What Players Want

clearly as the main goal. Players are rewarded for achieving these sub-goals just as they
are for the main goal, but with a proportionally smaller reward. Of course one can take
this down to any level of detail, with the sub-goals having sub-sub-goals and so forth, as
much as is necessary to clue players in that they are on the right track.
Of course, not every goal needs to be communicated to the players via text. For
example, in a story-based shooter such as Call of Duty, there are macro-goals that are
communicated via text to players on the “mission objectives” screen. There are an
average of four objectives on any given level. Beyond that, though, the game is littered
with sub-goals (such as “clear out the machine gun nests”) that players intuitively fig-
ure out along the way. For accomplishing these goals, players are rewarded by
congratulatory dialog from their fellow soldiers, the health and ammo they will be able
to collect from the fallen German soldiers, and the ability to access a new area of the
level. If one takes it to a truly micro level, each enemy that players must kill can be con-
sidered a mini-objective with tangible rewards such as seeing the foe fall over dead, the
fact that he stops being a threat to players, and players’ ability to collect his weaponry.
Platformer-style games such as Ratchet & Clank are particularly good at providing
incremental micro-goals, with all of the thousands of bolts players are able to pick up
throughout the game each helping them a tiny bit toward their larger goal of buying the
super weapon to use against the giant enemy. The great platformer games all use these
incremental pick-up rewards to pull players through their levels.
Without providing feedback of this kind (no matter how small it is), especially if the
steps necessary to obtain a goal are particularly long and involved, players may well be
on the right track and not realize it. When there is no positive reinforcement to keep
them on that track, players are likely to grow frustrated and try something else. And
when they cannot figure out the solution to a particular obstacle, they will become frus-
trated, stop playing, and tell all their friends what a miserable time they had playing
your game.

Players Expect to Be Immersed

A director of a musical I was once in would become incensed when actors waiting in the
wings would bump into the curtains. She suggested that once the audience sees the
curtains moving, their concentration is taken away from the actors on the stage and
their suspension of disbelief is shattered. They are reminded that it is only a play they
are watching, not real at all, and that there are people jostling the curtains surrounding
this whole charade. Perhaps exaggerating a bit, this director suggested that all of
Broadway would collapse if the curtains were seen shaking.
But she had a point, and it is a point that can be directly applied to computer games.
Once players get into a game, they are progressing through various challenges, they
have a good understanding of the game’s controls, and they are role-playing a fantasy.
They have forgotten that they are playing a game at all, just as a film audience may for-
get they’re in a theater or a book’s reader may become completely swept up in the lives
of the story’s characters. Commonly referred to as the “suspension of disbelief,” this is
the point when a piece of art can be its most affecting on its audience. Once their disbe-
lief is suspended, players do not want to be snapped out of their experience. For
starters, a game should never crash, as that would be the most jarring disruption possi-
ble. Beyond that, the littlest glitch in the game can immediately bring players out of
 Chapter 1: What Players Want 13

their trance-like immersion. If a character that is supposed to be walking on the ground

starts walking into the air for no recognizable reason, players will realize it is a bug and
their suspension of disbelief will be lost. If players come to a puzzle, figure out a per-
fectly reasonable solution to it, and that solution does not work, players will again be
reminded that they are “only” playing a computer game. If the game’s GUI is not
designed to be easy to read, transparent, and stylistically consistent with the rest of the
game-world art, it will stick out and ruin their immersion. All of these pitfalls and count-
less others detract from players’ feeling of immersion, and the more players are rudely
awakened from their game-world fantasy, the harder it is to re-immerse them in it.
Remember that many players want to play games in order to fulfill fantasies. It is very
hard to fulfill a fantasy when the game’s idiosyncrasies keep reminding players that it is
just a game.

Despite all his fame,

Mario does not have
a very distinct
personality. He is
pictured here in
Super Mario 64.

Another important component of player immersion is the character that players

are controlling in the game. Most all games are about role-playing to some extent. And
if the character players are controlling, their surrogate in the game-world, is not some-
one they like or can see themselves as being, their immersion will be disrupted. For
instance, in the third-person action/adventure game Super Mario 64, players are pre-
sented with a character to control, Mario, who does not have a very distinct personality.
Mario has a fairly unique look in his pseudo-plumber getup, but he never really says
much, and acts as something of a blank slate on which players can impose their own
personality. On the other hand, some adventure games have starred characters that
acted like spoiled brats, and players have to watch as their character says annoying, idi-
otic things over and over again. Each time the character says something that players
would never say if they had the choice, they are reminded that they are playing a game
and that they are not really in control of their character as much as they would like to be.
In order for players to become truly immersed, they must come to see themselves as
their game-world surrogate.
14 Chapter 1: What Players Want

Players Expect Some Setbacks

Players tend not to enjoy games that can be played all the way through the first time. If
the game is so unchallenging that players can storm right through it on their first
attempt, it might as well not be a game. If they wanted something that simple they
might as well have watched a movie. Remember that gamers are drawn to playing
games because they want a challenge. And a challenge necessarily implies that the
players will not succeed at first, and that many attempts must be made to overcome
obstacles before they are finally successful. A victory that is too easily achieved is a
hollow victory. It is not unlike winning a fistfight with someone half your size.
It is important to understand that players want setbacks because of their own
shortcomings, not because of the idiosyncrasies of the game they are playing. When
players fail, they should see what they should have done instead and they should
instantly recognize why what they were attempting failed to work out. If players feel
that the game defeated them through some “trick” or “cheap shot,” they will become
frustrated with the game. Players need to blame only themselves for not succeeding,
but at the same time the game must be challenging enough that they do not succeed
right away.
It is also a good idea to let players win a bit at the beginning of the game. This will
suck players into the game, making them think, “this isn’t so hard.” Players may even
develop a feeling of superiority to the game. Then the difficulty must increase or “ramp
up” so that players start to fail. By this time players are already involved in the game,
they have time invested in it, and they will want to keep playing, to overcome the obsta-
cle that has now defeated them. If players are defeated too early in the game, they may
decide it is too hard for them or not understand what sort of rewards they will receive if
they keep playing. If a game allows players to win at first, they will know that success is
possible and enjoyable and will try extra hard to overcome what has bested them.

Players Expect a Fair Chance

Players do not want to be presented with an obstacle that can only be surmounted
through trial and error, where an error results in their character’s death or the end of
their game. Players may be able to figure out the proper way to overcome the obstacle
through trial and error, but there should be some way to figure out a successful path on
their first try. So, extending this rule to the whole game, extremely observant and
skilled novice players should be able to progress through the entire game without
dying. It may be that no players will ever be this skilled on their first time playing, and,
as we discussed, ideally the designer wants players to have many setbacks before com-
pleting the game. However, it must be theoretically possible for players to make it
through on their first try without dying. If players keep dying from each shot-in-
the-dark attempt around an obstacle, they will realize that, due to short-sighted design,
there was no real way to avoid all of these deaths. They will be frustrated, they will
curse the game, and soon they will not waste their time with it any longer.
 Chapter 1: What Players Want 15

Players Expect to Not Need to Repeat Themselves

Once players have accomplished a goal in a game, they do not want to have to repeat
their accomplishment. If the designer has created an extremely challenging puzzle, one
that is still difficult to complete even after players have solved it once, it should not be
overused. For instance, the same painfully difficult puzzle should not appear in an iden-
tical or even slightly different form in multiple levels of an action/adventure, unless
defeating the puzzle is a lot of fun and the rewards are significantly different each time
the puzzle is completed. If it is not a lot of fun to do, and players have to keep solving it
throughout the game, they will become frustrated and will hate the game designers for
their lack of creativity in not coming up with new challenges.
Of course, many games are built on the principle of players repeating themselves,
or at least repeating their actions in subtly varied ways. Sports games such as NFL Blitz
and racing games such as Project Gotham Racing are all about covering the same ground
over and over again, though the challenges presented in any one playing of those games
are unique to that playing. Classic arcade games like Centipede and Defender offer
roughly the same amount of repetition. Tetris is perhaps the king of repetitive gameplay,
yet players never seem to grow tired of its challenge. The key component of these
games that makes their repetition acceptable is that these games are built purely upon
their game mechanics and the enjoyment players derive from various permutations of
them. In games where exploration is a key part of the players’ enjoyment and in which
the challenges presented in any specific playing are fairly static and unchanging, play-
ers do not wish to unduly repeat themselves. In these games, after exploring a
game-world once, subsequent explorations are significantly less interesting. While
every time players engage in a game of Tetris, Defender, Project Gotham Racing, or NFL
Blitz the game is unique, every time players play The Legend of Zelda: The Wind Waker,
Doom, or Baldur’s Gate the challenges presented are roughly the same. Therefore,
players do not mind the repetition in the former games while they will quickly become
frustrated when forced to repeat themselves in the latter.
Game players’ lack of desire to repeat themselves is why save-games were cre-
ated. With save-games, once players have completed a particularly arduous task they
can back up their progress so they can restore to that position when they die later.
Players must be given the opportunity to save their work after a huge, tricky challenge
has finally been overcome. Allowing players to save their game prevents them from
having to repeat themselves.
Some games will even automatically save players’ games at this newly achieved
position, a process sometimes known as checkpoint saving. This method is somewhat
superior since often players, having succeeded at an arduous task, will be granted
access to a new and exciting area of gameplay, one that they will immediately want to
explore and interact with. Often, in their excitement, they will forget to save. Then,
when they are defeated in the new area, the game will throw them back to their last
save-game, which they had made prior to the challenging obstacle. Now players have to
make it through the challenging obstacle once again. However, if the game designers
recognize that the obstacle is a difficult one to pass, they can make the game automati-
cally save the players’ position, so that when players die in the new area, they are able
to start playing in the new area right away. Indeed, automatic saving provides players
with a more immersive experience: every time players access a save-game screen or
16 Chapter 1: What Players Want

menu, they are reminded that they are playing a game. If players can play through a
game without ever having to explicitly save their progress, their experience will be that
much more transparent and immersive.
However, it is important to note that automatic saves should not be used as a
replacement for player-requested saves, but should instead work in conjunction with
them. This way players who are accustomed to saving their games will be able to do
so whenever they deem it appropriate, while gamers who often forget to save will be
allowed to play all the way through the game without ever needing to hit the save
key. Many developers are concerned that allowing players to save anywhere removes a
key element of tension for the player. Indeed, if players can save after each tiny,
incremental step they make, the game will be significantly less challenging. However,
it is important to remember two fundamental things. First and foremost, if players
truly want to ruin their experience by saving constantly, we should allow them to do
that, because games are supposed to be about empowering players to do whatever
they want to do. Secondly, by not allowing players to save whenever they want, they
will be forced to do ridiculous things such as leave their game system on overnight
because a parent or spouse has demanded that bedtime has arrived but they do not want
to lose their progress. If games are supposed to be the most interactive medium, game
designers need to make sure they are at least as interactive as a DVD player or a book,
and thus allow players to stop the activity and save their progress at any point they
desire.

Players Expect to Not Get Hopelessly Stuck

There should be no time while playing a game that players are incapable of somehow
winning, regardless of how unlikely it may actually be. Many older adventure games
enjoyed breaking this cardinal rule. Often in these games, if players failed to do a partic-
ular action at a specific time, or failed to retrieve a small item from a location early in the
game, they would be unable to complete the game. The problem was that players would
not necessarily realize this until many hours of fruitless gameplay had passed. The
players’ game was essentially over, but they were still playing. Nothing is more frus-
trating than playing a game that cannot be won.
As an example, modern 3D world exploration games, whether Metroid Prime or
Super Mario Sunshine, need to concern themselves with the possibility that players can
get hopelessly stuck in the 3D world. Often this style of game provides pits or chasms
that players can fall into without dying. It is vital to always provide ways out of these
chasms, such as escape ladders or platforms that allow players to get back to their
game. The method of getting out of the pit can be extremely difficult, which is fine, but
it must at least be possible. What is the point of having players fall into a pit from which
they cannot escape? If they are incapable of escape, the players’ game-world surrogate
needs to be killed by something in the pit, either instantly on impact (say the floor of the
pit is electrified) or fairly soon (the pit is flooding with lava, which kills players within
ten seconds of their falling in). Under no circumstances should the players be left alive,
stuck in a situation from which they cannot continue on with their game.
One of the primary criticisms leveled against Civilization, an otherwise excellent
game, is that its end-games can go on for too long. When two countries remain and one
is hopelessly far behind the other, the game can tend to stretch on past the point of
 Chapter 1: What Players Want 17

Level designers for

3D action/adventure
games, such as
Metroid Prime, need
to create maps that
prevent the player
from ever getting
permanently stuck
behind a piece of
architecture.

interest while the dominant power tracks down and slaughters the opposition. Indeed,
the less advanced country is not technically without hope. Players can still come from
behind and win the game; it is not completely impossible. Players are not stuck to the
same degree as players trapped in the pit with no exit, but the players are so far behind
that it might as well be impossible; the luck they would need to have and the mistakes
the dominant power would have to make are quite staggering. The solution to this is
perhaps to allow the AI to figure out when it is hopelessly overpowered and surrender,
just as players who are hopelessly far behind will do the same by quitting and starting a
new game.

Players Expect to Do, Not to Watch

For a time the industry was very excited about the prospect of “interactive movies.”
During this period computer game cut-scenes got longer and longer. Slightly famous
film actors started starring in the cut-scenes, and the budgets ballooned. Games
became less and less interactive, less, in fact, like games. Then — surprise, surprise —
gamers did not like these types of games. They failed to buy them. Companies col-
lapsed, and everyone in the industry scratched their heads wondering what had gone
wrong. Of course the gamers knew, and the game designers were soon able to figure
out what was amiss. The problem was that players wanted to do; they did not want to
watch. And they still feel the same way.
I am not completely against cut-scenes; they can be very useful tools for communi-
cating a game’s story, or for passing along to players information they will need in order
to succeed at the next section of gameplay. That said, I do believe that cut-scenes
should be stripped down and minimized to the absolute shortest length that is neces-
sary to give some idea of the game’s narrative, if any, and set up the next sequence of
gameplay. Cut-scenes over one minute in length, especially those that fail to provide
information essential for completing the next gameplay sequence, should be avoided. It
does not matter if the cut-scene is text scrolling along the back of the screen,
full-motion video with live actors, cel animation, or done using the game engine, the
entirety of this break in the gameplay should not take longer than a minute. If there is
18 Chapter 1: What Players Want

gameplay involved in some way, such as players planning out troop placement for the
next mission, then it is not really a cut-scene and can be as long as is necessary. And
certainly, if the cut-scene contains information critical to the gameplay, the designer
will want to let the players replay the cut-scene as many times as they desire.
The quality of the cut-scene really does not matter either. There have been many
games with the most atrocious “acting” ever witnessed, usually as performed by the
assistant producer and the lead tester. There have been games with Hollywood-quality
or better production and content. But in the end, if the game is any good, gamers are
going to want to get back to playing and will skip the cut-scene.
In short, the reason people play games is because they want something different
from what a movie, book, radio show, or comic can provide. They want to interact. I did
not include among the reasons why people play games “because the library is closed”
or “because the TV is on the blink.” Gamers want a game, and game designers should
give it to them.

Players Do Not Know What They Want, but

They Know When It Is Missing
One of the biggest mistakes a designer can make at the start of development is to have a
focus group with a bunch of gamers and ask them what they want to see in a new game.
One could see this as an argument against focus groups, but that is not quite the point.
Having playtesters is a very important part of game development. By playtesters, I
mean people looking not for bugs in your game, but rather analyzing the gameplay and
providing constructive feedback about it. A designer should have lots of people playing
his game once it is at a stage in development where a majority of the gameplay can be
judged. This may include using focus groups to obtain invaluable feedback about where
the game is too challenging or confusing, but only once the game is ready for them to
play.
On the other hand, having a focus group of gamers before a game has been created
just to “bounce ideas around” is pretty much useless. Gamers are good, of course, at
judging whether a game they are playing is any fun or not. They may not be able to
explain in a useful way what exactly they like or dislike about a particular game, but
they certainly know when they are having a good time, whether they are having their
fantasies fulfilled, whether they are being appropriately challenged, or if a game gets
them excited. When the game is failing to be any fun at all, gamers will be able to point
that out to you but relatively few will be able to tell you what to do in order to fix the
problem. Furthermore, just because gamers enjoy a wide range of finished games does
not mean they are qualified to critique raw game ideas. Similarly, game ideas they come
up with are not certain to be good ones. It is the rare person who can discuss the idea of
a computer game and determine if is likely the final game will be fun or not. People with
these skills are those best suited to become game designers. Not all game players have
these skills, so when asked what sort of game they might be interested in playing,
gamers may not really know what they want. But, as I say, they will be sure to tell you
when it is missing from the final product.
 Chapter 1: What Players Want 19

A Never-Ending List
Of course, this exploration of what players want could fill an entire book. I encourage
readers, whether aspiring game designers or those who have already had a number of
games published, to create their own lists of what they think gamers want. Think of
what frustrates you while you play a game and what parts of a given game give you the
greatest satisfaction. Then try to determine why you react to a game mechanic as you
do. What did it do right and what did it do wrong? This will allow you to establish your
own list of rules, which you can then apply to your own designs. These rules will be part
of what makes your games uniquely your own. Without feedback from playtesters it is
often hard to determine whether your game is entertaining and compelling or not. But
with a set of rules you can systematically apply to your design, you may be able to figure
out whether anyone will like the completed game.
Chapter 2
Interview:
Sid Meier

Sid Meier is certainly the most famous and well-respected Western computer
game designer, and deservedly so. In his nearly twenty years of developing
games, he has covered all manner of game designs and all types of subject
matter. He co-founded Microprose and at first focused on flight simulators,
culminating in his classic F-15 Strike Eagle and F-19 Stealth Fighter. Subse-
quently, he shifted to the style of game he is better known for today, developing
such classics as Pirates!, Railroad Tycoon, Covert Action, and Civilization, this
last game being one of the most universally admired game designs in the his-
tory of the form. In the late ’90s Meier founded a new company, Firaxis, where
he created the truly unique RTS wargame Gettysburg! Most recently he has
continued to take on new gameplay genres with the amusing course manager
SimGolf. What strikes one most when looking back over his games is their con-
sistent level of quality and the fact that he almost never repeats himself, always
preferring to take on something new and different for his personal projects. If
anyone has a solid grasp on what makes a game a compelling experience, it is
Sid Meier.

20
 Chapter 2: Interview: Sid Meier 21

Your first published games were flight simulators. Eventually you drifted over
to doing what you are now known for — strategy games. What drove you from
one genre to the other?
It was not a deliberate
plan. I think I’ve always
tried to write games
about topics that I
thought were interesting.
There are just a lot of dif-
ferent topics, I guess. A
lot of things that I’ve writ-
ten games about are
things that, as a kid, I got
interested in, or found a
neat book about the Civil
War, or airplanes, or
whatever. I think the F-19 Stealth Fighter
other thing that drove
that a little bit was the technology. That at certain times the technology is ready to do a
good job with this kind of game or that kind of game. Or the market is ready for a strat-
egy game, for example, or a game that you’ve wanted to do for a while but you didn’t
think the time was right. The shift, specifically from flight simulators to strategy, came
about for two reasons, I think. One, I had just finished F-19 Stealth Fighter, which
included all of the ideas I had up to that point about flight simulation. Anything I did
after that would be better graphics or more sounds or more scenarios or whatever, but I
didn’t feel I had a lot of new ideas at that point about flight simulation. Everything I
thought was cool about a flight simulator had gone into that game. And the other thing
was that I had spent some time playing SimCity and a game called Empire which got me
to thinking about strategy in a grand sense, a game that really had a significant amount
of scope and time and a lot of interesting decisions to be made. The combination of
those two factors led me to do first Railroad Tycoon and then Civilization after that, as
kind of a series of strategy games.
I find it dangerous to think in terms of genre first and then topic. Like, say, “I want
to do a real-time strategy game. OK. What’s a cool topic?” I think, for me at least, it’s
more interesting to say, “I want to do a game about railroads. OK, now what’s the most
interesting way to bring that to life? Is it in real-time, or is it turn-based, or is it
first-person . . . ” To first figure out what your topic is and then find interesting ways and
an appropriate genre to bring it to life as opposed to coming the other way around and
say, “OK, I want to do a first-person shooter; what hasn’t been done yet?” If you
approach it from a genre point of view, you’re basically saying, “I’m trying to fit into a
mold.” And I think most of the really great games have not started from that point of
view. They first started with the idea that, “Here’s a really cool topic. And by the way it
would probably work really well as a real-time strategy game with a little bit of this
in it.”
22 Chapter 2: Interview: Sid Meier

So when you come up with your ideas for new games, you start with the set-
ting of the game instead of with a gameplay genre.
I think a good example of
that is Pirates! The idea
was to do a pirate game,
and then it was, “OK,
there’s not really a genre
out there that fits what I
think is cool about
pirates. The pirate movie,
with the sailing, the
sword fighting, the stop-
ping in different towns
and all that kind of stuff,
really doesn’t fit into a
genre.” So we picked and Pirates!
chose different pieces of
different things like a sailing sequence in real-time and a menu-based adventuring sys-
tem for going into town, and then a sword fight in an action sequence. So we picked
different styles for the different parts of the game as we thought they were appropriate,
as opposed to saying, “We’re going to do a game that’s real-time, or turn-based, or
first-person, or whatever” and then make the pirates idea fit into that.

I think it’s interesting that Pirates! was designed with all those mini-games, but
you haven’t really used discrete sub-games so much since. Did you not like the
way the mini-games came together?
Well, I think it worked pretty well in Pirates! It doesn’t work for every situation. One of
the rules of game design that I have learned over the years is that it’s better to have one
great game than two good games. And, unless you’re careful, too many sub-games can
lose the player. In other words, if you’ve got a good mini-game, then the player’s going
to get absorbed in that. And when they’re done with that, they may well have lost the
thread of what your story was, or if any game is too engrossing it may disturb the flow of
your story. Frankly, the mini-games in Pirates! were simple enough that you didn’t lose
track of where you were or what your objective was or what you were trying to do. But I
wrote a game a couple of years later called Covert Action which had more intense
mini-games. You’d go into a building, and you’d go from room to room, and you’d throw
grenades and shoot people and open safes and all that kind of stuff and you’d spend
probably ten minutes running through this building trying to find more clues and when
you came out you’d say to yourself, “OK, what was the mission I was on, what was I try-
ing to do here?” So that’s an example for me of the wrong way to have mini-games
inside of an overall story.
 Chapter 2: Interview: Sid Meier 23

I’ve read that Covert Action was one of your personal favorites among the games
you designed.
I enjoyed it but it had that
particular problem where
the individual mini-
sequences were a little
too involving and they
took you away from the
overall case. The idea
was that there was this
plot brewing and you had
to go from city to city and
from place to place find-
ing these clues that would
tell you piece by piece
what the overall plot was Covert Action
and find the people that
were involved. I thought it was a neat idea, it was different. If I had it to do over again, I’d
probably make a few changes. There was a code-breaking sequence, and circuit
unscrambling, and there were some cool puzzles in it. I thought that overall there were
a lot of neat ideas in it but the whole was probably not quite as good as the individual
parts. I would probably do a couple of things differently now.

So Covert Action seems to have had origins similar to Pirates! You started with,
“I want to do a covert espionage game . . . ”
Right, what are the cool things about that. And unfortunately, the technology had gotten
to the point where I could do each individual part in more detail and that for me
detracted from the overall comprehensibility of the game.

In Pirates! and Covert Action, the player can see their character in the game,
and the player is really role-playing a character. By contrast, in Railroad Tycoon,
Civilization, or Gettysburg!, the player does not really have a character to
role-play. I’m curious about that shift in your game design, where the player
used to be a specific character and now is more of a godlike figure.
It’s good to be God. I think that’s really a scale issue more than a specific game design
choice. It’s fun to see yourself, and even in a game like Civilization you see your palace,
you do tend to see things about yourself. But the other thing is that a pirate looks cool,
while a railroad baron doesn’t look especially cool. Why go to the trouble to put him on
the screen? I’ve never really thought too much about that, but I think it’s probably more
of a scale thing. If you’re going through hundreds and thousands of years of time, and
you’re a semi-godlike character doing lots of different things, it’s less interesting what
you actually look like than if you’re more of a really cool individual character.
24 Chapter 2: Interview: Sid Meier

So how did you first start working on Railroad Tycoon?

Well, it actually started as
a model railroad game
with none of the eco-
nomic aspects and even
more of the low-level
running the trains. You
would actually switch the
switches and manipulate
the signals in the original
prototype. It kind of grew
from that with a fair
amount of inspiration
from 1830, an Avalon Hill
board game designed by
Bruce Shelley, who I
worked with on Railroad
Railroad Tycoon
Tycoon. So, that inspired a
lot of the economic side, the stock market aspects of the game. As we added that, we
felt that we had too much range, too much in the game, that going all the way from flip-
ping the switches to running the stock market was too much. We also wanted to have
the march of technology with the newer engines over time, all the way up to the diesels.
So there was just too much micro-management involved when you had to do all the
low-level railroading things. So we bumped it up one level where all of the stuff that had
to happen on a routine basis was done for you automatically in terms of switching and
signaling. But if you wanted to, and you had an express or a special cargo or something,
you could go in there and manipulate those if you really wanted to make sure that train
got through on time, or a bridge was out and you had to stop the trains. But the origin of
that was as a model railroading game and we added some of the more strategic ele-
ments over time.
It really was the inspiration for Civilization in a lot of ways, in terms of combining a
couple of different, interesting systems that interacted continuously. The economic,
the operational, the stock market, all interesting in their own right, but when they
started to interact with each other was when the real magic started to happen. As
opposed to Pirates! and Covert Action, where you had individual sub-games that monop-
olized the computer. When you were sword fighting, nothing else was going on. Here
you had sub-games that were going on simultaneously and interacting with each other
and we really thought that worked well both in Railroad Tycoon and later in Civilization,
where we had military, political, and economic considerations all happening at the same
time.

So in a way, you are still using sub-games; they just happen to all be in play all
the time.
It’s not episodic in the way that Pirates! was. Whenever you’re making a decision
you’re really considering all of those aspects at the same time. That’s part of what
 Chapter 2: Interview: Sid Meier 25

makes Civilization interesting. You’ve got these fairly simple individual systems; the
military system, the economic system, the production system are all pretty easy to
understand on their own. But once you start trading them off against each other, it
becomes more complex: “I’ve got an opportunity to build something here. My military
really needs another chariot, but the people are demanding a temple . . . ” So these
things are always in play and I think that makes the game really interesting.

In Railroad Tycoon you’ve got a very interesting economic simulation going, but
at the same time the player has the fun of constructing a railroad, much as a
child would. Do you think that contributed to the game’s success?
It actually started there.
And it was really the first
game that I had done
where you had this dra-
matic, dramatic change
from the state at the
beginning of the game to
the state at the end of the
game. Where, at the
beginning of the game
you had essentially noth-
ing, or two stations and a
little piece of track, and
by the end of the game
you could look at this
massive spiderweb of
trains and say, “I did Railroad Tycoon
that.” And, again, that
was a concept that we carried forward to Civilization, the idea that you would start with
this single settler and a little bit of land that you knew about and by the end of the game
you had created this massive story about the evolution of civilization and you could look
back and say, “That was me, I did that.” The state of the game changed so dramatically
from the beginning to the end, there was such a sense of having gotten somewhere. As
opposed to a game like Pirates! or all the games before that where you had gotten a
score or had done something, but there was not this real sense that the world was com-
pletely different. I think that owes a lot to SimCity, probably, as the first game that really
did a good job of creating that feeling.

Were you at all inspired by the Avalon Hill board game Civilization when you
made your computer version?
We did play it, I was familiar with it, but it was really less of an inspiration than, for
example, Empire or SimCity. Primarily, I think, because of the limitations of board
games. There were some neat ideas in there, but a lot of the cool things in Civ., the
exploration, the simultaneous operation of these different systems, are very difficult to
do in a board game. So there were some neat ideas in the game, and we liked the name.
26 Chapter 2: Interview: Sid Meier

[laughter] But in terms of actual ideas they were probably more from other sources
than the Civilization board game.

A lot of your games seem to be inspired in part from board games. But, as you
just said, Civilization would never really work as a board game. How do you
take an idea that you liked in a board game and transfer it into something that
really is a computer game instead of just a straight translation?
Before there were computers, I played a lot of board games and I was into Avalon Hill
games, et cetera. I think they provided a lot of seed ideas for games. Often they are a
good model of what’s important, what’s interesting, and what’s not about a topic. But
once you get into mechanics and interface and those kind of things, really there starts to
be a pretty significant difference between board games and computer games. There’s a
lot of interesting research material sometimes in board games. Often they’re interest-
ing for “we need some technologies” or “we need to think about which units,” et
cetera. There’s that kind of overlap in terms of the basic playing pieces sometimes. But
how they are used and so forth, those things are pretty different between board games
and computer games. I would say board games provide an interesting review of topics
that are available and topics that are interesting. But once it gets into the actual game
itself there is a wide difference between computer games and board games, in my mind.

One of the most remarkable things about Civilization is its addictive quality. I
was wondering if that came about by luck or if you planned it from the start.
We didn’t really envision
that. We intend for all of
our games to be fun to
play and hope that they
are addictive to some
degree. But Civilization
had a magic addictiveness
that we really didn’t
design, that we really
didn’t anticipate. I think
any game where every-
thing falls together in a
really neat way is going to
have that quality. I think
that it’s really a result of
how well the pieces fit
together and how I think Civilization
we picked a good scale, a good complexity level, a good number of things to do. I think
we made some wise decisions in designing that game. And the sum of all those deci-
sions is addictiveness. And I think that it was a good topic. A lot of things were right
about that game, and that all came together to create this addictive quality. It was not
something that we designed in, but it was something that we were kind of aware of.
 Chapter 2: Interview: Sid Meier 27

About halfway through the process we realized that, wow, this game really is a lot of fun
to play. It was a pleasant discovery for us.

So you don’t have any advice for how other designers can try to achieve that
addictiveness in their own games?
I think in hindsight we know, or we think we know, why the game is addictive, or have
our theories. One thing is what we call “interesting decisions.” To us that means you
are presented with a stream of decision points where the decisions are not so complex
that you are basically randomly choosing from a list of options. A too-complex decision
is one where you say, “Oh, I’ve got these three options. Yeah, I could spend five minutes
analyzing the situation, but I really want to get on with the game so I’m going to pick B
because it looks good.” And on the other extreme there’s the too-simple decisions:
“It’s obvious that I must choose A, because it is clearly better than all of the other
options.” In Civ. we try to present you choices where they are easy enough to under-
stand, but in a certain situation you might choose A, in a slightly different situation B is
a good choice, in another situation C is a good choice. So you’re really saying, “Here are
the three technologies that I can go for next.” And you say to yourself, “Well, right now
I’m about to get into a conflict with those no-good Romans. So I really need that tech-
nology that gives me the next cool military unit. But, well, that map-making looks kind
of interesting. Next time I might take that because I want to do some exploring.” So if
you can create decisions where the player is always saying, “Next time, I’m going to try
that one, because that looks interesting too,” that creates this whole idea that there’s
this richness there that you’re only scratching the surface of this time.
The addictive quality, I think, also falls out of the fact that you’ve got multiple
things happening or in process at the same time. On the one hand you’ve got your next
technology churning away over there. Your scientists are working on that. And this city
is making that first tank that you’re looking forward to. Over here is a unit wandering
around to the next continent, and pretty soon he’ll find something interesting. You’ve
got different things that you are looking forward to in the game, and there’s never a
time when those are all done. There’s never a reset state. There’s always two or three
things happening in the game that you are looking forward to when they finish. So
there’s never actually a good time to stop playing. I think that really helps the “you can
never stop playing the game” phenomenon.

I know Gettysburg! was not your first real-time game, but it seems to have
been in part inspired by the big hit RTS games like Command & Conquer and
WarCraft.
I think the technology had gotten to the point where you could have a whole bunch of
little guys running around doing stuff on the screen in real-time. And what you call
“real-time,” it’s kind of a weird term because we’ve done real-time games forever, but
we didn’t think of them as real-time because it just seemed a natural thing. But I guess
when turn-based got to be its own genre, we had to make a distinction. I think Gettys-
burg! is a game that I wanted to do for a long time, but the technology didn’t really lend
itself to being able to do it until fairly recently. We finally got to the point where we could
have a bunch of guys marching around the screen on a realistic-looking battlefield,
28 Chapter 2: Interview: Sid Meier

loading their muskets, shooting and wheeling in different formations, and doing all that
sort of stuff that I had visualized as what was cool about a Civil War battle. The time
came along when that was doable.

It seems like it takes what WarCraft and the other, simpler RTS games did well,
but then adds a deeper level of simulation, where you have flanking bonuses
and other more traditional wargame features. Was it your goal to take a more
complex wargame and merge it with the fast-paced RTS format?
Again, the idea was to do
a Gettysburg battle game,
and then the genre of
“real-time” made the
most sense. I’d always
had a feeling in playing
any other board game
that something was miss-
ing. The sense that I get
from reading the histo-
ries, the stories of the
battles, is not captured in
a board game or in any of
the games I had played
about Gettysburg. The
time pressure, the sense
of confusion, the sense of Gettysburg!
these different forma-
tions, et cetera, didn’t make any sense until you actually had to make the decisions
yourself. And then all of a sudden you realize, “Boy, it wasn’t quite that easy to do that
obvious maneuver that would have won the battle if only they had tried it,” or “Now I
understand why they lined up in these formations that seemed pretty stupid to me
before.” A lot of things started to make sense when the battle came to life. And that was
the idea, to include enough Civil War tactics like flanking, morale, and things like that to
really capture the flavor of a Civil War battle without overwhelming the player with
hard-core wargaming concepts. By representing the key factors that influenced the bat-
tle or that influenced tactics, you could naturally learn how to be a commander. You
wouldn’t have to follow a set of rules, but you would realize that, “Oh, if I give these
guys some support they’re going to be better soldiers, and if I can come in on the flank
then that’s a better attack.” And you go through a learning process as opposed to being
told how to be a good general. You learn that along the way. That was the intention.

I was wondering about the “click-and-drag” method you had the player use for
directing his troops somewhere. It’s very different from what other RTS
games employ. Did you use it because you thought it was a better system, even
though it was not the standard?
I’m not sure I’d do that the same way today. I think that click-and-drag made a certain
amount of sense, especially since as you dragged we were showing with the arrow
 Chapter 2: Interview: Sid Meier 29

interesting things about the path that you would take. I’m also a big fan of standard
interfaces, so if I had that to do today, I probably would try to go with more of the stan-
dard RTS interface. I think at the time that we were doing that, it was pretty early.
WarCraft was out, but I don’t think StarCraft was out, and Age of Empires came out at
just about the same time. So the interface standard had not coalesced when we did that.
I think that in recognition of that we gave the player the option to use the
right-click/left-click way of doing things too. But if I had that to do today, I would proba-
bly make the standard RTS method the default and make the click-and-drag the option.

As opposed to Railroad Tycoon or Civilization, Gettysburg! has discrete scenarios:

you play for a while and then that battle ends, you get a new briefing, and your
troops reset. Why did you opt for that style of gameplay progression?
Well, I did that because
the stupid Battle of Get-
tysburg had too many
units! [laughter] I would
have preferred a com-
plete battle at the kind of
level that the actual game
turned out to be.
Basically, to make the
game fun, I have found
that you need to have
somewhere between ten
and twenty-five discrete
units that you can move
around. Unfortunately
the entire battle had sev-
enty or eighty regiments, Gettysburg!
so it would have been totally out of control. We tried for a while actually fudging the
scale, and saying, “You’ll actually be given brigades but they’ll act like regiments and
then you can fight the whole battle.” But it didn’t feel right skewing the scale in that
way. So, we got to the point where it was, “OK, the most fun and most interesting bat-
tles are of this scale. And that really means that it’s a portion of the battle. And we have
to accept that, and live with that, and make the best of that.” And I think the scenario
system was an attempt to do that.
I think that in an ideal world I could have picked the Battle of Hunter’s Run or
something where there were only three brigades and it was all capturable in a single
scenario. But nobody’s going to buy The Battle of Hunter’s Run; they all want Gettys-
burg! So it’s an unfortunate part of history that it happened to be such a large battle.
And, I think it worked fairly well. But I understand when people say, “Well, I really want
the whole battle.” And we tried to give them that, and show them that they really didn’t
want that in this system. It was a case where history and reality didn’t create probably
the ideal situation for the game system that we had. But it was our feeling that, as
opposed to either giving you the whole battle and overwhelming you with eighty units,
or trying to play some pretty convoluted games to get the whole battle into that scale,
30 Chapter 2: Interview: Sid Meier

we thought that the scenario system was the best compromise in trying to make it play-
able but also historically realistic. And I think there are some cool scenarios in there. It
probably skews it a little more toward the hard-core, Civil War interested person but
they can’t all be Civilization.

So you are still working on your dinosaur-themed game. What are your goals
with that project?
Well, the goal of the game is really the same as all the games that I’ve worked on: to fig-
ure out what is the really cool part, the unique part, the interesting part of this topic, and
find a way to turn that into a computer game. I’ve thought that dinosaurs were cool for
the longest time, and I think it’s a topic that needs to be computer-motized. I try to take
the approach of putting into the game a lot of things that are scientifically true or histor-
ically accurate, but that’s not to be educational, it’s to let the player use their own
knowledge in playing the game. Most people know something about dinosaurs, or
something about history, and if they can apply that knowledge to the game, then that
makes it a lot more interesting and makes them feel good about themselves. It’s not
because they read the manual that they’re good at the game, it’s because of what they
know. They realize that it’s cool to have gunpowder and the wheel and things like that.
So in the same sense, people know that the T. rex is the baddest dinosaur. So we use
things in the game to make it valuable to know some basic facts about whatever the
topic is. We try and put that amount of realism and accuracy into the game. And then
make it fun on top of that. In the same way that a movie gives you all the fun and the
action sequences and all the important parts of a story and then jumps quickly over the
boring things. I think the game has the same responsibility, to bring you to the key deci-
sion points and then move you on to the next interesting thing. We’re trying to take that
same approach with the dinosaur game, to bring them to life, to figure out what’s cool
and unique about them while cutting out all the dull parts. We’re really in a “working
that out” phase, and we don’t have a lot to say about the specifics of that; hopefully in
another few months we’ll be able to talk a little bit more about how that’s going to turn
out. [Since this interview was conducted, Meier abandoned the dinosaur game, instead
opting to develop SimGolf.]

Relatively speaking, you’ve been making computer games for a long time,
since the early ’80s. I was wondering how you thought the industry has
changed over that time.
I think there’s been a general, overall improvement in the quality of the games. I think
there are some great games out there right now. I like StarCraft, Age of Empires, Diablo,
The Sims I thought was really interesting, and RollerCoaster Tycoon was a hoot, a lot of
fun. So I think those games compare very favorably to anything that’s been done. I think
they’re overall better games than we were doing five or ten years ago. I think you can
certainly see the improvement in presentation, graphics, video, and all that kind of
stuff. The core of the games, the game design stuff, I think is a pretty slow evolutionary
process. I think in terms of game design, games like Pirates! and SimCity and Civiliza-
tion really stand up. I think they’re really pretty strong designs, even today. I think they
haven’t been eclipsed by what’s going on now. So I think that in terms of game design,
 Chapter 2: Interview: Sid Meier 31

the rule that says that things get twice as good every year, processors get twice as fast,
et cetera, I don’t think that applies. I think game design is a pretty gradual, evolutionary
process, where we build on what’s gone on before, and make it a little bit better, a little
bit more interesting. Every so often a new genre comes along to open our eyes to some
new possibilities. I think that will continue, but it’s interesting to me that a three-year-
old computer is completely obsolete, but a three-year-old game can still be a lot of fun.

As long as you can get it to run …

Right, as long as you have that three-year-old computer to run it on. There’s a different
pace, I think. Technology moves at one pace, a very quick pace, and game design evolu-
tion moves at a much slower pace.

Do you think that game design evolution has slowed since the early days of the
industry?
I don’t see a significant change. I think one phenomenon is that we only remember the
good games from the past. The past seems like it had all sorts of great games, and the
present seems like it has a few great games and a lot of crap. And I think there was a lot
of crap in those days too, it has just all faded away. I think there is a lot of great game
design work going on today. Before there was a lot more unexplored territory, and that
gave us the opportunity to be a little more innovative. But with online technology and
things like that, that opens up a lot of new areas for being innovative. So I don’t see a
substantial difference between the amount of good work being done today versus what
was going on years ago.

You have worked at both small development studios, Microprose in the early
days and Firaxis, as well as a big one, latter-day Microprose. Do you find that
one environment is better at fostering the creation of good games?
I’m personally much more comfortable in the small environment. That may be more of
a personal feeling than any kind of a rule about where good games happen. I think the
trend certainly has been to bigger groups, bigger teams, bigger bigger bigger. And that
may be just the way things are. If there’s anything that makes me feel a little bit old, it is
the fact that I’m not as comfortable in the big group environment as clearly some of the
other developers. I think some of the younger developers who grew up in that mode are
much more comfortable with the big projects. I was in Los Angles for the E3 show, and
the winner of the Hall of Fame award was Hironobu Sakaguchi who designed Final Fan-
tasy, which is a massive, massive, massive game. It would totally frighten me to tackle
something that big. But there are designers who just thrive on that. I think it’s a per-
sonal preference for designers, and I think since I started in the time when there was no
such thing as a gigantic team that I am comfortable in that smaller mode, while other
designers prefer the larger projects. Primarily it’s a personal preference.
32 Chapter 2: Interview: Sid Meier

Since you started in game development, development teams have grown from
one or two people to a standard number of twenty or more. Do you think that
has made games less personal?
I think it did, but there are still games today that have that personal touch. And I think
those are the good games. I think that a lot of the games that are not so much fun are
those that have this “designed by committee, programmed by a horde” feeling to them.
And, yeah they look good, and they are kind of reminiscent of maybe one or two other
games that were good. But they don’t have that personal spark. To me, RollerCoaster
Tycoon is a good example of a personal game. It really feels like somebody thought that
was cool. Nobody said, “That’s goofy” or “That’s stupid.” A lot of the ideas there are
very clever, but if you brought it up before a committee they would say, “Oh really,
won’t people think that’s silly?” And even Final Fantasy, in spite of its massive team, is
really the product of one person’s vision. And if you can keep that going in a big team,
that’s great. But I think that it becomes harder and harder the larger the team is to keep
that personal vision alive and not get watered down by the committee approach.

You still serve as both lead programmer and lead designer on your projects.
Are you happiest filling both roles?
I cannot imagine working in another way. It’s just much more efficient for me to have an
idea and just type it into the computer than to try to explain it to somebody else and see
what happens. So, again, it’s my personal style, but to me it’s the most efficient way to
get something done.

On most modern projects at other companies, you have one person who’s the
lead designer, and one person who’s the lead programmer, and they’re both
very busy. It would appear that performing both roles you would be completely
overwhelmed.
Well, I think they probably spend half their time talking to each other, which is some-
thing I don’t have to do. I would see a certain efficiency in cutting out all those
meetings. But certainly it works both ways. Either way can work, but my personal pref-
erence is for the designer/programmer approach.

Now that you are working on a larger team, how do you communicate your
game design vision to the rest of the team and get them excited about the
project?
Our primary tool is the prototype. In our development, one of the advantages of being a
programmer/designer is that within a week or two we can throw together something
that feels like a game. That gives people the idea of what the game is going to be about,
how it’s going to work, the general parameters of it. Again, if we’re working on a histor-
ical or scientific topic, most people are half-way into it already, they know something
about the topic. And then just talking, saying here’s the kind of game I want to do, and
here are the three or four really cool things that are going to happen in the game that are
going to be the payoffs. Putting those things together I think gives people a pretty good
idea of what direction we’re headed. At that point you want people not to get the whole
picture, but to figure out where they fit in and can contribute their own things that
 Chapter 2: Interview: Sid Meier 33

hopefully you hadn’t even thought of, in terms of cool art or cool sounds or neat ideas.
In a way you don’t want it to be so complete that it feels done, because you want people
to feel that they can make their own contributions above and beyond what you’ve
already thought of.

So if someone else comes up with some cool ideas to add to your game design,
you’re happy to incorporate those even though you didn’t come up with them.
I’m happy to steal those and claim they were my ideas years later. [laughter]

With your prototyping system, do you ever try out a game and then it just
doesn’t work out as you had hoped?
Yup, I have a whole group of directories on my hard drive that fall into that category. And
many of the games that turned out to be products started in a very different direction.
Civilization, for example, was originally much more like SimCity, much more zone this
territory for farms, and place a city here and watch it grow. Initially it was much more of
a stand-back-and-watch-it-evolve approach; it only became turn-based after a couple of
months. I mentioned that Railroad Tycoon started out as a model railroading game. A lot
of times the prototypes will have to be radically modified to work. That’s the whole idea
of the prototype: to pretty quickly give you an idea of does the idea work, does it not
work, and what are the major problems. It lets you focus on the big issues first, and
hopefully straighten those out.

Your games seem very easy to pick up and learn to play. But at the same time
they have very deep, interesting gameplay. How do you manage to accomplish
both?
The easy-to-play part is
pretty well understood. I
think interface conven-
tions, and again getting
back to the idea of a famil-
iar topic helps people to
get right into it because
they know a little bit of
what they should be
doing. You want to give
the players a lot of posi-
tive feedback early in the
game to give them the
idea they’re on the right
track. In Civilization,
pretty quickly the people
add something to your Civilization
palace, and you get a population milestone, and your first city is formed. You want to
give the players, especially in the early stages, the idea that they’re on the right track,
that everything they do, the computer acknowledges it, recognizes it, and thinks it’s
34 Chapter 2: Interview: Sid Meier

really cool. That gets the players into the game.

In terms of the depth, that’s really because we play the games. The other advan-
tage of prototyping is that if you have a game that takes two years to write, you spend
one year and eleven months playing the game. You get pretty bored with the beginning
of the game after a while. In one sense you are putting that depth in the game to keep
yourself interested in writing this game. If there’s twenty or forty hours of gameplay in
a scenario, it’s because we have played those scenarios for twenty or forty hours and
found that, after about twenty hours, it gets a little thin. We have to come in with a new
thing and make this problem a little more interesting, a little more complex at that
point. So a lot of the depth comes out of the fact that we have intensively played the
game for long periods of time.

Do you find that prototyping facilitates balancing as well?

Playing the prototype really facilitates balancing. It also really helps with writing the AI
if you’ve played the game enough so that you really understand what are good strate-
gies, bad strategies, and interesting strategies. Having played the game quite a bit
helps to write the AI, it’s good for the depth. The danger is that you lose sight of the
beginning player. That’s why we go back to playtesting at the end of the game’s devel-
opment. And we say, “Here’s what we think the game is, try and play it.” And we
invariably find that they can’t play it. There’s just too much of that cool stuff in there. So
we say, “All right, where are you getting stuck?” We’re essentially unable to see the
game in that light anymore. But you need to have both the depth and the ease of entry.
Those are both important.

Your games all are grounded in history or real-life events, as opposed to many
games which have fantasy or science fiction settings. Is this because you enjoy
creating a game-world that the player is already somewhat familiar with?
I do think that’s important. It does add a lot when you can apply your own knowledge to
a game. I think that makes you feel better about yourself, and I think that’s a positive
thing. I think it also gives me a lot more to work with in terms of a historical or realistic
situation. I probably grew up in a time also when there was less of the Middle Earth, the
fantasy, the Star Wars, et cetera. Kids these days think these things are just as real as
history. Spaceships, magicians, and wizards are as real to a lot of kids as airplanes, sub-
marines, and things like that. It’s kind of an evolutionary thing, but in my growing up it
was things like airplanes, submarines, the Civil War, and the Roman Empire that were
interesting and cool things, and I try to translate those things into games.

I am curious about how you balance historical realism with the gameplay.
Gettysburg! seems to be one case where you had to break the gameplay up into
scenarios to keep it both historically accurate and fun.
That was one of the few times that we actually gave in to historical reality. In general
our rule is if you come to a conflict between fun and history, you go with the fun. You can
justify any game decision somewhere in history. Our decisions are made almost exclu-
sively to the benefit, hopefully, of the gameplay as opposed to the historical accuracy. In
Gettysburg! we came to a situation that we could just not fudge, though we tried. We
 Chapter 2: Interview: Sid Meier 35

tried as hard as we could

to fudge that situation. In
many other situations we
come to an idea that we
think is going to work
well for the game and
then we find the historical
precedent or an explana-
tion historically to justify
it. In no sense do we try
and stay slavishly accu-
rate because, basically,
we’re trying to create a
situation which is fluid
where you’re not just
going down the path of
Gettysburg!
history, you’re creating
your own history. Even though the pieces are realistic, you can take them off in a com-
pletely different direction that never really happened. Certainly, part of the fun of
Civilization is that the Zulus can take over the world, or the Mongols. Anybody can take
over the world; it’s not necessarily the Americans who are going to win in the end.
We’re not slaves to history.

At least since your days developing flight simulators, your games have not
really been on the cutting edge of technology in terms of graphics. Was that a
conscious decision on your part?
As I have said, in our prototyping process, things change almost up until the last min-
ute. Most of the cutting-edge technologies are things that need to be researched from
day one, and are gigantic investments in technology. And given that we’re in a mode
where things are changing constantly, it’s practically impossible to merge those two
approaches. The research project can’t start really unless you know exactly what you
want, or pretty much what you want. And we don’t usually know that at the beginning.
And we’re not willing to put ourselves in that straightjacket in terms of game design.
And I think a lot of times that’s what it is. If you are committed to a first-person 3D
viewpoint where you can see a certain amount, and you find out that to make your game
fun you really need to see more, you really need to get more context for your location or
whatever, you’re kind of screwed at that point.
Often there’s a conflict also between the functionality of the graphics and the love-
liness of the graphics. A game that looks good but doesn’t give you the information you
need to play or doesn’t give you the clarity, I think that’s the wrong trade-off. We try and
make games that we think look good. But in any good game the great graphics are hap-
pening in your imagination and not on the screen. If we tell you that the people have
declared “we love the king day” in a certain town, if you’re really into the game, that’s a
lot more meaningful, and you create a much more exciting image in your mind than any-
thing we could show you on the screen. And vice versa, if you’re not into the game, then
anything that comes on the screen you’re going to pick apart anyway. Our goal is to
36 Chapter 2: Interview: Sid Meier

involve you in the game itself and have you create your own really cool mental images
based on some suggestions that we give you on the screen.

You were one of the first game designers to get your name above the title on
the box. I was curious how that came about.
Well, the way that hap-
pened goes back to
Pirates! That was the first
game that had my name
on it. In those days I was
working at Microprose
and my partner was Bill
Stealey who did the
business/marketing side
of things while I did
the development/creative
stuff. And the previous
game before Pirates! was
one of the flight simulator F-15 Strike Eagle
games, and I said to Bill,
“Well, I’m going to work on this game about pirates.” And he said, “Pirates? Wait a min-
ute, there are no airplanes in pirates. Wait a minute, you can’t do that.” “Well, I think it’s
going to be a cool game.” And he answered, “Well, who’s going to buy a pirates game?
Maybe if we put your name on it, they’ll know that they liked F-15 or whatever, and they
might give it a try. OK.” There was a real concern that there was this pirates game com-
ing out, but nobody’s going to be interested, because who wants a pirates game? People
want flight simulators. So it was to say, “Sure, you want a flight simulator, but maybe
you might want to try this pirates game because it was written by the guy who wrote
that flight simulator that you’re playing.” I guess it was branding in a very crude, early
form. It was because we were making this big switch in the type of game that I was
working on, and to try to keep that connection between the games.

So it wasn’t your lust for fame?

[laughter] No, no. Even today, fame is not a computer game thing. I think it’s good. It’s
still a pretty non-personality oriented business. I think that people remember great
games, and they know to a certain extent who’s involved. But there’s not a cult of Robin
Williams or, you know, movie stars who really have a cult of personality. I think it’s
good. Once we get the idea that we can get away with anything just because we’re who
we are, that’s not a good thing.

But that sort of confidence led to Pirates!, didn’t it?

[laughter] Well, it was a good game. Had it not been a good game, that strategy would
not have worked.
 Chapter 2: Interview: Sid Meier 37

A lot of your games have had sequels of one kind or another, but you have
never been the lead designer on one of them. Why is this?
I think they are a fine thing to do in general, especially if they’re done well. I seldom go
back to a topic primarily because I haven’t run out of ideas yet, so I’d rather do a dino-
saur game than go back to an older title. I don’t have a lot of energy to get too involved in
the sequels. Some of them turn out well, some of them turn out not quite so well. As
opposed to letting the topic fade away, I think doing a sequel is often a good idea. In an
ideal world, I’d like to be involved in everything, but I can’t really do that. So I tend to be
more interested in being involved in a new product as opposed to a sequel. It’s certainly
gratifying that people want another Railroad Tycoon or Civilization, et cetera. I think
that’s great. I’m happy that it can be done. On Civilization III, since it’s being done
inside of Firaxis, I’m able to take a more direct part in that, which I think is good. I would
have liked to have done Railroad Tycoon II and do a new Pirates!, et cetera, if I had an
infinite amount of time. But it’s just not feasible.

I hear a lot of people talking about storytelling in games. Usually by storytell-

ing they mean using cut-scenes or branching dialog trees or devices like that.
Your games have never been very concerned with that side of storytelling.
To me, a game of Civiliza-
tion is an epic story. I
think the kind of stories
I’m interested in are all
about the player and not
so much about the
designer. There are play-
ers that are more
comfortable in situations
where they’re making
small decisions and the
designer’s making the big
decisions. But I think
games are more interest-
ing when the player
makes the big decisions
and the designer makes Civilization
the small decisions. I think, in some sense, games are all about telling stories. They
have a story created more by the player and less by the designer, in my mind. I think in
Civilization there are fantastic stories in every game, they’re just not in the more tradi-
tional sense of a story. We have, amongst our rules of game design, the three categories
of games. There are games where the designer’s having all the fun, games where the
computer is having all the fun, and games where the player is having all the fun. And we
think we ought to write games where the player is having all the fun. And I think a story
can tend to get to the point where the designer is having all the fun or at least having a
lot of the fun, and the player is left to tidy up a few decisions along the way, but is really
being taken for a ride. And that’s not necessarily bad, but our philosophy is to try to give
38 Chapter 2: Interview: Sid Meier

the player as much of the decision making as possible.

Though Gettysburg! had a multi-player option, by and large your games have
been single-player only for a long time. What do you think of the emerging pop-
ularity of multi-player gaming?
I think down the road I would like to get more into multi-player, perhaps even a game
that is primarily multi-player. But I still enjoy essentially single-player games, so I’m
not sure exactly when or how that’s going to happen. Online multi-player gaming is
probably the only revolutionary development in our technology we’ve seen since I
started writing computer games. Everything else has been pretty much evolutionary.
Better graphics, better speed, more memory, et cetera. But the multi-player online
thing was a revolutionary change in the tools that we had to make games. I’m interested
in doing something along those lines, but I’m not sure what it would be right now.

In an old Next Generation magazine interview, you said, “Games are going to
take over the world. It’s going to take a while, but there’s something inher-
ently more engaging about computer games than any other form of
entertainment.” Board games have certainly been around a long time, but
have not yet taken over the world. I wondered what it is about computer
games that you find so compelling.
Yeah, I think I stand by that statement. I think that it’s the element of interactivity that
makes them unique. They interact personally with you as a player, as opposed to mov-
ies, television, or music, which don’t. There’s this phenomenon of watching television
and using the remote control to desperately try to make it an interactive experience,
going from one channel to another... [laughter] But the interactivity of computer games
is what differentiates it and makes it so very powerful. Now, we’re still learning how to
use that tool and in a lot of other ways we’re not as good as television, movies, et cetera.
But I think that as we learn to use the advantages that we have, they’re more powerful
advantages than the advantages of other entertainment media.
I think that board games are kind of interactive, but they require other players. The
computer brings a lot of power to the equation that board games don’t take advantage
of. If anything, the advent of the Internet and multi-player play, that combined with
interactivity seems to me like a really powerful combination. I think as we learn to use
that element of our technology too, games can be very, very compelling. The question
that pops up is do people want games that are that interesting to play? There was the
whole Deer Hunter phenomenon, and there was Slingo and things like that and I’m still
working to integrate that into my model of the world, and I haven’t totally succeeded in
doing that. But what that tells me is that there’s a broader range of potential gamers
than I am really familiar with. And part of our learning process is going to be to integrate
them into the way that we design games and the way that we create games. But I still
think we’re going to take over the world.
 Chapter 2: Interview: Sid Meier 39

Sid Meier Gameography

Hellcat Ace, 1982
NATO Commander, 1983
Spitfire Ace, 1984
Solo Flight, 1984
F-15 Strike Eagle, 1985
Decision in the Desert, 1985
Conflict in Vietnam, 1985
Crusade in Europe, 1985
Silent Service, 1986
Gunship, 1986
Pirates!, 1987
F-19 Stealth Fighter, 1988
Railroad Tycoon, 1990
Covert Action, 1990
Civilization, 1991
Colonization, 1994 (Consultant)
Civilization II, 1996 (Consultant)
Gettysburg!, 1997
Alpha Centauri, 1999 (Consultant)
Civilization III, 2001 (Consultant)
SimGolf, 2002
Chapter 3
Brainstorming a
Game Idea:
Gameplay,
Technology, and
Story

“You know what’s the number one dumbest question I get asked when I’m out
at some great university lecturing? I’m always asked ‘Where do you get your
ideas?’ For about forty years I’ve been yanking their chain when I answer
‘Schenectady.’ They stare at me, and I say, ‘Yeah, Schenectady, in New York.
There’s this idea service, see, and every week I send ’em twenty-five bucks,
and every week they send me a freshly picked six-pack of ideas.’”
— Harlan Ellison

40
 Chapter 3: Brainstorming a Game Idea 41

H arlan Ellison might scoff at the idea of trying to explain where ideas come
from. Certainly, if you are a novelist having trouble coming up with ideas, it
may be time to wonder if you have chosen the right profession. Similarly, a
good game designer, at any given moment, will be able to come up with no less than five
solid ideas she would like to try to make into a computer game. There is no shortage of
ideas in the gaming world. Aspiring game designers often think they can sell their idea
to a development company. They seem to be under the impression that game develop-
ers are just sitting around waiting for a hot idea to come around so they can spend
several million dollars to make it a reality. On the contrary, selling a game idea to a com-
pany is so rare that one should consider it an impossibility. Almost all of the challenge in
game development is not coming up with a good idea, but in following through and
being able to craft a compelling game around that idea. That’s what the rest of this book
endeavors to explore.
In the arena of computer game design, the process of coming up with a game idea
that will work is complicated by a number of factors fiction authors do not need to worry
about. In part this is because computer game ideas can come from three distinct, unre-
lated areas of the form: gameplay, technology, and story. These different origins are
interconnected in interesting ways, with the origin of the game’s idea limiting what one
will be able to accomplish in the other two areas. So when a game designer starts think-
ing about the game she is hoping to make — thinking about it in terms of gameplay,
technology, or story — it is important that she consider how that initial idea will impact
all aspects of the final game.

Starting Points
Perhaps a quick example is in order. Say a game designer feels the need to create a
game based around the specific stories of Greek mythology. This would be starting
from a story. Immediately this limits the type of gameplay she will be going for. Chances
are a Civilization-style strategy game is out, since that sort of game really has nothing
to do with the classical stories of Zeus, Heracles, Ares, and so on. A real-time strategy
game is out of the question as well, since it is not good at telling stories involving only a
few protagonists. A high-end flight simulator is probably not going to work either. The
designer could, however, still pursue it through an action game, a role-playing game, or
an adventure game. Similarly, the technology is limited. In order to tell the story of the
Greek gods, the designer will need some way to communicate a lot of back-story infor-
mation to the player. Thus there will need to be technology in place that can allow this.
Furthermore, if the designer chooses the technology to be employed by the game at
this point, this will have still further impact on what type of gameplay will be possible.
For example, choosing an isometric 2D engine will best lend itself to an RPG or an
adventure game instead of an action game, unless one plans on being deliberately
“retro” and opts for a 2D action-adventure in the spirit of Crusader: No Remorse. If a 3D
technology is to be used, in order to tell the story of Greek mythology properly it will
need to support both indoor and outdoor environments, which immediately eliminates
a lot of 3D game engines.
42 Chapter 3: Brainstorming a Game Idea

For each decision the designer makes about the game she is hoping to create, she
needs to understand how that limits what the game will be. If the designer tries to fit a
type of gameplay around an ill-suited engine, the game will suffer in the end. Trying to
do a Populous-esque “god-sim” using a first-person, indoor Unreal-style 3D engine is a
big mistake. Just as if one tried to tell the story of the Greek gods through flight simula-
tor gameplay, the game would simply fail to work. Herein lies the difficulty with many
“high-concept” ideas, often the brainchildren of marketing specialists who want to cap-
ture disparate markets with one product. If the parts do not work together, it does not
matter how many markets the concept covers — no gamers will be interested in play-
ing the final game.

Starting with Gameplay

Beginning with gameplay is one of the most common starting points for game develop-
ment, especially for designer- or management-driven projects. Thinking about a style
of gameplay is often the easiest core for someone to latch onto, especially if that
gameplay is similar to an existing game. “It’s a racing game!” “It’s a flight simulator!”
“It’s a 3D action/adventure like Super Mario 64!” “It’s a first-person shooter like Halo!”
Often a game developer will have enjoyed a game in one of these genres and will want
to apply her own spin to it. With a general idea for a game that is interesting to her, the
designer will want to work out what her particular game is going to accomplish in terms
of gameplay. What type of racing game will it be? What aspects of racing are we trying to
capture for the player? With a more specific idea of what type of gameplay she wants to
create, the designer should start thinking about how that will impact the technology the
game will require and what sort of story, if any, the game will be able to have.
Depending on the type of gameplay you are hoping to create for the player, you
need to analyze what sort of technology that undertaking will require. Does the game
need a 3D engine, or will 2D be enough or even more appropriate? What sort of view
will the player have of the game-world? Will it be fixed or dynamic? Does the action
transpire fast and furious with a large number of entities moving around on the screen
at once? Are the game-worlds large or small? All of these questions and many more
need to be analyzed to understand what the game’s engine must accomplish in order to
properly execute the gameplay idea. Of course the technology you choose to employ for
your gameplay must actually run on the target system, whether it be a PC, console, or
custom-made arcade cabinet. You must also ask if the game’s programming team is up
to creating the required technology. Technological feasibility may end up limiting the
scope of your gameplay. Even worse, will the engine team’s existing technology work
or will they need to scrap it and start from scratch? Is there enough budget and time to
trash it and start over? If you find that you need to adapt your gameplay to match the
engine, you really are not starting out with gameplay as the origin of your idea, but
instead with technology, as I will discuss next. If you are starting out with a gaming
engine that must be used, it is in your best interest to not fight that technology with
incompatible gameplay. Instead you should try to conceive of gameplay that is well
suited to that engine.
The type of gameplay your game will employ similarly limits what type of story can
be told. An RPG can tell a much more complex and involved story than an action/adven-
ture game, and in turn an action/adventure can tell a more substantial story than an
 Chapter 3: Brainstorming a Game Idea 43

arcade shooter. Certain types of stories just will not fit with certain types of gameplay,
such as the Greek mythology in a flight simulator example discussed previously. Simi-
larly, a romantic story might not fit with a strategy game, and a tale about diplomacy
would not fit so well with a fast-action first-person shooter. Since you made the choice
to come up with your gameplay style first, you need to ask yourself what sort of story is
best suited to that gameplay, and try to tell that tale. Sometimes a designer will have
both a story she wants to tell and a type of gameplay she wants to explore, and will
attempt to do both in the same game, even if the two do not go well together. Do not try
to cobble an inappropriate story, either in terms of complexity or subject matter, around
gameplay that is ill-suited to that type of narrative. Save the story for a later date when
you are working on a title with gameplay that will support that story better. And while
your technology is limited by what your team is capable of accomplishing in the time
allotted, the story is limited only by your own ability to tell it. You should pick the story
best suited to your gameplay and go with it.

Starting with Technology

Going into a project with a large portion of the game’s technology already developed is
also a fairly common occurrence. If this is not the development team’s first project
together at a new company, then it is likely that there will be an existing technology
base that the project is supposed to build from. Even if the project is to use a “new”
engine, this often only means an older engine updated, and as a result, the style of game
best suited to the engine will not change significantly. Even if an engine is being written
from scratch for the project, it is likely that the lead programmer and her team are best
equipped to create a certain type of engine, be it indoor or outdoor, real-time or
pre-rendered, 3D or 2D, with a complex physics system for object movement or some-
thing more simple. The programmers may be interested in experimenting with certain
special lighting or rendering effects, and will create an engine that excels at these
objectives. The designer is then presented with this new technology and tasked with
coming up with a game that will exploit the sophisticated technology to full effect.
Other times it is predetermined that the project will be using an engine licensed
from some other source, either from another game developer or a technology-only
company. Though some of these licensed engines are becoming more and more robust
and as a result can allow for a fairly broad number of games to be made with them (Cri-
terion’s RenderWare is certainly a good example of this), many licensed engines are
still developed with one game genre in mind, and no engine is without its fundamental
limitations. Sometimes the project leaders have enough foresight to consider the type
of game they want to make first and then pick an engine well suited to that. Sometimes
the engine licensing deal that seems to deliver the most “bang for the buck” will be the
one chosen. Then, with an engine choice decided, the team is tasked with creating a
game and story that will fit together well using that technology.
Just as starting with a desired sort of gameplay dictates what type of engine should
be created, starting with set technology requires that the game designer consider pri-
marily gameplay that will work with that sort of technology. If the engine is 3D, the
designer will need to create a game that takes place in a 3D world and uses that world to
create interesting 3D gameplay. If the engine is only 2D, a first-person shooter is out of
the question. If the engine has a sophisticated physics system, a game should be
44 Chapter 3: Brainstorming a Game Idea

designed that makes use of the physics for puzzles and player movement. Of course,
the designer does not need to use every piece of technology that a programmer feels
compelled to create, but it is always better to have your gameplay work with the engine
instead of fight against it. Often, when a project is using a licensed game engine, that
technology will have been chosen with a certain type of gameplay in mind. The
designer needs to seriously consider how far she should deviate from that initial tech-
nology, for it is surely going to be easier to make the engine perform tasks for which it
was intended instead of pushing it in directions its programmers never imagined. For
instance, the oft-licensed Quake engine (in all its various incarnations) was created for
handling an indoor, first-person perspective, fast-action game involving a lot of shoot-
ing. Though some teams that have licensed that engine have tried to push it in different
directions, one of the most artistically successful licensees thus far, Valve, retained
much of the standard Quake gameplay that the engine excelled at for their game
Half-Life. Certainly Valve added a lot of their own work to the engine, technology that
was necessary in order to do the type of game they wanted. But at the same time they
did not try to do something foolish such as setting their game primarily outdoors or
using only melee combat, at least not in their first title with the technology. When tech-
nology is handed to a game designer who is told to make a game out of it, it makes the
most sense for the designer to embrace the limitations of that technology and turn
them into strengths in her game.

The designers of
Half-Life smartly used
the indoor first-person
shooter gameplay
established by Quake,
the engine licensed for
the game’s creation.
Pictured here: Quake II.

The technology can also limit what sort of story can be told. Without a sophisti-
cated language parser, it is going to be difficult to tell a story in which players need to
communicate with characters by typing in questions. Without an engine that can handle
outdoor environments reasonably well, it is going to be difficult to make a game about
mountain climbing. Without robust artificial intelligence, it is going to be hard to make a
good game about diplomacy. Without streaming technology that allows for the playback
of large sounds, it will be hard to have huge amounts of dialog and hence hard to have
characters whose dialects are important to the story. Without the ability to have large
 Chapter 3: Brainstorming a Game Idea 45

numbers of moving units on the screen at once, it will be impossible to tell a story
where the player must participate in epic, massive battles between armies. The game
designer needs to consider how the story line will be communicated to the player
through the engine that she must use. Trying to tell a story with an inadequate engine is
just as likely to compromise the game as tying a particular story to inappropriate
gameplay. Again using the example of Half-Life mentioned above, if the team at Valve
had tried to set their game in Death Valley and involve the player battling gangs of
twenty giant insects at once, the Quake engine would have ground to a halt on the
machines of the day and the game would have been miserable to play. In the Death Val-
ley scenario, Valve might have been telling the story they wanted, but no one would
have cared since the game would have been miserably slow and looked horrendous. For
the greater good of the game, the story and the technology must be compatible with
each other.
Something else to always keep in mind when considering how your technology will
limit your gameplay and story is how you can creatively work around your limitations.
For example, if you are trying to do a game about massive battles with thousands of
individual units, do all of the units need to be represented in 3D, or will a 2D representa-
tion work just as well? Or, perhaps you never need to have all of the units in the world at
the same time; you could tell the story of such a gigantic conflict from the viewpoint of a
single soldier in that battle, with between-mission updates that show the larger picture.
For an example out of my own past, my ill-fated game Gunslinger tried to capture the
myths and storytelling of the Old West. We had a technology that was perfectly suited to
rendering sprawling outdoor environments in 3D, so it was a natural fit to the game.
But if we had only had a 2D engine, there is nothing to say we could not still have done a
tale about the legends of the Old West in a 2D game with a god’s-eye view of the pro-
ceedings. As a game designer, it is possible to get stuck in a rut of how a game “needs to
be done” and forget the potential for alternate implementations that may be a better fit
for your technology.

Starting with Story

Finally, it is certainly possible that the brainstorming for your game may start with a
setting you want to employ, a story you want to tell, or a set of characters you want to
explore. This is probably a less common starting point than technology or gameplay.
Indeed, since many games have no story whatsoever, the very concept of a game start-
ing with a story may seem strange. At the same time, it is not unheard of for a game
designer to think of a story she wants to explore, and only then start exploring what
sort of technology and gameplay will be best suited to telling that story. Frequently, a
particular setting may inspire a game designer, such as the adventurous world of Errol
Flynn or the dark and gritty crime world of Sin City. A designer may not care too much
about the specifics of the plot, but may have a strong desire to work in a world filled with
swashbucklers or grim private detectives. For my purposes in this chapter, I consider
these inspirational settings to fall under the definition of starting with story.
Any good game designer who thinks up a story or a setting will have a tendency to
think of it in terms of how it would translate into a game, how the player can interact
with that story, and how the story may unfold in different ways depending on the
player’s actions in the game-world. Indeed, not all stories will translate very well into
46 Chapter 3: Brainstorming a Game Idea

games, and thinking of gameplay possibilities early can help you rule out settings that
simply will not work out in games. So a designer may not be thinking solely of the story
but also of the gameplay. But the story can be the jumping-off point, the central vision
from which all other aspects of the game are determined.
Of course the type of story to be told will have a dramatic effect on the type of
gameplay the project will need to have. If the designer wants to tell the story of a group
of friends battling their way through a fantastic world full of hostile creatures, a
first-person shooter with teammates might be appropriate. Any sort of story that
involves the player talking to a large range of characters and going on “quests” for
those characters might be addressed with more RPG-style mechanics. Telling the story
of the Battle of Waterloo could be perfectly addressed in a project with wargame-style
strategic play, with the gameplay adjusted in order to best bring out the aspects of
Waterloo with which the designer is primarily concerned. Does the designer want the
player to have a general’s-eye view of the game? In that case, gameplay that allows for
the tracking of tactics and logistics should be used. Or does the designer want to tell the
story more from the view of the soldiers who had to fight that battle? Then gameplay
that would allow the player to track and manipulate her troops unit by unit would be
appropriate. If conversations with non-player characters (NPCs) are an important part
of communicating the story, the designer will need to design game mechanics that allow
for such conversations, using typed-in sentences, branching dialog choices, or what-
ever will work best. The designer needs to find gameplay that will allow the player to
experience the most important elements of whatever story she is trying to tell.
Of course, the technology will have to match up with the story as well, primarily in
order to support the gameplay the designer decides is best suited to telling that story. If
conversations are an important part of communicating the story, the programming
team will need to be able to develop a conversation system. If world exploration and dis-
covery are a big part of telling the story, perhaps a 3D engine is best suited to the
gameplay — one that allows the players to look anywhere they want with the game
camera. The designer may find that specifically scripted events are important to com-
municating aspects of the tale; players must be able to observe unique events that
transpire at specific times in different parts of the world. In this case, the programmers
will need to give the level designers the ability to implement these scenes. The tech-
nology is the medium of communication to the players, and thereby the story is directly
limited by what the technology is capable of telling.

Maniac Mansion was the

first of the story-centered
adventure games from
LucasArts to use the
SCUMM system.
 Chapter 3: Brainstorming a Game Idea 47

Good examples of story-centered or at least story-dominant game design are some

of the adventure games created by Infocom and LucasArts. All of the adventure games
from these companies used very standardized play mechanics and technology. The
game designers worked with the company’s proprietary adventure game creation tech-
nology, either the Infocom text-adventure authoring tool or LucasArts’ SCUMM
system. By the time the game designer came onto the project, her process of creation
could start more naturally with creating a story she wanted to tell. Certainly the story
had to be one that was well suited to the adventure game format and that could be
implemented using the existing tool set. And of course, there was a lot of game design
still to do, in terms of coming up with what the player’s actions and choices would be in
that specific story, what puzzles would be encountered, and so forth. Both Infocom’s
and LucasArts’ tools were general purpose enough to allow the designer to create a
wide range of games, with a good amount of variation in terms of storytelling possibili-
ties, even though the core mechanics had to consist of a typing-centered text adventure
in the case of Infocom and a point-and-click graphical adventure for LucasArts. Thus
the game designers’ primary driving motivation in the game’s creation could be telling
a story, with the designing of game mechanics and technology development much less
of a concern. Just as film directors are limited by what they can shoot with a camera and
then project on a 2D screen of a certain size at 24 frames per second, the adventure
game designers at Infocom and LucasArts were limited by the mechanics of the adven-
ture game authoring system they were using. Since the mechanics of the medium were
firmly established well before both the film director and the adventure game designer
began their project, they were freed up to think beyond the nuts and bolts of the audi-
ence or user’s gaming experience.

Working with Limitations

Experienced game designers already understand the limitations placed on the creation
of games by the technology, gameplay, and story. When they take part in brainstorming
sessions, these game designers have a good gut sense of how making certain choices
about the game in question will limit its creation further down the road. For each deci-
sion that is made about the game, many doors are closed. When enough decisions about
the nature of the game have been made, it may be that there is only one type of game
that can possibly accomplish all that the designers want. The stage for making major
decisions is over, and now all that lies ahead are the thousands of smaller implementa-
tion issues.
For four of the games I have completed — Odyssey: The Legend of Nemesis, Damage
Incorporated, Centipede 3D, and The Suffering — I began development from different
starting points. Coincidentally, one game started with story, another with technology,
the third with gameplay, and the final with a combination of setting and gameplay.
Throughout each game’s development I made every effort to remember where the
game was coming from and what it was hoping to accomplish. The origins and objec-
tives limited everything else about the experience, resulting in only one acceptable
game that achieved the goals I had set.
48 Chapter 3: Brainstorming a Game Idea

Odyssey: The Legend of Nemesis

Odyssey started with a story. I actually inherited this project at a point where a signifi-
cant part of the 2D technology and RPG game mechanics were in place. Some story
existed but it was by no means complete, and I was not terribly excited by it. As my first
game project that was actually likely to be published, I immediately set to work rewrit-
ing the story into something in which I was personally invested. For years I had been
wanting to get into game development in order to tell interactive, non-linear stories,
and so I immediately set to writing just such a story, wherein the player would be pre-
sented with moral choices beyond just “to kill or not to kill.” I wanted to create a game
in which the choices the players made would actually change the outcome of the story
in a meaningful way. So I charged blindly forward, with the story as my only concern.

Levels in Odyssey: The

Legend of Nemesis were
designed around the
game’s story.

Fortunately, the technology and game mechanics that were in place by and large
supported this story I wanted to tell. Where they did not, I changed the game mechan-
ics as necessary. When NPC AI had to function in a certain way to support the story, I
made the AI work that way. When forced conversations became required, where an
NPC could walk up to the player and initiate a conversation with her instead of the
other way around, I implemented the appropriate game mechanic. The levels were
designed with no other goal than to support the story. Since I was primarily interested
in the story, the game’s levels were not designed with exciting battles in mind and com-
bat situations in the game were not as compelling as they could have been. The
constant conflict with strange, marauding creatures was something people expected in
an RPG and so it remained in, but I made combat such that it was very much secondary
to exploring the story. This ended up turning the game into almost more of an adven-
ture than an RPG, but that was fine with me, since it was what supported the story best.
Looking at it today, I can see that Odyssey has many flaws. But I do not think that
these problems arose because it was a game whose development started with a story.
This may be a rare way to begin game development, but it can still be a viable starting
point. If I had possessed a better sense of game design at the time, I could have taken
 Chapter 3: Brainstorming a Game Idea 49

efforts to make the rest of the game as interesting as the story was, while never under-
mining or diminishing the impact of the game’s epic tale.

Damage Incorporated
In the case of Damage Incorporated, the publisher, MacSoft, had obtained the license to
a sophisticated (at the time) technology that they wanted to use for a game. It was the
engine Bungie Software had created for use in Marathon and Marathon 2, two games I
enjoy and admire. In particular, Marathon 2 remains one of the best first-person shoot-
ers ever made, easily holding its own against its PC contemporary, Doom. What
Marathon 2 lacked in fast-action battles and the atmosphere of menace that Doom cre-
ated so well, it more than made up for with a compelling and complex story line,
superior level design, and a good (though simple) physics model. Indeed, Bungie’s Halo
built upon Marathon’s many innovations, finally bringing them to a wider audience. As a
result of my having enjoyed the Marathon games so much, I decided to make my game
embrace the technology and gameplay that Marathon had established. I would craft my
game around the technology that had been licensed and use that technology to the
greatest effect I possibly could.

Damage Incorporated
(pictured) had its origins
in the licensed Marathon
technology.

With a starting point of technology, I crafted gameplay and a story that could suc-
ceed using the Marathon technology. Of course, we added features to the gameplay and
engine. The primary addition to the game mechanics was the player’s ability to order
teammates around the game-world, thereby adding a real-time strategy element to the
mix. We added to the engine numerous enhancements that allowed for swinging doors,
moving objects, and other effects necessary to create a game-world that more resem-
bled the real-world. I was still concerned with story in the game, though not to as great
an extent as I had been with Odyssey. Since having conversations with NPCs did not
really fit in with Marathon’s game mechanics, I worked interesting characters into the
game experience through the player’s teammates. These fellow marines would chat
among themselves as the player maneuvered them through the game-world.
50 Chapter 3: Brainstorming a Game Idea

One of the game’s weaknesses was that at the start of the project I did not fully
understand the limitations of the Marathon engine. It was best suited to creating indoor
environments, so outdoor areas ended up looking fake, especially when they were sup-
posed to represent real-life locations on Earth. Modeling the exterior of an alien world
in the engine, as Marathon 2 had done, was one thing, but creating environments that
looked like the woods in Nebraska was another. Around half of the levels in Damage
Incorporated are set outside, and none of these outdoor areas ended up looking very
good. If I had understood the technology better, I could have designed the game to take
place in more indoor environments, thereby better exploiting what the engine did well.
Interestingly, at the same time I was using the Marathon 2 engine to create Dam-
age Incorporated, MacSoft had another team using the same engine to create a game
called Prime Target. The members of that team did not like Marathon 2 as much as I did,
and wanted to create more of a Doom-style shooter, with faster, simpler, more intense
combat. Instead of starting with the technology and running with the type of gameplay
it handled well, they started with a type of gameplay they wanted to achieve and modi-
fied the engine to better support that. As a result, the Prime Target team spent much
more time modifying the engine to suit their needs than we did. On the other hand, they
were wise enough to set their game primarily indoors, an environment much better
suited to the technology. Because of our different decisions in how to use the technol-
ogy, Prime Target became a significantly different game from either Marathon 2 or
Damage Incorporated. Not a better or worse game, merely different. The differences
can be traced back to the origins of the idea for their game, and the way they approached
using a licensed engine.

Centipede 3D
The Centipede 3D project was started when the publisher, Hasbro Interactive,
approached the game’s developer, Leaping Lizard Software, about using their Raider
technology for a new version of Centipede. Hasbro had recently found success with
their modernization of Frogger, and wanted to do the same for Centipede, the rights to
which they had recently purchased. Producers at Hasbro had seen a preview for Raider
in a magazine, and thought it might be well suited to the project. Hasbro had a very defi-
nite idea about the type of gameplay they wanted for Centipede 3D: game mechanics
similar to the classic Centipede except in a 3D world. The team at Leaping Lizard
agreed. At the time, few games were utilizing simple, elegant arcade-style gameplay,
and adapting it to a 3D world would be a unique challenge.
For the development of Centipede 3D, the origin of the game’s development lay in
gameplay. Recreating the feel of the original Centipede was at the forefront of every-
one’s minds throughout the project’s development. When Hasbro set out to find a
company with a technology capable of handling the game, they knew to look for an
engine that could handle larger, more outdoor areas, because those were the type of
locations a modernized Centipede would require. They knew not to go for a Quake-style
technology in order to achieve the gameplay they wanted. Leaping Lizard’s Raider
engine was a good match with the gameplay, but not a perfect one. Much work was
required to modify it to achieve the responsiveness of a classic arcade game. Raider
employed a physics system that was by and large not needed for Centipede 3D, and so
 Chapter 3: Brainstorming a Game Idea 51

The new, 3D version of

Centipede was based on
the classic “bug shooter”
gameplay found in the
original Centipede.

the majority of it was stripped out. Thus the technology was molded to fit the gameplay
desired.
Centipede 3D’s story was the simplest of any of the games I have worked on. In part
this is because one of the traits of a classic arcade game is its lack of any real storytell-
ing. For games like Centipede, Pac-Man, and Space Invaders, setting was enough; all the
games needed was a basic premise through which the gameplay could take place. Fur-
thermore, everyone working on the Centipede 3D project realized that it was the
simple, addictive gameplay that would draw players into Centipede 3D, not the story.
The classic arcade style of gameplay simply did not call for it. The primary effect of the
meager story line was to provide a setup and to affect the look of the game, to explain
why the player is flying around blasting centipedes and mushrooms, and why the
game-worlds change in appearance every few levels. Just as the original Centipede used
the setting of a garden and bugs to justify the game’s gameplay, so did the remake. In
the end, Centipede 3D was all about the gameplay.

The Suffering
My most recent game, The Suffering, had its origins in a combination of setting and
gameplay. The game’s publisher, Midway, suggested to the game’s developer, Surreal
Software, that they wanted an action game, preferably a shooter, set in a horror milieu.
Surreal was excited at the prospect of working in a horror space, but we were not big
fans of the game mechanics that up until then had dominated the genre. Games such as
Resident Evil and Silent Hill, though very good games, relied on scaring the player by
limiting their ability to look around the environment with the camera, by having awk-
ward and unresponsive controls, by strictly limiting the available ammo, and by using
fairly weak central protagonists. This had the effect of distancing players from the
game, forcing them to think about the camera and controls, and making them realize
that they definitely were not playing themselves. In short, these games were not as
immersive as they could have been, and being big first-person shooter fans we knew
that immersion was fundamental to truly frightening someone. Making the game more
52 Chapter 3: Brainstorming a Game Idea

of a shooter got us a more action-oriented experience and increased the game’s poten-
tial for immersion.

The Suffering originated

with the idea of
combining shooter
gameplay with a
distinctly disturbing
horror setting.

So our origins were truly in a combination of gameplay and horror, with both
dependent on the other. It was only through the combination of these two elements that
we were going to differentiate ourselves among the many games that were available for
the PlayStation 2 and Xbox. Certainly, there were many shooters on the market, and
also plenty of horror games, but no game that combined both. Without considering both
setting and gameplay simultaneously from the very beginning, our game design would
not have evolved into a game that accomplished what we wanted.
Though The Suffering was built on existing technology that Surreal had most
recently used for Drakan: The Ancients’ Gates, that engine was significantly stronger at
outdoor environments and thus was ill-suited to the dark and shadowy confined spaces
of a horror game. From the beginning of the game we knew we wanted to include out-
door environments as well in order to add much-needed variety to the game, but we
also knew we would have to rework our technology significantly to pull off our
action/horror ambitions. Thus our technology was significantly reworked to use portals
that allowed us to include complex and detailed indoor spaces in addition to outdoor
ones. Since our primary starting point for the project was gameplay and setting, our
technology was forced to change and adapt.

Embrace Your Limitations

In many ways, developing a game is all about understanding your limitations and then
turning those limitations into advantages. In this chapter I have discussed how the
designer must understand where her game idea is coming from: gameplay, story, or
technology. With this understanding, the designer must recognize how this limits the
other attributes of the game — how a certain gameplay calls for a certain type of story
and technology, how one story requires a specific technology and gameplay, and how
 Chapter 3: Brainstorming a Game Idea 53

technology will lend itself to specific types of games and stories. One designer may con-
sider these requirements to be limitations, while a more positive designer may
consider them to be simply constraints. Indeed, many people do their best work when
operating inside constraints; having limitless options can be quite intimidating and con-
fusing. It is the designer’s job to establish what constraints the project has, find the
perfect parts that fit within those limitations, and finally make all the pieces fit together
in a compelling game.
It is a very rare case indeed for a designer to be able to think of whatever game she
wants and then search out the perfect implementation of that idea. In almost all cases,
the designer is limited by the situation that is presented to her. The limitations may
come in the form of the technology available, the team she has to work with, the budget
available to develop the game, and the amount of time allowed for its creation. Though
the producer is primarily responsible for making sure the game is on time and on bud-
get, the designer must concern herself with all of the limitations she is faced with if she
hopes to create a good game in the final analysis.

Established Technology
Often a designer at a larger company is required to work with whatever technology that
company has. This may be an engine left over from a previous game, or it may be that
the programming team only has experience working in 2D and as a result the only tech-
nology they will be able to viably develop in a reasonable time frame will be 2D. Even if
the designer is fortunate enough to be able to seek out a technology to license for a pro-
ject, that designer will still be limited by the quality of the engines that are available for
licensing and the amount of money she has to spend. Engines are becoming increas-
ingly versatile and affordable, but it will be some time before they can be used for all
game types on all budgets.
If the developer is a lone wolf, working solo as both designer and programmer on a
project, one might think the designer could make whatever she wants. Of course this is
not the case, as the designer will quickly be limited by her own skills as a programmer
and by the amount of work she can actually accomplish by herself. Except in rare cases,
no single programmer is going to be able to create a fully featured 3D technology to
rival what can be built by the large team at Criterion or John Carmack and his id Soft-
ware cohorts. It is simply not possible. Functioning as the sole programmer and
designer on a project has many benefits, but it certainly limits what one will be able to
accomplish.
Even if a programmer is able to create the perfect engine for her game, what if it is
simply too slow? If a large number of fully articulated characters in an outdoor real-time
3D environment are required for your gameplay and the technology is not specifically
built to support this, the frame rate is going to be languid. Throw in some truly sophisti-
cated AI for each of those creatures and your game will slow to 1 FPS, becoming, in
essence, a slide show. If she must make that game, the designer has to wait until the
processing power required is available, which may not be for years to come. Unfortu-
nately, suggesting that a project be put on hold until the technology improves usually
has the direct result of causing the publisher to stop making milestone payments.
Of course, if a designer is truly committed to making a certain game, before giving
up she may need to be more clever in how she implements it. Are there tricks that can
54 Chapter 3: Brainstorming a Game Idea

be employed to make a large group of AI agents look like they are working independ-
ently when really they are using a relatively cheap flocking algorithm? How high-poly
do the environments truly need to be? Or the really big question: does the game truly
need to be 3D at all, or will a 2D implementation be just as good? Resourceful and deter-
mined designers will be able to find clever solutions to what at first seem like
unsolvable problems.

The Case of the Many Mushrooms

When working on Centipede 3D, we were constantly troubled by our frame rate.
Remember, for that game, our primary concern was to achieve gameplay that was in the
spirit of the original arcade classic. But Centipede’s gameplay hinged on the presence of
a lot of mushrooms on the screen at once, with similarly large numbers of other insects,
arachnids, and arthropods flying around the world, threatening to destroy the player’s
little “shooter” ship. Furthermore, the gameplay necessitated a top-down view, which
provided a fairly large viewing area of the game-world so that the player would be able
to see the maneuverings of those deadly creatures. The end result was that there could
be several hundred 24-polygon mushrooms, twelve 40-polygon centipede segments,
and numerous other creatures all on the screen at once. On top of that, Hasbro wanted
Centipede 3D to be a mass-market title, so the product’s minimum system requirement
had been predetermined to be a 133 MHz Pentium with no hardware graphics accelera-
tion. On top of all that, Centipede’s fast-action gameplay required a similarly fast frame
rate to be any fun at all.
While working on the project, we were constantly confronted with the problem of
escalating polygon counts, with artists always attempting to shave a few polygons off of
the much-used mushroom model. At one point, one artist suggested that perhaps if we
could reduce the mushroom to two pyramids sitting on top of each other, we would have
the absolute minimum representation of a mushroom, while using only six or eight
polygons. Indeed, it was suggested, if all of the game’s models went for a minimalist
representation, we could use the polygon limitation to our advantage, creating a unique
game-world filled with objects that looked as if they were created by a cubist. It would
certainly be a unique look for a game, and would fit in quite well with Centipede 3D’s
already somewhat surreal game-world. “Embrace your limitations!” I proclaimed in the
midst of this discussion, not unlike a weary scientist might finally shout, “Eureka!” All
present thought my proclamation to be quite funny, but thinking about it later I decided
it was actually quite true for game development. Unfortunately, we were too far along in
development to convert all of our art to the minimalist implementation we had thought
of, not to mention the potential troubles of trying to sell the publisher on the idea of a
minimalist game.
But in general I still believe that game developers need to embrace their limita-
tions as soon as they discover them. When presented with an engine that must be used
for a project, why go out of your way to design a game that is ill-suited to that technol-
ogy? Your game design may be fabulous and well thought out, but if the technology you
must use is not capable of implementing it well, you will still be left with a bad game in
the end. It is better to shelve an idea that is incompatible with your technology (you can
always come back to it later) and come up with a design better suited to the tools you
have. Once you have identified the limitations that the engine saddles you with, it is
 Chapter 3: Brainstorming a Game Idea 55

best to embrace those limitations instead of fighting them. This is not to suggest that a
designer should always design the simplest game that she can think of or that sophisti-
cated, experimental designs should not be attempted. If a shrewd theater director
knows a given actor is interested in working with her, she will pick the best play to
show off the particular skills of that actor. Similarly, a designer should consider what the
technology lends itself to and use that as the basis for the game she designs and the
story she sets out to tell.

The Time Allotted

Limitations that I have not discussed much in this chapter but which are nonetheless
very important in game development are the budget and schedule with which a
designer may be presented. Though these are primarily the concern and responsibility
of the project’s producer, the game designer needs to know how these factors will limit
the project just as the technology, gameplay, or story may. When choosing the technol-
ogy to be used, the designer must ask herself: can it be completed in the amount of time
scheduled for the project? Can it be completed in time for level implementation and bal-
ancing? Does the suggested design call for the creation of such a large number of
complex levels and heavily scripted behaviors that they cannot be completed in eigh-
teen months by only one designer? Just as the timeline will limit the amount of time
that can be spent on the project, the budget will affect how many people can be working
on the project during that time. It may be that, given double the budget, the game
design could be easily completed in a year and a half, but with only half the budget the
designer will need to scale back the design to come up with something feasible. Again,
if development is running six months late with no end in sight and as a result the pub-
lisher pulls the plug, it does not matter how brilliant your game design may have been
in theory. No one will get to play your game because you failed to fully consider the
logistics of implementing it. And if you fail to allocate enough time for fine-tuning and
balancing the gameplay, your publisher may demand you ship a game you consider
unfinished. What might have been a great game will be a bad one because there was not
enough time to really finish it.
Lone wolf developers have it a bit easier in terms of time constraints and budget-
ary limitations. If a single person is creating all of the art, code, and design for the game,
and is developing the game on her own time without relying on income from its devel-
opment in order to survive, she is much more free to follow wherever her muse takes
her, for as long as she likes. Of course, she is still limited by her own talents, by the
quality of the art she can create, and by the limits of her programming skills, but at least
these are the only limitations. When creating art, there is a lot to be said for not being
beholden to the person writing the checks.
56 Chapter 3: Brainstorming a Game Idea

If You Choose Not to Decide, You

Still Have Made a Choice
So often producers, programmers, artists, and designers fail to consider the limitations
of the game idea they are planning to develop. Whether it springs from notions of
gameplay, suggestions of technology, or thoughts about a story, as soon as a game idea
takes on form it begins limiting what the game can be if it is to be successful. Game
developers need to understand that not every technology will work with every game
design, nor every design with every story, nor even every story with every technology.
Often developers will try to take a bunch of compelling concepts and attempt to
stuff them all into one game. The lead programmer may be interested in developing a
cutting-edge human body physics system. The lead game designer might have wanted
to try a real-time strategy game ever since she played Age of Empires for the first time.
The game’s writer may think there’s entirely too much violence in computer games
and therefore wants to write a tale of romance. If the producer is a fool, she may even be
thrilled that the members of her team are so excited about what they are developing
and that, by combining physics, RTS, and romance, the result will be a breakthrough
game.
Of course anyone with a whit of sense knows this game is doomed to fail. Without a
consistent and unified vision, no game will have a fighting chance. Though each mem-
ber of the team may have a valid case for pursuing her idea, if the ideas do not work
together, at some point the group will need to pick one and go with it. If, at the brain-
storming session, the team decides which idea they want to concentrate on, the team
can work to make the game as a whole as good as possible. Suppose they choose phys-
ics as their most promising strength. Then the designer can mull it over and realize an
RTS is probably not ideal but a circus-themed game could be an inventive use of the
human body physics simulator. It could include launching performers out of cannons,
having acrobats create human pyramids, and allowing players to perform complex tra-
peze stunts. From there, the writer could come up with a love story about two aerialists
whose relationship is tested by the arrival at the circus of a stunning new strong man,
with everything coming to a climax during a complex high-wire act where the safety net
has been removed. This game has a fighting chance of being fun to play because all of
the components are working together. In the end, you do not want your game to consist
only of an excellent technology or a compelling story or a brilliant game design. If none
of these components support each other and you lack a unified vision, your game will be
just as bad as if you were working with a hackneyed story, a thin game design, and an
incomplete technology.
Chapter 4
Game Analysis:
Centipede
Designed by Ed Logg with Donna Bailey
Released in 1981

O ne can think of the classic arcade game as a form of the computer game in the
same way that a silent slapstick comedy is a form of film or the hard-boiled
detective novel is a form of literature. The classic arcade game form fell out
of favor with the commercial gaming companies pretty much as soon as the technology
was available to move beyond it. However, many independent game developers still
work on classic arcade games either for their own amusement or to be released as
freeware or shareware titles. Many of these labors of love are imitations of established
classic arcade games, but many others are interesting experiments in new gameplay.
There remains something uniquely compelling about the form, and the fact that one
does not need to have a sophisticated 3D engine to make a wonderfully entertaining
classic arcade game helps to make the form an appealing one in which to work.

57
58 Chapter 4: Game Analysis: Centipede

It bears mentioning that when I refer to the classic arcade game, I do not mean to
imply that all classic arcade games are classics. Many of them are quite bad. As with any
media, the old arcade games that are remembered and talked about decades after their
release tend to be the best ones, thus creating the false impression of a “golden age.”
The bad arcade games have fallen between the cracks of history. The term “classic
arcade game” refers to the form as a classic one, not to the games themselves, just as
one might refer to “classical music.” Surely the term “arcade game” is not limiting
enough, since this would seem to include every game found in an arcade, including
modern racing, gun, and fighting games, none of which are what I consider to be part of
the form I am concerned with here.
The classic arcade game form had its commercial and creative heyday in the late
1970s through the early 1980s, when machines exhibiting the form lined the arcades.
Looking at the games as a whole, one can come up with a series of traits that they all
shared. Some of these aspects of the form may have been arrived at because of the com-
mercial considerations of the arcades. The thought was to get players to easily
understand a game, so that by the end of their very first game they had a good sense of
how the game worked and what was necessary for success. Second, the players’ game,
even the game of an expert, could not last very long, since any one player had only paid
a quarter, and if the game only earned a single quarter in a half hour, it would not be prof-
itable to operate. The manufacturers of coin-op games wanted average play time to be
2.5 minutes. Players needed to be sucked in to replay the games, to keep plunking in
quarters. As a result, in some ways the arcade games had to be more refined than home
games are today. Once the players have purchased a home game, often for at least a
hundred times the cost of a single arcade game play, the sale is completed. If they are
not completely disgusted with the game they are unlikely to return it. Features such as
scoring and high-score tables only served to increase the arcade game’s addictive
nature and encourage players to keep spending money.
In addition, the technical restrictions of the day limited what the games could do,
and thereby influenced what the game could accomplish in terms of gameplay. Had the
designers had the RAM and processing power to include fully scrolling game-worlds
that were many times the size of the screen, they probably would have. If the games had
been able to replay full-motion video of some sort, perhaps the designers would have
incorporated more story line into the games. But the fact remains that a unique genre of
computer games emerged, and if the commercial and technical limitations shaped the
form, so be it. Just as early films had to work with the limitations of silence and short
running times, computer game designers were limited in what they could create, and
were able to come up with brilliant games nonetheless. Often, a series of strict con-
straints forces artists to focus their creativity in a fashion that leads to better work than
if they could do anything they wanted.
One key ingredient to many classic arcade games was their wild variation in
gameplay styles. Centipede, Missile Command, Pac-Man, and Frogger are as different
from each other as they possibly could be. Many classic arcade games featured varia-
tions on a theme: Centipede, Space Invaders, Galaga, and Tempest all revolved around
the idea of shooting at a descending onslaught of enemies. However, the gameplay vari-
ations these games embraced are far more radical than the tiny amount of variation one
will find in modern games, which are more content to endlessly clone already-proven
 Chapter 4: Game Analysis: Centipede 59

Tempest is one of many

classic arcade games
that is centered on
shooting at enemies
which keep getting
closer. Tempest
is memorable because
of the many unique
twists included.

gaming genres. Despite the wild variety of gameplay that can be found in classic arcade
games, one can still look back on these games as a collective and view them as an artis-
tic movement in the brief history of computer games. By analyzing the form’s shared
traits, modern game designers can learn a lot about how they can make their own
games more compelling experiences for players.

Classic Arcade Game Traits

• Single Screen Play: In a classic arcade game, the bulk of the gameplay takes place
on a single screen, with players maneuvering their game-world surrogate around
that screen, sometimes only in a portion of that screen. This was done, no doubt, in
part because of technological limitations, but it also has very important artistic
ramifications on the game’s design. Players, at any time, are able to see the entire
game-world, and can make their decisions with a full knowledge of the state of that
game-world. Obviously, empowering players with that kind of information
seriously impacts the gameplay. Many of the games in the classic arcade game form
would include more than one screen’s worth of gameplay by switching play-fields
or modifying existing ones to create additional “levels.” Examples of this include
Joust, Pac-Man, and Mario Bros. Though these games may have included more
than a single screen in the entire game, at any one time the game-world still
consisted of just that one screen.
• Infinite Play: Players can play the game forever. There is no ending to the game,
and hence no winning it either. This was done in part to allow players to challenge
themselves, to see how long they could play on a single quarter. Players can never
say, “I beat Asteroids,” and hence players are always able to keep playing, to keep
putting in quarters. At the same time, having an unwinnable game makes every
game a defeat for players. Every game ends with the player’s death, and hence is a
kind of tragedy. Having an unwinnable game also necessitates making a game that
continuously becomes more challenging, hence a game design with a continuous,
infinite ramping up of difficulty. With the advent of the home market, game
60 Chapter 4: Game Analysis: Centipede

publishers no longer wanted players to play a single game forever. Instead they
want players to finish the games they have and buy more. This is one reason why it
is now rare to see a game with infinite play.
• Multiple Lives: Typically, classic arcade games allow players a finite number of
tries, or a number of “lives,” before their game is over. Perhaps derived from
pinball games, which for decades had provided players with three or five balls,
multiple lives allowed novice players a chance to learn the game’s mechanics
before the game was over. Given adequate chances to try to figure out how the
game works, players are more likely to want to play again if they improved from
one life to the next. The ability to earn extra lives provides another reward
incentive for players and also sets up a game where dying once is not necessarily
the end of the game, which in turn encourages players to take risks they might not
otherwise.
• Scoring/High Scores: Almost all classic arcade games included a scoring feature
through which players would accumulate points for accomplishing different
objectives in the game. For example, in Centipede, players get 1 point for
destroying a mushroom, 10 points for a centipede segment, 100 points for a
centipede head, and 1000 points for a scorpion. Another classic arcade game
component with origins in the world of pinball, the score allows players to ascertain
how well they did at the game, since winning the game is impossible. The
high-score table was introduced in order to allow players to enter their initials next
to their score, which would then be ranked in a table of scores so players could have
a point of comparison to see just how good they really were. The game would
remember the table as long as it stayed plugged in, with some games, such as
Centipede, even remembering the high-score list or some portion of it once
unplugged. The high-score table enabled the classic arcade games to exploit one of
the key motivations for playing games — “bragging rights.” Players could point out
their name in the high-score table to their friends as a way of proving their mettle.
Friends could compete with each other (almost all of the games included
two-player modes, where players switch off playing) to see who could get the
higher score.
• Easy-to-Learn, Simple Gameplay: Classic arcade games were easy for players to
learn, impossible (or at least very difficult) to master. Players could walk up to a
game of Centipede, plunk in their quarter, and by their third life have a good idea of
how the game functioned and how they might play better. Why players died was
always completely apparent to them. There were typically no “special moves”
involving large combinations of buttons that players had to learn through trial and
error. There were few games with tricky concepts such as “health” or “shields” or
“power-ups.” Again, commercial considerations were probably a factor in making
these games simple to learn. At the time of their initial introduction, there was no
established market of computer game players and there were few arcades. The
games wound up in pizza parlors and bars, where any regular person might walk up
to one and try it out. These novice players might be scared away if the game were
too complex or baffling. Of course, simple does not always mean “limited” or “bad”
gameplay; it can also mean “elegant” and “refined.”
 Chapter 4: Game Analysis: Centipede 61

• No Story: Classic arcade games almost universally eschewed the notion of trying
to “tell a story” of any sort, just as many modern arcade games continue to do. The
games always had a setting players could easily recognize and relate to, many of
them revolving around science fiction themes, though others dabbled in war,
fantasy, and sports, among others. Many, such as Pac-Man and Q*Bert, created
their own, unique settings, keeping up with the rampant creativity found in their
gameplay. The classic arcade game designers did not feel required to flesh out their
game-worlds, to concoct explanations for why players were shooting at a given
target or eating a certain type of dot, and the games did not suffer for it.

Even though the action

in Sinistar did not take
place only on one
screen, it is still
considered to be an
example of the classic
arcade game form.

Of course, some games broke some of the above rules of the form, yet they can still
be considered classic arcade games. For example, Sinistar and Defender both included
scrolling game-worlds for players to travel through, with players unable to see all
aspects of the game-world at any one time. Indeed, on first inspection, Battlezone seems
entirely the odd man out among early classic arcade games. Yet, if one looks at the traits
above, one will discover that it featured infinite play, multiple lives, scoring, was easy to
learn, and had almost no story. All three of these games included mechanics which, by
and large, were adherent to the classic arcade game form. Thus we can still group them
with games like Space Invaders and Asteroids, which follow all the rules laid out above.
Centipede, one of the defining games of the form, follows all of the characteristics of
the classic arcade game listed above. Though not a very complex game by today’s stan-
dards, the marvel of Centipede is how all of the different gameplay elements work
together to create a uniquely challenging game. It is easy enough to make a game ramp
up in difficulty by adding more and more enemies, but Centipede naturally increases the
challenge by the interplay of its few elements so that the game organically becomes
more difficult over time. Nothing in Centipede is out of place, nothing is inconsistent,
nothing is unbalanced. To analyze Centipede is to attempt to understand how to design
the perfect game.
62 Chapter 4: Game Analysis: Centipede

Input
One of the great advantages to working on a game for the arcades is that the designer
has complete control over the type of device players will use to control the game. On
the PC, the designer can only count on players having a keyboard and a mouse, and on a
console, the designer must work with the standard controller that comes with that par-
ticular console. The arcade designer (budget constraints notwithstanding) is able to
pick the best type of control for the game and provide players with that control system.
The designer can then create the game around those controls, precisely balancing the
game to work perfectly with that input method. Centipede does this expertly, providing
players with an extremely precise analog control device in the form of a trackball. This
is ideally suited to moving the player’s shooter ship around on the bottom of the screen.
Players can move the ship quickly or slowly, whatever the situation calls for. For many
fans of Centipede, the excellent controller is one of the first things they remember about
the game.

The player’s shooter in

Centipede is more
mobile than in Space
Invaders, since it can
move up and down in
addition to moving
sideways. Pictured
here: Centipede.

The shooter is extremely responsive to the players’ manipulation of the trackball,

with players being able to easily and intuitively understand the relationship between
their manipulation of the trackball and the shooter’s movement. Centipede was no doubt
inspired by other classic arcade games, such as Space Invaders, which feature the play-
ers’ game-world surrogate locked at the bottom of the screen, allowed only to move left
or right and shoot. Centipede takes that idiom one step further: players are still trapped
at the bottom of the screen, but the shooter can move within a six-row vertical space.
This allows players to avoid enemies that might be on the bottom row. At the same
time, the shooter can still only shoot forward, so enemies that get behind the ship can-
not be destroyed. Aside from the trackball, the only other control players have is a
button for firing the shooter’s laser-type weapon. The game allows an infinitely fast
rate of fire, but only one shot can be on the screen at a time, which means players have
to think beyond just holding down the fire button constantly. If players move the
shooter directly below a mushroom, they can hold down the fire button and quickly
 Chapter 4: Game Analysis: Centipede 63

shoot the mushroom four times, thus destroying it. But at the top of the screen, where
players cannot maneuver the ship, destroying a mushroom takes much longer, since
players must wait for each shot to hit the mushroom before another shot can be fired.
Shooting the ever-approaching enemies creates a similar situation. If their last shot is
in the midst of traveling to a faraway target, players will be unable to shoot again in
order to take out a dive-bombing enemy. Thus, when the enemies are far away, they are
less of a threat, but players have trouble killing them. As the critters get closer, players
can kill the bugs more easily, but their chance of dying goes up. This keeps the game
perfectly balanced, and requires players to plan their shots carefully, a design element
that adds more depth to the game’s mechanics.

Interconnectedness
One of the great strengths of Centipede is how well all the different elements of the
gameplay fit together. Consider the different enemy insects that try to kill players. The
centipede winds its way down from the top of the screen to the player’s area at the bot-
tom, moving horizontally. The centipede appears as either a lone twelve-segment
centipede or as a shorter centipede accompanied by a number of single heads. At the
start of a wave, the number of centipede segments on the screen always totals twelve.
Next is the spider, which moves in a diagonal, bouncing pattern across the bottom of the
screen, passing in and out of the player’s area. Then comes the flea, which plummets
vertically, straight down. There is nothing terribly sophisticated about any of the move-
ment patterns of these insects. Indeed, the flea and the centipede, once they have
appeared in the play-field, follow a completely predictable pattern as they approach the
player’s area. The spider has a more random nature to its zigzagging movement, but
even it does nothing to actually pursue players. Therefore, once players have played
the game just a few times, they have a completely reliable set of expectations about
how these enemies will attack them. Fighting any one of these creatures by itself would
provide very little challenge for players. Yet, when they function together they combine
to create uniquely challenging situations for players. With any one of these adversaries
missing, the game’s challenge would be significantly diminished, if not removed
altogether.
Each of the insects in the game also has a unique relationship to the mushrooms,
which fill the game’s play-field. The primary reason for the existence of the mushrooms
is to speed up the centipede’s progress to the bottom of the screen. Every time a centi-
pede bumps into a mushroom, it turns down to the next row below, as if it had run into
the edge of the play-field. Thus, once the screen becomes packed with mushrooms, the
centipede will get to the bottom of the play-field extremely quickly. Once at the bottom
of the screen, the centipede moves back and forth inside the player’s area, posing a
great danger to players. So, it behooves players to do everything they can to destroy the
mushrooms on the play-field, even though the mushrooms themselves do not pose a
direct threat. Further complicating matters, every time players shoot a segment of the
centipede it leaves a mushroom where it died. Thus, wiping out a twelve-segment cen-
tipede leaves a big cluster of mushrooms with which players must contend.
As the flea falls to the bottom of the play-field, it leaves a trail of new mushrooms
behind itself, and the only way for players to stop it is to kill it. The flea only comes on to
64 Chapter 4: Game Analysis: Centipede

In Centipede, fleas drop

toward the bottom of the
screen, leaving
mushrooms behind
them, while spiders eat
whatever mushrooms
block their movement.

the play-field if less than a certain number of mushrooms are on the bottom half of the
screen. This way, if players destroy all the mushrooms closest to them, the flea comes
out immediately to lay down more. The spider, the creature that poses the biggest
threat to players, has the side effect that it eats mushrooms. This then presents players
with a quandary: shoot and kill the spider or just try to avoid it so it can take out more
mushrooms? Finally, the scorpion, a creature that travels horizontally across the top
half of the screen and hence can never collide with and kill players, poisons the mush-
rooms it passes under. These poisoned mushrooms affect the centipede differently
when it bumps into them. Instead of just turning down to the next row, the centipede
will move vertically straight down to the bottom of the screen. So when a centipede hits
a poisoned mushroom, the centipede becomes a much more grave threat than it was
before. Once a scorpion has passed by, players must now expend effort trying to shoot
all the poisoned mushrooms at the top of the screen or be prepared to blast the centi-
pedes as they plummet vertically straight toward them.
So we can see that each of the creatures in the game has a special, unique relation-
ship to the mushrooms. It is the interplay of these relationships that creates the
challenge for players. The more mushrooms the flea drops, the more mushrooms the
scorpion has to poison. The spider may take out mushrooms along the bottom of the
screen, getting them out of the way of players, but it may eat so many that the flea starts
coming out again. If players kill the centipede too close to the top of the screen, it will
leave a clump of mushrooms that are difficult to destroy at such a distance and that will
cause future centipedes to reach the bottom of the screen at a greater speed. However,
if players wait until the centipede is at the bottom of the screen, the centipede is more
likely to kill them. With the mushrooms almost functioning as puzzle pieces, Centipede
becomes something of a hybrid between an arcade shooter and a real-time puzzle game.
Indeed, some players were able to develop special strategies that would work to stop
the flea from ever coming out, thus making the centipede get to the bottom of the
screen less quickly and allowing players to survive much longer. It is the interplay of
each of the adversaries with these mushrooms and with each other that creates a
unique challenge for players.
 Chapter 4: Game Analysis: Centipede 65

Escalating Tension
A big part of the success of Centipede is how it escalates tension over the length of the
game. The game actually creates peaks and valleys in which tension escalates to an
apex and, with the killing of the last centipede segment, relaxes for a moment as the
game switches over to the next wave. One small way in which the game escalates
tension over a few seconds is through the flea, which is the only enemy in the game
players must shoot twice. When it is shot just once, its speed increases dramatically
and players must quickly shoot it again to avoid being hit. For that brief speed burst,
tension escalates. In terms of the centipede itself, the game escalates the tension by
splitting the centipede each time it is shot. If players shoot the middle segment of an
eleven-segment centipede, it will split into two five-segment centipedes that head in
opposite directions. Sure, the players have decreased the total number of segments on
the screen by one, but now they have two adversaries to worry about at once. As a
result, skilled players will end up going for the head or tail of the centipede to avoid
splitting it.
Most of the game’s escalating tension over the course of a wave is derived from the
centipede’s approach toward the bottom of the screen and players’ often frantic efforts
to kill it before it gets there. Once a centipede head reaches the bottom of the screen, a
special centipede head generator is activated, which spits out additional centipede
heads into the player’s area. If players are unable to kill the centipede before it reaches
the bottom of the screen, which has already increased tension by its very approach, that
tension is further escalated by the arrival of these extra heads. And those extra heads
keep arriving until players have managed to kill all of the remaining centipede seg-
ments on the screen. The rate at which those extra heads come out increases over
time, such that if players takes their time in killing them, additional centipedes will
arrive all the faster, making players still more frantic.
Once players kill the last segment, the game goes to its next wave, and the centi-
pede is regenerated from the top of the screen. This provides a crucial reprieve for
players, a moment of rest. Players will feel a great rush at having finally defeated the
centipede, especially if the extra centipede head generator had been activated. In addi-
tion, the newly generated centipede at first appears easier to kill, since it is generated
so far from the player’s area.
Over the course of the entire game, the mushrooms inevitably become more and
more packed on the play-field. Once there are more mushrooms toward the bottom of
the screen, players feel lucky if they can just clear all of the mushrooms in the lower half
of the play-field. They have no chance of destroying the mushrooms toward the top,
since the lower mushrooms block their shots. Similarly, if the scorpion has left any poi-
soned mushrooms toward the top of the screen, players have no chance whatsoever of
destroying them, and as a result the centipede dive-bombs the bottom of the screen on
every single wave. Far into a game, the top of the play-field becomes a solid wall of
mushrooms. As the mushrooms become more and more dense, the centipede gets to
the bottom of the screen faster. When the centipede can get to the bottom of the screen
extremely quickly, the game is that much faster paced, and players are that much more
panicked about destroying the centipede before it reaches the bottom of the screen.
This increased mushroom density has the effect of escalating tension not just within a
66 Chapter 4: Game Analysis: Centipede

Over the course of a

game of Centipede,
mushrooms become
more and more tightly
packed on the play-field.

wave as the extra centipede head generator did, but also from wave to wave, since the
mushrooms never go away unless players shoot them.
Centipede also balances its monsters to become harder and harder as players’
scores increase. And since the score can never decrease, the tension escalates over the
course of the game. Most obvious is the spider, whose speed approximately doubles
once the score reaches 5000 (1000 if the game’s operator has set the game to “hard”).
The spider also maneuvers in a smaller and smaller area of the bottom of the screen as
the score gets really high, eventually moving only one row out of the player’s six-row
area. With the spider thus constrained, it is both more likely to hit players and less
likely for players to be able to shoot it. Recall that the flea drops from the top of the
screen based on the quantity of mushrooms in the bottom half of the screen. When play-
ers start the game, if there are less than five mushrooms in that area, the flea will come
down, dropping more as it does so. As the score increases, however, so does the quan-
tity of mushrooms needed to prevent the flea’s appearance. Now players must leave
more and more mushrooms in that space to prevent the flea from coming out and clut-
tering the top of the screen with mushrooms.
At the start of each wave, the game always generates a total of twelve centipede
segments and heads at the top of the screen. This means that if a twelve-segment centi-
pede appears at the top of the screen, it will be the only centipede. If a seven-segment
centipede appears, then five other centipede heads will appear as well, thus totaling the
magic number of twelve. The more centipedes that appear, the more challenging it is
for players to shoot them all, and the more likely one will sneak to the bottom of the
screen. The game starts by releasing a single twelve-segment centipede. In the next
wave, a slow eleven-segment centipede appears along with one head. In the following
wave, a fast eleven-segment and one head combination arrive. Then a slow
ten-segment and two heads appear. With each wave there are a greater number of indi-
vidual centipedes for players to keep track of and a greater escalation of tension. The
game cycles around once twelve individual heads are spawned, and then becomes
harder by only spawning fast centipedes.
 Chapter 4: Game Analysis: Centipede 67

The player’s death also provides a brief respite from the tension. When the player’s
ship is destroyed, the wave starts over and hence the centipede returns to the top of the
screen. Before this, however, all of the mushrooms on the screen are reset. This means
that all the partially destroyed mushrooms are returned to their undamaged state and
all of the mushrooms poisoned by the scorpion are returned to their unpoisoned state.
Many waves into the game, the increased mushroom density makes shooting poisoned
mushrooms all but impossible, and with those poisoned mushrooms in place, players
are bombarded by centipedes hurtling toward them in every single wave. Thus, players
are almost relieved when their shooter is destroyed and all those poisoned mushrooms
are removed from the top of the screen. This causes the game to be much more relaxed,
at least for a time.

Centipede’s frantic
gameplay keeps the
player tense most of
the time, though it
provides some breaks in
the action during which
the player can relax.

Centipede is marvelous at creating and maintaining a tense situation for players,

while still providing brief “breathing periods” within the action. Designers of modern
games, who are always concerned with ramping up difficulty for players, could learn
much by analyzing how Centipede keeps players constantly on their toes without ever
unfairly overwhelming them.

One Person, One Game

Many may scoff at Centipede almost twenty-five years after its creation. There is no
question that it is a less technically astounding accomplishment than more modern
works, and those who do not examine it closely are likely to dismiss it as more of a light
diversion instead of a serious game. But what Centipede does, it does with such facility,
featuring game mechanics so precisely and perfectly balanced and gameplay so
uniquely compelling, that it is truly a marvel of computer game design. One must
remember that Centipede was created in the days of the one-person-one-game system,
when the development team for a game consisted primarily of one person, in this case
Ed Logg. By having one person in total control of a project, where a single talented
68 Chapter 4: Game Analysis: Centipede

individual fully understands every last nuance of the game, the final product is much
more likely to come out with a clearness of vision and brilliance of execution. Of course,
one person can create a terrible game just as easily as a large team, but one must won-
der if the lone wolf developer does not have a better chance at creating the perfect
game.
Chapter 5
Focus

“Feel the flow… To become one with the flow is to realize purpose.”
— Warrel Dane

D eveloping a game for two years with a team of twenty people typically more
resembles war than the creation of art. Many would say that a decent amount
of conflict can lead to great art, especially in collaborative forms such as mod-
ern commercial computer games. A stronger game may arise from the ashes of team
members arguing over the best way to implement some aspect of gameplay. If the game
merely becomes unfocused as a result of these squabbles, then a good game is not likely
to emerge. Over the course of the many battles you must fight, skirmishes you must
endure, and defeats you must overcome in the course of a game’s development, with
conflicts potentially arising with other team members or from within yourself, it is far
too easy to lose track of just why you were creating the game in the first place. Is it pos-
sible that at one point the game you are working on captivated your imagination? Was
there some vision you had for why this game would be fun, compelling, and unique? Is it
possible that at one point you actually liked computer games at all?

69
70 Chapter 5: Focus

Sometimes in the middle of a project it is easy to get sidetracked — sidetracked by

technological obstacles that are thrown in your path, sidetracked by altercations
between team members, or sidetracked when your publisher tells you features A, B,
and C simply have to be changed. It is at these junctures where you come to doubt that
your game will ever be fun, or whether it will even be completed. These periods of
doubt are the ones that separate the good game designers from those who are merely
passable. Good game designers will be able to overcome these difficulties and stay on
track by remembering their focus.
The technique I explore in this chapter is certainly not one that all game designers
use, but I think it is one that all game designers could benefit from. Many designers may
use the technique but not realize it or have a different name for it. Others may have
entirely different methods for assuring their game comes together as a fun, consistent
whole. You cannot expect to go up to any game designer and say, “What’s your focus for
your current project?” and expect them to produce an answer in line with the method I
explore in this chapter. But if you start being rigorous in maintaining focus in your pro-
jects, I think you will see very positive results in the final quality of your games.

Establishing Focus
A game’s focus is the designer’s idea of what is most important about a game. In this
chapter I encourage designers to write their focus down in a short paragraph, since
putting it down in writing can often clarify and solidify a designer’s thoughts. Further-
more, having it in physical form opens it up for discussion with the development team.
However, it is the idea of the focus that is of paramount importance. In a way, a game’s
focus is similar to a corporation’s “mission statement,” assuming such mission state-
ments are actually meaningful and used to guide all of a corporation’s decisions.
As a game designer you should start concerning yourself with your game’s focus
from the very beginning of the project. When the project is in its infancy, before work
has started on the design document and the project exists primarily as an idea in your
head, you should ask yourself a series of questions about the game you are envisioning:
• What is it about this game that is most compelling?
• What is this game trying to accomplish?
• What type of experience will the player have?
• What sort of emotions is the game trying to evoke in the player?
• What should the player take away from the game?
• How is this game unique? What differentiates it from other games?
• What sort of control will the player have over the game-world?
By going over these questions, you should be able to determine the core nature of
the game you are planning to create. If you have trouble answering these questions,
now is the time to think about the game until the answers to these questions become
obvious. Now — before there is anyone else working on the project, before “burn rate”
is being spent and driving up the game’s budget, before the marketing department
starts trying to influence the game’s content and direction — is the time to focus. Only
 Chapter 5: Focus 71

by firmly establishing the vision of the game early on will you have any chance of seeing
it carried out.
If you do not have too much trouble divining answers to these questions, you may
have written an entire page or more delineating the game’s points of differentiation.
But a page is too much. The focus that we are striving for needs to be succinct — a few
sentences, a short paragraph at the most. Some would go so far as to say it should be a
single sentence, though I personally prefer something slightly longer than that. What is
most important is that it be something you can quickly read to your colleagues without
their eyes glazing over. You should take whatever notes you have in answer to these
questions and whittle them down until they are short enough to fill only a few sen-
tences, a mid-sized paragraph. Keep only your most compelling ideas. You do not need
to list every single feature of the game, or even everything it does differently from
other games. Keep only what is most important to your vision of the game, only those
points which, if you took them away, would irreparably weaken the game.
You do not need to include the fictional setting of your game if that is not inherent
to the actual focus of the project. It may not matter if your game has a fantasy, science
fiction, or 1920s crime fiction setting if what is really at the heart of your game is
exploring the relationships between characters in a stressful situation or the subtleties
of siege warfare. If the setting is not vital to what you want to do with the game, leave it
out. Of course, your primary motivation for working on a project may be hopelessly
intertwined with the setting. If you actually started with a setting you wanted to
explore in a game, such as costumed superheroes in small-town America, and your
vision of the gameplay formed around the idea of these characters in a certain environ-
ment, then you will want to include it in your focus. The focus is exclusively for the
concepts that are most central to the game you are hoping to develop. All that should
remain in your focus are the elements without which the game would no longer exist.
Your focus should be something that grabs you viscerally, stirs your creative juices,
and makes you feel absolutely exhilarated. If it is not something that thrills you, even at
this early stage, it is going to be hard for you to muster enthusiasm when your deadlines
are slipping, your budget is skyrocketing, you still have three levels to create, and your
lead artist just left for another company. Chris Crawford touched on the idea of a game’s
focus in his book, The Art of Computer Game Design, as he was discussing what he called
a game’s goal: “This is your opportunity to express yourself; choose a goal in which you
believe, a goal that expresses your sense of aesthetic, your world view… It matters not
what your goal is, so long as it is congruent with your own interests, beliefs, and pas-
sions.” If you do not believe in your game, it is not going to be the best game you can
make.
Even if you are working under the constraints of a license, a domineering pub-
lisher, or a prima donna lead programmer, make your own goals for the project. If the
game you have been assigned to work on is not one in which you are interested, figure
out some way to transform it into something you can get excited about. No situation is
so bad that, given enough time, you cannot make something out of it that you find per-
sonally compelling. You want your focus to be something you will fight for intensely
until the game finally ships.
Much of this chapter is written in a fashion that implies that you are in charge of
your project, at least from a game design standpoint. Of course, this may not be the
72 Chapter 5: Focus

case. You may be one of several designers on the project. You may even be one of seven
and you were just hired last week, so you are at the bottom of the seniority ladder. This
does not excuse you from determining what your game’s focus is and doing everything
you can to keep the game on track. Hopefully the lead designer has already determined
what the project’s goals are and should have included this information in the introduc-
tion to the design document. If you cannot find it there, you may wish to go talk to your
lead. Ask him what the project is really trying to do, not in a confrontational way, but just
so you get a good idea of where the project is going, and how your contribution to the
game can be properly aligned with that direction.
If it turns out the design lead does not really have a focus in mind, it may be held by
another member of the team, say a lead programmer or lead artist. However, if despite
your best research efforts, the project seems to be goal-less, you may need to take mat-
ters into your own hands. Try to figure out where the project seems to be heading, and
start talking with people about it. Chat with the other designers, artists, programmers,
and producers. Try to talk to them about what the game is all about, and try to get
everyone to agree. Meetings may be a good place to do this; when everyone is present,
any conflicts between different perspectives or personalities on the team can be found
and addressed. You do not need to be in a lead position in order to keep your project on
track. As a designer in any capacity on a project, it is ultimately your responsibility that
the game always has a clear direction and that a fun game emerges at the end of the
tunnel.

An Example: Winter Carnival Whirlwind

Let us suppose you have a vision for a game involving a winter carnival. What is it about
winter carnivals that excites you? Is it the ice sculptures? Taking a block of ice and con-
verting it into a snow-themed mammal? No? Perhaps what is really exciting to you is
going to winter festivals, with their combination of frozen art, ice skating, snowman
competitions, skiing, snowball fights, and championship ice fishing. Indeed, you always
wondered how they kept those festivals going so long even with the threat of warmer
weather constantly looming on the horizon. Since the winter carnival component
seems fairly central to your idea, you will need to include it in the focus. So your focus
can start with a sentence that explains this: “The player’s experience will revolve
around running an ice carnival, with the player responsible for maintaining as long a
season as possible, despite uncooperative weather.”
Now, what is it about running an ice carnival that grabs you? You see a relentless
battle against the elements, racing against spring to keep your operation running as
long as possible. Something about harnessing the cold is uniquely compelling to you.
Perhaps you enjoy the feeling of running around in the snow, not quite being in control
of how fast you can stop and the slapstick moments that may result. This particular
appeal of the elements may be unique to you and may not be the most commercially
promising new game to come along, but at this stage you’re trying to capture your per-
sonal thoughts about the game. Do not self-censor your ideas until it is absolutely
necessary. So include a few more sentences that serve to illustrate the feeling of your
game: “The game will capture the excitement of playing in the snow, including the sim-
ple physics that make that fun, through a central character who must move around a
somewhat hazardous environment and keep multiple displays, rides, and other
 Chapter 5: Focus 73

attractions operating smoothly. The player’s main source of conflict will be the weather
itself. Throughout, the tone will be light and whimsical.”
What else about your winter festival game is a central part of your vision? Do you
want to realistically simulate the injuries one might sustain by falling down on ice? Is
going to the hospital and waiting for your surrogate to heal an intrinsic part of your
game? Not really; it seems that though that feature could be added to the game, it is not
absolutely essential to your vision. Indeed, such a level of “simulation” might detract
from the light and whimsical tone. Will the game be in 3D or in 2D? Well, actually, the
game could work in either. To be commercially viable in today’s marketplace it will
probably need to be 3D, but that is not central to your vision. In your focus, do not
include aspects of your game that are more about getting the project funded and pub-
lished than making the game you want to make. You can worry about commercial
considerations later. As I stated before, right now you are concerned with your vision,
and if you start compromising your vision before absolutely necessary, at the end of the
day you are going to be blind. So you do not need to specify 2D or 3D. Indeed, maybe
you have everything you need for the focus. Remember, the focus should not be very
long.
Now is the time to put your two sentences together in a paragraph and name the
game. Though it may seem premature, naming the game is actually a good idea at this
point. You want other members of your team, the marketing department, and the busi-
ness people to start liking your game as soon as possible, and having a name they can
refer to it by is fairly important to that process. Can they really discuss it seriously as
“this game idea Richard had”? Giving your game a name makes it real instead of just an
idea, as ridiculous as that may seem.
Try your very best to come up with a name that you like and that could end up being
the final name for the game. Often whatever name is given to a game early on will end
up sticking with the game forever. It is especially important not to pick a purposefully
idiotic name, since those are the kind most likely to stick. For instance, let us say you
name it Egyptian Rumba. As your team keeps referring to the game as Egyptian Rumba,
they will start to associate your cool game with this idiotic title, and your idiotic title
will start to sound pretty good through association. Someone working on the art team
may start giving the characters an Egyptian color scheme. Team members who are
working on the story might spend a lot of time trying to figure out why the game should
be named Egyptian Rumba, and will develop an especially clever story line around the
name. If you later try to change the name they will be sad and possibly angry that their
story no longer makes any sense. Even the “suits” will start to like your Egyptian
Rumba title. They will think of how they can capture both the adventuring archeologist
market and the Cuban dance market. And soon, if you even remember, you will say it is
time to change the game’s title, and everyone will say, “Why? We like Egyptian Rumba!
It’s a great name!” And then you will really be stuck. Then the public will see it on the
shelves and will think, “What the heck is that? It sounds stupid,” and quickly pass on to
games with more reasonable titles.
So you finally choose Winter Carnival Whirlwind. Perhaps a more exciting name
will come up later, but you can live with this one. Now, assemble the pieces of your
focus into one paragraph, and try to write it cleanly and succinctly. Refer to your game
in the present tense, as though your game already exists. “Winter Carnival Whirlwind
74 Chapter 5: Focus

is an exhilarating…” instead of “Winter Carnival Whirlwind will be an exhilarating…”

This lends your game a more concrete existence in the minds of those who read your
focus. It is not just a game that may come about at some point in the future; it already is
a game, if only in your head. Something else to avoid is using generic descriptions that
do not actually provide the reader with any useful information. For instance, “Winter
Carnival Whirlwind is a high-quality, fun game that…” Of course it is supposed to be
fun. Does anyone set out to create a boring or low-quality game? Edit out any sections
of your focus that do not communicate important information about your game.
Putting together the parts of your focus, you will end up with the following:
Winter Carnival Whirlwind is a fast and furious character action and
theme park management hybrid game. The player’s experience revolves
around running an ice carnival, with the player responsible for maintain-
ing as long a season as possible, despite uncooperative weather. The game
captures the excitement of playing in the snow, including the simple phys-
ics that make that fun, through a central character who must navigate a
somewhat hazardous environment and keep multiple systems operating
smoothly. The player's main source of conflict is the weather itself. Winter
Carnival Whirlwind has a light and whimsical tone throughout.

The Function of the Focus

Try to keep your focus from referring to other games. You want the focus to describe
the essence of your game, and if your focus is, “Voltarr is like Tomb Raider, but set on
the whimsical planet Dongo and featuring many intense laser gunfights,” it is hard for
someone looking at your focus to understand immediately what parts of Tomb Raider
you are hoping to emulate. Take a look at Tomb Raider itself and determine what you
think its focus may have been. Then take that focus, remove whatever parts are not
necessary for your game, and add in whatever new ideas your game will incorporate.
Chances are your idea of what was compelling about Tomb Raider will be different from

Your game may be

similar to another game
such as Tomb Raider, but
in your focus you want to
describe the game on its
own terms and avoid
making comparisons to
other games.
 Chapter 5: Focus 75

someone else’s understanding. When members of your team read, “It’s like Tomb
Raider,” they are probably reminded of some different aspect of that game’s gameplay
than you are. That’s assuming that they have played Tomb Raider at all. Since the focus
is designed to guide your team members as well as yourself, it needs to communicate
the same ideas to everyone who reads it. Even if the focus is primarily for your own use,
the process of analyzing Tomb Raider to determine what about it you want to replicate
will help you to better understand your own game. You need to have a properly stream-
lined focus that can stand on its own, without demanding that the person who is reading
the focus understand any other particular games. All the relevant information that is
important to your focus must be contained within the focus itself, without outside refer-
ences. Often when designers set out to create “It’s like Game X but with…” games,
they tend to lose sight of what made the game they are imitating so compelling in the
first place. Then they proceed to make their own game top-heavy with tacked-on fea-
tures that exist only to hide the fact their game is just like Game X. Removing
references to other games from your focus will help expose the true nature of the pro-
ject you are undertaking. If you add sufficient description revealing what it is about
another game that you are trying to capture in your new design, it may be OK to leave in
the reference to that original game since it can provide a helpful starting point for read-
ers. This is a matter of individual preference when writing your focus, and I personally
prefer to leave out other game references of any kind if at all possible.
Establishing a focus for your project does not need to limit the scope of your game,
and is not intended to do so. Your game can still be a massively complex game with an
epic sweep. In fact, if appropriate, this complexity and depth should probably be men-
tioned in your focus, but you should still be able to describe the game in a few sentences
in order to succinctly communicate what is most important about your undertaking.
Your game can even include multiple styles of gameplay within the same game. Sup-
pose your goal is to simulate the life of a pirate. You might want to include an
exploration mode for navigating the seas, a tactical mode for engaging another ship in
battle, a sword-fighting mode for fighting an enemy captain one-on-one, and even a
trading mode for selling off booty. (Indeed, Sid Meier already made this game; it is
called Pirates!) But having this multiple game structure does not mean that the focus
could not still consist of, “This game recreates the many different facets of a pirate’s life
through numerous different campaign modes, all designed to evoke the spirit of being a
cutthroat. The player is able to explore the nature of being an outlaw, including the eco-
nomic and physical risks involved.” If your game is to have multiple separate modes,
your focus should apply to all of the different sub-games within your project.
If you are working on a project solo or with a small team, you may think it unneces-
sary to actually write down your focus. After all, if you can just explain it to everyone
who needs to know, what’s the sense in writing it down? I would argue that writing it
down is key to truly coming to grips with the nature of the game you are planning to
develop. There is a world of difference between an idea that is kicking around in your
head and one that is written down on paper in front of you. When it is on paper you can
look at it and make sure that what is typed is really the core of your idea, and that those
sentences represent everything that is most important to you about the project. Unlike
when you describe the project to someone, on paper you cannot say, “Oh, yeah, and
there’s this part, and this other aspect over here, and I really mean this when I say
76 Chapter 5: Focus

that.” If it is not down on the paper, it is not part of the game’s focus. Someone who
reads the focus on paper should be able to understand your vision without further
explanation. I find that writing the focus down really helps to clarify and solidify what
the game is attempting to achieve.

Though I did not know it

at the time of the
game’s development,
Odyssey’s focus was
centered on telling a
specific story.

When I worked on my first game, Odyssey, I had no grand plan to have a focus. Nor
did I sit down and purposefully think it out. On the other hand, I recall the primary goal
revolving around a story. It was the story of a mad scientist-type character, a powerful
sorcerer who performed experiments on hapless humanoid creatures. These were not
biological experiments, but rather social ones — experiments where he would see how
these humans would treat each other when placed in certain circumstances. Really, he
was exploring the evil side of all sentient creatures. So Odyssey’s focus was to explore
the mean and vicious ways different groups of people can treat each other in certain sit-
uations and to set up scenarios where the players witnessed this first-hand and would
have a chance to make a real change in their lives. Non-linearity and multiple solutions
were also at the forefront of my mind, so I set out to make sure players would be able to
pursue different tactics to solve the problems they were presented with, with no solu-
tion being designated as the “right” one. And so I had my focus. Without really thinking
of it in terms of a focus or vision, I had determined what I wanted to do with the game,
and I was able to stick with that for the duration of the project. Since I was basically
developing the project solo, I did not have to communicate this focus to anyone else,
and if I had needed to I doubt that I could have without considerable reflection. Though I
knew in my head what I wanted in the game, at the time I could not define my goals in
terms someone else could understand. Now, looking back, I can come up with the
following:
In Odyssey, the player explores a rich story line about the evil nature of
mankind, and sees under what circumstances groups will treat each other
in morally reprehensible ways. This is a simple RPG/adventure game.
Though sword-and-sorcery combat will be involved, it never overtakes the
 Chapter 5: Focus 77

story line. The story line allows for multiple solutions and non-linearity
whenever possible, with the player able to effect real change among the
NPCs he encounters in the game.

Maintaining Focus
Once you have a focus down on paper and can read it over and say with confidence,
“Yes, certainly, that’s what I’m going for,” it is time to share it with the other members
of your team. It is important that you get everyone on your team to “sign on” to your
focus. You want them to acknowledge that, yes, this is the direction the team is taking,
and to agree that they see a compelling game coming out of it in the end. If no one on
your team thinks your focus is very captivating, and despite your best efforts to cam-
paign for it no one can get excited about it, you can come to one of two conclusions.
First, perhaps your game idea is not all that good. Hard as this may be to admit, it could
be that your focus statement and possibly the game it describes are simply not original
or enticing. If the idea in your head is still exciting to you, maybe you did not capture the
correct focus properly on paper. You should go back and try to figure out what about the
game excites you but did not come across in your focus.
If you persist in thinking your game is compelling and that your focus properly
reflects why, it may be that people on your team are not excited by it because they were
not involved in creating it. When working in a team environment, it is important to
include people in early brainstorming sessions so that they can feel that they contrib-
uted to the birth of the idea. Even if not everyone’s ideas end up being used, if you
honestly listen to people and use not only your own ideas but the best ideas regardless
of their source, you will end up with a happier team that respects your leadership. In the
end, all projects can benefit from a strong central vision that is maintained by a single
person, but that does not mean you need to lock yourself into a room to be “brilliant” all
by yourself. It is often said that the best lead designers on large projects act primarily as
filters, taking in ideas from all sources and molding them to fit into a single, unified
vision. It may be that the focus you have come up with is quite strong and will produce a
great game, but selling people on it will be trickier if they feel like they were needlessly
excluded from its creation.
It may also be the case that the team assembled is simply the wrong one to develop
the game you have come up with. Not every team can develop every type of game. A
team that has been making sports games for years, likes working on sports games, and
knows how to make a sports game fun is probably not the best team to enlist to create
your nineteenth-century economics simulation. If you have the option of finding a new
team for your game, you probably should. If not, you may need to come up with an idea
that most of your team is going to find compelling. It is important that everyone on your
team sees the value in your focused idea. Because of the collaborative nature of mod-
ern, high-budget computer games, it is virtually impossible to create a good game if you
do not have the majority of your team excited to be working on it.
If you are working on a project largely by yourself with others contributing signifi-
cantly less to the game than you, you may not need to sell your focus at all. Indeed,
games created by lone wolf designer/programmer/artists can be among the most
focused of computer games. Since one person is creating the vast majority of the
78 Chapter 5: Focus

game’s content, he is able to exert absolute control over every nuance. Solo game
development is typically not something at which one can earn a living these days, but I
know of a few who manage it. Of course, the fact that a game was created largely by one
individual does not assure that the game is going to be focused. If that individual is scat-
terbrained and unfocused himself, chances are good the game will not be very focused
either. Even if he is a more sane, organized person, if he does not keep track of his
game’s focus over the course of the project, his game may end up being just as
unfocused as the most uncoordinated, over-budgeted, fifty-developer game.
If you are working as a designer on a game with a team, it is essential to make sure
the other people on your project, whether artists, programmers, or producers, under-
stand the nature of the game’s focus. Without a strong focus to guide their actions,
programmers and artists may have a misunderstanding of what the game is supposed to
accomplish, and may be thinking of some other type of game as they work on yours.
Through no fault of their own, their work may deviate from what needs to happen for
your game to become a reality, and you will be forced to say, “No, that doesn’t fit, redo
it.” If the team has a focus to follow, a focus they have signed on to, then they are far less
likely to create work that is inappropriate for your game. Having a strong focus does not
get you out of keeping a watchful eye on the artists’ and programmers’ work, of course,
but it will save you the trouble of having to redirect them too frequently.

Fleshing Out the Focus

Once the team is enthusiastic about the project, has signed on to the focus, and has a
clear understanding of what the game is supposed to be, you can proceed to more fully
flesh out your idea through a complete design document. You may even want to make
your focus the beginning of your document, as a sort of summary of the nature of the
game that people can read quickly. (The nature and creation of design documents is
more fully explored in Chapter 19, “The Design Document.”) The design document
should take the game suggested by your focus and expand on it, detailing how the goals
in your focus will be accomplished by gameplay and precisely how that gameplay will
function. You will also be sketching out the flow of the game, what the game-world will
be like, and what sort of entities the player will encounter. Of course, while you are
working on the design document, there will be countless points at which you have to
struggle to come up with the correct solution to a given problem. Should the control
system use method A or method B? In what sort of environments will the player be
interacting? What sort of challenges do the enemies present? A properly designed
focus will allow you to refer back to it to answer many of the questions you encounter
during the design process. As these elements of the game are fleshed out, you should
continually refer back to your focus to see if the additions you are making match with
that focus. Through the focus, you can carefully consider if you are adding gameplay
that takes the game in a new direction. It is important to identify which additions to
your game cause it to deviate from the focus, and then to change or eliminate those
erroneous elements.
You want to avoid having your game become too bloated with features, components
that may be “cool” in some way but that do not support the game’s main focus or that
distract the player’s attentions. Using your focus as a tool, you can prevent this overex-
pansion by cutting away the chaff in your game design to leave only the core gameplay
 Chapter 5: Focus 79

for which you were striving. Many of the ideas you or members of your team have may
be fine concepts, but if they do not fit the game you are currently working on, they are
not worth exploring or implementing. Do not throw these incompatible ideas away,
however. Write them down in your notebook for the next time you are working on a
game design. If they are good ideas, there is probably some game with which they will
work well. If they are very good ideas, you may even want to design an entire game
around them. But for the current project, by referring back to your focus you should be
able to determine whether these extra, cool features are helping or hurting your game
as a whole.
Once the design document is finished and other elements of preproduction are
completed, full production can start on your game. Your team of programmers, artists,
and other personnel will begin attempting to implement what you have set out to
accomplish in your design document. As the project proceeds, there will be countless
times where questions arise. Your design document will not cover everything needed
to actually make the game playable; it cannot possibly. Questions will come up about
how to implement a feature, in addition to new ideas about how to improve the game.
For each of these, again, you should refer back to your focus to clarify your team’s direc-
tion. Is the implementation that is being suggested going to keep the game on track
with the focus or will it distract from the main thrust of the game? Is the distraction
going to be too much of a diversion? Using your focus statement wisely throughout the
course of the project will keep the game on the right course, and will result in an end
product that is better because of it. Players will know the difference between a game
that is properly focused and one that is not, even if they do not communicate their feel-
ings in so many words. They will play and enjoy a focused game and will quickly cast
aside one that is unfocused.

Changing Focus
Of course, either while working on your design document or when the game is in full
production, it may become apparent that the goals of your game need to change. This
can happen for a variety of reasons. You may come to see shortcomings or failings in
your original focus. Through the act of creating your game, you may come to recognize
a more compelling experience that the game can provide that is outside the scope of
your original focus. Depending on where you are in the project’s development, you may
want to change your focus. This is particularly painless to do when you are still in the
preproduction phase and the design document is not yet complete. In fact, you should
expect your focus to change several times, if not on a daily basis, while you are working
on the design document. There is nothing like trying to write down all the important
information about your game to expose holes and failings in your original concept.
Even beyond the design document, when you are working on your game’s first
level you may begin to see weaknesses in your design, holes you had not anticipated
when you were just working with an idea of the gameplay in your head instead of a play-
able game on the screen in front of you. At this point making changes to the focus is still
not catastrophically damaging to your schedule and will not involve redoing much work.
Better to fix problems in the game and your focus now than to be stuck with them for
the rest of the project and end up with an inferior game.
80 Chapter 5: Focus

When changing the focus, you should take the same care as you did when you ini-
tially came up with it. Make sure the focus fully represents your new vision for the
project. Of course, if your focus changes radically, you will need to tell the team about
the change and make sure they all agree with it. Remember, the team needs to be
behind the project in order for it to succeed, and if you change the focus in such a way
that the team is no longer interested in working on the project, you need to rethink that
change or rethink your team.
For whatever reason or in whatever way you may change your focus, it is important
to examine what parts of the game may already exist and see how far they diverge from
your new focus. Look over the design document and realign it to your new goals. Con-
sider whatever game mechanics may be in place and see if they are sufficient to carry
the new focus. Look over whatever levels may exist (hopefully not too many have been
created at this point) and see if they fit with the new focus. Whether it is in documenta-
tion, code, level design, or art, anything that does not fit will need to be reworked so
that the new focus is properly supported.
If too many assets need to be reworked, or if it is too close to the ship date to
change them, or if there is not enough funding available to get them changed, you may
need to rethink changing your direction. Is it really necessary? Often, after you have
been working on a project for a long time, you may want to change your game just to
keep it interesting to yourself. What seemed fun to you a year ago may seem dull now,
not because it fundamentally is not fun but because you have been buried in the project
too long. Avoid changing things just because you are tired of them, since your players,
seeing it for the first time, will think it is fantastic and throwing out all the good work of
your team would be a tragedy.
However, even late in the project you may find out that your game truly is not what
you had hoped, and a refocus is necessary to fix it. At this point you need to move into a
damage control mode. Can you make the change in direction less drastic while still
solving the problems, such that the old assets can still be used? The worst decision you
can make is to create whatever new assets the game needs following a new focus, while
the old assets still follow the inferior focus you had embraced previously. Instead of
focusing the game, your two focuses will end up creating a game with a split personality,
one that is entirely unfocused. Try your very hardest to come up with a refocusing plan
for your project that will not put you over budget or schedule, if these are pressing con-
cerns (as they almost always are). Realizing your project is not as good as it could be,
but lacking the time or money to fix it properly is a tough position to be in. Finding the
best solution in such difficult situations can be extremely challenging and frustrating.
When I worked on Centipede 3D, we ended up changing our focus near the begin-
ning of the project. This resulted in some amount of work needing to be redone, but it
also led to a significantly stronger game in the end. Centipede 3D was something of a
special case since it was a remake of a classic and much-loved game, the original Atari
Centipede, created by Ed Logg. When doing a remake or a sequel, it makes sense to take
a look at the original game you are working from, and get a clear understanding, for
yourself, of what its focus was. This is necessary so you will have a good idea of what
exactly you are remaking. Of course I was not present when Logg was making the origi-
nal Centipede in 1979 and 1980, but I can try to guess what his focus might have been:
 Chapter 5: Focus 81

Centipede is a fast-action shooting game involving a variety of adversar-

ies that the player must kill in order to avoid being killed by them. The ene-
mies move in completely predictable, predetermined patterns, but the
combination of the movement of these creatures and other objects in the
game-world creates a challenging experience for the player. The player can
attempt to change the game-world to make the adversaries’ movements less
threatening, and the player can see the entire game-world at once. The
game continues until the player dies a specific number of times, with
points accumulating to represent how well the player did in that particular
game; there is no winning or finishing Centipede.
That focus is probably too long and too detailed to be a proper game focus, but it is hard
for me to read Ed Logg’s mind to know what his core concerns were when making Cen-
tipede. So I have included all of the crucial parts of the game I can find. Of course, the
focus he used may bear no relationship at all to the one above, if he used a focus at all.

The focus of the 3D

version of Centipede was
to create a game that
captured the arcade
game-play of the
original Centipede in a
three-dimensional,
level-based
environment.

When development of Centipede 3D initially got under way, the idea was to take
only the most basic characters of Centipede — the player’s shooter ship, the centipedes,
spiders, fleas, and mushrooms — and have them interact in a 3D world. The decision to
move the game to 3D was already a foregone conclusion when we started working on
the project. It was a choice whose appropriateness was certainly debatable given the
fundamental mechanics of the original. Indeed, from conception through the earliest
versions of the game, not much attention was paid to the game mechanics and behav-
iors of the original. The elements from the original Centipede were being used more for
aesthetics than anything else. When our initial game prototype turned out not to be
very fun, we decided to try to emulate more of the original game’s gameplay in the new
3D version, wherever possible imitating and updating whatever the 1981 Centipede did
in a 3D, level-based world. As we started pursuing our new focus, we found that the
more we emulated the classic, the more fun the new game became. Though it was not
written down at the time, you could say our focus was along the lines of the following:
82 Chapter 5: Focus

Centipede 3D is a remake of the arcade game Centipede, and attempts to

take what that original game did well and transplant it to a 3D environ-
ment. The original Centipede featured fast-action shooting combat in
waves, with the player’s deft maneuvering of the ship being the key to suc-
cess, and with enemies that moved in completely predictable patterns.
Instead of being on one level for the entire game as Centipede was, Centi-
pede 3D takes the player through a progression of levels. The new game
also embraces certain gameplay norms of modern console games, such as
replayable levels, bonus objectives, and obstacle navigation. The action
and combat portions of Centipede 3D, however, will be extremely reminis-
cent of the original game, employing identical AI wherever possible, and
thus retaining the gameplay feel of the original.
With our new focus, the game assets we had developed thus far were readdressed, and
a number of levels had to be discarded, while others were significantly reworked. A
small amount of coding that had been done had to be modified, but fortunately no
change in the artwork was necessary. All told, our refocus resulted in some loss of
work. However, in the end this lost work was worth it because the final Centipede 3D
had a consistent, focused style of gameplay. And as a direct result, it was fun to play.
It is important to note that our focus for Centipede 3D was not a standalone focus as
I advocated earlier in this chapter. The focus for Centipede 3D refers to another game,
the original Centipede, and thereby does not stand completely on its own. Of course,
Centipede 3D is a remake, and as such it makes sense to refer to the game the project
follows. For either a remake or a sequel, the game you are making has a direct relation
to the other game you refer to in the focus, and a large part of whether the game is
deemed a success or not will rest on how well it follows up its predecessor. As such,
throughout the game’s development, the team members should be asking themselves
how their work relates to the original game, and whether what they are trying to
accomplish in terms of gameplay is a logical and worthy successor. Since this is such a
central concern, it belongs in the focus. In working on a sequel or a remake, your entire
team should have played the original game through, and hence can be expected to
understand it reasonably well. Note, however, that the focus for Centipede 3D includes a
brief description of the primary appeal of the original Centipede, so that the focus can
stand by itself better than if the central concerns of the classic game were assumed. If
the focus must refer to another game, it is important to make sure everyone involved
with the project understands the focus of that other game as well.

Sub-Focuses
It may be advantageous to take the focus technique to another level by including
sub-focuses. Though not absolutely necessary, this will allow you to start to flesh out
your game idea while keeping track of your overall focus. A sub-focus is distinct from
the main focus, and should be designated as such when presented alongside the main
focus. You can see a sub-focus as a concept that supports your main focus, and one that
will help your game attain that central focus. A sub-focus alone cannot be used to design
a game. It serves primarily to support your main goal, to break apart other objectives
your game will strive for in an attempt to accomplish the central focus.
 Chapter 5: Focus 83

For an example of using sub-focuses, I will return to the Winter Carnival Whirl-
wind example. As you may remember, you had come up with a focus for a game that
puts players in charge of a winter carnival. Now that you have the central focus for Win-
ter Carnival Whirlwind squared away, you can consider what other goals the game may
have. What other aspects of the game should the development team focus on to assure
that our gameplay vision is implemented in the best way possible?
Now might be a time to explore what type of player you are thinking will want to
play your game. Are you appealing more to the hard-core gaming crowd, or to people
who maybe do not play computer games quite so often? This will have a direct effect on
many aspects of the game, including what level of simulation will need to be created
(the hard-core gamers will demand a more involved and complex gameplay experi-
ence), as well as the control system the game will use (hard-core gamers can put up
with a more obtuse and convoluted control scheme if that provides a deeper play expe-
rience in the end, while more casual gamers will need something they can pick up
quickly).
Perhaps it has long been your desire to make a game that all of your non-gamer
friends could enjoy. Thus you decide you want to go for the more casual gaming crowd.
This means you can create a sub-focus explaining what you will do to skew the game
toward this audience: “Winter Carnival Whirlwind appeals to more casual gamers.” It
makes sense to explain just what you mean by making the game appeal to casual
gamers. Probably the biggest issue is control; you want Winter Carnival Whirlwind to
allow people to get in and play the game quickly, without confusing them with a lot of
keys to remember to control the main character. Your focus could read: “The game pro-
vides the simplest control scheme possible, with a player needing to use a small
number of easily remembered keys to successfully play the game. Novice players can
figure out how to play the game without reading the manual or playing the tutorial,
though a training mission will be provided.” Note that you do not actually want to go
into what the controls are at this point. Save that for the design document. Here you are
just working on your goals for the game, not so much the specifics of how they will be
implemented. You may also want to say something about the game’s difficulty level. If
you are aiming at casual gamers, you are probably going to want to make the game eas-
ier than it would be if it were aimed more at the hard-core market. You may want to
specify that the game will play at various difficulty levels: “Winter Carnival Whirlwind
is of a relatively low overall difficulty, with the player able to specify difficulty levels in
the game. Even marginally skilled, poor players will be able to play the game to comple-
tion on the easiest difficulty level, given enough attempts.”
It might make sense to talk about what type of engine and graphics your game will
have in one of the sub-focuses. We discussed previously whether the game should be
2D or 3D, but decided that aspect was not central to our vision of the game. Therefore it
was left out of the primary focus. It may, however, fit well as a sub-focus, something that
will help further define how the game’s development will carry out the initial vision.
Now might be a good time to explain the visual style of the game as best you can, to give
your art team an idea of what direction they should pursue, as well as your program-
ming team what sort of technology your game will need to support. Furthermore, you
may want to consider our previous sub-focus here. It states that this game is supposed
to appeal to the casual gaming audience, and that the game is supposed to be fairly easy
84 Chapter 5: Focus

to play. Thus you will want your statements about the game’s graphics to support this if
appropriate. “Winter Carnival Whirlwind features a visually lush, high-contrast envi-
ronment. Despite being set in a somewhat monochromatic snow and ice environment,
specular effects will be used to clearly differentiate different types of ice. The player
character along with the patrons of the winter carnival will be brightly colored in their
cold weather gear in order to set them off from the environment and make them easier
to see.” You may decide you want to pursue a 3D engine technology that handles phys-
ics well, since that can best help capture the out-of-control nature of running around in
snow and ice, and since the nature of the marketplace demands a 3D game. As part of
the 3D engine, perhaps a variable-zoom third-person view is the one that will work best
to allow the player to control their harried carnival manager while keeping an eye on all
the attractions. So your focus statement could include: “The game uses a 3D engine
that allows for the player to easily zoom in and out on the micro or macro events taking
place at the winter carnival, with the technology capable of rendering the entire carni-
val at once when necessary.”
Of course, there could be numerous other sub-focuses for Winter Carnival Whirl-
wind, covering everything from gameplay mechanics to what sort of story line the
game will have, to how long an average game should last. Always try to avoid putting in
too much detail, however. That is for the design document. Here you are merely setting
the project’s direction, not actually implementing it. But for the purposes of our exam-
ple, we have enough sub-focuses now, leaving us with a focus and sub-focuses that look
like this:
Winter Carnival Whirlwind is a fast and furious character action and theme
park management hybrid game. The player’s experience revolves around run-
ning an ice carnival, with the player responsible for maintaining as long a sea-
son as possible, despite uncooperative weather. The game captures the excitement
of playing in the snow, including the simple physics that make that fun, through a
central character who must navigate a somewhat hazardous environment and
keep multiple systems operating smoothly. The player’s main source of conflict is
the weather itself. Winter Carnival Whirlwind has a light and whimsical tone
throughout.
Audience
Winter Carnival Whirlwind appeals to more casual gamers. The game
provides the simplest control scheme possible, with a player needing to use
a small number of easily remembered keys to successfully play the game.
Novice players can figure out how to play the game without reading the
manual or playing the tutorial, though a training mission will be provided.
Winter Carnival Whirlwind is of a relatively low overall difficulty, with the
player able to specify difficulty levels in the game. Even marginally skilled,
poor players will be able to play the game to completion on the easiest diffi-
culty level, given enough attempts.
Visuals
Winter Carnival Whirlwind features a visually lush, high-contrast envi-
ronment. Despite being set in a somewhat monochromatic snow and ice
environment, specular effects will be used to clearly differentiate different
 Chapter 5: Focus 85

types of ice. The player character along with the patrons of the winter carni-
val will be brightly colored in their cold weather gear in order to set them off
from the environment. The game uses a 3D engine that allows for the
player to easily zoom in and out on the micro or macro events taking place
at the winter carnival, with the technology capable of rendering the entire
carnival at once when necessary.
Notice how the sub-focuses are set off by separate headings from the primary focus.
This way, readers of the focus can easily see the primary and most important focus and
how the sub-focuses go into detail about specific parts of the game.
As you are working on your sub-focuses, it is important to always make sure that
they jibe with your primary focus, as well as any other sub-focuses you may have. For
instance, it makes sense that the Visuals sub-focus talks about the game providing a
game-world that is simple to understand visually, since the Audience sub-focus talks
about making the game easy to pick up and get into. If you are already contradicting
yourself in the writing of your focus you are going to have a very hard time writing a
whole design document that makes any sense at all. Keeping all the components of your
focuses supporting each other should not be a problem, however, since properly writ-
ten focuses should be short, concise, and easy to understand.

Using Focus
It is important to realize that your focus statement is not a marketing tool. It is not cre-
ated to sell your game to the executives. It is not written with the hope of printing it on
the back of the box or showing it to the people in charge of purchasing for large retail-
ers. It is first and foremost written as a development tool for your team. Writing a
statement that clearly establishes the goals of your game will be hard enough without
also trying to craft something that will work for the marketing folks. Nevertheless, you
may be able to take your focus and change it into something to get your marketing
department excited about your game. If generating a significant number of sales is one
of the items on your agenda (let us presume it is not your primary motivation for work-
ing in games, for surely there are more profitable careers to pursue), then having the
marketing people get excited about your game when they try to sell it is almost as
important as having the programmers excited during the game’s development. Mar-
keting people will try to sell games they believe in and that they think are cool
concepts, and a modified and adapted version of your focus statement can serve to
quickly explain to them what is so thrilling about your idea. Of course, marketing peo-
ple also love comparative descriptions, such as, “The game’s basically Bejeweled meets
Max Payne.” Thus, you may want to come up with some direct comparisons that place
your game within the context of known popular games, games that the marketing spe-
cialists already know how to sell. Of course, you can use the content of your focus to
back up such superficial comparisons and to make the marketing folk understand why
your game is unique and will appeal to gamers. With this knowledge in hand, hopefully
they can make an ad campaign that is an appropriate representation of your game and
not something that you will be embarrassed by when you see it in the magazines.
86 Chapter 5: Focus

Regardless of what other applications you may find for it, always remember that
you wrote down your focus in order to help your game’s development. Many game
designers do not have a focus when they are working on a game, and it shows. Some
fear it because they do not want to become “locked” into any one idea. Such trepidation
is unfounded since you have the freedom to change your focus whenever you want.
Indeed, without writing it down, you may not even realize that a change of course is
warranted. Of course, it is possible to make a good game without really having any idea
of what your game is all about. It is also possible to win the lottery. When your liveli-
hood, reputation, and the quality of your final game are on the line, however, you want
something more than luck to determine if your game works or not. Using a focus is one
tool that will help you to create a solid, entertaining, and compelling game.
Chapter 6
Interview: Ed Logg

Asteroids, Centipede, and Gauntlet. If there was ever an impressive track

record for a game designer, that is it. Throw in some lesser-known classics
such as Super Breakout, Millipede, Gauntlet II, and Xybots, and you have a
truly unequaled career. Ed Logg designed and developed all of those titles at
Atari back in the heyday of the arcades. Before the collapse of the coin-op
market, Logg had already switched to working in home game development,
adapting popular Atari arcade games such as the San Francisco Rush series to
consoles. Subsequently, Logg took on an original home game for the first time,
serving as lead programmer on the unique platformer Dr. Muto. Today Logg
has returned to his roots, working on games for mobile phones. To look at
them, the classic arcade games seem quite simple, but it is that simplicity
which forced their designers to refine them to the point of perfection. Logg’s
classic coin-op games remain some of the best computer games ever made,
and the insight designers can gain from studying them is enormous.

What was it like working at Atari in the late ’70s and early ’80s?
We were young and energetic. I imagine it is very similar to the atmosphere at most
Internet start-ups these days. We were a relatively small group in the Coin Operated
Games Division. This allowed everyone to know everyone else. Ideas and pranks
flowed freely. Since we were working on a new medium we could do anything and it
would be “new.” Even games like Lunar Lander, done by Rich Moore, which had been
done originally years before, were new to our audience.

87
88 Chapter 6: Interview: Ed Logg

Where did most of the ideas for the games come from?
The ideas came from many
sources. For example, Owen
Rubin, another engineer at
Atari, told me Nolan Bushnell
had suggested to him an
extension of Breakout. I took
his idea and added many of my
own to create Super Breakout,
my first commercial success.
The idea for Asteroids came
from Lyle Rains, who was in
charge of engineering at the
time. He got the idea from a
previous coin-op game. Xybots
came from a challenge by
Doug Snyder, a hardware Asteroids
engineer at Atari. We wanted to do a multi-player Castle Wolfenstein-like game but we
had no “bit-map” hardware. So I created an algorithm based on 8 by 8 stamps and he did
the hardware. Centipede came from a list of brainstorming ideas. Atari would go off-site
each year to think up new ideas. One of those ideas was “Bug Shooter,” which was used
as a starting point for Centipede.
Management had reviews where they would come in and play the game and give
feedback. Sometimes the consensus was negative and a game could be killed. Most
often it would continue until it could be “field tested.” This meant it was left to the play-
ers to determine how much and for how long the game earned. However, sometimes
good suggestions came from these reviews. The most important one of all was a sug-
gestion made by Dan Van Elderen, who was in charge of engineering. He asked me why
we could not shoot the mushrooms in Centipede. Yes, the mushrooms were originally
static. It was his suggestion that led to the breakthrough that made this game fun.

Were you excited to get into game development at Atari?

Actually, I had been doing games for many years on the side, while in high school, at
Berkeley in the ’60s, and also at my first job at Control Data Corp. I ported Star Trek and
the original Dungeon game between Stanford’s and CDC’s computers.
I had built a home computer a year or two before joining Atari, just to create and
play games. I had been to a Pizza Time Theater and played Pong and Breakout, so I was
well aware of the coin-op business. I had also played games and was very inspired by a
prototype of the Atari VCS (2600) at a Christmas party in 1977. So the change in
employment seemed natural for me. At the time I thought it was great for them to pay
me to create and play games.
 Chapter 6: Interview: Ed Logg 89

Dirt Bike was your first game for Atari, but I understand it didn’t make it into
production. What sort of game was it?
This game was started by Dennis Koble who went on to do many consumer titles. It
was a game similar to Sprint except you drove a dirt bike and the control was a set of
handlebars that could be used to steer the bike instead of a steering wheel.
We field tested the game and it earned enough money to make it good enough not
to kill outright but not good enough to make it into production. However, I had made
Super Breakout at the same time I was working on Dirt Bike. No one at Atari had ever
worked on two games at once before. Super Breakout had earned a large amount of
money, and this probably led to the decision not to build Dirt Bike. I was not disap-
pointed considering the success of Super Breakout.

What was the genesis of Super Breakout?

The original idea included six variations on Breakout. I envisioned three released
games with two variations in each game. However, in actual play there was one overall
favorite: Progressive Breakout. In the end we put three variations in one game: Progres-
sive, Double, and Cavity Breakout. The variations that did not make it were more
vertically oriented and I had to agree they were not as fun.

Were you given a lot of creative freedom on Super Breakout, or were you con-
strained since it was a sequel to a previous hit?
To me, Super Breakout was not a sequel. Remem-
ber, the original game was not done in software.
The code had to be created from scratch and the
gameplay was completely different from the origi-
nal even though we used the same controls.
I was given freedom because I was doing the
title without any official sanction. It was not the last
time I would do that, either. Games could be done in
a short time in those days, which meant you could
make something fun before anyone even noticed
you were doing anything different.
Maybe I should explain how we were develop-
ing games in those days. We had one main Digital
computer which had the cross assembler for our
6502 based games. We had several gals who would Super Breakout
enter our handwritten pages into our programs and
give us back a computer printout and a paper tape. Yes, you heard that right. We would
then feed the paper tape through our development system into the RAM replacing the
game ROM on the PCB. We would debug this using primitive tools and a hardware ana-
lyzer and write our changes on the paper printout. Since this process left time between
the debug session and the next version, I used this time to develop a second game. I
would just swap the graphics PROM (yes, we created the graphics by hand ourselves),
and load the new paper tape.
90 Chapter 6: Interview: Ed Logg

That’s really astonishing that you ever developed a game using such primitive
methods. How did you manage to fine-tune your game with such a long time
between versions?
Well, actually, I was very good at just patching RAM with new instructions, so it was
easy to see what small changes did to the game. We also had an HP analyzer that we
could use to trap on many conditions, which allowed us to find many bugs that many
development systems cannot even do today. Actually it was possible to do some new
coding while you were waiting for your last changes to be made, so less time was lost
than you think.

But you would certainly agree that modern development tools have made
game development easier?
There are several issues here. First, back then we often knew everything about the tar-
get hardware, which made it easier to see what was going wrong. Today, the target hard-
ware is often hidden from us and there are several layers of software, which can make
debugging or doing what we really want to do difficult. So in this sense it is much harder
now. Also, these modern software or hardware layers are often not documented, docu-
mented incorrectly, or just getting in our way. Second, the hardware has gotten very
complex with interactions between the many bytes causing all sorts of problems. Third,
the processors have become very complex, causing all sorts of debugging nightmares,
especially in dealing with the caches. Fourth, today there are many programmers work-
ing on a game and it is easy to mess up one of your coworkers.
Surprisingly, the development environment has not gotten any faster over the past
few years despite the great increases in the computing power and RAM. As an example,
some of my files on my 25 MHz Mac IIci with 6 MB of RAM compile and link in the
same time or faster than files on a 550 MHz PC under NT with 512 MB of RAM. Even
the same project on my 150 MHz Indy builds faster than my 550 MHz PC. I firmly
believe that every tool developer should be given the slowest possible system to use to
develop their software! Otherwise, we are doomed to continue to run no faster with
each new upgrade.
The modern tools are so much better than the old method, it is hard to imagine how
I could have done so well, but you mustn’t forget how much time is spent learning each
new software tool, processor, and operating system these days. In addition, the amount
of time wasted chasing after bugs on new systems because I did not understand some
other hardware or software is quite large. But I would not want to go back to the old
tools unless the processors, hardware, software, game concepts, and team sizes were
much simpler.

I’ve never seen your next game, Video Pinball. How did it play?
It simulated pinball by using a half-silvered mirror with a monitor below the mirror and
the graphics for the play-field above the mirror. The monitor would show the flippers
and ball, which gave the impression the white ball was on the play-field. The play-field
actually had LEDs controlled by the program which simulated lit targets. In addition,
the control panel was hinged, which allowed the player to “nudge” the cabinet to give
the ball some English. I did not think this game up. I believe it was Dave Stubben’s idea.
 Chapter 6: Interview: Ed Logg 91

How did you hope to convince players to play Video Pinball instead of the real
thing?
I did not believe Video Pinball would be successful and I was asking that exact question.
However, there were places video games could go that a large pinball game could not. In
the end, the game earned more than I had expected and it was a commercial success. I
must say I was wrong on my first impressions, and that does not happen often.

Was it hard to work on a project that you did not think would be any fun? Did
the final game turn out to be entertaining?
The gameplay was fun but no comparison to a real pinball game. I was surprised that it
sold as well as it did. Yes, it was hard to work on an idea that I did not think would work
well. But I was young and motivated… What else can I say?

Where did the idea for Asteroids come from?

Lyle Rains had suggested to
me the idea of a game where
the player could shoot aster-
oids because there had been
an earlier coin-op game with
an indestructible asteroid that
the players kept shooting
instead of pursuing the
intended goal. I told Lyle we
would need a saucer to force
the player to shoot the aster-
oids instead of wasting time. I
also suggested breaking the
rocks up into pieces to give
the players some strategy
instead of just shooting the Asteroids
larger rocks first.
Lyle gave me the idea. People often attribute the success to one or the other of us. I
would probably not have come up with the idea on my own, and if someone else had
done the game it would most likely have been totally different. So in truth, we should
both be given credit for this idea. Come to think of it, without the vector hardware,
Asteroids would not have been a success either. So there are many people and events
that led to its success. I am very glad to have been there at that time and place.
The game changed very little in development from the original idea. I did make two
saucers, one dumb and one smart. I made one fundamental change near the end of the
project that had far-reaching implications. Originally, the saucer would shoot as soon as
the player entered the screen. Players complained — and I agreed — this seemed
unfair. Often the saucer was not visible just off the edge, and if it started next to your
ship you had no defense. So I added a delay before his first shot. This, of course, led to
the “lurking” strategy. While testing, I had actually tried to lurk at one point and
92 Chapter 6: Interview: Ed Logg

decided it was not going to work, which shows you how well the game designer can play
his own game.

Were you surprised by Asteroids’ success?

I was not surprised by its success. It sounded like a fun game when I played it in my
mind. Even after the first few weeks, people would come by and ask when they could
play. That was a sign your game was fun!
Even when we field tested the game for the very first time, I saw a player start a
game and die three times within 20 seconds. He proceeded to put another quarter in.
This tells me the player felt it was his fault he died and he was convinced he could do
better. This is one of the primary goals a game designer tries to achieve and it was clear
to me Asteroids had “it.”

Back there you mentioned that you played the game out “in your mind.” Do
you find that to be an effective technique for predicting whether a game will be
fun or not?
It is a skill which I find works
well for me. I also play devil’s
advocate with my ideas. I ask
myself, “What can go wrong?”
or “Will players be confused
by what I am presenting?” I
find that some designers often
are so married to their ideas
that they will not accept the
concept that maybe it just
won’t work. I cannot tell you
the number of great ideas I
have had that I “played out” in
my mind that turned out to be
bad ideas.
I am one of the few Asteroids
designers I have ever met that has actually killed many of his own games. I think this is
a good trait. Why waste another year to two if the gameplay does not play like you
expected?

Did you work on the sequel, Asteroids Deluxe?

I did not do Asteroids Deluxe. It was done by Dave Shepperd. I was promoted around that
time into a supervisor role. I believe I was also leading the four-player Football project.
So I was busy. I have no problem doing sequels if that is the best course of action. I had
some new ideas, so I wanted to do Millipede. Gauntlet II was a logical choice since Bob
Flanagan, my co-programmer, and I knew the code and this was the best game concept
we came up with.
 Chapter 6: Interview: Ed Logg 93

After Asteroids you didn’t make another vector-based game. Did you not like
working with the hardware?
Actually, I loved vector hardware for the reason it allowed me to put up high-resolution
1024 by 768 graphics. However, the industry was just moving over to color monitors at
the time. Dave Theurer did do Tempest as a color vector game, but the color mask on
color monitors did not permit high resolution. Besides, you could not fill the screen
with color on vector-based games, so that medium died with the advance of color
games.

Wasn’t Asteroids the first Atari game to have a high-score table?

Actually, Asteroids was not the first game; there was another game that used it just
prior. I thought the idea was a great way to preserve your score and identity for the
world to see. So I added it to Asteroids. I see it as filling the role of graffiti. Now it is stan-
dard, of course, and the industry has added battery-backed RAM or EEROM to save it
permanently.

Around this time you created the Othello cartridge for the Atari 2600. I under-
stand you studied AI while at Stanford. Did the Othello project grow out of your
interest in AI?
No, actually Asteroids showed more influence from my Stanford experience. While I
was at the Stanford AI Lab, I had played Space War on their PDP machines. I had also
played a coin-op version of this in the Student Forum coffee shop. In my mind, this was
the first video game. Pong certainly was the first commercial video game. Anyway, the
spaceship design in Asteroids was a copy of the original Space War ship.
I had played Othello as a board game and I was intrigued by possible strategies. So I
worked on this game at home and developed an idea that the game could be played by
pattern matching without any AI. In other words, the computer does not look ahead at
your replies to any of its moves, which was the standard AI approach at the time. So
really the Othello game I did had no AI. It was good enough for the beginner and average
player. It was not an advanced game by any means. Besides, the 2600 had only 128
bytes of RAM so there was not much space to look ahead.
In fact, Carol Shaw had done the hard part by providing me the kernel which drew
the pieces on a checkerboard. The 2600 was extremely difficult to do anything complex
on. It was intended to do Pong-style games. You spent all of active video counting cycles
to draw the screen. This left Vblank to do any thinking or other work. There was lim-
ited RAM so nothing complex could be saved in RAM. Othello was 2,048 bytes. Most of
this was the kernel. So I often spent time trying to eliminate a few bytes to add some-
thing new.

Was Centipede your next game?

No, as I mentioned I was a supervisor at the time. I was project leader on four-player
Football and a kit to upgrade the plays on the original Football game.
On Centipede, I thought up the idea of the centipede segments and the way the legs
moved. I do not believe it was mentioned in the original “Bug Shooter” brainstorming
idea. In fact, no one has ever stepped forward to claim “Bug Shooter” as their idea.
94 Chapter 6: Interview: Ed Logg

Maybe it was due to the finished product being so much different from the original idea.
I had assigned a new programmer, Donna Bailey, to do the programming on Centipede.
Partway through the project, I quit being a supervisor (I didn’t like the job and it took
me away from doing games) and spent time working on Centipede.

So Bailey was pretty important to the game’s development?

I would guess she did about half the programming. The game design was left to me
because she was working on her first project.

It seems that Centipede appeals to women more than most arcade games. Do
you think Bailey had something to do with that?
I wish I knew the answer to that question.
Someone could point out that no other game I
have done appeals to women as much as
Centipede.
Many theories have been suggested. One
is that is was created by a woman. Another is
that destroying insects fits well with a woman’s
psyche. I believe this game appeals to women
because it is not gender biased like fighting
games or RPGs or sports games. Other exam-
ples like Pac-Man and Tetris are notable.
I do know Centipede fits the basic criterion
for a game that appeals to a wide audience. It
has a new, appealing look (to get players to try
Centipede
it), an obvious goal (shoot anything), clear
rules, an easy set of controls, a sense of accomplishment (kill the entire centipede
before he gets you), dynamic strategies abound (trap the centipede and kill spiders or
the blob strategy or channel the centipede or just plain straight-up play), enough ran-
domness to make the game different each time, a goal to keep you going (a new life
every 12,000 points), a clear sense of getting better with more play, and a sense that any
death was the player’s fault.

So you mentioned that Centipede grew out of a brainstorming idea. How did the
brainstorming process work at Atari?
The brainstorming ideas came from anyone in the company. They were usually gath-
ered weeks before the actual meeting which was held off-site, away from Atari. Often
the ideas were just a theme. Most submittals had sort of a sketch or art to give the
reader a little more info. Occasionally a full game description was submitted which
explained the hardware, controls, art, and gameplay.
During the brainstorming session, each idea would be presented and then sugges-
tions would be made for improving it. In addition, marketing would give a rundown of
what was selling and the state of the industry. We would also break into smaller groups
to discuss a specific type of game or talk about specific games themselves. In the end
we would meet again to present any additional ideas from these smaller meetings and
 Chapter 6: Interview: Ed Logg 95

vote for the popular ideas. I would say we would get a majority from programmers and
designers, but there were a significant number of ideas from artists and others in the
company. I found many of the ideas needed a lot of work, so it was not uncommon for the
original brainstorming idea to get a major overhaul.
Atari Games Corp., now Midway Games West, still uses this process each year. But
quite honestly, many of the recent coin-op games are just remakes of older games. For
example, more versions of Rush or Cruisin’. The reason is often market driven: these
are the games that have done well in the past and the company does not often want to
risk taking a chance on a new theme.

How did Centipede change over the course of the game’s development?
I mentioned that Dan Van Elderen asked why
the player could not shoot mushrooms. I real-
ized early I would need some means to create
new mushrooms. This led to one being left
when a centipede segment was shot. I also cre-
ated the flea which left a trail of them when he
dropped to create more randomness in the pat-
tern. In other words, I did not want the player
to create the only pattern of mushrooms. The
spider was always planned to be my “Asteroids
saucer” which kept the player moving; the spi-
der also had to eat mushrooms to keep the
player area somewhat free of mushrooms. The
scorpion was added to add a randomness to the
Centipede
centipede pattern and create a sense of panic
when the segments would come rushing to the bottom of the screen.

Do you try to create games that allow different players to use different strate-
gies to succeed?
I do strive to give the players as much freedom to create as many strategies as possible.
So in a sense, yes, I guess I do encourage players to experiment and try different strate-
gies. I do try to make sure that none of them work all the time or make the game too
easy. But I want to leave the player with the impression that if he was only a little bit
better he could pull it off.

Why did you choose to use the trackball for Centipede?

I believe we used the trackball from the start. I had experience with the trackball on
Football, but I wanted something that was not as heavy and physical to move around.
That is how the Centipede trackball came about. The trackball, just like the computer
mouse, provides a means for inputting arbitrary direction as well as speed. No other
controller comes close. It was the clear winner for player controllability.
96 Chapter 6: Interview: Ed Logg

In my opinion, Centipede is one of the best balanced games ever. Was there a lot
of experimentation to achieve such a balance?
I would not use the term experimentation in this case because nothing was tried and
discarded. There was a grasshopper that we intended to add to hop onto the player, but
the spider was sufficient in forcing the player to move so the grasshopper was never
even tried. Of course, you can still see the graphics for the grasshopper if you look at
the self-test graphics.
There certainly was a lot of tuning. The timing and speed of when things happened
certainly was changed over the course of the project. The balance comes from the
inherent rules of the game and the art of knowing when to leave the play alone and
when to change something. This art is something that some people have and others
just don’t. I cannot define it other than to use the term “game sense.”

Were you given freedom to do whatever you wanted for Millipede?

With my past record I was given more freedom
than anyone else. Something most people do
not understand is that half of the games I
started did not make it into production. No one
ever hears about the failures. Some of the
games I actually killed myself. That’s some-
thing I believe no one else at Atari did. Of
course, there are a few I tried to kill but was not
allowed to that eventually died. These days
you would probably see them come out in the
consumer market anyway just to get back
some of the development cost. But in the
coin-op market there is no chance to sell any-
thing that isn’t a clear winner.
Millipede

Millipede allowed players to start farther into the game, at 45,000 points, for
example. Was this an effort to shorten the games of the expert players?
It was a way to increase the cash box. It allowed the good players to start at a higher
score where the gameplay was on a difficulty level that was probably just above his level
of skill. This often meant shorter game times but would allow higher scores. In a sense
I was doing this for marketing reasons. This was not a first for Millipede. Tempest had
this feature back in 1981.

I particularly like the “growth” of the extra mushrooms in Millipede. Was this
done using a “life” algorithm?
Yes, it is based on the game of life where two or three neighbors would create a new
mushroom and anything more or less would kill the mushroom. This has an interesting
history. Mark Cerny asked why I didn’t do a life algorithm on the mushrooms. I told him
I was busy but if he wanted to add it to the game he could. Of course, Mark, being the
sharp guy he is, looked at my code and quickly created this feature. He also added the
attract mode to demonstrate all the creatures.
 Chapter 6: Interview: Ed Logg 97

During the Asteroids to Millipede period, almost all your games were being
ported to a wide variety of systems: the 2600, the Apple II, and so forth. How
did you feel about these conversions?
It was good business for the company so it
made business sense. Of course it always made
me proud to see my game in many new places. I
did have some concerns about several of the
ports. I understand the limitations of some of
the systems but I wanted to make sure the
company released the best possible conver-
sion. In many cases I was involved in making
sure it had all the features but unfortunately
not often enough.
Some of the conversions made improve-
ments that were not possible in the coin-op
market. For example, in Gauntlet they made a
quest mode with a limited amount of health.
Millipede
This would not be possible in coin-op where
the object is to get more money added on a regular basis. Another example would be to
look at the number of variations of Pong included on the Atari 2600 cartridge. It just
makes good sense to add value for a consumer title.

Was Maze Invaders the next game you worked on after Millipede? I know it never
went into production.
It was a cute puzzle-like game. I was not sad it didn’t make it; it did not earn enough on
field test. My son loved the game though and I still have one of the two prototypes in my
garage. The other was purchased by an operator in Texas, I believe. He loved the game
so much he talked Atari into selling it to him.
I believe I mentioned earlier that nearly half of my games did not make it into pro-
duction. There were engineers that had a higher percentage, Dave Theurer in
particular. But there were others who never had a game in production.

The name Maze Invaders suggests perhaps something inspired by Pac-Man.

Was it?
Yes, in a way. It was a maze-like game but the maze changed dynamically. The main
character was very Pac-Man like; he was cute. There were some parts that I found frus-
trating, such as when the maze would temporarily block me off. I could not resolve this
frustrating aspect, which is probably why it failed.

I understand in 1983 you also worked on a Road Runner laser disk game. Was it
based on the Warner Bros. cartoon character?
Yes, it was based on Road Runner created by Chuck Jones. The player played the part of
the Road Runner who would try to have Wile E. Coyote fall prey to some trap. I had
Time Warner send me all of the Road Runner cartoons. I watched every one and
selected the best shorts to be included on a laser disk. So when you succeeded in
98 Chapter 6: Interview: Ed Logg

getting Wile E. destroyed, the game would cut from the action to a similar scene from a
cartoon where Wile E. met his usual fate.
I always loved the Road Runner and I thought I could bring him to a video game.
When I started I had a vision of something unique. The game certainly met that crite-
rion but it was not as fun as I had hoped. I certainly enjoying seeing all the old cartoons
and meeting Chuck Jones but…

So the game was killed?

Laser disk games were failing in the coin-op world because of reliability problems. The
game actually earned enough to warrant interest but not as a laser disk game. So when
they asked me to port it to their new “System I” hardware, I declined, saying I had
another idea I wanted to pursue. I am glad they let me pursue this new idea because this
idea became Gauntlet. Road Runner was converted over to System I and actually was
released.

Did Gauntlet follow your initial vision fairly closely, or did it change a lot in
development?
I went back recently and
looked at the original game
design document and I was
surprised how closely the
graphics and gameplay
matched the finished product.
Of course, what did change
during development was the
hardware. I created an algo-
rithm which would allow me
to deal with 1,000 objects
without burdening the pro-
cessor or slowing down the
frame rate. I asked Pat
McCarthy, the electrical engi- Gauntlet
neer, if he could extend the
existing hardware and he found a way to do this which would allow me to display all the
objects I needed. In the end there were five patents issued for Gauntlet.
Because of the size of the PCB and the restrictions on PCB size for Japanese kits,
we decided to use a four-layer PCB for Gauntlet. Atari had never laid out such a board
nor had they ever used traces as small as we required. But in the end we paved the way
for all future PCBs at Atari. So besides the success of the game in the industry, Gauntlet
also made a giant leap in the way we did engineering and manufacturing at Atari.

To my memory of arcades in 1985, Gauntlet seemed to be one of the first action

games to allow four players to play at once.
This was the first multi-player game which allowed players to end or leave at any time
and the screen scrolling was controlled by their actions. This was not the first game to
 Chapter 6: Interview: Ed Logg 99

have multi-players. Tank 8 allowed eight players on one monitor. But all the players had
to start at the same time. The idea of using four players was designed into Gauntlet
from the start. I suspect it was due to the fact that I could only put four players around
an upright monitor.
I believe Gauntlet was the first game that allowed the player to buy in any time he
wanted. I did not want the players to wait, like in Tank 8, for everyone to coin-up at the
same time. The only solution was to have players come and go at will. Health was
always planned from the start. I believe this idea came from Dungeons & Dragons,
which was very popular at the time. So it was logical that money just bought more
health. Since it is every coin-op designer’s wish to have the players put as much money
as they can into their game, I saw no reason why I would not have the players just
increase their health with each coin. In hindsight, this is a wonderful idea because los-
ing 2000 health was not as painful psychologically as inserting another quarter.
Besides, the players would not need to reach into their pocket to find another quarter to
insert before their character was lost.

Where did the idea to have the game say things like “Red Warrior needs food,
badly” come from?
I do not remember. I suspect it was not my idea. It may have come from my
co-programmer Bob Flanagan or from someone else at Atari. In any case we had a large
list of phrases we wanted the “Dungeon Master” to say to taunt the player. There are
several phrases that seem to stick in everyone’s mind. My favorite is “the Wizard (me)
seems to be eating all the food lately.”

Many think the Valkyrie was the most powerful of the four characters.
Actually, the Hulk or the Wizard could be used to play forever. This was demonstrated
first by players in Japan playing a one-player game. This was fixed later by reducing the
amount of food on subsequent levels if the player had not lost enough health during the
last level. The Valkyrie was designed to be the most balanced of the characters but shot
power, shot speed, and strength proved to be more important than other attributes.
This is why the Hulk and Wizard seemed to be the most powerful. Of course, the Elf
was fun to play with for many players because you could always get more food or trea-
sure than the other players.

Gauntlet II allowed four players to all be playing Valkyries, or Elves, or what-

ever combination they wanted. Did this mean the character classes had to be
more equal than in the first game?
No, we actually did very little that I can recall to equalize the characters. This feature
was added because some players wanted to play a particular character and I did not
want them to wait until the desired position was open. So in essence I eliminated
another reason for not entering the game right away.

Was Xybots your next project after Gauntlet II?

Bob Flanagan and I actually started another game, which I quickly killed after the initial
gameplay turned out to be less fun than I had expected.
100 Chapter 6: Interview: Ed Logg

Xybots, as I mentioned
earlier, started out as an idea
to do Castle Wolfenstein. I
started the game as a two-
player split-screen Gauntlet
III. Partway through, market-
ing said they wanted
something other than Gaunt-
let. So I changed the
characters and enemies to be
more like Major Havoc. I still
regret changing the theme
and wish I had kept my origi-
nal game concept.
Gauntlet II
Was it a great engineering challenge to create the game’s 3D look?
I developed a very interesting algorithm for doing the 3D rotation using just 8 by 8 pixel
stamps, as we call them. I don’t know how to explain how this worked without getting
my original sketches to visually demonstrate it. I could have had the player rotate other
than in 90-degree increments, but it made the gameplay simpler to just allow only
90-degree rotations.

If I recall, the game had interesting and unique controls.

The controller was very
unique because it provided
the standard eight-way joy-
stick as well as a knob on top
which could turn left or right
to indicate a rotation. This
control made the game more
difficult, which is often the
kiss of death in the coin-op
market. As with any 3D game,
players could not easily visu-
alize where they were despite
the map available to them. In
addition, it was possible to get
shot in the back, which added Xybots
to the frustration factor.

How did you get involved working on the Atari Tetris?

I played a version of Tetris and was quickly addicted. I asked our legal counsel, Dennis
Wood, to get the rights. Since I had just worked on reverse engineering the Nintendo
Family Computer, which soon became the Nintendo Entertainment System in the U.S.,
I decided to create a version on the FC and NES and sell it through Tengen, which was
 Chapter 6: Interview: Ed Logg 101

Atari’s consumer publisher. Dennis Wood got the rights and we showed Tetris first at
the June Consumer Electronics Show. It was decided to improve the game so I redid the
visuals and we released it at the following CES in January.
I should point out that I was working on another game at the time I was doing this,
so I could not devote all my time to the Tetris project. It was this fact that made me need
to turn over Tetris to Greg Rivera and Norm Avellar for the coin-op market. I did get my
original code to run on the coin-op hardware before going back to my project. This is
why my name appears on the credits of the coin-op version.

What did you like so much about Tetris?

It was just so addicting I knew we had to have it. In hindsight, I could explain why this
game worked so well but I am not sure that would prove anything. Besides, the real
question is “Why didn’t I think of this idea?”

Was Tengen Tetris your only NES project?

I had Centipede and Millipede running on the FC before the lawsuit with Atari Corp.
resulted in the ruling that they owned the rights to all our games prior to the sale of
Atari to Tramiel by Time Warner. So we had to drop the work I did. So my previous work
made Tetris very easy to do on the NES. I also added the two-player simultaneous fea-
ture, which made this game better than all the other versions. Later you would see
Tengen versions selling for $150 or more.

Why was Tengen Tetris eventually withdrawn from circulation?

You can read several versions of the story but I suspect the bottom line is the Hungar-
ian who had the rights did a poor job of covering all the bases. The Russians accepted
money from Nintendo when Nintendo created a new category of rights. Despite the fact
we had the rights to computer systems, Nintendo claimed their Family Computer was
not a computer even though they sold Basic and a keyboard and other services in Japan
just like any other computer. I was certainly disappointed to see my work lost.

Why did you want to work on conversions of someone else’s game?

As with many of my games, this was the best idea I could think of at the time. However,
in this case, because I enjoyed it so much, it was an easy decision. What better way to
play the game you like so much and make sure it comes out the way you like?

What did you work on next?

I eventually killed the game I was working on during the “Tetris Affair.” I believe Steel
Talons was my next project. I wanted to do a 3D Red Baron flying/shooting game but
marketing thought World War I planes were not cool enough for teens, who were the
prime coin-op target audience. Marketing wanted jets and I thought that was a dumb
idea because who wants to see dots at a distance shooting at each other. I wanted some-
thing close where you can see the detail of the enemy you are shooting at. Helicopters
were the logical choice.
102 Chapter 6: Interview: Ed Logg

Wasn’t Steel Talons a fairly authentic helicopter simulator?

Steel Talons had all the regular helicopter controls: a rudder, a collective for controlling
height, and a stick for turning. Of course flying a helicopter is difficult without some
assistance, so I had computer assist just like real military helicopters. I added automatic
collective control so the player would maintain level flight and any landing would be
smooth. It would also increase height if the ground was sloping in front of the height.
The “real” mode just disabled this helping code and increased the player’s acceleration
to compensate. This was a unique feature and Atari was issued a patent on this idea.
The game had another interesting feature that had never been used on a video
game before. We installed a pinball thumper, often used to indicate a free game, under
the seat. This was used whenever the player’s helicopter was hit by enemy fire. During
the first field test, the voltage for this thumper was higher than it should have been and
the first players to use it nearly jumped out of their seats when it fired. The noise could
be heard over the entire arcade.
The first field test also introduced a new problem that we never had before. I went
out to check on collections and I tried to remove the coin box. If you have ever seen
Steel Talons, you will see that the coin box is located at a strange angle, requiring the
operator to lift the box with his arms fully extended. Not the easiest position to lift any
weight. Well back to the story. I tried to lift the box out but could not budge it. I thought
it was jammed. I soon discovered that the box was so full and was so heavy it was nearly
impossible to remove. This led to the strange instructions in the manual asking the
operators to empty the coin box every couple of days.

On Steel Talons, didn’t you work with Battlezone creator Ed Rotberg?

Yes I did. He was at Atari during the golden days of Battlezone, Asteroids, et cetera. He
left Atari to do a start-up called Sente, before returning to Atari a few years later. He had
just finished working on a Tube Chase-like game using the same 3D hardware that Steel
Talons used. This hardware was a cost-reduced version of the Hard Drivin’ PCBs. So it
was natural for Ed to work with me on this project. Another interesting feature of this
game was fog. The original Hard Drivin’ team did not believe me when I told them I
could add fog to the world. I am still proud of this effect and they were surprised that it
worked.

How did the Space Lords project come about?

I wanted to continue my ideas of multi-player play that I started on Gauntlet, and then
continued on Xybots and Steel Talons. So I chose a 3D space environment with up to four
cabinets linked together. Each cabinet had two monitors similar to Cyberball. I tried to
keep the cost down by using Atari’s “growth motion object” hardware, which was
cheaper by far than the 3D hardware used on Steel Talons. It could not draw 3D poly-
gons, but it could grow or shrink flat textures.

I understand Space Lords did not do too well financially.

Space Lords had some strange earning patterns. At some arcades it earned more than
$1,000 per week for two double cabinets. But at some small arcades it earned only $75
as a single cabinet. The bottom line is we had a difficult time selling it because of its cost
 Chapter 6: Interview: Ed Logg 103

and the limited number of locations it could be sold into. It was definitely hard to make a
coin-op game using the concept of one player per monitor. Even though I added a sec-
ond player as a gunner at half price, it was felt by many to be not as fun as being the pilot.

And Space Lords came out right around the time the fighting games were tak-
ing off.
The fighting games made Space Lords difficult to sell because they were often “kits,”
which sold much cheaper than a large dedicated upright. Street Fighter II had great earn-
ings and continued to earn good money for a long time.

In fact, since the early ’90s most arcade games have been in one of a very few,
limited genres. What do you think of many of the arcade games that come out
these days?
You are right, the coin-op market seems to be all driving, fighting, and shooting with an
occasional sports title, like golf. There are reasons for this. Driving has universal appeal
and usually earns for long periods. So it is often the most accepted game theme.
Besides, most home units do not have steering wheels and gas pedals or give you the
feel of being inside a car. So you cannot get this experience in the home. Fighting games
are now difficult to sell in the arcades, and I believe this is because you can get the same
experience on most advanced consoles. At the time, they were cheap and earned big
bucks. Shooting games are still viable because guns are not the standard controller on
consoles or PCs. So the only way a game player can get this experience is in the arcade.
So the bottom line is, most arcade games these days are not unique and fit very lim-
ited categories. I don’t think the arcades are completely dead but they are not the
destination places they used to be.

Did Space Lords turn out to be your last coin-op?

I was working on a shooting game prior to my departure from Atari. That game died but
the gun was used later on Area 51. I joined Electronic Arts who were trying to start up
their own coin-op group. My intention was to start doing consumer games. But EA had
some old Atari friends and I decided to join them. I had done one puzzle game, which I
killed, and was working on a shooting game when they decided to drop out of the
coin-op market. Then I was even more determined to enter the consumer games
business.

How did you come to start doing N64 programming?

I was looking for a project to work on, so I contacted many companies to see what they
had to offer. I was planning to work with another programmer from EA but he decided to
join some friends to start up a new company. Atari wanted the coin-op Wayne Gretzky 3D
Hockey done on the N64 and I was looking forward to doing something on that platform.
This was partly because the game promised to look better than the PSX but also
because it looked like we could be the first hockey title available. So I joined a group at
Atari and we started work on Wayne Gretzky 3D Hockey. This turned out to be more
work than I expected partly due to the state of N64 development systems but also due
to the fact the coin-op was not going to be done until just before we released.
104 Chapter 6: Interview: Ed Logg

As you mentioned, a lot of the appeal of playing an arcade game like San Fran-
cisco Rush seems to be sitting in the chair, having the gearshift, the steering
wheel, the force feedback, and so forth. How do you try to capture that for the
N64, which has none of these niceties?
You are right. The home does
not have the environment of
the arcade cabinets but we can
do things on the home games
we can never do in the arcade.
We can provide more choices
for the player, more tracks for
them to learn, and more
things to discover.
I try to keep the basic
play the same but I always try
to add value to the product.
This is one thing I made clear
when I joined Atari. Atari
wanted me to just do a
straight port. That had always San Francisco Rush: Extreme Racing for the Nintendo 64
worked for them in the past. I
did not believe this would work and told them I would be adding additional “stuff.” For
example, on Gretzky we added a full-sized rink, a new AI, instant replay, more players,
full seasons, et cetera. In general, home games require considerably more work. I also
believe we can do different games for the home market that we could never do in the
arcade. So for me, this opens up new possibilities.
Arcade pieces must be easy to learn with rules that are obvious and provide enter-
tainment that lasts ninety seconds. The home market is not bound by these rules.
Instead, you must provide more life for your product. Often this means it takes the
player longer to “finish” the game. Even when the player has finished it, there must be
reasons why he will want to go back to do it all over again.

Do you like the engineering challenges of doing home conversions?

I actually enjoy the “old style” of trying to get everything to fit. I also enjoy adding
tricks to get the frame rate as high as possible. It was very interesting to get all of SF
Rush into 8 MB, which includes around 3 MB of audio and all the graphics.

How did the Dr. Muto project originate?

I am not sure of all the details, but I believe the basic concept came from our producer,
Scot Amos. I was very intrigued by the idea of playing as a mad scientist, so I thought
the game idea was a good one.
There is actually an interesting story that goes along with this. When we proposed
the game to the management committee, their main complaint was that no one would
want to play a mad scientist. To prove their point they wanted to do a marketing survey
to see if a mad scientist was a good choice. Of course, the engineering team thought this
 Chapter 6: Interview: Ed Logg 105

was a waste of time. Imagine

if they were to ask anyone if a
purple hedgehog or an Italian
plumber would make a good
main character. Of course, the
answer came back that the
mad scientist was not a good
idea because they had no
point of reference as to how it
would be used. In the mean-
time we did a small demo with
a couple of rooms to show off
our rendering engine, basic
look and feel, morphing, and
some basic humor. When
management saw this, they Dr. Muto
knew exactly what we had in
mind and we got a unanimous decision to go ahead with the project.

I always thought that Dr. Muto was fairly unique for a platformer in that its
main character was older and not particularly cute or furry. Where did the
desire to have such a different character originate?
The character design concepts came from our lead artist, Steve Caterson, whom we
call Scat. We definitely wanted to do something different than everyone else was doing.
Having a cute and fuzzy mad scientist just did not sound right. Besides, we wanted to
look different than everyone else.

Dr. Muto was the first game you developed for the home market that wasn’t an
adaptation of an existing game. How was the development different from your
previous experiences?
This game was so different from any other game I have attempted to do. The market of
course had changed, requiring better rendering, special effects, and movies. But the
most important point was, this was a platformer and the standards for this type of game
are very high indeed. We needed to match anything that was currently on the market or
planned to be on the market.
The other most significant point is the sheer number of people, the cost, and the
time required to do this project. Dr. Muto was by far the largest project I had ever been
part of. There were more than twenty-five people on the team plus a tools group and
video production people. The game design alone was orders of magnitude larger than
anything else I have ever been associated with.

For Dr. Muto you were just the lead programmer and not the lead designer,
correct?
The lead designer, Mark Simon, came in later on the project, around April 2002, I
believe. This was his first large-scale project where he was lead designer, and I think he
106 Chapter 6: Interview: Ed Logg

was a little over his head on this one. I would not have made a good choice as lead
designer either because this type of game was unfamiliar territory for me. Besides, I
like to program and I would not have been able to do anything except design as the
designer. Even then I would have had to have several others assisting me in laying out
levels, tuning, et cetera. But I was not even leading all the programmers because there
was a tools group doing the
rendering engine and all the
work making sure the game
ran on the Xbox and
GameCube as well. Scot
Amos, our producer, served
as project lead. He was really
good at motivating people and
even better at enthusiasti-
cally pushing our product —
much better than I could do.
He did a marvelous job.
But there were things I
would have done differently. I
certainly would have pushed
our original idea for a side- Dr. Muto
kick. She was called Eyesore.
She was to add sex appeal and humor to complement our bumbling mad scientist.

Why do you think Dr. Muto didn’t fare better commercially?

I wish I had a good answer to this. I am afraid that we just did not get critical mass in the
market. There were many platformers coming out at Christmas 2002 and we were up
against some very well-done and well-advertised products. The industry claims that
platformers did not do as well in 2002 as they had done in previous years. However, I
believe the reason has to do with the game Grand Theft Auto. Because this game had
such huge sales it naturally took sales away from other games. I contend this game is
really a platformer, shooter, and a driving game all in one. If you lump this game into the
platformer category, then you will see that platformers actually did quite well.

What are you working on these days?

I am doing cell phone games for a start-up called GenPlay Games. There are several of
us from Midway Games West (originally Atari Games Corp.) working together now. I
have just finished my second game, which will be out shortly on Verizon and Sprint.
I like the cell phone game industry in that the games are smaller and more arcade
like. By that I mean the audience is looking for a more casual gaming experience. I also
like the fact I can get back to doing programming and game design without managing
other programmers. This industry will of course change as the cell phones become
more powerful. 3D chips are already on their way into cell phones. It will not be long
before we see the latest console games running on cell phones. The marketing of
games is already getting to the stage where licenses or some name recognition are
needed to get the attention of the carriers and players.
 Chapter 6: Interview: Ed Logg 107

You have been involved in game development for almost twenty-five years.
How do you explain your longevity?
Longevity comes from doing what I like. Working on games requires something which
many people do not have. Many cannot take the constant pressure to perform, the long
hours, and the thought that their “baby” that they have been working on may get killed
after eighteen months of hard labor. Others are programmers or artists who have found
more interesting things to do.
I must admit I have often thought of doing something else. I just have not found
anything else I want to do more than what I am doing now. That could change or I may
find myself doing games until I retire.

How did you feel about the closing of the old Atari offices?
This is like asking me how I feel about an old, dear friend passing on. I was very sad. We
were the only project at Midway to be on time but in the end we were all let go. Such a
waste of technology and the really great people we had working together.

In recent memory, Asteroids, Centipede, and Gauntlet have all been remade. How
do you feel about the remakes?
Many are doomed to fail just
like most game ideas. Gaunt-
let was a good case of a remake
that worked very well.
Arkanoid was a remake of
Breakout that worked very
well. So remakes can work,
but it is difficult.
The real failure comes
from comparing the gameplay
to the original. For example,
making a 3D version of Centi-
pede makes the gameplay
harder because the 3D infor-
mation is not as easy for the
player to process. Remember, Gauntlet Legends
designers have had twenty years to play these old games and come up with a new twist
to make a new great game. The fact that they haven’t done it yet seems to indicate that
it is unlikely. Not impossible, but unlikely.

Which one of your games might you want to remake?

If I had the answer to that, and if I believed it was the best idea I had, I would be working
on it. Besides, if I told you, then someone else would be doing it now, wouldn’t they? In
other words, I don’t have any idea how to take some old classics and make them new
and interesting in today’s market.
108 Chapter 6: Interview: Ed Logg

How has the game development industry changed over the years?
The games industry has definitely changed, but it is still a video game industry. Video
games were not a $7 billion industry when I started. With big business comes big
money and that invariably brings with it control over how it is spent. So there is defi-
nitely more politics at the corporate level. The interference from management comes
from their need to control the costs, but the real reason, I believe, is due to the evolu-
tion of the games themselves. By that I mean, we could design and program a game in
three months in the early years. In three months you did not spend enough money for
them to interfere. Games have evolved to the point where you cannot do a game with
just one person in a realistic amount of time. It takes several programmers, several art-
ists, an audio specialist, and someone to manage the project over a period from twelve
to twenty-four months. The console market has changed too. You did not need to spend
$1 billion to launch a new console in the early days, but it costs that much now. So with
evolution comes longer periods for development and higher costs to produce a product.
With the higher costs comes more money and hence more control (i.e., interference)
over how it is spent.

When working on home games, what have you changed in how you design your
games versus your work in coin-op?
This depends on the type of game. For example, it is not sufficient to have a driving
game with a dozen cars and a similar number of tracks. Now we would expect to see a
large number of licensed cars, perhaps licensed drivers or tracks, or better yet a movie
license. Of course we expect even better graphics and special effects than before. But
aside from this point the basic idea is to add enough gameplay to make the purchase of a
console game worthwhile. Remember, players can rent the game at the video store. If
the gameplay is too short or does not meet their expectations or does not merit replays,
then you can be sure the game will not sell well.
Now that I am on the subject, I have been really disappointed to see that nearly
ninety percent of the top one hundred games are licenses or sequels. It is the single
most overwhelming concern for any new game. It is sad to think game design cannot
proceed without some tie-in with a movie or some other easily recognized title.

Do you miss doing more simple, classic arcade game designs?

Yes, I do miss the old game designs, which is why I am glad to be working on cell phone
games. 2D worlds are so much easier for the player to understand. I also like the idea of
creating a game with a fixed set of rules and enough randomness so that the player can
create different play-styles and their own strategies.
I am not sure I could sell a game with an “old design” to the console market.
Players have different expectations now. They would expect 3D designs or Internet
play or high-resolution textures and pre-rendered movies or highly developed charac-
ters... Besides, just about anything I do now will just elicit comments like “It is just a
twist on game xxx with a little of game zzz.” For the record, many of the old designs
were based on previous game ideas. Remember, Asteroids came from a previous game
with a little of Space War thrown in, even though many thought of this as an original
design.
 Chapter 6: Interview: Ed Logg 109

For most of your original designs, you served as both designer and lead pro-
grammer. Do you enjoy working in both capacities?
Working as game designer and programmer is a good idea if you can pull it off. There are
very few people who are good at both. So it is not a strategy I recommend today. For
example, for today’s complex multi-character and multi-level games, I am not as good a
designer as I would be on other styles of games. So I would be willing to give up this role
to someone else.
The programmer has to implement the design and if the designer’s ideas are not
communicated well enough, then the game is programmed differently than the
designer expected. I believe it is often the programmer who can make or break the
“feel” of a game.
You seem to have missed one point. I was also project leader on many projects.
This is a role I am very good at but receive no acknowledgment. My projects are almost
always on time and if there are problems, management is often told well in advance. No
one outside Atari probably is aware of this. Unfortunately, I do not enjoy this role so I try
to spend as little time as possible actually managing a project.

You even served as artist on your early games, didn’t you?

Early on it was a good idea.
There is no reason to train an
artist to create a rock on graph
paper and provide me with the
coordinates so I could enter
them into my game. When
there was so little in the way
of graphics or audio required,
it makes no sense to have
another specialized person
doing this. Today, it is an
entirely different matter.
Today it is absolutely
required.
Asteroids

Do you feel that any of your games are underappreciated?

As a game designer, no, I do not feel I have any games that were underappreciated. If
the game design works, then the gameplay is fun and the game sells. As a programmer,
yes, there are probably some game ideas or algorithms or programming speed which
are underappreciated. Many programming tricks I do for personal enjoyment so I am
not looking for external recognition.

In the early days you were pretty limited by the technology available to you.
Did the technology limitations foster creativity?
Yes, I would have to agree. There were many times I spent thinking about how to do
something on a given hardware and that turned into a game. Xybots was certainly one of
110 Chapter 6: Interview: Ed Logg

those games. On Gauntlet we created new hardware to make the gameplay possible.

Do you think that gaming technology is stabilizing to the point where future
games will be less about cutting-edge rendering and more about new game
ideas?
As I mentioned earlier, marketing forces will drive games more than technology from
the standpoint of getting the financing to get started. Since games have gotten so much
more expensive and take so long, I suspect technology and new game ideas will take a
backseat. This is not to say that there will not be even more improvement in the quality
of the video and audio. I can assure you technology will be used to help sell the game in
the end and will be a factor for the players. I can also assure you that new ideas will be
tried but I doubt that any major studio will pin the hopes on the technology or game idea
by itself.
In a way I agree that gaming technology is leveling out, as it were. By that I mean if
the number of polygons that can be drawn increases by ten I would not expect to see
much improvement in the quality of the video. Yes, you can add bump mapping or
per-pixel shaders, but the basic TV has only so many pixels and covering the screen
with more than one polygon per pixel will not improve the quality of the final video.

When working with an original game design, where do you start?

First, I try to come up with the game and then look at all the aspects of the play. From
the market perspective: will it sell, is the timing right, licensing requirements, compe-
tition, et cetera. From the player’s perspective: what makes this game fun and what is
unique that will make it interesting. From the development side: what will it take to do
this game in terms of people and equipment and will it be fun to do. Ideas themselves
come from just about every possible source. I have mentioned how some come from
previous games, brainstorming ideas, technical challenges, and other people’s
suggestions.

So, once you have your idea, do you start coding right away, or do you spend a
lot of time thinking it through ahead of time?
With the large budgets and large teams these days, it is necessary to do a game design
document and technical design document before the game gets too far into develop-
ment. However, I try to start work on some critical aspect while the design documents
are being drawn up. I believe it is extremely important to work on the aspect of the
game that will make or break the concept. The front-end movies, story line, front and
back end screens can all wait until the gameplay has been proven. Sometimes this
prototyping phase is quick but often it can take several months.

Once you have proven the gameplay concept in a prototype, how does the rest
of development progress?
Games go through four phases for me. The high at the beginning of a project of doing
something new and the feeling that this will really be a great game. The project often
makes giant leaps in short periods. The middle part of the project is mundane. The con-
cept has been proven but there is often so much work to do and the game does not
 Chapter 6: Interview: Ed Logg 111

appear to change much for all your effort. The third phase is often full of panic and
stress. This is the part just before release when you just want the project to end. The
fourth phase is one of satisfaction after the game has been released.
With the current long projects I often feel I am getting diminishing returns for my
effort, so I am happy to have the game end. In my case, almost everything I had planned
for my game has been implemented, so I am happy to call it done. Except for finding
those irritating last-minute bugs…

So after the prototype is functional, you don’t really enjoy the development
process?
Yes, I would say the bulk of the game is done after the core game concept has been
proven. However, there are often parts that prove rewarding during the long develop-
ment before the game is finished. But after doing so many games over the past thirty
years, working on, say, the user interface just does not get me all excited.
No, I would like to do a prototype and leave it to someone else to finish. But I feel I
still have the vision for the gameplay and I do not believe another person or group
would continue the gameplay as I envision it. So in the end I would feel that the game
was not what I expected, not mine anymore. I would always have the feeling that if I had
worked on it to the finish, the game would be better than what anyone else could have
done. I guess I would feel differently if I had not been as successful as I have.

Do you think focus groups or playtesting accomplishes for home games what
field testing accomplishes for coin-op?
Field testing served as a means to make sure the software and hardware was bug free
but this was a secondary benefit — this was not the real reason why it was done. Field
testing for coin-op games gives you a good idea how well the game stacks up against
other current games. It is easy to predict from the earnings and sales price how well it
will sell. Focus groups rarely gave any clear indication of how well the game would sell
either in coin-op or the consumer market.
For the consumer games,
I do not believe there is any
direct equivalent. The
playtesting or focus group
gives you some idea how well
the game will be perceived,
but in the case of Dr. Muto the
ratings did not translate into
the sales expected. I believe
the reason is when a player
goes to an arcade he can
expect to see only a few new
games. So it is likely your
game will be seen. In the cur-
rent consumer market there
are numerous titles and it is Dr. Muto
112 Chapter 6: Interview: Ed Logg

not easy to find the new games. In many cases your local games store may not even
carry the game because they have reduced the number of games they will put on
shelves. Even more important, coin-op games have a sample of gameplay, which play-
ers can glimpse to see if it interests them. The best you are going to get from the
consumer store is a few screenshots on the box. I know this is not really accurate
because we expect to see TV time for consumer games, but you need to be one of the
top games to warrant that kind of marketing money and not all games do.
For Dr. Muto this point was rather moot for another reason. The finish date was
selected for the team. We were told when it would be released, so we cut many of the
features and gameplay we would like to have seen. More importantly, player testing
was of no use because if they suggested a change there would be no time to add it or
change the game.

What role do you think AI plays in games?

In the old games AI had no involvement. Often the enemy would follow a fixed set of
rules with some randomness thrown in if necessary. These days it is entirely a different
matter. It is becoming very important for modern games. Some people have recom-
mended that, when appropriate, each project have one specially trained person
dedicated to doing the game AI. And for some games, I would agree.

Why do you think games require more sophisticated AI now?

I believe the theme and gameplay of most new games require more AI. The sim games,
the shooters, et cetera, all try to give the real sense of intelligent life competing against
you. If games do not try to mimic real life, then a set of rules may do just fine.

How important do you think it is to make the AI in a game “real”? That is, to
provide the AI only with the information the player would have in the AI
agent’s position?
It is not necessary but may lead to more believable enemy AI, so I would recommend it
in some cases. For example, in Steel Talons, the enemy gunners would not turn or fire
until they could see you visually. If there was a hill in the way or you were hugging the
ground at the end of their range, then they did not see you. This is one case where it
was necessary.

Lately, a lot of attention is being given to combining games and stories. Many
arcade coin-ops, perhaps as part of their nature, have almost no story. What do
you think about telling a story within a game?
I have never been high on stories. I feel it is absolutely necessary to have the player
grasp the theme: setting, ambience, and goals. Sometimes stories help to make the
goals easier to understand. Some games are made like a movie, so a story makes good
sense: the player feels he is the main character that he is controlling. In a coin-op game,
a story makes no sense unless it is shown in the attract mode. We do not want the
player wasting his time watching something when he could be playing or putting in
more money.
 Chapter 6: Interview: Ed Logg 113

You mentioned before that you specifically wanted to get into doing games for
the home market. Why was this?
I wanted to do home games instead of coin-op games because I saw more opportunity to
do something new in the home market.

Do you not see any future for coin-op arcade games?

I suspect coin-op games in the
arcades will tend toward
cheaper simulation rides
(physical movement or
encompassing environment),
just like you see now. They
provide something you cannot
get at home and are cheaper
than the rides at Disneyland. I
believe the coin-op arcade
market is already there. The
coin-op street market will
always need to be inexpen-
sive. So I see a consumer
platform in a coin-op box or
cheap PCBs with simple The arcade version of San Francisco Rush 2049
games that do not require long
development times.
The consumer market already dominates over the coin-op industry. I do not have
the numbers, but it is clear to me by looking at sales numbers of hit games and the dol-
lars they represent. It is sad to see the changes in the coin-op industry. I am sure glad I
was a part of the industry. I feel I was definitely in the right place at the right time.
114 Chapter 6: Interview: Ed Logg

Ed Logg Gameography
Super Breakout, 1978
Video Pinball, 1979
Asteroids, 1979
Othello (for Atari 2600), 1979
Football (four-player conversion), 1979
Centipede, 1981
Millipede, 1982
Gauntlet, 1985
Gauntlet II, 1986
Xybots, 1987
Tetris (conversion to NES), 1988
Steel Talons, 1991
Space Lords, 1992
Wayne Gretzky 3D Hockey (conversion to N64), 1996
San Francisco Rush (conversion to N64), 1997
San Francisco Rush 2 (conversion to N64), 1999
San Francisco Rush 2049 (conversion to N64
and Dreamcast), 2000
Dr. Muto, 2002
GenPlay Stack’um, 2004
GenPlay Pool Pro Online, 2004
Chapter 7
The Elements of
Gameplay

“We ended up with a game that I didn’t know how to win. I didn’t know which
were the best strategies or tactics, even though I designed all the game’s sys-
tems. That is what makes a good strategy game.”
— Julian Gollop, talking about his game X-Com: UFO Defense

W hat are the game design elements that make up a really good game? Of
course, there is no definitive answer to such a question. Nonetheless, as a
game designer you will be expected to intuitively know the answer.
Understanding game design, as with any art form, is very much an internalized under-
standing, a “gut” reaction, a “feeling” you might have. It may be that you will not be able
to form that answer into words, but you will need to understand what aspects of a game
are strong and which are weak, and how the latter can be replaced with more of the for-
mer. Experience plays a big part in understanding what makes a game fun, experience
both as a game designer and as a game player.
Over my years of playing and creating games I have come up with my own answers
for what makes a game great, and in this chapter I discuss some of those qualities. Some
of these topics may seem fairly distinct from each other, yet to my mind they all play a
crucial role in making a good game. Certainly I cannot hope to list all of the knowledge I

115
116 Chapter 7: The Elements of Gameplay

have, since, as I mentioned, much of my understanding is more akin to a “sixth sense”

than anything I could hope to write down. But the ideas contained in this chapter should
provide a solid foundation.

Unique Solutions
For me, one of the most exciting moments of being a game designer is when I hear
someone talking about playing one of my games, and they explain a successful tactic for
a given situation that I had never considered. This could be a solution to a specific puz-
zle, a new strategy to incapacitate challenging enemies, or a method for maneuvering a
perilous canyon. I see the games I develop as creating situations in which game players
can utilize their own creativity to succeed. When players’ creativity can lead them to
solutions that I had not envisioned, it shows me that the players and I are sharing in the
creation of their experience, instead of my dictating everything. And when the players
and I share in the authorship, I feel my game is doing its job.

Anticipatory versus Complex Systems

Good designers will try to guess what players are going to attempt to do and make cer-
tain their game responds well to those actions. For instance, take an RPG that features
a puzzle that involves placing weights on a series of pressure plates. (Having put such a
puzzle in a game of my own, I would like to implore game designers to be a bit more cre-
ative than that, as pressure plates are surely one of the most overdone puzzle devices.
But I digress.) Suppose the designer leaves a conspicuous pile of rocks a few rooms
over from the pressure plate puzzle. The obvious solution to the puzzle is to use those
rocks on the pressure plates to achieve the desired results. But what if players try drop-
ping their various weapons on the plates instead? This is a perfectly valid solution that
should work equally well, provided players have weaponry of the appropriate weights.
What if players have the Summon Minor Threat spell, which allows them to summon a
variety of different small monsters? If players summon those monsters onto the pres-
sure plates, they might do the trick too.
Now the designer, having thought through the puzzle fully, can have the program-
mer add in code where the game reacts correctly if rocks, weapons, or monsters are on
the plates. This is the anticipatory school of game design, where the designer thinks of
what players might do and hardwires the game to work well with those actions. I agree
that this tactic is surely better than allowing for just one solution. However, what if
players think of some other weight they can place on the pressure plates? What if play-
ers use their Berkshire Blizzard spell on the pressure plates, causing snow to fall on
them? Enough snow could conceivably pile up on the plates to have a significant weight.
However, if the game has been hardwired only for rocks, weapons, or monsters, the
game will not react appropriately. Players will have thought of a perfectly reasonable
solution and the game will fail to recognize it.
Instead of hardwiring, however, what if the designer had the programmer come up
with a system where every object in the game had a weight associated with it? This
would include rocks, weapons, monsters, weather effects, blood, and any other
dynamic objects found in the game-world. If the programmer then made the pressure
plates simply measure the weight of all of the objects on top of them, regardless of their
 Chapter 7: The Elements of Gameplay 117

type, then this global solution would work for all objects. If each object was set up with a
reasonable weighting, it would not matter what objects players tried to place on the
pressure plates, as they would all work automatically.
This latter method is less of an anticipatory technique of game design; it is more
holistic and systems-based in its approach. It relies more on creating reliable, consis-
tent systems with which your game will function. With these systems in place, the
game becomes more a simulation and less of a hard-coded puzzle. A game need not be a
flight simulator or a SimCity-style game to include some level of simulation; indeed
almost all games include some degree of simulation, however crude it may be. The
more designers recognize the value of simulation over hard coding and emphasize
these complex and interconnected systems in their games, the deeper their games
become. In a game with a more simulation-based approach, containing a puzzle such as
the pressure plate one described above, the designer and programmer come up with a
series of success conditions for that puzzle. Instead of “the puzzle is solved if players
use rocks, weapons, or monsters to offset the plates,” the rule is “the puzzle is solved
when the plates are offset by the correct weight being placed on top of them.” Certainly
the example of this puzzle is a simple one, but the same techniques can be applied to
much more sophisticated and interesting systems that engender a wide variety of suc-
cessful playing styles.

Emergence
The Civilization games
are some of the best
examples of complex
gameplay emerging out
of multiple consistent
systems running in
parallel. Pictured here:
Civilization II.

It is the development of numerous robust and logical systems that leads to

player-unique solutions to situations in the game. One could describe these solutions
as “emergent” from the systems design of the game, a popular buzzword in game
design circles. Establishing a game universe that functions in accordance with logical
rules players can easily understand and use to their advantage allows those same play-
ers to come up with their own solutions to the problems the game presents. Nothing is
more rewarding for players than devising some obtuse, unobvious method for solving a
118 Chapter 7: The Elements of Gameplay

puzzle or a combat situation and then having it actually work. The more complex sys-
tems work correctly and concurrently with each other, the more interesting and varied
the solutions to situations become. Consider the game Civilization, with its numerous
systems running in parallel. These systems work together to create some of the most
compelling gameplay ever pressed to disk.
At the same time, many designers fear players discovering emergent strategies
they can use as exploits: tactics that will allow players to finish a game too easily, skip-
ping a lot of the fun. With its complex systems design, Civilization was a prime
candidate for player exploitation. In the original game, players were able to exploit a
rush strategy where they would never build cities of a size larger than two while stay-
ing in the most primitive form of government, quickly sweeping over the world and
winning the game prematurely. This strategy was so effective it was clearly the best
strategy to use and allowed players to miss 90 percent of the game. Sid Meier ended up
patching the game to increase the citizens’ unhappiness when this strategy was used,
fixing the exploit. In this case the emergent tactic revealed a shortcut through the game
that needed to be fixed.
Another example of this sort of emergent strategy that might be regarded as an
exploit can be found in the original Centipede. Anyone who has ever played the game
knows that the piling up of mushrooms is one of the greatest impediments to a long
game, and many players understand the importance of keeping the play-field as clear as
possible. As the devotees of the game pumped quarter after quarter into the game, they
began to notice some patterns. First, they recognized that the flea is responsible for
dropping most of the problematic mushrooms, though destroyed centipede segments
also drop them. Second, they saw that the flea does not come out on the game’s first
wave. Third, it was observed that the flea is triggered by the absence of mushrooms in
the bottom half of the screen. Thus the famous “blob” strategy was developed, one that
the game’s designer, Ed Logg, never anticipated. To use the blob strategy, players
would clear all of the mushrooms from the board on the first wave, and then allow
mushrooms to survive only on the bottom-right quadrant of the screen. If, through
careful destruction of the centipede, the players only allow mushrooms to be created in
that section of the screen, the flea will never come out, making the game much simpler
indeed. This is an emergent solution to racking up a high score at Centipede, one which
players no doubt felt quite proud of when it was discovered. It was a tactic that Logg, as
the game’s creator, did not even know was there to be found. Unlike the Civilization
rush strategy described above, the blob strategy was so hard to pull off that it was not
truly an exploit, merely an alternate tactic that required a good deal of player skill.
Though some designers become distressed whenever an unanticipated strategy
emerges in their game, it is important to look at the given tactic and determine if it
ruins the player’s experience or if it is a technique equally or even more fun than what
the designer had planned. If such emergent strategies do not completely break the
game, they need to be viewed as a boon to the game’s depth and the direct result of good
game design.
 Chapter 7: The Elements of Gameplay 119

Non-Linearity
Non-linearity is another buzzword in the game industry, but like emergence, there is a
lot of value to the concept. Non-linearity is what interesting gameplay is all about, and
many game developers forget this in the heat of production. Non-linearity gives
interactivity meaning, and without non-linearity, game developers might as well be
working on movies instead. The more parts of your game that you can make non-linear,
the better your game will be. Unfortunately, on the flip side, the more non-linearity
your game has, the more time consuming and difficult it will be to develop.
In general, when someone says something is linear they mean that it follows a line.
A line is a series of points connected in either two- or three-dimensional space, where
one can find any point on that line using a specific equation, such as, in a 2D case, y =
mx + b. In layman’s terms, this means that a line must be straight. If one considers any
two points on that line, say A and B, there is only one way to navigate that line from A to
B. There are no choices to be made; one simply must navigate all of the points between
A and B. Outside the world of mathematics, we can consider reading a book to be a lin-
ear experience. If one is reading a 323-page book and if one does not skip pages or
chapters, there is only one way to read the book: by starting on page 1 and reading all of
the pages leading up to page 323.
Games, however, are non-linear works. In the game of chess, there are multiple
ways to capture the opponent’s king, to move from the game’s predetermined starting
state to its conclusion. Indeed, there are a vast number of different ways to be victori-
ous in chess, and that variety is what keeps the game interesting. These choices make
chess non-linear. Suppose the chessboard were one-dimensional instead of two, each
player’s pieces could only move in one direction, and each player had only one piece.
This version of chess is a linear one, since there are no meaningful choices for players
to make and the outcome of every game is completely predetermined. And, as a result,
it would not be any fun to play.

Types of Non-Linearity
So when we say we want our games to be non-linear, we mean we want them to provide
choices for players to make, different paths they can take to get from point A to point B,
from the game’s beginning to its end. We can mean this in a number of ways: in terms of
the game’s story, in terms of how players solve the game’s challenges, in terms of the
order in which players tackle the challenges, and in which challenges players choose to
engage. All of these components can contribute to making a game non-linear, and the
more non-linearity the developer creates, the more unique each player’s experience
can be. Furthermore, the different non-linear components can interact with each other
to make the whole far greater than the sum of its parts.
• Storytelling: I discuss non-linear storytelling in more detail in Chapter 11,
“Storytelling.” Of course, a non-linear story line is necessarily tied to non-linear
gameplay, and no one would bother to try to make a story non-linear if the game
itself offered players very little in the way of meaningful decisions. Storytelling is
perhaps one of the most neglected parts of games in terms of non-linearity, with
120 Chapter 7: The Elements of Gameplay

many developers allowing for non-linear gameplay while constraining their games
to a completely linear story.
• Multiple Solutions: I discussed above how a well-designed game will enable
players to come up with their own solutions to the challenges the game presents.
Not every player will go about solving a situation in the same way, and, given that
these alternate solutions are reasonable, almost any challenge must have multiple
ways for players to overcome it. Having multiple solutions to the individual
challenges within a game is a big part of non-linearity; it enables players to have
multiple paths to get from point A (being presented with the challenge) and point B
(solving the challenge).
• Order: Beyond being able to figure out the solutions to challenges in unique ways,
players will appreciate the ability to pick the order in which they perform
challenges. Many adventure games have made the mistake of being overly linear
by allowing players access to only one puzzle at a given time. In order to even
attempt a second puzzle, players must complete the first one. That is a linear way
of thinking, which proves especially frustrating when players get stuck on a
particular puzzle and, due to the game’s linear nature, can do nothing else until that
puzzle is solved. Giving players choices of different puzzles to solve allows them to
put aside a troubling puzzle and go work on another one for a while. After
completing the second puzzle, players may return to the first refreshed and
revitalized, and thereby have a better chance of solving it.
• Selection: Another way of making a game non-linear is to allow players to pick and
choose which challenges they want to overcome. Say that between point A and
point B in a game there lies a series of three challenges, X, Y, and Z, which are
non-order dependent, that is to say, players can do these challenges in any order
they wish. What if, once players surmount challenge X, they do not have to go back
and solve challenge Y or Z, they can simply move on to point B in the game,
perhaps never returning to Y or Z? The same is true if players initially choose to
tackle Y or Z instead of X. Any one of the choices will allow players to proceed. The
advantage is that if players find challenge X to be insurmountable, they can try
challenge Y or Z. This greatly decreases the chance of players becoming
permanently stuck. It need not be the case that Y is easier than X; the mere fact
that it is different may allow players a better chance of getting through it,
depending on their strengths. Other players may find X to be easier than Y or Z, but
giving players a choice of which challenges they take on allows them to exploit
their own personal skills to get through the game. Of course, after completing
challenge X, players may still have the option of going back and completing the Y
and Z challenges, perhaps just for the fun of it or because overcoming those
challenges somehow improves their chances down the line. Perhaps completing Y
and Z gives their player character greater overall experience or riches. This type of
non-linearity can also be used to add totally optional side-quests to the game.
These challenges are not strictly required for players to get to the end of the game,
though they may make it somewhat easier or merely provide an interesting
diversion along the way. Whatever the case, these optional challenges provide an
extra degree of non-linearity, further customizing players’ experiences.
 Chapter 7: The Elements of Gameplay 121

Implementation

Odyssey is an extremely
non-linear game,
allowing the player to
solve puzzles in whatever
order he chooses and to
select which quests he
wants to go on. The
game almost always
provides more than one
solution to any given
puzzle.

My first game, Odyssey: The Legend of Nemesis, is without doubt the most relent-
lessly non-linear game design I have ever done, and includes examples of all the types
of non-linearity described above. Odyssey is an RPG and takes place on an archipelago
that includes seven primary islands for players to explore. Though players are required
to complete at least one quest on the first island before moving on to the rest of the
game, there are two quests, each with multiple solutions from which players may
choose. Indeed, clever players can skip the quests entirely if they figure out how to rob
a particular townsperson. (In fact, this was an emergent behavior that I had not antici-
pated, but which fortunately made sense and did not derail the game significantly.)
From there, players are able to move freely about the next five islands, picking which
ones they want to explore and which they prefer to just pass through. Indeed, all that is
required for players to reach the seventh island and the end-game is successful naviga-
tion of each island, killing the monsters that get in their way. Of course, killing those
creatures is made significantly easier if players receive the rewards for completing the
quests. But if players so choose, they can skip the entire middle of the game. Of course,
few players have done this, preferring instead to explore the different quests and situa-
tions they encounter there. Nearly every one of these quests has multiple ways for
players to solve it, with their actions having a direct impact on how each of the island’s
mini-stories resolves. Finally, the game itself has multiple endings for players to
explore, endings that suit the different overall goals players may have: survival,
revenge, or a sort of justice and harmony. Though the game had a very definite story, I
am happy to say that I doubt very much that any two players ever experienced it in
exactly the same way.
Overall, my game The Suffering was significantly less non-linear than Odyssey, but
still I applied many of the same non-linear storytelling techniques in order to give the
game’s story depth. The Suffering makes each player’s experience unique through its
morality system, which assesses how the game is being played and then determines
122 Chapter 7: The Elements of Gameplay

the player character’s past and changes how the characters in the present speak to him.
As a horror game, the plot was kept somewhat vague on purpose, with players needing
to fill in many of the blanks themselves. Furthermore, each player was likely to have a
different subsection of the overall story, since much of the story is contained in optional
side areas. Indeed, players who blaze through the game full speed ahead will miss a lot
of the plot, while those who play normally will probably see about half of what there is to
be found. This means there are many different ways to experience the story and players
will have different impressions of it depending on how they play. Indeed, during devel-
opment there was a lot of concern about players missing too much of the game by
running through it quickly since there are relatively few bottlenecks to block progres-
sion. In the end, though, through gameplay testing and the feedback we received after
the game shipped, we realized that almost all players will explore the game more than is
required of them merely because they are interested in it. Similarly, players will fight
creatures they don’t strictly need to. It is important to remember that players want to
play a game to have fun, and only the most masochistic will deliberately ruin their play
experience. Thus you don’t need to worry about the game’s exploits quite as much as
making sure the game is fun if played by cooperative players.
On the puzzle side of things, The Suffering is somewhat less successful in terms of
non-linearity: many of the puzzles have multiple solutions, but an equal number do not.
Though most of the objectives were planned to have multiple ways of completing them,
we had several situations where one solution would involve an exciting payoff while the
other did not. Our producers were concerned gamers would miss too much by choosing
the alternate solution, and thus we ended up cutting some of the less exciting alterna-
tives. This leads to an important rule of thumb: if you want to have multiple solutions or
paths, they should all be equally compelling so players will not feel cheated at having
picked the much less spectacular path. Another failed bit of non-linearity in The Suffer-
ing involved a particular level that was initially designed to be extremely non-linear. In
this level, there were originally three separate paths leading to the level’s end.
Through our gameplay testing we learned that players were extremely confused by the
three paths, with almost all players looping back to the beginning of the level and then
being confused as to where they were. Admittedly this particular problem was due to
poor level design, but this is a case where non-linearity ended up hurting the player’s
experience, and we ended up reworking the level flow in the final game.
Non-linearity is an extremely powerful tool to use in designing a game, and the
above descriptions of the types of non-linearity a designer can employ may seem obvi-
ous to the reader. What is astonishing, then, is how many games fail to provide any
substantial non-linearity for players, instead insisting that players play through the
game on a single line from point A to point B. One reason for this is that creating all of
these non-linear elements can be quite time consuming. Consider that between point A
and B, we have the aforementioned challenges X, Y, and Z, but players only have to
overcome one of these challenges in order to progress. Players can then continue play-
ing through to the end of the game having never interacted with challenge Y or Z. As a
non-linear game, that is the players’ prerogative. The problem arises when a cost
accountant looks at the game and tries to figure out where the game’s budget can be
trimmed. Well, obviously, if Y and Z are not strictly necessary, why bother having them
at all? Why spend a lot of money on the programming, art, and design necessary to get Y
 Chapter 7: The Elements of Gameplay 123

Working meaningful
non-linearity into The
Suffering proved quite
challenging.

and Z working when there’s a chance players will never see them? Unfortunately,
accountants are often not in touch with the finer points of game design, and when you
say, “But non-linearity is what makes this game great!” they are likely to dismiss you as
“unreasonable” or “difficult.”
Non-linearity is also often hard to pull off from a design perspective, certainly
harder than simple linearity. This may be another reason why so many designers shy
away from it at the first opportunity. Designing numerous obstacles that are different
enough to provide variety for players and apply roughly the same challenge is not an
easy task. In the X, Y, and Z challenges example, if Z is significantly easier than X or Y, it
is quite likely no one will ever bother with X or Y. In a way, a game with poorly designed
choices for players is nearly as linear as a game without any choices at all. The
non-linearity your game provides must be meaningful and useful to players or it is a
waste. Designers who think too highly of their own design skills may also avoid
non-linearity in their designs because they want players to experience every single
element of the game they decide to include. “Why spend a lot of time on portions of the
game that not everyone will see?” say these somewhat egotistical designers, missing
the point entirely. If enough people play your game, some people will surely see what
you have created, and each one of the players will have a somewhat different experi-
ence because of it. Just as a great novel will have multiple layers to its story and
different meanings that different readers will take away, even more so a game should
allow players to find their own way through the game-world and empower them to craft
their own unique experience.

The Purpose of Non-Linearity

It is important to always remember that non-linearity is included in the game to provide
players some meaningful authorship in the way they play the game. If they are forced to
stay on a specific line to get from the beginning of the game to the end, the game will
feel constrained. The challenges along that line may be brilliantly conceived, but if
124 Chapter 7: The Elements of Gameplay

players have no choice but to take them on in order, one by one, the fun they provide
will be greatly diminished.
Non-linearity is great for providing players with a reason to replay the game.
Replaying a game where players have already overcome all of the challenges is not that
much fun. In replaying a more non-linear game, however, players will be able to steer
away from the challenges they succeeded at the last time they played and instead take
on the game’s other branches. However, it is important to note that replayability is not
the main motivation for including non-linearity in your game designs. I have heard
some game designers complain that replayability is unnecessary since so many players
never manage to finish the games they start playing. So if they never finish, why add
replayability? These designers do not realize that the true point of non-linearity is to
grant players a sense of freedom in the game-world, to let players have a unique playing
experience, to tell their own story. If players want to replay the game again, that is fine,
but the primary goal of non-linearity is to surrender some degree of authorship to the
players.
Furthermore, the contention that players seldom finish games and hence the
games do not need to be non-linear is a self-fulfilling prophecy. The reason players fail
to finish games is often because they become stuck at one particular juncture in the
game. This may be a boss-monster that is too difficult, a puzzle that is too confounding,
or merely failing to find the exit from a given area. If the game were more non-linear,
however, players would have much less chance of getting stuck at any point in the
game, since the variety of paths available would increase the likelihood that players’
unique talents would be sufficient for them to make it successfully through one of the
paths.
At a Game Developers Conference talk entitled “A Grand Unified Game Theory,”
Noah Falstein suggested that when non-linearity allows players to tackle a series of
required challenges in whatever order they desire, completing one challenge should
make the others easier for players to accomplish. In the case of a collection of puzzles,
this can be done by providing players with a hint about the other puzzles once one is
completed. In the case of a collection of battles of some sort, this can be done by provid-
ing players with additional weaponry with which to survive the other battles. Whatever
the case may be, using this technique increases the chance that players will be able to
overcome the challenges at hand and get on with the game.
A note of caution: all designers should understand that non-linearity is not about
having players wander around the game-world aimlessly. If the game is non-linear to
the point where players have no idea what they are supposed to try to accomplish or
how they might go about it, the non-linearity may have gone too far. Often game design-
ers talk up their in-development games by making statements like “In our game-world,
players can do anything they want; there are no restrictions. The game is completely
non-linear!” Such a game would likely be completely annoying as well. Of course, by
the time these “completely non-linear” games have shipped, most of the non-linearity
has been stripped out and players are left solving puzzles on a rail. Somewhere between
“on a rail” games and total freedom lays an ideal middle ground, where players are left
with a sense of freedom accompanied by a sense of guidance.
 Chapter 7: The Elements of Gameplay 125

Modeling Reality
The desire to model reality in computer games is one that has driven game develop-
ment for a number of years. The more real we make the games, proponents say, the
more compelling and immersive gamers will find them. But is this always the case?
What would a greater degree of reality add to a game like Tetris or Centipede? Surely
they could not be much more immersive than they already are. Consider a game such as
Age of Empires, which is already modeled on reality. Would adding more reality to it
make it any more fun? Actually, quite the opposite is true: adding a more realistic eco-
nomic model or combat system would detract from the game’s strengths as a
macro-strategy game and quite possibly make the game more annoying than fun.
The trouble with modeling reality in games comes when titles get mired in reality
to the point where they come to resemble real life a little more than players actually
want. Alfred Hitchcock described films as “Life with the dull bits cut out.” Indeed,
games can be seen as modeling life or some aspect of life while leaving out the tedious
and boring parts. If the designer, in an attempt to achieve a greater degree of reality,
decides to include too many unnecessary and dull details, the game will likely become
tedious to play. My favorite example of this is the use of food in RPGs. Many RPGs of
the ’80s were perpetually on a quest to make themselves more real than other RPGs, to
up the ante with each new game that was released. One way designers attempted to do
this was to add a basic hunger simulation, and to require players to remember to feed
their party members periodically, lest they starve to death. Here was a “dull bit” that
did not need inclusion, especially as eating regularly scheduled meals is not the first
thing that jumps to people’s minds when they think of adventuring in fantastic worlds.
Using reality as a basis for your game has its advantages, however. First and fore-
most, it provides players with a world they are instantly familiar with, a world in which
they have some idea of what actions are reasonable and which are out of the question.
Whether in Civilization, SimCity, Deadline, or Grand Theft Auto, a properly executed
realistic setting gives players an instant “in” to your game-world. They understand or
at least think they understand how it works and what they can do to be successful in it.
Players can start playing the game and instantly have some idea of what they are sup-
posed to accomplish. A more abstract game like Centipede or Tetris, on the other hand,
has such abstract goals that players must be taught what it is they are supposed to do,
either through reading the directions or by experimenting with the game-world.
Beyond the gameplay advantages, in terms of story and setting, placing your game
in a real-world setting can be much more meaningful to players, allowing the actions
that take place in the game-world to resonate with them more deeply than if your game
were set in abstract worlds. The Sims works in part because of its well-balanced
gameplay and simulation, but also because of its real-world setting that allows players
to feel that their actions have real meaning to the simulated people they are guiding. My
game Damage Incorporated, though it admittedly had a somewhat implausible premise,
was set in the real-world and dealt with real-world issues that made the missions and
their outcomes more relevant to players than if the game had been set in outer space.
Similarly, The Suffering, despite having supernatural creatures spawning out of every
nook and cranny, was set in a believable prison environment populated by recognizable