Transcript The Iterative and Incremental Nature of Game Design Dr. Lewis Pulsipher Copyright 2008 Lewis Pulsipher Teachgamedesign.blogspot.com Pulsiphergames.com pulsiphergamedesign.blogspot.

The Iterative and Incremental
Nature of Game Design
Dr. Lewis
Pulsipher
Copyright 2008 Lewis Pulsipher
Teachgamedesign.blogspot.com
Pulsiphergames.com
pulsiphergamedesign.blogspot.
Who am I
 Designed my own games while a teenager
 Began playing commercial wargames in 1963
 Played the original Atari 2600 and have played some




PC games heavily
Designer of six commercially-published board
wargames (most recently February ’06, reprint this
spring)
Active designer of games (playtesters solicited!)
First to teach game design in the state as far as I
know (Fall ’04). Recently taught nearly 100
beginners at Wake Tech
Presently writing textbook(s) about how to design
games, and how to teach people to design games
November 6, 2015
What is today’s subject problem?
 Students, and even instructors, who don’t
actually design games, don’t understand the
process of design
 Hence “game design” classes often become
“game production” classes, and the most
important part of design (the last 20% that
takes 80% of the time) is skipped
 And students think, when they have a
working prototype, they’ve “succeeded”
November 6, 2015
The last 20%
 "One of the hardest things when dealing with
students is to convince them to work on small games
and complete them, rather than working on a single
huge sprawling mess that dies under its own weight.
It's also hard to convey the 80/20 rule, that 20% of
the work gets you the first 80% of the game... but
getting that last 20% of the game (which is the
polish factor) takes a lot of time after the game
already feels like it 'should' be done, and pressing on
when you're sick of working on the game already is
what separates the developers from the wannabes."
 Ian Schrieber, http://teachingdesign.blogspot.com/
November 6, 2015
Delusions of “wannabe”
designers
 “I designed a game” because
– I thought of an idea
• Ideas are “a dime a dozen”
• Publishers don’t publish ideas
– I talked about that idea with others
• OK, not a bad thing to do
– I made a prototype and my family loves it
• Or at least, they said they did
– It’s reasonable to work on just one game at a time
– I tested the prototype with other people several times
• Good, but how much, how many, how long?
– I’ve made a beautiful submission version (non-electronic,
usually)
• Publishers want good gameplay
• Looks don’t matter in prototypes
 All delusions
November 6, 2015
What’s the “artificial” way?
 Lopsided treatment of the process in
“video game design” books
– Emphasis on design “up front” rather than
as a continuing process
– This derives largely from the expense (time
and money) of making electronic
prototypes
– Give impression that virtually all the design
is done before a prototype exists
November 6, 2015
Artificial way 2
 Yet this is like any form of planning: “no plan
survives contact with the enemy”; and that
“contact” is actually playing the game
 If the fundamental design is bad, there will
be no saving the prototype; but good
playtesting and modification can make a
weak game pretty good
 Poor playtesting and modification will make
even the best game weak
November 6, 2015
Artificial way 3
 Costs too much to make prototype on
“speculation”
– Electronic games require all the “rules”
(specifications) before a prototype can be made
– And the “rules” are much more complex, because
the computer must understand them, not a
human with human intelligence
– So “real” playable prototypes (as opposed to
prototypes to show concept) are very complex and
time-consuming
 Studios spend much time and effort
persuading publishers to pay them on the
basis of a plan (description of a design)
November 6, 2015
Artificial way 4
 Industry habit of running out of time
– Publishers make schedules and the “suits” don’t understand
the iterative nature of the process
– Electronic games are engineering problems: and no one can
say with certainty how long is needed to solve an
engineering problem
– “You can’t gather nine pregnant women and have a baby in
a month”—games (and especially game design) take time
– So frequently, studio runs out of time and a poor game is
published
– “Patches” can do only so much to repair weak gameplay;
they’re mainly for “bugs”
– Yet we do see games that are mightily improved by the first
patch, because of additional incremental modification
November 6, 2015
What’s the “natural” way to
design a game?
 Get ideas, figure out roughly how the game will work,





and try it out almost immediately
Work on the game for what seems like forever,
testing and making modifications
Finish (or nearly finish) the game, then approach a
publisher on the basis of the actual game, not a plan
for the game
“Narbacular Drop” (= Portal)
Even then, the published game will often be much
different from the submitted game (Portal again?)
Development studios that can take as much time as
they like are doing it the “natural” way– e.g. Blizzard
November 6, 2015
When we get serious what the
“wannabes” should be doing
 We’ve tested it with many people until I’m
SICK of it
•
•
•
•
The last 20% of polish takes 80% of the time
Plan-monitor-control (modify)-replan
Iterative and incremental
This is where the real designers are separated from the
“wannabes”
 I actually tried to sell it to a publisher (some
wannabes do try)
 Wannabes often self-publish
 It was published and I am being paid or have
been paid for it
November 6, 2015
The game design process
 Adams and Rollings talk three phases
– Conception,
– Elaboration,
– Tuning (which is iterative and incremental)
 I’ve expressed the process a different
way, in Data Flow Diagram terms
November 6, 2015
November 6, 2015
Data Flow Diagram notes
 There are seven processes (activities),
not in a particular order—several are
going on at the same time
 Each process has sub-processes not
shown here
 There are also data stores, data flows
(arrows), and agents external to the
system (rectangles)
November 6, 2015
List of processes
 Conceive and refine ideas
 Play game in “mind’s eye”—thought
experiments
 Conceive game, structure, framework
 Create and refine prototype
 Write notes-rules-software
 Solo playtest
 Playtest with others
November 6, 2015
Prototypes—”testing is sovereign”
 To truly improve a game, you must have a
playable prototype
– Civilization I—Sid Meier programmed, Bruce
Shelley tested, they talked, Sid modified, Bruce
tested again, day after day
– Sid said recently on slashdot, "My whole approach
to making games revolves around first creating a
solid prototype and then playing and improving
the game over the course of the 2-3 year
development cycle... until we think it's ready for
prime time. My experience in this area helps me
to know what to do and where to start. I
definitely spend a lot of time playing the game
before I let anyone else look at it."
November 6, 2015
Prototypes
– The sooner Firaxis got a playable version of Civ 4,
the more they could learn
 The rules for a non-video game are the
equivalent of the programming of a video
game
– Programming must be precise and is very time
consuming (game engines may help some)
– A playable set of rules can be much less precise,
relying on the mind(s) of the designer(s) when
they’re present, and (inevitably imprecise) notes
November 6, 2015
Proof in publication
 How many games aren’t very good until
the first patch?
 That’s because the studio did not take
(or was not allowed) enough time to
finish the incremental, iterative process
of improvement
November 6, 2015
Art vs. science
 Game design is 10% art, 90% science
 Art is something created by an individual,
then presented to the public “as is”
– There is no “testing” or “focus groups”
 Science is something subject to repeated
testing
– And almost all good games are thoroughly
playtested
– A sign of an “amateur” designer is insufficient
testing
 But it IS a creative endeavor, not mechanical
November 6, 2015
Teaching design: non-electronic
much more efficient
 For teaching purposes, non-electronic games teach
students much more about game design
 Prototypes are quickly produced
– It’s much easier to produce the physical prototype, than to
create the artwork for a video game
 Simplicity lays bare the real process of design
– Novices tend to assume the computer will take care of
problems and limitations that are really design problems and
limitations
 It’s also much easier to change the non-video
prototype to test different approaches—more
flexibility = better results
 There’s time to do the long polishing required and to
actually “finish” the game
November 6, 2015
Learning to design
 So we can have a playable, testable non-
video game much more quickly than a
computer game of similar scope or subject
 Consequently, it’s much easier to learn game
design with physical games than with video
games!
 Kevin O’Gorman (American International U)
has designed at least six published video
games: agrees that non-video games must be
used to teach game design
November 6, 2015
What happens in Game Design
classes?
 Game production vs. game design
 We don’t teach game design or
programming (or minimally) in 3D
modeling
 We don’t teach 3D modeling or design
(or minimally) in programming
 So why teach graphics and
programming in game design classes?
November 6, 2015
Game Design becomes “Game
Production” class
 But we do teach programming and art in “game production”
classes
– For example, groups required to produce:
• Playable prototype with 3 levels in three weeks
• CD Cover, CD Box Art, 11x17 Poster, and Docs (Design, manual)
– 3 weeks is ludicrous for an electronic game, unless it is “castrated”
– “levels”—already defines what the game is going to have and not
have
– But at least they’re making games, not memorizing from a book
 Of course, expecting groups of students to produce an
electronic game in three weeks, or individuals to produce a
boardgame in a week (including rules) is ridiculous
 “You can’t gather nine pregnant women and have a baby in a
month”—game design takes time for reflection and
experimentation
 This teaches students that they’re doing something mechanical
and simple, rather than creative and complex
November 6, 2015
Why are we doing this?
 Derives in part from fundamental contempt
for games: “oh, games are just kid stuff,
anyone can design them”
 Derives in part from ignorance—most people
teaching “game design” haven’t done it in
any meaningful sense, they’ve been fooled by
the textbooks
 Students think that because they’re expert
gamers, they can easily design good games
– There’s little connection between the two skills
– Many designers aren’t particularly good players,
though it’s better if they are (they can find flaws
themselves rather than rely on testers)
November 6, 2015
Why are we doing this?
– “This will be the best game ever”. (Sure)
• Testing proves otherwise
 False notion that game design is a
knowledge, not a skill—knowing, not doing
– Memorization of information
– “Delivery of content”
– At one large school, online game design class
taught by someone who has not been a game
player—ridiculous, how can results be evaluated?
– Ask yourself, would this make sense in a musical
composition or sculpture course?
November 6, 2015
Game design, orchestral composition,
creative writing, other creative endeavors
 This is a creative endeavor, involving complex
entities, not simple entities
 Would you expect people with no experience
to produce good compositions, or good
fiction, right off?
 Examples:
– John Creasy, over 600 books published, rejected
over 700 times to begin career
– Jerry Pournelle (SF writer) says “be willing to
throw away your first million words”
– How many of Beethoven’s early works would be
played, if not written by Beethoven? Very few
November 6, 2015
Creative endeavors
 No wonder so many early video games
were poor games—lack of experience of
the designers!
 No wonder so few “big budget” games
are designed by inexperienced people,
and no wonder the big games tend to
be designed by committee
November 6, 2015
The stages of completion of a
non-video game design












Idea
Notes about idea
Detailed notes about idea
Rough board/layout of pieces (if any)
Detailed board/layout (if any)
Prototype (pieces/cards added)
Solo-played prototype
Prototype played by others
Full written rules (rarely done before others have played)
"Settled" game
Blind testing
"Done" (but still subject to change, especially by manufacturer)
November 6, 2015
The stages of completion of a
video game design










Idea
Notes about idea
Detailed notes about idea
Game treatment
“Rules”
Computer Prototype (usually for show)
Playable Prototype (usually new code)
Development
Testing
“Done”
November 6, 2015
Design vs. “development”
 “Development” has two meanings
– In video games, it means writing the program
– In non-video, development (often by a person
other than the designer) sets the finishing touches
on a game, but may include significant changes
• This can include the bulk of the testing and modification
– Development takes longer than design, in either
case
– Video game classes tend to entirely leave out
“development” in the sense of testing and
modification to put on “finishing touches”
November 6, 2015
The designer’s game vs. the
game that’s published
 Video games are often overseen by the
publisher, who is paying the bills; so it
is modified to suit as it is developed
 Non-video games are often unseen by
the publisher until “done”; some
publishers then modify them, often
heavily
November 6, 2015
November 6, 2015
My original intention for this talk
 How do I represent the changes in this short
face-to-face format?
 Many of the changes that occur in a game
are not immediately visible, or not visible at
all—only noticeable through extended play
 We’re interested in gameplay, not
appearance—functional changes
 Maps?
 Cards to pass around
November 6, 2015
Example: the progress of a
design . . . “Law & Chaos”
 Design constraint: I wanted a game that primarily
used colored glass beads (“stones”)—elegant, visual
effect
– Likely to be abstract, then—not enough variety for anything
“realistic”
 But how much variety can you get with one kind of
piece (even chess has many kinds); how could I
provide variety?
– Introduce a random but somewhat controllable element
– Dice undesirable to publishers nowadays
– Why not use cards to change the rules (from Fluxx, CCG)
November 6, 2015
“Law & Chaos”
 What to change?
– Victory conditions (pattern of stones needed to win)
– Capture methods (pattern needed to take an opposing
piece)
 The game turned out to be best for three players
(which is very rare), not something I looked for when
I started
 And there are many, many variations now extant,
changing other aspects of the game (the board, the
placement/movement of pieces, etc.)
 Examples (if there’s time)
November 6, 2015
Some Web resources










These slides at pulsipher.net/teaching1.htm
IGDA.org (Game developers)
Sloperama.com
Gamespot.com, gamewire.com
Gamesjournal.com (no longer published, but read the
archives)
Teachgamedesign.blogspot.com
Boardgamegeek.com
Boardgamedesign Yahoo Group
rec.game.design (limited)
Board Game Designers Forum (online)
November 6, 2015
Questions?
Comments?