Play as Research: The Iterative Design Process
Final Draft:
Needs and Pleasures
Design is a way to ask questions. Design research, when it occurs through the practice of design itself, is a way to ask larger questions beyond the limited scope of a particular design problem. When design research is integrated into the design process, new and unexpected questions emerge directly from the act of design. This chapter outlines one such research design methodology -- the iterative design process -- using three recent game projects with which I have been involved (SiSSYFiGHT 2000,
The creation of games is particularly well-suited to provide a model of research through design. In this book’s introduction, Brenda Laurel makes a distinction between the notion of designing “for needs” and designing “for delight.” {see
As a form of designed “delight,” the process of interacting with a game is not a means to an outside end, but an end in and of itself. It is this curious quality of games that makes them wonderful case studies for design research through the process of design. As a game evolves (through the iterative process outlined below), it defines and redefines its own form and the experiences it can provide for players. Through the iterative play of design itself, entirely new questions can come into being.
Iteration Iteration
Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a work in progress. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.
{zimmerman.chapter.01}
Test; analyze; refine. And repeat. Because the experience of
a viewer/user/player/etc cannot ever be completely predicted, in an iterative
process design decisions are based on the experience of the prototype in
progress. The prototype is tested, revisions are made, and the project is
tested once more. In this way, the project develops through an ongoing dialogue
between the designers, the design, and the testing audience.
In the case of games, iterative design means playtesting. Throughout
the entire process of design and development, your game is played. You play it.
The rest of the development team plays it. Other people in the office play it.
People visiting your office play it. You organize groups of testers that
match your target audience. You have as many people as possible play the game. In
each case, you observe them, ask them questions, then adjust your design and playtest again.
This iterative process of design is radically different than
typical retail game development. More often than not, at the start of the
design process for a computer or console title, a game designer will think up a
finished concept and then write an exhaustive design document that outlines
every possible aspect of the game in minute detail. Invariably, the final game never
resembles the carefully conceived original. A more iterative design process, on
the other hand, will not only streamline development resources, but will also
result in a more robust and successful final product.
Case Study 1: SiSSYFiGHT 2000
Summary: SiSSYFiGHT 2000 is a
multiplayer online game in which players create a schoolgirl avatar and then vie
with 3-6 players for dominance of the playground. Each turn a player selects
one of six actions to take, ranging from teasing and tattling to cowering and licking
a lolly. The outcome of an action is dependent on other players’ decisions,
making for highly social gameplay. SiSSYFiGHT 2000 is also a robust online
community. You can play the game at www.sissyfight.com.
These play values were the parameters for a series of brainstorming
sessions, interspersed with group play of computer and
non-computer games. Eventually, a game concept emerged: little girls in social
conflict on a playground. While every game embodies some kind of conflict, we
were drawn towards modeling a conflict that we hadn’t seen depicted previously in
a game. Technology and production limitations meant that the game would be
turn-based, although it could involve real-time chat.
Once these basic formal and conceptual questions had begun
to be mapped out, the shape of the initial prototype became clear. The very
first version of SiSSYFiGHT was played with post-it-notes around a conference
table. I designed a handful of basic actions each player could take, and acting
as the program, I “processed” the actions each turn and reported the results
back to the players, keeping score on a piece of paper.
Designing a first prototype requires strategic thinking
about how to most quickly implement a playable version that can begin to
address the project’s chief uncertainties in a meaningful way. Can you create a
paper version of your digital game? Can you design a short version of a game
that will last much longer in its final form? Can you test the interaction
pattern of a massively multiplayer game with just a handful of players?
In the iterative design process, the most detailed thinking
you need at any moment is that which will get you to your next prototype. It is,
of course, important to understand the big picture as well: the larger
conceptual, technical, and design questions that drive the project as a whole. Just
be sure not to let your design get ahead of your iterative research. Keep your
eye on the prize, but leave room for play in your design, for the potential to change
as you learn from your playtesting, accepting the fact that some of your
assumptions will undoubtedly be wrong.
The project team continued to develop the paper prototype,
seeking the balance between cooperation and competition that would become the
heart of the final gameplay. We refined the base ruleset -- the actions a
player can take each turn and the outcomes that result. These rules were turned
into a spec for the first digital prototype: a text-only version on IRC, which
we played hotseat-style, taking turns sitting at the same computer. Constructing
that early, text-only prototype allowed us to focus on the complexities of the
game logic without worrying about implementing interactivity, visual and audio aesthetics,
and other aspects of the game.
While we tested gameplay via the text-only iteration,
programming for the final version began in Director, and the core game logic we
had developed for the IRC prototype was recycled into the Director code with
little alteration. Parallel to the game design, the project’s visual designers
had begun to develop the graphic language of the game and chart out possible
screen layouts. These early drafts of the visuals (revised many times over the
course of the entire development) were dropped into the Director version of the
game, and the first rough-hewn iteration of SiSSYFiGHT as a multiplayer online
game took shape, inspired by Henry Darger’s outsider art and retro game
graphics.
{zimmerman.chapter.02}
When the server infrastructure was completed, we launched
the game to an invite-only beta-tester community that slowly grew in the weeks
leading up to public release. Certain time slots were scheduled as official
testing events, but our beta users could come online anytime and play. We made it
very easy for the beta testers to contact us and email in bug reports.
Even with this small sample of a few dozen participants, larger
play patterns emerged. For example, as with many multiplayer games, it was
highly advantageous to play defensively, leading to standstill matches. In
response, we tweaked the game logic to discourage this play style: any player
that “cowered” twice in a row was penalized for acting like a chicken! When the
game did launch, our loyal beta testers became the core of the game community, easing
new players into the game’s social space.
{zimmerman.chapter.03}
{zimmerman.chapter.04}
{zimmerman.chapter.05}
Case Study 2: LOOP
Summary:
Initial prototypes are usually quite ugly. Game prototypes do
not emphasize aesthetics or narrative content: they emphasize the game rules,
which manifest as the internal logic of the game, tied to the player’s interaction.
Visuals, audio, and story are important aspects of a game, but the core
uncertainties of game design, the questions that a prototype should address,
lie in the more fundamental elements of rules and play.
Another way of framing this problem is to ask, What is the activity of the game? Rather than asking
what the game is about, ask what the player is actually doing from
moment to moment as they play. Virtually all games have a core mechanic,
an action or set of actions that players will repeat over and over as they move
through the designed system of a game. The prototype should help you understand
what this core mechanic is and how the activity becomes meaningful over time.
Asking questions about your game’s core mechanic can guide the creation of your
first prototype, as well as successive iterations. Ideally, initial prototypes model
this core mechanic and begin to test it through play.
The first prototype tested only this core interaction,
allowing the player to draw lines, but nothing else. Our next step was to have
the program detect a closed loop and add objects that would shrink and
disappear when caught in a loop.
{zimmerman.chapter.06}
{zimmerman.chapter.07}
{zimmerman.chapter.08}
Each of these prototypes had parameters adjustable by the
person playing the game. The length of line and detail on the curve could be
tweaked, as well as the number of objects, their speed and behavior, and
several other variables. As we played the game, we could try out different
parameters and immediately see how they affected the experience, adjusting the
rules to arrive at a different sort of play. This programming approach,
building accessible game design tools into a game prototype, is a technical
strategy that incorporates and facilitates iterative design. A sample of the
game editor code follows:
-- LOOP SCORES
score_same=0,5,10,20,40,80,150,250,350,500,700,1000,1400,1900,2500,3100,380
0,4600,5500,7000
score_different=0,0,30,75,200,500
score_badloop=-20
-- # of caught butterflies for each level of loop sound effect
loop_sound_num=1,4,6,8,10
-- BONUSES
-- butterfly-borne bonus (x2):
bonus_lifetime=60
-- leaf-blown bonus (longer, moretime, freeze, flock):
freebonus_speedlimit=15
bonus_freeze_duration=4
bonus_flock_duration=12
-- HAZARDS
snail_speedlimit=1.2
killerbee_speedlimit=12, killerbee_attackrate=3,killerbee_stingduration=6
beetle_speedlimit=3, beetle_fighttime=4, beetle_aborttime=10,
beetle_effectradius=300
stinkbug_speedlimit=2, stinkbug_tag_radius=40,
stinkbug_effect_duration=10, stinkbug_effect_radius=300
spider_speedlimit=9, spider_climblimit=22,spider_stingduration=6,spider_loop_length=5
As the butterfly content of the game emerged, so did debate
about the game’s overall structure and victory and loss conditions. Did the entire
screen need to be cleared of butterflies or did the player just have to catch a
certain number of them? Did the butterflies gradually fill up the screen or did
their number remain constant? Was there some kind of time-pressure element? Were
there discreet levels or did the game just go on until the loss conditions were
met? These fundamental questions, which grew out of our core mechanic
prototyping, were only answered by actually trying out possibilities and coming
to conclusions through play.
As the game code solidified, the many adjustable parameters
of the game were placed in a text file that was read into the application when
it ran. These parameters controlled everything from the behavior of game
creatures to points scored for different numbers of butterflies in a loop to
the progression of the game’s escalating difficulty. Thus the game designers
could focus on refining game variables and designing levels, while the rest of
the program -- screen transitions and help functionality, the high score system
and integration with the host site -- was under construction.
{zimmerman.chapter.09}
{zimmerman.chapter.10}
{zimmerman.chapter.11}
Case Study 3: LEGO Junkbot
Summary: LEGO Junkbot is a
singleplayer game in which the player helps the robot character Junkbot empty
trash cans throughout a factory. The player doesn’t control Junkbot directly
but instead uses the mouse to move LEGO bricks around the screen,
deconstructing and reconstructing his environment brick by brick, building
stairways and bridges that help Junkbot get where he needs to go. A variety of
helpful and hazardous objects and robots add variety and complication to the
game’s 60 levels. Junkbot levels can be solved in multiple ways and the game
structure encourages players to go back to previously solved levels and
complete them using a different method.
The conceptual starting point for the creation of LEGO
Junkbot came from gameLab’s client, LEGO.com. LEGO wanted a game about brick
construction with a target audience of 8-12 year-old boys that that could also
be played and enjoyed by adults. The challenge of the design problem was that real-world
LEGO play was the referent. Yet in no way could we ever hope to recreate the sublime
interactivity of plastic LEGO bricks. How could we translate LEGO play into a
digital game?
Our first step was to purchase and play with a whole mess of
LEGO bricks, as a way of analyzing and understanding their subtleties. Then, as
with most gameLab projects, we began to design by identifying the project’s play
values. These values, which embodied the material and experiential qualities of
LEGO as well as the cultural ethos of the LEGO play philosophy, included concepts
like modularity, open-ended construction, design creativity, multiple-solution
problem-solving, imaginative play, and engineering. Using these play values as
our limiting parameters, we brainstormed a number of game concepts.
The concept LEGO selected was called LEGOman (the character
and storyline of Junkbot had not yet emerged) and it centered around moving
bricks to indirectly help a character move through an environment. The first playable
prototype was the simplest possible iteration of the core interactive idea: the
player could use the mouse to drag bricks on the screen; there was a single, autonomously-moving
protagonist character; there were goal flags to touch; and there were rolling
wheel hazards to avoid.
{zimmerman.chapter.12}
{zimmerman.chapter.13}
We played that first prototype. And it was not very fun. Because
gameLab projects often try to invent new forms of gameplay, we sometimes find
that our initial prototypes are just not that enjoyable to play. At such an
early juncture in the iterative design process, we could have scrapped the
design altogether and started fresh, building on insights learned from the
unsuccessful prototype, or we could dig in and push on through. We chose the
latter. Gradually we added elements to the game, refining the interaction, expanding
the level possibilities, putting in new kinds of special bricks and robot
hazards.
Each new element addressed something that was lacking in the
experience of the previous prototype: it was monotonous to move bricks one by one,
so we implemented code that let players stack bricks and move them as a group. We
needed a way to move the main character vertically on the screen, so we added fan
bricks, which float Junkbot upwards. The game obstacles all felt too
deterministic, so we introduced robot hazards that responded to Junkbot in real
time. And as these interactive embellishments deepened the game (which was
actually becoming fun to play), the character and storyline of Junkbot emerged.
Throughout the process, we utilized a level editor, a visual
design tool that let the game designers create and save levels. The editor
allowed them to experiment with game elements and level designs, refining the
overall experience and planning features for the next iteration of the
prototype.
{zimmerman.chapter.14}
Playtesting continued with the gameLab Rats, using a
web-based form to collect and collate testing data about the difficulty and
enjoyment of each level. However, our main concern was whether the basic
brick-construction core mechanic would be understood by our target audience, so
we visited an elementary school computer classroom, sat kids down in front of
the game, and let them play cold. This testing was invaluable, and confirmed
our fears: too many of the testers had trouble picking up basic game concepts,
such as how to make a stairway for Junkbot out of bricks. This testing directly
influenced the design of the game, and we slowed down the overall learning
curve, designing the first several game levels to more clearly communicate the
essential interactive ideas.
{zimmerman.chapter.15}
{zimmerman.chapter.16}
{zimmerman.chapter.17}
A good rule of thumb for iterative testing is to err on the
side of observation rather than guidance. While it may be difficult to keep
your hands off the tester’s mouse, instead sit back and see what your audience
actually does, rather than telling them how it is supposed to work. What you
observe can sometimes be painful to watch, but it will help you design more
successful play. Part of iterative design is simply learning how to listen.
Conclusions
Iterative design is a process-based design methodology, but
it is also a form of design research. In each of these three case studies, new questions
emerged out of the very process of design, questions that were not part of the initial
investigation but were nevertheless addressed through iterative play and design.
To design a game is to construct a set of rules. But the
point of game design is not to have players experience rules -- it is to have
players experience play. Game design is therefore a second-order design
problem, in which designers craft play, but only indirectly, through the
systems of rules that game designers create. Play arises out of the rules as
they are inhabited and enacted by players, creating emergent patterns of
behavior, sensation, social exchange, and meaning. Thus the necessity of the iterative
design process. The delicate interaction of rule and play is something too subtle
and too complex to script out in advance, requiring the improvisational
balancing that only testing and prototyping can provide.
The principles of the iterative process are clearly applicable
beyond the limited domain of games. Rules and play are just game
design terms for structure and experience: a designer creates
some kind of structure (a typeface, a building, a car), and a reader,
visitor, or car passenger experiences it: encountering, exploring, dwelling
in, and manipulating the system -- using it, playing with it, delighting in it.
Games provide particularly clear examples of iterative design, but any design
field can benefit from such an approach.
In iterative design, there is a blending of designer and
user, of creator and player. It is a process of design through the reinvention
of play. Through iterative design, designers create systems and play with them.
They become participants, but do so in order to critique their creations, to bend
them, break them, and re-fashion them into something new. And in these
procedures of investigation and experimentation, a special form of research
takes place. The process of iteration, of design through play, is a way of discovering
the answers to questions you didn’t even know were there. And that makes it a
powerful and important form of design research.
Project Teams
Word.com, 2000
Marisa Bowe, Ranjit Bhatnagar, Tomas Clarke, Michelle
Golden, Lucas Gonze, Lem Jay Ignacio, Jason Mohr, Daron Murphy, Yoshi Sodeka,
Wade Tinney, Eric Zimmerman
gameLab, 2001, published by Shockwave.com
Ranjit Bhatnagar, Peter Lee, Frank Lantz, Eric Zimmerman,
& Michael Sweet / Audiobrain
gameLab, 2001, published by LEGO.com
Ranjit Bhatnagar, Nick Fortugno, Peter Lee, Frank Lantz, Eric
Zimmerman, & Michael Sweet / Audiobrain
{zimmerman.chapter.01} The iterative design process
{zimmerman.chapter.12}{zimmerman.chapter.13} LEGO Junkbot
early prototype
{zimmerman.chapter.14} LEGO Junkbot level editor tool
copyright © 2010 eric zimmerman |
be playful |