Visit ebookball.

com to download the full version and

explore more ebook or textbook

Players Making Decisions Game Design Essentials

and the Art of Understanding Your Players 1st
Edition by Zack Hiwiller ISBN 9780134394640
013439464X
_____ Click the link below to download _____
https://ebookball.com/product/players-making-decisions-game-
design-essentials-and-the-art-of-understanding-your-
players-1st-edition-by-zack-hiwiller-
isbn-9780134394640-013439464x-23556/

Explore and download more ebook or textbook at ebookball.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Making Games Better The Art and Process of Game Design and
Development 1st Edition by Andrew Mayer, Will Guy ISBN
B01L9P9WRG
https://ebookball.com/product/making-games-better-the-art-and-process-
of-game-design-and-development-1st-edition-by-andrew-mayer-will-guy-
isbn-b01l9p9wrg-23592/

Bowls Making the most of your game 1st Edition by Patrick

Hulbert ISBN 0719812976 9780719812972

https://ebookball.com/product/bowls-making-the-most-of-your-game-1st-
edition-by-patrick-hulbert-isbn-0719812976-9780719812972-23572/

The HEAD Game High Efficiency Analytic Decision Making and

the Art of Solving Complex Problems Quickly 1st Edition by
Philip Mudd ISBN 9780871407894 0871407892
https://ebookball.com/product/the-head-game-high-efficiency-analytic-
decision-making-and-the-art-of-solving-complex-problems-quickly-1st-
edition-by-philip-mudd-isbn-9780871407894-0871407892-23566/

The Visual Effects Producer Understanding the Art and

Business of VFX 1st edition by Charles Finance, Susan
Zwerman ISBN 1138133272 978-1138133273
https://ebookball.com/product/the-visual-effects-producer-
understanding-the-art-and-business-of-vfx-1st-edition-by-charles-
finance-susan-zwerman-isbn-1138133272-978-1138133273-12040/
Making It All Work Winning at the Game of Work and the
Business of Life 1st Edition by David Allen ISBN
0143116622 9780143116622
https://ebookball.com/product/making-it-all-work-winning-at-the-game-
of-work-and-the-business-of-life-1st-edition-by-david-allen-
isbn-0143116622-9780143116622-23582/

3D Art Essentials The Fundamentals of 3D Modeling

Texturing and Animation 1st Edition by Ami Chopine ISBN
113613221X 9781136132216
https://ebookball.com/product/3d-art-essentials-the-fundamentals-
of-3d-modeling-texturing-and-animation-1st-edition-by-ami-chopine-
isbn-113613221x-9781136132216-13914/

(Ebook PDF) The Problem of Assessment in Art and Design

1st edition by Trevor Rayment 1841509574 9781841509570
full chapters
https://ebookball.com/product/ebook-pdf-the-problem-of-assessment-in-
art-and-design-1st-edition-by-trevor-
rayment-1841509574-9781841509570-full-chapters-22964/

Game Sound An Introduction to the History, Theory, and

Practice of Video Game Music and Sound Design 1st edtion
by Karen Collins ISBN 026253777X 9780262537773
https://ebookball.com/product/game-sound-an-introduction-to-the-
history-theory-and-practice-of-video-game-music-and-sound-design-1st-
edtion-by-karen-collins-isbn-026253777x-9780262537773-24998/

Financial Times Prentice Hall Presenting to Win The Art of

Telling Your Story 1st Edition by Jerry Weissman
0130464139 9780130464132
https://ebookball.com/product/financial-times-prentice-hall-
presenting-to-win-the-art-of-telling-your-story-1st-edition-by-jerry-
weissman-0130464139-9780130464132-12516/
Players
Making
Decisions
Game Design Essentials
and the Art of Understanding Your Players

ZACK HIWILLER
Players
Making
Decisions
Game Design Essentials
and the Art of Understanding Your Players

ZACK HIWILLER
Players Making Decisions:
Game Design Essentials and the Art of Understanding Your Players
Zack Hiwiller

New Riders
www.newriders.com
To report errors, please send a note to [email protected]
New Riders is an imprint of Peachpit, a division of Pearson Education
Copyright © 2016 by Zachary Hiwiller

Senior Editor: Karyn Johnson

Development Editor: Robyn G. Thomas
Production Editor: Danielle Foster
Copyeditor: Rebecca Rider
Proofreader: Patricia Pane
Compositor: Danielle Foster
Indexer: FireCrystal Communications
Interior Design: Danielle Foster
Cover Design: Mimi Heft, with Zack Hiwiller

Notice of Rights
All rights reserved. No part of this book may be reproduced or transmitted in any form by any
means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written
permission of the publisher. For information on getting permission for reprints and excerpts, con-
tact [email protected].

Notice of Liability
The information in this book is distributed on an “As Is” basis without warranty. While every pre-
caution has been taken in the preparation of the book, neither the author nor Peachpit shall have
any liability to any person or entity with respect to any loss or damage caused or alleged to be
caused directly or indirectly by the instructions contained in this book or by the computer soft-
ware and hardware products described in it.

Trademarks
Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in this book, and Peachpit was aware of
a trademark claim, the designations appear as requested by the owner of the trademark. All other
product names and services identified throughout this book are used in editorial fashion only and
for the benefit of such companies with no intention of infringement of the trademark. No such use,
or the use of any trade name, is intended to convey endorsement or other affiliation with this book.

ISBN-13: 978-0-134-39675-0
ISBN-10: 0-134-39675-8

987654321

Printed and bound in the United States of America

Dedication
To my grandmother, Betty Hiwiller (1927–2014), who always wanted me to be a writer.
Yes, textbooks count, Grandma.

Acknowledgments
First, I would like to thank my wife, Gloriana, and my parents, Dan and Jan Hiwiller,
for always tolerating me and encouraging me. Although the former would have been
enough, the latter is greatly appreciated.

I would like to thank everyone who provided comments and support on early drafts.
Many helped, but Mark Diehr, Matthew Gallant, and Scott Brodie did a yeoman’s job on
a short turnaround, even though they have extremely busy professional careers. If
Uncharted 4 is delayed, please do not blame me.

Everything that looks professional within is thanks to the wonderful team at Pearson
including Robyn Thomas, Rebecca Rider, Danielle Foster, Patricia Pane, and
Karyn Johnson.

I would like to use this space to thank Jesse Schell for convincing me game design could
yield a career and be intellectually interesting. I’d like to thank Jon Dean, James
Hawkins, and Jason Barnes for being early examples to me of what leadership looks like
among game industry professionals. I would also like to thank all my friends and col-
leagues at Project Horseshoe, the best community of game designers in the world.

Finally, I cannot forget the dedicated staff and faculty of the Game Design program at
Full Sail University who have helped me refine my approach to communicating the
practice of game design, including, but not limited to, Ricardo Aguilo, Dax Gazaway,
D’Juan Irvin, Christina Kadinger, Michael Lucas, Kingsley Montgomery, Andrew
O’Connor, Mark Pursell, Brian Stabile, and Lee Wood.
iv PLAYERS MAKING DECISIONS

About the Author

Zack Hiwiller is a game designer, educator, and writer who lives in Orlando, Florida.
He is a department chair for the Game Design degree program at Full Sail University
and does consultant work for many large and small companies. Previously, in addition
to independent projects, he was a designer at Gameloft and Electronic Arts. He holds a
Bachelor’s degree in Information Systems from Carnegie Mellon University and a
Master’s degree in Modeling and Simulation from the University of Central Florida. His
writings at hiwiller.com have been reposted by Kotaku, GameSetWatch, and other sites
and have reached over 2 million readers. You have probably seen something of his
reposted without attribution on sites like 9GAG, BuzzFeed, TheCHIVE, and others.
Mark Zuckerberg used an image from one of his blog posts in his keynote at the 2011
F8 conference, and although he would have liked to have been cited, he actually
thought it was pretty cool. In the fall months, he serves as an official for high school
football games in central Florida.
Contents
Preface xii
Who Is This Book For? xv
How Is This Book Organized? xvi
PART 1 Getting Started 2
1 What Is a Game Designer? 4
Responsibilities of a Game Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Attributes of a Game Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Make Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Cultivate Your Gardens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
On Ontology and Dogma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Formalism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Problem Statements 19
Defining the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Low-Hanging Fruit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Functional Fixedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Development Structures 28
Production Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Starting Practices 38
Analog Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Theme and Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Designing for Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Opening Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

v
vi PLAYERS MAKING DECISIONS

PART 2 Prototypes and Playtesting 48

5 Paper Prototyping Development Techniques 50
Software and Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
InDesign Data Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 Playtesting 63
Playtesting Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Playtesting Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Listening to Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Finding Playtesters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Iterating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7 Playtesting Methods 73
The Testing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Keep Playtesters Talking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A/B Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Self-Playtesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8 Prototypes and Intellectual Property 80

Do I Need an NDA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Ideas and Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

PART 3 Meaningful Decisions 84

9 Flow and the Fundamental Game Design Directive 86
Game Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Interest Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Learning Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Individual Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

10 Decision-Making 101
Player Agency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Anatomy of a Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Less-Interesting Decision-Making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
 Contents vii

More-Interesting Decision-Making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

11 Randomness 117
Completely Random Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Completely Skill-Based Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Fairness and Mitigating Randomness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

12 Goals 124
How Players Determine Game Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Criteria for Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Solving Goal Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

PART 4 Describing Game Elements 134

13 Mechanics, Dynamics, and Aesthetics (MDA) 136
What Are Games About? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
More Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

14 Milieu 151
What Is Milieu? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
Polish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Player Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Milieu as Design Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

15 Rules and Verbs 163

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Qualities of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Types of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Verbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

16 Balance 170
Symmetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Self-Balancing Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Progression and Numeric Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
viii PL AYERS MAKING DECISIONS

Balance Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

17 Feedback Loops 183

Positive Feedback Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Negative Feedback Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Feedback Loops in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Fixing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

18 Puzzle Design 193

What Is a Puzzle? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Possibility Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Breadcrumbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Features of Ineffective Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Types of Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Other Puzzle Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

PART 5 Game Theory and Rational Decision-Making 216

19 Equilibria in Normal Form Games 218
The Prisoner’s Dilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Solving Games Using Strict Dominance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Using (and Abusing) Dominance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Zero-Sum Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Stag Hunt and Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Determining Nash Equilibria in a Larger Matrix . . . . . . . . . . . . . . . . . . . . . . . . 228
Mixed Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Stag Hunt Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

20 Sequential and Iterated Games 235

Game Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Promises and Commitment Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Iterated Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Experimenting with Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Successful Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
 Contents ix

21 Problems with Game Theory 247

Rational Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
The Dollar Auction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
The “Guess Two-Thirds” Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Second-Price Auctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

22 Marginal Decision Analysis 255

Marginal Nuggets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Balance on Margins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

PART 6 Human Behavior in Games 262

23 Behaviorism and Schedules of Reinforcement 264
Operant Conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Schedules of Reinforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Anticipation and Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Ethical and Practical Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

24 Learning and Constructivism 275

Historic Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Novices and Experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Cognitive Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Expertise Reversal Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Split-Attention Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Tutorials and Learning Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

25 Motivation 287
Two Types of Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
What’s the Problem with Rewards? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Self-Determination Theory and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Competition and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Personality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Other Motivation Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
x PLAYERS MAKING DECISIONS

26 Human Decision-Making 296

Mental Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Attribution Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Misunderstanding Randomness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Anchoring and Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Understanding Value in Uncertain Situations . . . . . . . . . . . . . . . . . . . . . . . . . 304
Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Framing Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

27 Attention and Memory 311

Attention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Helping with Memory Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Perception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

PART 7 Game Design Tools 324

28 Documentation and Written Communication 326
The Game Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
The GDD Creation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Documentation for Tabletop Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
States and Flowcharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

29 Probability 343
Probability Is Fancy Counting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Adding Die Rolls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Example: The H/T Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Being Careful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

30 Spreadsheets for Simulation 361

Why Use Spreadsheets? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Goal Seek and Solver in Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
One-Way Data Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
 Contents xi

31 Monte Carlo Simulation 385

Answering Design Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Hot Hand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Monty Hall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Once Around the Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Martingale Betting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

32 Presenting Ideas 405

The Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Text on Slides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Data-Ink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Do Not Waste Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Acquiring Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Example: State of Mobile Games 2014 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Pitch Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

PART 8 The Game Design Business 424

33 Profit, Loss, and Metrics 426
Profit and Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Virality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Cash Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

34 Sustainable Lifestyles 438

Life in AAA Digital Game Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Life as an Independent Developer of Digital Games . . . . . . . . . . . . . . . . . . . . 441
Life in Tabletop Game Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Market Luck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Conclusion 446
Ludography 450
Index 455
 Preface
“If you wish to make an apple pie from scratch, you must
first invent the universe.”
—CARL SAGAN

This Carl Sagan quote from Cosmos intends to cheekily point out that even a simple
object like an apple pie contains a multitude of layers, depending on your level of
analysis. Although the baker feels that the apples, sugar, and flour are the funda-
mental building blocks of an apple pie, the physicist sees down to the atoms and
fundamental particles that make up the pie itself. It is a profound and long-lasting
quotation because of the disconnect that the listener experiences. Making an apple
pie is prosaic. Inventing the universe is deity-level stuff.

Teaching game design offers a similar conundrum. Making games is fairly easy, as is
apparent from looking at the number of available games. For example, when you
look at the games available for just a single platform (iOS) in a single country (the
US) at the time of this writing, you’ll see that there are nearly 400,000 games avail-
able.1 In addition, Over 110,000 analog games are listed in the BoardGameGeek.com
database.2 And, of course, the number of games children create every day on play-
grounds all across the world is uncountable. With so many games coming out every
day, games surely must be easy to make. As a result, teaching about games must be
fairly straightforward and simple.

Unfortunately, that is not true.

The primary reason is that there is no reliable algorithm that we can use to create
things as wildly disparate as Chess, Grand Theft Auto V, Red Rover, pole vaulting
meets, and Jeopardy!. A cursory listing of the skills a game designer of any type will

1 App Store Metrics. (n.d.). Retrieved July 13, 2015, from http://www.pocketgamer.biz/metrics/app-store/
app-count/.
2 BoardGameGeek. (n.d.). Retrieved July 13, 2015, from https://boardgamegeek.com/browse/boardgame.

xii
 Preface xiii

find useful includes mathematics, psychology, computer programming, composition,

rhetoric, drafting, architecture, art history, philosophy, economics, business, history,
education, mythology, and animation. I stopped the list not because it was complete,
but because I think the list—as incomplete as it is—makes the point that game design
is remarkably multidisciplinary.

Because no algorithm exists, we have to attempt to shoehorn the facts and methods
of a universe of disparate disciplines to make game design heuristics. Meanwhile,
the impatient student just wants to make a simple apple pie.

When I first left the world of full-time development of video games to teach game design,
I faced this very problem of distilling a vast universe down to a few salient points. I vora-
ciously consumed every book I could find about design or game design and found that
they largely talked about the process from a descriptive perspective. That was useful in
some aspects, but not useful when I was looking to teach a prescriptive method. Most
game design books were ludicrously padded with obvious statements that were not at all
helpful to aspiring or professional designers. Some books, like Schell’s Art of Game
Design and Salen and Zimmerman’s Rules of Play did a great job of merging descriptive
and prescriptive insights from numerous areas of study and then backed up these anec-
dotes with external best practices.3, 4 As my library expanded, I found more and more
areas that I wanted to share with students, but unless I wanted to assign them hundreds
of dollars worth of (sometimes overly academic, sometimes out-of-print) reading materi-
als, I had no way to easily teach lessons that would have helped me professionally if
someone had taught them to me in my apprentice years. This is the curse of a multidisci-
plinary field—the sources for insights are limitless, so collating knowledge into a
curriculum eventually expands like a gas to fill whatever space you have.

I have created games professionally on over a dozen platforms. I have created large physi-
cal games for corporate retreats; I have created interactive books for tablets; and I have
created free-to-play games in a brutally competitive market. These platforms seem like
they share little in common. Some topics make sense only in terms of analog games, or
single-player games, or multiplayer games. But some topics transcend platforms and are
timeless. Less than ten years ago, mobile games had few established design patterns.
Less than ten years ago, no digital social networks supported formal games. Less than
thirty years ago, networked games in general were a quiet niche. What platforms will sup-
port the games ten years from now? Thirty years from now? What game design concepts

3 Schell, J. (2008). The Art of Game Design: A Book of Lenses. Amsterdam: Elsevier/Morgan Kaufmann.
4 Zimmerman, E., & Salen, K. (2003). Rules of Play: Game Design Fundamentals. Cambridge, Mass.: MIT Press.
xiv PL AYERS MAKING DECISIONS

will help support the game designers of the future? I cannot possibly claim to know the
answer to those questions. But I can provide tools to support game designers today, and
I can present them in the most evergreen way I know in order to sustain their relevance.
In time, concepts in this book will be updated, expanded, or even retired as the industry
gains greater understanding of how we game designers complete our magic.

Teaching has been incredibly challenging and rewarding. Just as my career in game
design stemmed from a need to constantly learn about as many things as possible, my
teaching career has reflected that as well. Research is enlightening, but it is students who
provide me with unparalleled perspective into how to explain what game design actually
is and how to do it well. This book is another well-disguised ploy for me to learn more, to
pull insights from multiple disciplines, and to share new ideas with others.

Thank you for the opportunity,

—Zack Hiwiller
November 2015
Who Is This Book For?
This book is for those who are interested in what elements are involved in the design
of games. Its purpose is to introduce the knowledge areas that are most helpful for
understanding game design. This book is not a manual on how to design a game.
There is no such book possible. Neither is it a book that claims to let one in on all the
“secrets” of successful game design. Anyone promising that should not be trusted.
Nor is this a book to teach a specific programming language or scripting toolset.
Those books can be incredibly useful, but go obsolete quickly. This book focuses on
concepts that can be used to help you understand the design of any type of game—
analog or digital.

xv
 How Is This Book
Organized?
This book is split into eight sections, each of which covers a topic I feel is essential
to being a game designer—no matter the platform—and is not completely obvious to
new designers:

•• Part 1,”Getting Started,” is about how to start from nothing. Although some
games are iterations of previous games, most start with just the seed of an idea.
What should that seed look like? What are some prerequisite elements that will
help you organize your ideas into an actionable project?
•• Part 2, “Prototypes and Playtesting,” talks about how to plan and test your game
before it is a final product. There is a pervasive myth among novice designers that
games are largely birthed finished from idea to product, with only moderate
tweaking along the way. This section sets out to debunk that myth and provide
designers with the tools and inspiration required to make quick, testable versions
of their games.
•• Part 3, “Meaningful Decisions,” covers one of the most interesting topics in
games: decision-making. It is incontrovertible that interactivity is one of the key-
stone characteristics of games. Interactivity means that the players make some
decisions that the game reacts to. How do designers present these decisions?
What makes for interesting decision-making?
•• Part 4, “Describing Game Elements,” covers a number of topics concerning the
different elements of games and different considerations thereof. There is little
uniformity when talking with designers and academics about how game ele-
ments should be classified or applied, so this section takes a cross-section of the
most pragmatic approaches for actually designing games.
•• Part 5, “Game Theory and Rational Decision-Making,” considers how players
should behave were they to act rationally. By examining game decisions from this
perspective, designers can remove elements that should be consistently never
chosen. This leaves players with decisions between possibly interesting options.

xvi
 How Is This Book Organized? xvii

•• Part 6, “Human Behavior in Games,” eschews the convenient fable of the rational
player and looks to the realm of psychology to try to understand how real human
players actually act. If games are truly about decision-making, then the whole
branch of study spun off from psychology and economics that explores how humans
actually make decisions is relevant to game design.
•• Part 7, “Game Design Tools,” considers the different tools designers use to document,
analyze, and communicate ideas, such as the universally misunderstood game
design document (GDD).
•• Part 8, “The Game Design Business,” considers the craft of game design as it relates
to business. The old joke that is appropriated for nearly every industry is this: “How
do you make a small fortune in the games business? Start with a large fortune.” If a
designer’s craft is done for more than just a hobby, she must understand the require-
ments of the business aspects of game design.
 1
PART

Getting Started
Ideas are like stars—numerous and dazzling,
but it takes a lot of work to confirm life near one.
—DANIEL SOLIS
I teach game design to students in one of the larger game design programs in the world.
I see hundreds of students a year, and I see a fear in them. That fear is that they have a
desire—to be a game designer—and they don’t know what transition they will have to go
through to become one. The role seems so glorious and fulfilling, so certainly there must
be a change between their present, mundane self and their future-inspired “artiste” self.
Many seem to believe that a professor will come down from a mountaintop with stone
tablets, they will have some divine epiphany, and all will become clear. Even you, dear
reader, likely have some watered-down version of that belief. Otherwise, why would you
be reading a book about game design?

The problem with this meme is that game design itself has no gatekeepers. It doesn’t
need them. If you fail (and you will), so what? Ophthalmologists, for example, have hefty
barriers for entry into their profession because their failures come with major conse-
quences. If a game designer fails at making a game, then maybe someone just has less
fun for a little while.

Game design requires little specialized knowledge. Plenty of specialized knowledge

exists that helps (hence this book), but nearly all of it has been gleaned from the trial
and error of designers who have come before and failed.

When I tell students that they can be a game designer today, I tend to get glassy-eyed
stares. It is true: Anyone can make a card or board game with commonly found materials.
Even digital games are easier to throw together these days than ever before with tools
like GameMaker, Twine, and Perlenspiel. Where do you start? You make a game. You put
one foot in front of the other.
 1 What Is a Game Designer?
The best of men
That e’er wore earth about him, was a sufferer,
A soft, meek, patient, humble, tranquil spirit,
The first true gentleman that ever breathed.
—THOMAS DEKKER

Asking the question of what a game designer is seems pedantic,

especially to someone who has chosen to read a book about
game design. Yet so many people have misconceptions of game
designers’ role, abilities, and responsibilities, that it’s necessary
to address this topic right away.

4
 What Is a Game Designer? 5

Responsibilities of a Game Designer

Game designers have a myriad of responsibilities that often differ depending on the
type of game and development environment. Making a print-and-play card game for
free release on the Internet demands different skill sets than designing for a yearly,
iterative, big-budget software title. However, many similarities bubble to the surface:

•• ESTABLISH DESIGN GOALS AND PLANS ON HOW TO REACH THEM. Game design is rarely a
jam session where you use automatic writing to document ideas as they come to you.
Game design is problem solving to meet goals. Without clear goals and plans on how
to achieve those goals, the game designer is just riffing. Many designers are content
with riffing because it’s more difficult to prove the design ideas wrong and it protects
their ego. However, the most effective designers, those who end up with a game that
reflects their original intent, are those who problem-solve within the framework of
understood and well-defined problems.
•• THINK IN SYSTEMS. Games are interactive systems. Some have more interactive depth
than others. No matter how nuts-and-bolts the designer is in dealing with the day-to-
day tasks of game development, it’s absolutely essential that she have a deep
understanding of how all the game’s systems work together. It is not enough to know
how a feature works in isolation or to apply normative values like “good” or “bad” to
individual implementations or features.
Here’s an example: I once worked on a yearly iterative American football video game.
A feature request was made where mistakes on the field would lower the probabilities
that, say, the quarterback would hit his targets effectively, or receivers would run cor-
rect routes, and so on. This is fine in theory. However, a lack of understanding for
positive feedback loops and how the game’s unique systems function under-the-hood
and are revealed to the player can lead to disastrous results. When implemented, the
feature caused the first player who made a mistake to enter a death spiral of ineptitude
as his onscreen players followed mistakes with more mistakes. Eventually, the game
looked buggy as quarterbacks passed to empty field positions because their ratings
dropped so low. Players had no idea what was going on because these systems were
not revealed through the user interface, so they complained that the game was broken.
The designer failed in understanding both the system internally (the feedback loop
problem) and externally (the user-interface problem).
A contingent of practitioners exists on both the bootstrap indie end and the mega-
millions publisher end of the spectrum that has no time for any consideration of
game design theory. How dare anyone tell these practitioners how to make a game?
Their process boils down to a complicated dance of “guess and check.” They put
6 PLAYERS MAKING DECISIONS

something they think is “good” into a game—maybe it’s good or maybe it’s not. It’s
the most rugged form of determinism—wherever they end up was where they meant
to go all along.
Good design is not just whatever works or whatever sells. That is a koan at best. The
study of game design is an attempt to find repeatable, predictive things that help game
designers meet their design goals. These “things” may be immutable laws; but more
than likely they’ll just be helpful heuristics, bound to fail and be built upon until the
originals have become as quaint and old-fashioned as imagining light as a particle
traveling through ether or that behavior is regulated by four cardinal “humors.”
•• SEE WITH THE PLAYER’S EYES. Game development can be horribly tedious at times.
Often in frustration at a non-functioning or poorly functioning feature, designers do
whatever is the quickest that allows them to move on to the next task. But the
designer’s role is to understand how players will see this in the final product. What
is the easiest solution is rarely the best solution. Should this menu take three clicks
to navigate or is there a way to do it in one click? What if the three-click method is
much easier to implement? Is it worth the trade-off? Tracy Fullerton, in Game Design
Workshop calls this “be[ing] an advocate for the player” and cites it as the designer’s
most important responsibility.1 It is difficult for you to see with the player’s eyes
because you are biased by having seen the game from embryo to finish. You have the
luxury of comparing a game in its current state to what it was in an earlier unfin-
ished state, so it will always look better to you than it will to a new player without all
that information and baggage. The game designer often has to play the role of villain
in telling the team (or even himself) that what they have made is not what is best
for players.
•• EMBRACE BEING WRONG WITH HUMILITY AND UNDERSTANDING OF ALL OF ITS CONSEQUENCES.
Ego is great for promoting successes and inspiring others. It is horrible for remaining
objective. Game design requires iteration. Designers are always tempted to treat their
ideas as sacred. But when players experience those ideas and find them wanting, the
designer must be OK with admitting the idea didn’t work and changing it into a form
that better meets the design goals. Playtesters are sometimes wrong. More often,
they are right. A responsible designer knows when a playtest reveals that major
changes need to be made.

1 Fullerton, T., & Swain, C. (2008). Game Design Workshop: A Playcentric Approach to Creating Innovative
Games (2nd ed.). Amsterdam: Elsevier Morgan Kaufmann.
 What Is a Game Designer? 7

•• COMMUNICATE WITH TEAM AND PLAYERS. Understanding the game’s systems and
design goals has an additional responsibility: The game designer must be the one
who helps the rest of the team understand those goals so they can work in concert.
In large teams, this is often done by writing effective and clear game design docu-
ments and reiterating the goals and design focus when appropriate with every team
interaction. This communicator-in-chief role extends also to communication with
the players. The most brilliant, detailed system will fall flat with players if players do
not understand it. The zeal with which the designer must carry the torch of the
design goals and the means to achieve them must be duplicated by communicating
clearly with the players through thoroughly tested user interface and content.
•• FILL IN THE GAPS. Large “AAA” software titles can afford to be highly specialized due
to the size of the team. They can hire narrative designers, user interface (UI) design-
ers, designers who specialize in economies, and so forth. The smaller the team gets,
the more the designer has to be a jack-of-all-trades. In the singular case, a team of
one can rely only on the designer herself and the players. Anything the players can-
not do on their own must be done by the game designer in this case. The game
designer needs to have a polymath’s skill set to fill in the gaps where the game’s
goals are not being met.
•• FACILITATE PLAY. All of the previous similarities are applicable for any user-centered
design process. With some change in nomenclature, those responsibilities make
sense for designing a better ATM, or a website for ordering custom-tailored shirts.
The difference in games is that the freedom that comes with play is fundamentally
different than checking a box to determine whether a use case was satisfied. The
game designer who errs on the side of staid checklists is just as remiss as the
designer who riffs without having goals in mind and never finishes. Games are about
play. That play can facilitate different types of emotions and aesthetics, but at its
heart, it is still play. The designer shares in the producer’s responsibility to keep the
game on schedule. He shares in the engineer’s responsibility to make the game func-
tional. But the designer’s unique responsibility is to ensure that the game is
aesthetic and playful.
•• DON’T BE AN AUTEUR. The common outside stereotype of a game designer is similar to
the stereotype of the auteur film director. The auteur has tyrannical influence from
beginning to end, dictating her unique vision to a team of cogs who implement her
genius design. The auteur’s ideas come from her mind fully formed. If the audience
does not “get” it, then it’s their fault for not being sophisticated enough. This is a
stereotype without many successful antecedents in the real world. The successful
game designer shares more traits with a successful scientist than an auteur.
8 PLAYERS MAKING DECISIONS

Attributes of a Game Designer

As an administrator of one of the largest game design programs in the world, I con-
stantly have different stakeholders (students, parents, admission representatives, and
other university staff) ask what the qualities of a good game design student should be.
Should they be mathletes? Should they be expert tinkerers? Luckily for nascent design-
ers, my experience has led me away from the existence of any innate traits that make for
a good designer. My answer tends to be just three elements, all of which can be culti-
vated by anyone: varied interests, persistence, and mindset and purpose.

Varied Interests
In my classes, I almost always ask the question of why the students want to design
games. Quite often, students say, “I have been playing games since I was in the womb!”
He (this is always a male student) claims that he has played every game released for
every expensive console for the last 20 years. This, he claims, makes him extremely
qualified to be a designer. These students tend to not care about game design theories
because they know what a good game looks like already.

To this, I usually say how odd it is that I have eaten every day, maybe upward of 20 or 30
thousand meals by this point, yet I am just not a proficient chef. I have a refined palette,
I know what I like and what I do not like, and I can even approximate it to some degree.
Yet I often need a couple tries to make a good cake. It is almost as if experience in con-
suming something quite weakly correlates with the skill involved in making something!

In my experience, the best designers are not ones who are singularly interested in
games. This is somewhat counterintuitive. The best designers are those who are inter-
ested in everything and can learn new skills and disciplines quickly. Not only does a
designer often need to fill in and ramp up to a new responsibility quickly, but it is the
core of creativity to draw from varied experience. Ernest Hemingway is quoted as say-
ing, “In order to write about life first you must live it.” Legendary designer Richard
Bartle says, “Designers read up on every subject they can conceivably find. […] They’ll
spend six hours absorbed in the details of the inner workings of the Palestine
Liberation Organization in the 1970s because somehow they sense it will help their
understanding of guilds, or orcs, or griefing, or terrain, or who knows what.”2

2 Bateman, C. (2009). Beyond Game Design: Nine Steps Toward Creating Better Videogames. Boston,
Massachusetts: Cengage Learning.
 What Is a Game Designer? 9

A technical term for this is philomathy. A philomath is a lover of learning. The goal of
the philomath is to pursue varied skills and knowledge. Of course, a philomath can be
a dilettante by not applying that varied knowledge. Therefore, a great game designer
employs practical philomathy—applying the lessons of many different fields to a
practical project.

Some, such as educational researcher James Paul Gee,3 believe that games encourage
learning because of their ability to teach the transfer of skills and knowledge between
different domains. If this is true, then the game designer must also be comfortable
transferring between domains of knowledge.

Persistence
The rain to the wind said,
“You push and I’ll pelt.”
They so smote the garden bed.
That the flowers actually knelt,
And lay lodged—though not dead.
I know how the flowers felt.
—ROBERT FROST “LODGED”

Any successful creative endeavor is a slog. The most enjoyable times to be a game
designer are at the beginning of a project, when the possibilities are endless, and at the
end of the project, when the work is complete. Unfortunately, most of the project lies
between those two points. The middle contains unfathomable bugs, bratty and rude
playtesters, teammate squabbles, external flies in the ointment, and intense periods of
self-doubt.

Poor designers settle or quit and then blame the bugs, playtesters, squabbles, and more
for falling short of success. Excellent designers have the fortitude to stick with it when it
gets tough and are generally rewarded for their hard work by better output. “Sticking
with it” is not a measure of time. It is not a metric of how stone-faced you can be while
you wait out your troubles. Ego-driven designers can wait out a tsunami of criticism,
but if they do not adapt to that criticism, their work never improves. Instead, “sticking
with it” is a measure of work. How can a designer adapt to all the obstacles in her path?
That measure is a key attribute of a good designer. But it is not innate! It is something
that can be trained.

3 Gee, J. P. (2003). What Video Games Have to Teach Us About Learning and Literacy. Computers in
Entertainment (CIE) 1(1),20.
10 PLAYERS MAKING DECISIONS

Mindset and Purpose

I see a distinct difference among potential designers with two mindsets.

Some want to design games. They are perfect for the program at my university because
that is exactly what our program teaches. They have no problem throwing together pro-
totypes, and often many students I work with have a history of making games before I
see them in our program. They embrace failure as a step toward success. The act of
making games is what sustains them through the tough times.

The other type of potential designer is made up of folks who want to be game designers.
These people I find much harder to help. All these folks want is the gravitas that comes
with saying that you are a professional game designer. They want to tell someone what
to make and have it made. They want to be the mythical “idea guy.” These people shy
away from or are dismissive of making things themselves. Often they claim they “don’t
have the skills” to make things. They want the title without the work. This comes from a
common misconception of what game design actually is in practice.

 NOTE Spoiler: The problem with being an idea guy is that everyone is one. Everyone has a great game
There is no gravitas.
idea that they have been itching to make. But actually making it is difficult. Sometimes
Sorry. It is a good
icebreaker with strang- it requires specialized knowledge; it always requires a significant amount of work and
ers to say that you revision. Why should someone pay you for your ideas when everyone else has ideas? If
design games, but
beyond that, it has its
you were a programmer, would you want to work on your ideas or someone else’s? “But
pros and cons like any my ideas are great!” you may say. How do I know? Can you prove it? The way you can
other field.
prove it is by making a playable prototype, which requires you to be someone who
makes things, not just someone who talks about making things.

The concept of idea guys is a running gag in the industry. It is shorthand for people who
want to work in games without actually doing any work. Either they are afraid of doing
work or they are so afraid of their egos being damaged that they offshore and delay the
work that might prove their idea is no good. There are a few notable idea guys in the
industry today, but they earned that role by working really hard at implementing their
now-famous ideas until they were successful. For example, Will Wright sometimes
plays the role of idea guy, but he designed and coded SimCity by himself, not to mention
tons of other games that never reached that level of success. There are no idea guys who
started as “idea guys.”

Before you continue on your journey toward learning about game design topics, take
time to consider whether you want to design games or be a game designer.
 What Is a Game Designer? 11

Make Things
David Bayles and Ted Orland’s book Art & Fear is a great collection of observations  NOTE Thanks to
Joël Franusic, as I origi-
about creating things.4 The following excerpt is about ceramics, but its lessons apply to
nally found Art & Fear
almost any creative endeavor, especially making games: through his blog.

The ceramics teacher announced on opening day that he was dividing the
class into two groups. All those on the left side of the studio, he said, would
be graded solely on the quantity of work they produced, all those on the right
solely on its quality. His procedure was simple: On the final day of class he
would bring in his bathroom scales and weigh the work of the “quantity”
group: fifty pounds of pots rated an “A,” forty pounds a “B,” and so on.
Those being graded on “quality,” however, needed to produce only one pot—
albeit a perfect one—to get an “A.” Well, came grading time and a curious
fact emerged: The works of highest quality were all produced by the group
being graded for quantity. It seems that while the “quantity” group was bus-
ily churning out piles of work—and learning from their mistakes—the
“quality” group had sat theorizing about perfection, and in the end had little
more to show for their efforts than grandiose theories and a pile of dead clay.

At the start, ideas are exciting. It’s easy to see an idea only for its promise. There is a
honeymoon period where all the fun bits are coming together. But, extraordinarily,
rarely does an idea go from form to product in a smooth transition. Most projects enter a
period where the idea needs work: Either the code is not working, or the game is testing
poorly, or there is just a lot of foundational work to complete. Those parts are no fun. At
that point, the creator has a choice: Slog through the difficult parts and finish, or
choose one of the other new, exciting ideas and start working on the fun parts that it
promises. You can imagine what most people choose. It ends up leaving us with a
graveyard of half-finished ideas. Sometimes giving up on an idea is justified and useful,
but always chasing the next promising idea without ever finishing the one in progress
is an easy mistake to make. Worse yet, if you abandon a project with a difficult trajec-
tory for one with potential, you never learn the valuable lessons about the craft that the
process of slogging through difficult and tedious tasks ends up often teaching you.

4 Bayles, D., & Orland, T. (2001). Art & Fear: Observations on the Perils (and Rewards) of Artmaking. Eugene,
Oregon: Image Continuum Press.
12 PLAYERS MAKING DECISIONS

This is what Bayles and Orland are talking about. The “quantity” group probably made
some terrible pots. That is okay. By doing so, they did not shame themselves or reveal
that they didn’t have it in them to create ceramics. Instead, they were able to build upon
their mistakes. Their goal was not the one perfect pot, but better and better pots.

A similar, oft-repeated bit of advice is delivered by radio’s Ira Glass:5

Nobody tells this to people who are beginners, I wish someone told me. All of
us who do creative work, we get into it because we have good taste. But
there is this gap. For the first couple years you make stuff, it’s just not that
good. It’s trying to be good, it has potential, but it’s not. But your taste, the
thing that got you into the game, is still killer. And your taste is why your
work disappoints you. A lot of people never get past this phase, they quit.
Most people I know who do interesting, creative work went through years of
this. We know our work doesn’t have this special thing that we want it to
have. We all go through this. And if you are just starting out or you are still in
this phase, you gotta know it’s normal and the most important thing you can
do is do a lot of work. Put yourself on a deadline so that every week you will
finish one story. It is only by going through a volume of work that you will
close that gap, and your work will be as good as your ambitions. And I took
longer to figure out how to do this than anyone I’ve ever met. It’s gonna take
awhile. It’s normal to take awhile. You’ve just gotta fight your way through.

Do not underestimate how difficult the evolution can be at times. Sometimes students
cave in to the pressure that comes from the distance between where they are and where
they want to be. They respond to it by lowering their expectations of their own work
because they are “only students.” Architect, designer, and professor Christopher
Alexander has this fight often with his pupils:6

In my life as an architect, I find that the single thing which inhibits young pro-
fessionals, new students most severely, is their acceptance of standards that
are too low. If I ask a student whether her design is as good as Chartres, she
often smiles tolerantly at me as if to say, “Of course not, that isn’t what I am
trying to do…. I could never do that.” Then, I express my disagreement, and
tell her: “That standard must be our standard. If you are going to be a builder,
no other standard is worthwhile. That is what I expect of myself in my own
buildings, and it is what I expect of my students.”

5 Glass, I. (2009, August 18). “Ira Glass on Storytelling,” part 3 of 4. Retrieved March 11, 2015,
from www.youtube.com/watch?v=BI23U7U2aUY.
6 Gabriel, R. (1996). Patterns of Software: Tales from the Software Community. New York: Oxford University Press.
 What Is a Game Designer? 13

In this book, we’ll discuss many of the fields of study that touch and inform game
design. But these lessons are intended to guide your decision-making as you craft new
games. These lessons are not intended to make you a game designer. Only you can do
that through sustained, deliberate practice.

Abandon the common desire to achieve perfection. The Platonic ideal of your game only
exists in your head. To approximate it is a worthwhile goal, but to demand adherence to
it is not. Like Moses, your game can see the Promised Land but will never reach it. At
some point, you must finish that game to have the experience of finishing. It needs to be
released to the wild, not buried in a notebook or on a private thumb drive.

Additionally, your repeated practice in making games must be deliberate. If you make
games, that is good. But if you make games with a purpose toward becoming better at
making games, that is a whole lot better. Always challenge yourself to stretch outside
your comfort zone. This is the only way to grow. As Susan Cain writes in Quiet about
deliberate practice:

When you practice deliberately, you identify the tasks or knowledge that are
just out of your reach, strive to upgrade your performance, monitor your
progress, and revise accordingly. Practice sessions that fall short of this stan-
dard are not only less useful—they’re counterproductive. They reinforce
existing cognitive mechanisms instead of improving them.7

Cultivate Your Gardens

Playing games is, of course, not the same as making them. You do not have to be a mas-
ter at playing a game to understand why it works or to be able to describe and emulate
its systems. But understanding what is being done in the field currently saves you a lot
of time. And to do that, it is helpful to know how many different types of games solve
their design problems. You do not have to reinvent the wheel if you can use best prac-
tices from other games. How does Halo do weapon switching? How does League of
Legends implement end-game feedback? Perhaps you want to make a game by combin-
ing elements. It helps to know if that game already exists, or if a similar game exists
and what it did right and wrong.

The most helpful research you can conduct is often to play bad games. Good games are
similar, but bad games are different in a myriad of unique ways. Bad games teach you
hundreds of things not to do. For instance, you can learn just as much about level

7 Cain, S. (2013). Quiet: The Power of Introverts in a World That Can’t Stop Talking. Broadway Books.
14 PLAYERS MAKING DECISIONS

design from Gunvalkyrie as you can from BioShock. The other benefit of playing bad
games is that it differentiates you as a designer. Most designers have played Final
Fantasy VII, so most designers have internalized the same lessons. However, few will be
able to tell you the lessons they learned from Mario Is Missing, Dino Crisis 3, Rule of
Rose, or Azurik: Rise of Perathia.

 NOTE I try to be extraordinarily careful with the use of the terms “good” and “bad”
since they are not only wildly subjective, but also serve as a means to eliminate all critical
and helpful commentary from an object. In this instance, “good” games are games that
match your tastes and do so in a way that is widely accepted as being successful. “Bad”
games are those that are widely criticized or do not match your preferences.

In one class, I had students practice making presentations. At first, I let students select
any topic of their choice that didn’t violate university guidelines. Roughly 80 percent of
the presentations ended up being about games they had played or games they wanted
to design. It was the same presentation every month on the newest, hottest game. It was
dreadfully boring. Then I changed up the assignment and forbid anyone from doing
any presentation on games or game design. Instead, I challenged them to teach the
class something new that was not about games or pop culture. I received a lot of push-
back from students. They claimed that games were all they knew! I let these
protestations fall on deaf ears. When I finally received the presentations, the topics
were diverse and interesting: how to cook perfect chicken wings, the struggles in adopt-
ing three children from overseas, why greenhouse tomatoes are better than
store-bought, tips on figure drawing—one memorable presentation even did an ethno-
graphic study of Juggalo culture! People become more interesting if you push them
away from what makes them wholly comfortable. Writer Geoff Dyer once wrote: “How
can you know anything about literature if all you’ve done is read books?”8 The same
goes for games or any other creative endeavor.

Inspiration and guidance comes from every aspect of our lives. When we all do the
same things, we mold ourselves into cookie-cutter patterns that make us identical to
our neighbors. In some aspects, this is useful: We can communicate more easily using
shared experiences, and we can understand the motivations of those who think like us.
However, in creative endeavors, it can be a death knell. If you are identical to every
other designer, then why should anyone hire you or play your games? Products that are
identical to their direct competitors are called commodities. Commodities are priced as
low as possible. Do you want to be paid as low as possible? Or do you want to be differ-
ent and command the highest prices?

8 Dyer, G. (1999). Out of Sheer Rage: Wrestling with D. H. Lawrence. New York, New York: North Point Press.
 What Is a Game Designer? 15

On Ontology and Dogma

Man only plays when in the full meaning of the word he is a man, and he is
only completely a man when he plays.
—FREDRICH SCHILLER

Since the reality of play extends beyond the sphere of human life it cannot
have its foundations in any rational nexus, because this would limit it to
mankind. The incidence of play is not associated with any particular stage of
civilization or view of the universe. Any thinking person can see at a glance
that play is a thing on its own, even if his language possesses no general
concept to express it. Play cannot be denied. You can deny, if you like, nearly
all abstractions: justice, beauty, truth, goodness, mind, God. You can deny
seriousness, but not play.
—JOHAN HUIZINGA

Many game design books start by posing this question: What is a game? Surely you
have to know what you are creating in order to create it. So most game design textbooks
have a chapter covering this question. The primary problem with designers considering
this question is that no matter what the answer is, it’s not instrumental in making bet-
ter games. The main output of “what is a game” discussions is argument. We discuss it
here only to give it some air, since it constantly comes up in nearly every generalist
game design book. But this topic is only covered in a perfunctory way to make more
time for concepts with direct application to craft.

Formalism
The topic of the essential features of a game is an important debate in the field of game
studies. Game studies is an interdisciplinary catchall term for any research surrounding
the cultural and ontological components of games and play. Game design is a subset of
game studies that is most concerned with the normative aspects of how to make a game.

Scholars and lay folks have long attempted to pin down what exactly is meant when we
say “game.” Here are a few samples of what has been published:

•• French sociologist Roger Caillois in 1961: “an activity which is essentially: Free (vol-
untary), separate [in time and space], uncertain, unproductive, governed by rules,
make-believe.”9

9 Caillois, R. (1961). Man, Play, and Games. University of Illinois Press.

16 PLAYERS MAKING DECISIONS

•• Games researcher Clark Abt in 1968: “any contest among adversaries operating
under a limiting context for an objective.”10
•• Researchers E.M. Alvedon and Brian Sutton-Smith in 1971: “an exercise of voluntary
control systems in which there is an opposition between forces, confined by a proce-
dure and rules in order to produce a disequilibrial outcome.”11:
•• Philosopher Bernard Suits in 1978: “the voluntary attempt to overcome
unnecessary obstacles.”12
•• Game designers Katie Salen and Eric Zimmerman in 2003: “a system in which
players engage in an artificial conflict, defined by rules, that results in a
quantifiable outcome.”13
•• Game designers Andrew Rollings and Ernest Adams in 2007: “a type of play activity,
conducted in the context of a pretended reality, in which the participants try to
achieve at least one arbitrary, nontrivial goal by acting in accordance with the rules.”14
•• Game designer Jesse Schell in 2008: “a problem-solving activity approached with a
playful attitude.”15
•• Game researcher Jesper Juul in 2010: “a rule-based formal system with a variable
and quantifiable outcome, where different outcomes are assigned different values,
the player exerts effort in order to influence the outcome, the player feels attached to
the outcome, and the consequences of the activity are optional and negotiable.”16
•• Game designer Stephen “thecatamites” Murphy at some point: “some combination
of the following indivisible elements: skeleton, red key, score thing, magic door. If
you see something that looks like a video game but isn’t, you should immediately
call the police.”17

We could wander far into the weeds of philosophy, wondering if we are using the ruler
to measure the table or the table to measure the ruler, but the point here is not to argue
the validity or invalidity of any particular definition or definitions of games, but to
understand why these definitions are not important for this exercise.

10 Abt, C. C. (1968). “Games for Learning. Simulation Games in Learning,” Sage Publications 65-84.
11 Avedon, E., & Smith, B. (1971). The Study of Games. New York: J. Wiley.
12 Suits, B. (1978). The Grasshopper: Games, Life and Utopia. Toronto: University of Toronto Press.
13 Zimmerman, E., & Salen, K. (2003). Rules of Play: Game Design Fundamentals. Cambridge, Massachusetts:
MIT Press.
14 Adams, E. and Rollings, A. (2007). Fundamentals of Game Design. Upper Saddle River, New Jersey: Prentice Hall.
15 Schell, J. (2008). The Art of Game Design: A Book of Lenses. Amsterdam: Elsevier/Morgan Kaufmann.
16 Juul, J. (2010). The Game, the Player, the World: Looking for a Heart of Gameness. PLURAIS-Revista
Multidisciplinar da UNEB, 1(2).
17 Murphy, S. (n.d.). “VIDEOGAMES.” Retrieved March 16, 2015, from http://harmonyzone.org/Videogames.html.
 What Is a Game Designer? 17

Planetologists argue about the definition of planets (see the recent furor over Pluto), yet
the planets keep their orbit regardless. Researchers Espen Aarseth and Gordon Calleja
argue that we, as game designers, do not need definitions at all.18 They say that fields
such as literature, media studies, and planetology all have unsettled debates on defini-
tions yet have no problems continuing on in the production of their field. They also
argue that rigid definitions hurt multidisciplinary fields. As we have already covered,
game design is a vastly multidisciplinary field.

As the cultural reach of games has increased, some works have been created that do not
look at all like games, are familiar, and do not appeal to the same aesthetic goals and
audiences. This is expected when a medium grows. However, in some sort of insane
tribalism, some commentators use the previous definitions of games as a tool to exclude
these works and creators from the community of creators.

A recent flare-up of this debate surrounded the indie game Gone Home by Fullbright. It
was a top-seller and had wide-reaching critical acclaim,19 yet it eschewed many of the
features of mainstream games. There is no way to lose or win. There is no challenge in
the traditional sense. Players explore a house and piece together the story of the home’s
inhabitants. There is no antagonizing force. There are no resources, per se. It fails some
of the accepted definitions, yet many (including the creators)20 consider it a game.
Critics of the game often throw out that it is not a game at all and is thus somehow
unworthy of praise or scrutiny.

Imagine an 18th century art critic who wrote that art was the depiction of images as a
true depiction of their real elements. That was what art largely was up to that point.
Then when abstract and surreal art came along in the 19th and 20th centuries, that
definition had to change. A dogmatic following of the critic’s rules would have denied
the world the beauty of images like those popularized by painters like Salvador Dali,
Piet Mondrian, or even fantasy artists like H. R. Giger or Frank Frazetta. Ironically,
Frazetta’s work has influenced almost every popular fantasy game since the dawn
of the genre.21

If the purpose behind game formalism is to deny other works the light of day, then it is
garbage scholarship. The medium needs boundary-ignoring works or it risks being

18 Aarseth, E., & Calleja, G. (2009). The Word Game: The Ontology of an Undefinable Object. In Lecture
delivered at Philosophy of Computer Games Conference, Vol. 178, pp. 12–25.
19 Grant, C. (2014, January 15). “Polygon’s 2013 Game of the Year: Gone Home.” Retrieved March 16, 2015,
from www.polygon.com/2014/1/15/5311568/game-of-the-year-2013-gone-home.
20 Gaynor, S. (2014). “Why Is Gone Home a Game?” Game Developer’s Conference. San Francisco, CA.
21 “Tracing the Influence.” (n.d.). Retrieved March 16, 2015, from www.hardcoregaming101.net/tracing/
tracing2.htm.
18 PLAYERS MAKING DECISIONS

stuck in an endless status quo. This should not be threatening to game designers. There
is room for both the status quo and the new and original. Saying that something is “not
a game” as interchangeable criticism with “I don’t like this” weakens the entire
medium of games by considering that only something that meets guidelines of taste is
allowed to be in the medium at all. This puts a huge burden on designers: Make a thing
with this list of features and it must be appealing and good or else you cannot be a
game designer at all!

So why have game definitions in the first place? The term game means something.
When you use it, you are attempting to communicate a concept. If it could mean any-
thing, then the term itself must be empty. Relativism does not help us communicate. We
consider the topic so that we can find commonalities that inform all of our work. To the
end that a definition works, it is helpful. Otherwise, it is not. An attempt at a definition
is not to be exclusionary, but to distill what the magic is that defines the medium in
which designers labor and love. Any definition of games that we determine now may
become irrelevant by the creation of something new that invalidates that definition.
Arguing about that definition is just territorialism.

Make what is in your heart. Let someone else worry about classification.

Summary
•• A game designer needs a variety of skills to be the jack-of-all-trades that meets a
project’s varied needs.
•• Nothing that a designer needs is innate. All design skills can be cultivated through
practice and a correct attitude.
•• Reading about game design can be helpful. That’s why you have this book! However,
nothing is a substitute for making games. If you wait until you are ready to make
games, you’ll never make a single one.
•• Games are great, but don’t only be about games. There is so much to learn in this
world in vastly varying domains of knowledge. You never know when you’ll be able
to connect what you learn to games, so try to learn everything.
•• Don’t worry about people who waste time arguing about what is or is not a game. It
is philosophically interesting, but it does not have much relevance for actually mak-
ing anything tangible. At worst, it forces design into rigid limitations. If you make
something clever and someone calls it “not a game,” you have still made something
clever, and they have made nothing at all.
2 Problem Statements
A problem clearly stated is a problem half solved.
—DOROTHEA BRANDE

Often designers are working from a completely blank slate. What

game do you make? When do you know you are done? How do
you know if you have succeeded? One way is to make a problem
statement. The problem statement is a simple way of asking what
the designer or team is trying to do with the game. By identify-
ing the design problem you are looking to solve, you eliminate
situations in which you are simply copying the work of others
and making something dull and uninspired. One way to formu-
late a design problem statement is by starting with “What if…?”
This allows the design that follows to be an exploration of
that question.

19
20 PL AYERS MAKING DECISIONS

Defining the Problem

During the 2000s, Electronic Arts had a concept called “the X.” The X was a simple say-
ing or slogan that helped the team “sell” the idea and understand what they were
making. It was the problem statement. For instance, Madden NFL 2005’s X ended up
being the back-of-the-box slogan that marketing used to sell the game: “Defense Wins
Championships.” This three-word slogan told the team that Madden NFL 2005 was
going to be about improving and polishing the defensive options in the game when
compared to previous American football games.

 TIP For a different perspective on the X, see Randy Pausch’s “An Academic’s
Field Guide to Electronic Arts” at www.evl.uic.edu/spiff/class/cs426/Notes/
PauschAcademicsFieldGuideToEA.pdf.

Note that problem statements do not explain what the game is when it is finished. That
would require prescient future prediction. Often, creative endeavors do not follow a pre-
dictable path. Psychologist Dean Keith Simonton found that often a kind of unpredictable
search is involved in many successful creative efforts.1 Having no plan at all is not recom-
mended. Instead, try to distill a game down to a fundamental core for which a new idea
can be built. What makes it different? What makes it interesting? All games involve solv-
ing problems to some degree. What problems are posed to the player and under what
context they appear is the designer’s decision. You may have to change that core problem
along the way, but that core focus gives you something from which to build.

The following sidebars include example problem statements for some released games
with a less effective (bad) version of the statement, a more effective (better) version, and
an explanation of why the better statement is indeed better.

1 Simonton, D. K. (2010). “Creative thought as blind-variation and selective-retention: Combinatorial models

of exceptional creativity.” Physics of Life Reviews, 7(2), 156-179.
 Problem Statements 21

PROJECT GOTHAM RACING (2001)

BAD PROBLEM STATEMENT: What if a racing game gave out kudos?

BETTER PROBLEM STATEMENT: What if a racing game was determined by style instead of
just speed?
WHY: Who cares about kudos? The problem that the game is trying to solve is how to
make a new win condition for racing games. The solution was kudos, not the problem!
The problem was finding out a different way to “score” a race! One hint is that if you keep
asking “Why?” then you probably have not dug deeply enough into the problem. The
deeper question here is “Why are kudos interesting?” The answer is “Because they are a
different way to score a race.” Aha! This digging deeper gets us to the core of the design.

HEAVY RAIN (2010)

BAD PROBLEM STATEMENT: Who is the Origami Killer?

BETTER PROBLEM STATEMENT: What would it be like to “play” a movie?

WHY: The first problem statement here is a question about the story, which is not deter-
mined until later in the project and is not the fundamental design motivation to the
game. David Cage, founder of Quantic Dream, is an opinionated designer/producer who
is largely focused on making interactive narratives. Therefore, in this case, the problem
has to be about that influence in some way. Note also that a problem statement does
not have to be what makes the game entirely unique. Quantic Dream’s earlier games
tackled similar design questions.

BRAID (2008)

BAD PROBLEM STATEMENT: What would happen if you could rewind time an infinite num-
ber of times, make time relative to a player’s position on the screen, and create a
shadow character that allowed you to perform multiple actions at the same time?
BETTER PROBLEM STATEMENT: What puzzles could be created if you could
manipulate time?
WHY: The first problem is far too specific about the mechanics. It is not likely that the
designer started with this specific end goal in mind. It’s more likely that the designer
thought about ways that time manipulation could create interesting mechanics and
puzzles. This leads to the formulation of the better problem statement. The mechanical
decisions all come from that fundamental issue of figuring out what happens when a
player manipulates time.
22 PLAYERS MAKING DECISIONS

SAN JUAN (2004)

BAD PROBLEM STATEMENT: What would a card game version of Puerto Rico look like?

BETTER PROBLEM STATEMENT: What mechanics, dynamics, and aesthetics from Puerto
Rico could be preserved in a card game?
WHY: San Juan is a card game version of Puerto Rico, and the original design consider-
ation was probably how to make Puerto Rico: the Card Game. Yet Puerto Rico: the Card
Game could be literally any card game with a plantation and shipping theme integrated
into the text and art. A better way to start would be to understand what elements of
Puerto Rico were worth preserving: Selecting roles, piggybacking off the roles of other
players, harvesting crops, shipping them, and managing resources are all essential
elements that make the transition from Puerto Rico to San Juan. The better problem
statement also yielded another popular game, Race for the Galaxy. It was built off the
same idea to preserve elements of Puerto Rico in a strategy card game.2

Poor problem statements don’t get at the heart of the game, are overly vague, are overly
derivative, are only marketing statements, or don’t drive the design. For instance, “How
do we make another Elder Scrolls game?” is a poor problem statement. It essentially
directs the designers to just make a copy of what they have already made.

The best problem statements should get down to the concrete design goal so the designer
and team can follow up with effective tasks to create a unique and focused design.

Low-Hanging Fruit
After deciding at a high level on what problem you want to solve, the next step is to
figure out how to solve that problem. This is usually done by visualizing and describing
what the game will look and play like. You can use this high-level sketch of your rules,
mechanics, and/or theme in order to start building prototypes.

This process has a few danger areas. Let’s look at an example that illustrates these dangers.

2 Lehmann, T. (2011, May 11). “Race for the Galaxy Designer Diary #1.” Retrieved March 16, 2015, from
http://web.archive.org/web/20090227034911/boardgamenews.com/index.php/boardgamenews/
comments/game_preview_race_for_the_galaxy_designer_preview_1.
 Problem Statements 23

Assume you are tasked to create a game that uses all four of the following elements:

•• A standard 17-inch diameter car tire

•• Six (three pairs) of calf-height white cotton tube socks
•• 5 pounds of Florida navel oranges
•• A 10-foot length of thick rope

You do not have to use all of the materials exhaustively (that is, you do not have to use  NOTE Thanks to
Dax Gazaway for the
all the oranges, all the socks, or all the rope), but you must use at least a portion of all
setup for this idea.
four elements.

Before reading further, write down a one- or two-sentence description of the first game
you envision. The game should be coherent and feasible, but it does not necessarily
need to be fun or strategically fulfilling. Please come up with your idea before reading
further… I’ll wait.

I have given this exercise to professional game designers, college professors, lay per-
sons with no professional ties to games, and (many) students. Originally, I had planned
to keep track of the results as a pseudo-scientific study. However, the first 20 results I
received were nearly identical.

The easiest idea, the idea that sticks out the most, is the “low-hanging fruit.” This fruit
is easy to pick and anyone can reach up and grab it. For the sake of consistency, let’s
say your idea is like the first ones I received: Create a game where you throw an orange
through the tire. This is usually done by putting an orange in the sock and using the
sock as a sling. The rope is used to hang the tire from a tree or structure. As I said
before, the first 20 people I gave this exercise to did roughly the same thing. There were
some variations: Some used the rope to measure distance, some had the tire rolling
instead of stationary. Yet the core of the game was the same: Throw oranges through
the tire to win. Is this the idea you came up with?

Think of how limiting this is. Think of all the things you can do with an orange. Sure,
you can throw oranges, but you can also juggle, balance, eat, squeeze, roll, peel, stack,
hide, or catch them, among dozens of other things. A long list of verbs can be created
for each of the four elements. Yet each of the first 20 people asked chose a similar set of
verbs. These participants had a range of ages and game design experience. They did not
choose the same actions because of a similar background; they chose it because it was
the easiest solution to imagine.
24 PL AYERS MAKING DECISIONS

When solving traditional problems, we often go for the simplest possible solution. But
in efforts that require creativity, the simplest solution is the one everyone thinks of first.
If an important part of design is the creativity of ideas, then stopping when you think of
the first reasonable solution limits you to only the most obvious conclusions.

Although students answered the same as the other participants in this exercise, the dif-
ference between them and design professionals is that the design professionals were
willing to come back with better answers later. One of the professors I gave this exercise
to came back to me the following day with a really innovative game idea for the materi-
als that I had never heard before. Design professionals tend to keep digging away at the
idea until they have explored all of its facets. And, as a result, they can choose from a
deep list of ideas. Students, however, tend to stop at the first idea that makes sense.

Functional Fixedness
German psychologist Karl Duncker studied a phenomenon related to how the preceding
low-hanging fruit exercise produced similar answers from person to person.3 In a
famous test, he asked participants who were given a candle, a box of matches, and a
box of thumbtacks to figure out how to attach the candle to the wall so that the candle’s
wax did not drip onto the table below when lit.

The solution is to use the tacks to affix the box that the tacks came in to the wall and to
place the lit candle in the box. However, subjects found it hard to use the box as a tool
to solve the problem because they focused on the use of the box as a container for
matches. Duncker called this phenomenon functional fixedness. To them, the function
of the box was fixed as being a container. They could imagine no other function. When
designing games, it can be easy to assume that the uses of common objects or mechan-
ics are fixed. In the low-hanging fruit game example, oranges look like baseballs or
softballs, so the resulting games largely treated them as such.

Often, the most creative games break fundamental assumptions about genre. Divekick,
for example, is a fighting game that eschews combos, complex control schemes, block-
ing, directional movement, and even life bars but still delivers a fun fighting game
experience. Its designers took all the elements that most fighting game designers take
as being fixed elements and simply threw them out. Shadow of the Colossus created a
world right out of a Legend of Zelda-style adventure game and removed everything but
the boss fights.

3 Duncker, K., & Lees, L. S. (1945). “On Problem-Solving.” Psychological Monographs, 58(5), i.
 Problem Statements 25

Brainstorming
One technique studios tend to employ to find creative solutions to problems is brain-
storming. In classic brainstorming, members from one or many disciplines who are
stakeholders in the project get together in the same place to generate ideas. The brain-
storm tends to have a theme or purpose; there is some kind of problem the brainstorm
session tries to solve. Someone moderates the meeting, and members spout out possible
solutions while someone else records the proceedings.

This technique was presented in the 1950s by Alex Osborn in his book Applied
Imagination.4 In his book, he coined the term “brainstorming” and its cardinal rules.
The rules he created mostly carry over to properly run brainstorming meetings today:

•• QUANTITY, NOT QUALITY. Worry about “good” ideas later. In brainstorms, just come
up with as many ideas as possible.
•• BUILD ON IDEAS. The reason the brainstorm is a communal activity is that
participants use other participant’s ideas to spur the creation of new ideas from
different perspectives.
•• ENCOURAGE “CRAZY” IDEAS. Anyone can come up with the obvious ideas. If the obvi-
ous ideas worked, the team would not be experiencing the problem that results in
the brainstorm session in the first place! Even if the ideas presented are ridiculous,
maybe a kernel of that idea will inspire some other better and more feasible idea.
•• NO CRITICISM. Not only do people self-censor, but when we hear ideas, our critical
evaluation centers go active and we try to evaluate why the idea will not work. In
corporate environments, there is often a political motive to stamp out competing
ideas to develop one’s own standing. This is counter to the brainstorm’s goals.

Osborn found that when these rules were followed, idea generation was more produc-
tive than in a normal meeting situation.

Unfortunately, research on brainstorming versus other techniques in the corporate envi-

ronment since Alex Osborn created his rules has not been so kind. In fact, research has
clearly shown that using the brainstorming rules in an individual setting provides more
(and higher quality) ideas per person than the traditional group brainstorming setting.5

4 Osborn, A. (1963). Applied Imagination: Principles and Procedures of Creative Problem-Solving. (3rd rev. ed.).
New York: Scribner.
5 Mullen, B., Johnson, C., & Salas, E. (1991). “Productivity Loss in Brainstorming Groups: A Meta-analytic
Integration.” Basic and Applied Social Psychology, 12, 3–23.
26 PLAYERS MAKING DECISIONS

Researchers took a look at what was holding back group brainstorming and came up
with some reasons for the discrepancy:6

•• EVALUATION APPREHENSION. Anyone with any sort of social anxiety understands this
at heart. One of the rules of brainstorming is that quality does not matter. Yet in the
corporate environment, workers are constantly being judged on the quality of their
work. As a result many, even subconsciously, hold back and “test the waters” to see
what kind of ideas are being received appropriately. They then use that as a guide for
the risk level of other ideas, essentially turning off the “wild idea” center for fear of
being judged. Simple body language cues such as frowns or raised eyebrows can
turn us off and make us feel uncomfortable about delivering ideas.
•• SOCIAL LOAFING. If you have ever ridden a tandem bike, the person in front can pedal,
steer, and brake. The person in back can only pedal and pray. When you go up hills,
you can split the work and pedal equally hard, or the person in the back can enjoy
the breeze and let the person in the front do all the work. If your feet are moving
around the pedals but not pushing, to any outside observer, it looks like you are
working just as hard. This is the concept of social loafing. In a brainstorm, you’ll usu-
ally find that a couple of people will provide the lion’s share of ideas. Sometimes
these are Type-A personalities who compulsively dominate every meeting.
Sometimes these are just naturally prolific idea generators. In practice, everyone
else in the meeting sits back and lets these people take the helm. Maybe they don’t
want to break the flow of ideas. Maybe they just want to be polite. In any case, they
reduce the output ideas by not pedaling as hard as other members. Interestingly,
when researchers conducted exit interviews in studies of social loafing, the loafers
compared themselves to the least producing member of the group, in effect saying:
“Well, I didn’t do the least” or “I did almost as much as that guy” rather than compar-
ing themselves to the highest producers of the group.7
•• PRODUCTION BLOCKING. This is an unfortunate side effect of the human attention
span. When you sit in a room with others and generate ideas, you have to wait for
everyone else in the room to be silent before you can chime in and have your ideas
heard. This pause is, in essence, limiting individuals from contributing as much as
they could. In a brainstorm with only one individual, ideas are recorded as fast as
they are generated; there is no pause.

6 Diehl, M., & Stroebe, W. (1987). “Productivity Loss in Brainstorming Groups: Toward the Solution of a
Riddle.” Journal of Personality and Social Psychology, 53(3), 497.
7 Paulus, P. B., & Dzindolet, M. T. (1993). “Social Influence Processes in Group Brainstorming.” Journal of
Personality and Social Psychology, 64(4), 575.
 Problem Statements 27

Summary
•• By being explicit about the design problem your game aims to solve, you can focus
early design and development toward achieving a specific goal.
•• The first answer you think of to a problem is likely a simple solution, but it isn’t often
the best. Use brainstorming techniques to power past the low-hanging fruit.
•• Functional fixedness causes us to only solve problems in traditional ways, whereas
better or more original solutions may be possible.
•• The focus of brainstorming is on the quantity of ideas. By using brainstorming rules,
you can avoid editing that limits connection-building between ideas.
•• Individual brainstorming may be more effective than group brainstorming.
 3 Development Structures
Adding manpower to a late software project makes it later.
—BROOKS’ LAW

Game development can be a complex endeavor. In many cases,

dozens of distinct egos must harmoniously coordinate their
efforts to fit moving parts together seamlessly. Needless to say,
this can take a lot of organization.

We use models like the software development life cycle to wrap

our heads around the various processes that go into creating a
complex project. This is a model of order: When do we do things
and what steps follow what others? These structures are not lim-
ited to software development; you can model any product
development with these systems. It sometimes only requires
modifying the nomenclature.

28
 Development Structures  29

Production Methodologies
Even though these models were developed with software in mind, they work for many
complex creative endeavors. There are many different formulations of the software
development life cycle because the needs for various projects and industries differ.
However, most break down into one of two general types: waterfall and iterative.

Waterfall
The simplest software development model is the waterfall method (FIGURE 3.1). Even  NOTE A better al-
lusion might have been
though it is generally cited as a poor way to organize your software project, the water-
to black holes, but that
fall method’s simplicity and predictability, and the fact that many publishers draw up term was not used until
their contracts based on this model, lead many studios to still employ this method. The the mid-1960s. It’s also
much more cynical.
waterfall method was first mentioned in the 1950s1 and takes its name from a waterfall
in that it is nature’s one-way street: Water flows down, never up.

FIGURE 3.1
Ideation The waterfall method
organizes steps of
production that flow
Specification in only one direction.

Production

Test

Release

The waterfall method starts with ideation, which is, literally, the generation of ideas.
This is where the brainstorming, concept art, and sometimes prototyping come together
and the team gets an idea of what they are about to build.

In specification, the team gets down to the specifics of what they will build. Designers
write game design documents (GDDs), engineers write technical design documents
(TDDs), and artists start creating base assets or media design documents (MDDs). These
first two steps together (ideation and specification) are generally known as preproduction.

1 Bennington, H. D. (1956, June). “Production of Large Computer Systems.” In proceedings during the
Symposium on Advanced Programming Methods for Digital Computers at the Office of Naval Research (ONR).
30 PLAYERS MAKING DECISIONS

Next, the team enters what is usually the longest phase: production. In this phase, the
team actually constructs what they laid out in their design documentation. As already
mentioned, the key aspect of the waterfall method is that work flows only in one direc-
tion. This means that, at this point, the team is strictly making what is on the design
documents and is not revising and changing the requirements to adapt to new issues.
Production generally splits into self-contained milestones where individual features are
completed and then are not touched again. This allows the team to schedule with a
great amount of specificity.

The last two steps can require a high percentage of the total work of the project. In test,
the team works together to eliminate any bugs and rough edges generated during pro-
duction. This can be laborious since the nature of the waterfall method does not allow
the team to go back and make changes that may result in fewer bugs and technical
challenges. When the system is sufficiently bug free, the product is released and the
team starts over with a new project.

Alpha, beta, and gold are terms for sections of the test phase. Alpha is the state of the
project when all the features have been completed and the testing stage begins. Beta is
the state when the bug count has been reduced to acceptably small levels, but bugs are
still incoming. Gold is when the publisher or team decides the game is sufficiently bug
free and sends it to the manufacturer (or releases it to partners) to be printed and/or dis-
tributed. These terms can vary from place to place. For instance, Google likes to label its
products as beta long after they have been released.

In FIGURE 3.2 , the number of bugs in the project increases until the features are all com-
plete. In alpha, the team tackles the bugs, decreasing the number (while some bugs are
still being added as mistakes are made). In beta, the team still bounces above zero bugs
as new bugs are added and tackled.
FIGURE 3.2
Bugs increase as
features are imple-
mented and decrease
as features lock and
the team sets their
priority to bug elimi-
nation. However,
new bugs are con-
stantly found, and it
is tough to keep a
project at zero bugs. Production Alpha Beta
 Development Structures  31

The waterfall method is highly predictable. It can be broken down into tiny, measurable
tasks. The financiers can know exactly when the cycle will end and can plan the mas-
sive multimillion dollar ad campaign around that release date.

But the drawback is that game development projects are not straightforward and easily
predictable. Most software has an easy end state: Did my document print? Did my
source compile? Did my photo effect get applied? If yes, you are finished. Games are dif-
ferent. Games involve challenge, mystery, and learning. When you start making a game,
you have no idea if your implementation will be fun until it is made. “Fun” is an elusive
concept that is highly subjective and personal. It’s often the case where what seems like
it would be fun on paper simply is not fun in practice, or a system that you created on a
spreadsheet has a hidden dominant strategy that you missed during planning. What
happens in a waterfall software product? You must forge ahead because there is no
turning back. In games, this is deadly. Instead, we need a model where we can test
before production and throughout the process and still be able to return to earlier steps.
This kind of process is known as an iterative process.

Iterative Processes
FIGURE 3.3 shows an iterative process for designing games. The game starts first with
an idea. That idea causes the team to formulate a plan. Often these plans are in the form
of design documentation like GDDs, flowcharts, and mockups.

FIGURE 3.3 Iterative processes

Idea allow for steps to repeat. Often,
they tackle small portions of a
project at a time and go through
Plan many cycles.

Prototype

Evaluate

Complete

Next the team creates prototypes. A prototype is the smallest possible execution of the
idea that allows the idea to be tested in a real environment. In board games this is
incredibly easy! All a designer has to do is scribble on some paper, assemble some com-
ponents like dice or playing cards, and go at it! In digital games, this can be a little
32 PLAYERS MAKING DECISIONS

more difficult because sometimes the technical prerequisites need a substantial amount
of groundwork before useful prototyping can happen. This is why some digital game
creators start with paper prototypes.

The next step is to evaluate the prototype. Here the team figures out what the successes
and failures of the prototype are and uses them to formulate new ideas to restart the
process. Teams may complete this loop a dozen times or more. Eventually, the creators
either run out of time or patience and have to complete the project with the best results
from previous tests.

Scrum is a popular brand of agile software development. It involves setting up specific

roles for various people including the ScrumMaster and the Product Owner, and it
focuses on solving problems endemic to the software development process, such as
marathon meetings and outside interference.

One of the great metaphors in Scrum literature is the story of the pigs and the chickens.
The story goes thus: A pig and a chicken get together and decide to open a restaurant.
The chicken suggests serving ham and eggs, but the pig balks. He says that the chicken
is only involved, but he, the pig, would be committed. The fable is a parallel to the two
types of people involved in a project. Chickens are involved in the project and provide
input or consultation, but ultimately it is the pigs that need to make the big decisions
because they are the ones fully committed. Respecting the role of the pigs puts the
power of the project in the hands of those most instrumental to its success or failure.

This iterative design method allows creators to maximize time testing of their ideas.
Remember that this is important because you do not know what will be fun or balanced
until you see how real, unpredictable players actually interact with it. Many designers resist
this model because it forces them to constantly change their ideas. They want to see a fully
formed idea go untouched from brain to product. Unfortunately, quite often those products
are of inferior quality to ones that were thoroughly tested. Who knows? You may get lucky
and get it right on the first try, but do you really want to bet a studio’s future on it?

Intuitively agile methods seem to be the way to go, and they anecdotally seem to pro-
vide for more organized projects that dovetail with best results. That said, the Game
Outcomes Project studied what factors most contributed to the success of game soft-
ware projects and found only a small effect (if any) on outcomes with regards to
project methodology.2

2 Tozour, P. (2014, December 16). “The Game Outcomes Project, Part 1: The Best and the Rest,” Gamasutra:
Paul Tozour’s Blog. Retrieved April 7, 2015, from www.gamasutra.com/blogs/PaulTozour/20141216/232023/
The_Game_Outcomes_Project_Part_1_The_Best_and_the_Rest.php.
 Development Structures  33

Climbing the Pyramid

The metaphor that I feel most generally covers game development from the smallest board
game to the largest software project is a model I call climbing the pyramid (FIGURE 3.4).

FIGURE 3.4 Climbing the pyramid

often involves sliding back down to
Finish an earlier step.

Test

Implement

Design

Gather Requirements

Projects start at the bottom of the pyramid. First, they must gather requirements. For a
board game, this can be as simple as making a list of the features desired and the audi-
ence expectations. For a complex software project, requirements gathering can be a
long undertaking. In any project, it must include research that supports understanding
the needs the project is trying to solve, understanding the competitors in the industry,
and understanding how similar projects tackle similar goals. If you have a broad under-
standing of what techniques are used in the industry, this step can be easier.

Next, the project climbs up the pyramid to design. To naive designers, this is where they
start and finish. However, for all projects, this is only part of the designer’s role. In this
phase, the team or designer takes the requirements from the previous phase and trans-
lates them into a full set of instructions of what the project will be. In digital games, this
can be broken down into game design, technical design, and media design documents
(among others). In analog games, this usually starts as a draft of the rules and content.

The third phase often takes the longest and is often confused with being the final phase.
To implement, the creators put together whatever is needed to make the game playable
and complete to the requirements. In digital games, this involves scripting and coding
the game, making and placing the art and animations, and tuning and tweaking the
aspects of the game that make systems work together. In analog games, this involves
creating the materials for the game. This often involves printing and cutting game
boards and cards.
Other documents randomly have
different content
 payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project

Gutenberg™ electronic work or group of works on different
terms than are set forth in this agreement, you must obtain
permission in writing from the Project Gutenberg Literary
Archive Foundation, the manager of the Project Gutenberg™
trademark. Contact the Foundation as set forth in Section 3
below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on,
transcribe and proofread works not protected by U.S. copyright
law in creating the Project Gutenberg™ collection. Despite these
efforts, Project Gutenberg™ electronic works, and the medium
on which they may be stored, may contain “Defects,” such as,
but not limited to, incomplete, inaccurate or corrupt data,
transcription errors, a copyright or other intellectual property
infringement, a defective or damaged disk or other medium, a
computer virus, or computer codes that damage or cannot be
read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU AGREE
THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT
LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT
EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE
THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person
or entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set

forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you
do or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status
by the Internal Revenue Service. The Foundation’s EIN or
federal tax identification number is 64-6221541. Contributions
to the Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact
 Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or determine
the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookball.com