I recently spoke with Stone Librande, who has worked as a designer
on games including “Spore” and “Diablo III”. Stone also leads an
annual design workshop at the Game Developers’ Conference and teaches a
college course in game design. We discussed game design process,
including a method of paper prototyping that UX designers will find
both familiar in concept and new in execution.
Q: Tell me a bit about your background.
Before I went into gaming I was actually doing a lot of work in user
interface design. I commercialized a technology that parameterized
artwork and allowed users to quickly sift through thousands of drawings
just by pulling sliders mapped to different characteristics. We found
a lot of video game applications for it. Then I took a job managing a
Web design team at a company called MPlayer, which was a social gaming
network that was a little bit ahead of its time. But looking all the
way back to my childhood, game design was always something I was
interested in. Eventually I worked my way into Blizzard and from there
on to Maxis to work on Spore.
Q: How was Spore’s game experience created?
Well there were really two pieces to that. First, there was a
high-level description from Will Wright. In one case, we were asked to
make a game about cells swimming in a drop of water. Then
there’s the bottom-up design of the game mechanics. An important
consideration in the cell game was creating the right balance of risk
and reward. In any game you don’t want it to either be too hard (which
would become frustrating) or too easy (which would make the game
boring). But everyone’s different and we wanted Spore to have broad
appeal to both casual players and hardcore gamers. The question is:
How do you make an experience to fit many different tastes?
way we approached that was by giving players opportunities to outfit
their cell creatures with different pieces as they evolve. Novice
players can finish the whole cell experience with just the basic
creature design. You can get by while taking very modest risks, but
you also won’t reap great rewards from it. But for hardcore players,
there’s an opportunity to really dig into the game by experimenting
with the effects of different pieces. They’re invited to take a lot
more risks, and they put themselves in more danger of failing. Since
the traits they pick up in the cell game effect the later stages, those
players who take on a greater challenge can also put themselves at an
advantage and realize a greater reward.
Q: How do you guide players’ behavior in games?
A lot of those ideas you learned in Psych 101 like reinforcement
schedules are fundamental to game design. People are subject to the
same behavioral influences as pigeons and rats. You can influence the
players’ behavior by attaching a meaningful reward to the actions you
want them to take. For example, say you’re designing a card game and
you want players to try to collect three 3’s. You could force them to
do that by making it the winning condition — there’s your reward. Or
you can make people pursue that same goal less aggressively by saying
that three 3’s are worth 3 points, while all other collections of cards
are worth one point.
The most powerful reward you can give a
player is a social reward. Intrinsic rewards are nice, but adding in a
social component exploits people’s basic competitive nature. If
someone else has something that you don’t have, you’ll work really hard
to obtain it. There’s also a element of inclusion, of being part of an
in-group that’s tied together by the game experience.
You gave a presentation at last year’s Game Developers’ Conference
about paper prototyping. Tell me about how your method works.
First of all, the paper prototype is not a representation of the actual
game, and it’s not intended to be. That’s not the purpose. Instead,
the point is to ask and answer one simple question about the game
you’re working on. Second, it should be something that you can
experiment with and iterate very quickly.
So for Spore’s cell
game, a key design question was figuring out the various creature parts
that would be available to the player, and how they balance against one
another. So I put together a board game version on paper. [See an image of the game board here.] I wrote up
a large list of parts and their abilities, going big at first so we
could test a lot of scenarios and then scale it back. Players would
assemble a unique cell creature using different
combinations of eyes, mouths, graspers and tails. The cell pieces have
different game abilities. For instance, tails allow the cell to move
forward and rotate. During the game, each cell would either attempt to
eat the most green food tokens (herbivore victory) or to attack and
kill the opposing cell (carnivore victory).
We ended up with 12
parts that were given away over the course of the cell game’s five
stages. We also defined the other creatures you’d encounter in each of
those stages, ranging from harmless to more difficult as the player
progressed through the game. That output was what made it into the
final game. [See an image of the game output here.]
Q: Why do this on paper, when you could model thousands of different scenarios in one go using a computer?
I run a workshop teaching this technique at the Game Developer’s
Conference, and computers aren’t even allowed into the session.
Building prototypes with paper fosters team interaction. As people
work on it, they’ll start role-playing and getting into the characters
of the game. They also develop a shared vocabulary for discussing
elements of the game. If you did it with computers, everyone would
just be working on their own and you wouldn’t get that kind of
Q: What works best prototyped on paper?
You can’t represent the full gameplay experience, that’s just not
practical. A video game like Spore has a lot of physics and math, and
that just can’t be done on paper. Input controllers like mice or
keyboards are also really difficult to simulate. Anything that’s too
complex would just be misery to test. Similarly, if a user interface
designer were prototyping the front end for a database, you could show
what the form elements and buttons look like but you couldn’t simulate
the return of actual data. That’s just too complicated to do.
said, when you really abstract a design problem there’s a lot that you
can pull into a non-electronic prototype. In my workshop, I do an
exercise where I have people build prototypes of existing video games.
A few years ago one team decided to try doing Rock Band, and I was
really skeptical that it would work. Surprisingly, they came up with a
game that captured Rock Band’s core mechanics. There were five
players, one of whom had a shuffled deck of colored index cards. He
would throw out the cards in sequence, and all of the other players had
to dig through their own cards and throw down matching colors. When
you matched the pattern, the moderator would give you coins. If you
missed, he would take coins away. Players could support one another by
throwing coins to band members who were missing their beats. Even
though there was no music and there were no plastic instruments, the
game really captured the Rock Band feel.
This is a really amazing method. Thanks so much for taking the time to talk, Stone.
Leave a Reply