in the 1950's, my grandfather was the superintendent of a skyscraper
in Tulsa, Oklahoma called the Philtower. (That's Phil as in Phillips
66 Petroleum. Mr. Phillips was an oil baron, and he named a lot
of things after himself.) At the same time, my mother was an "elevator
girl" - she operated elevators in the building. The elevators
in the Philtower were still controlled by hand, and she had to learn
to stop them at exactly the right time to get the floor of the elevator
to line up with the floor of the building.
this kind of family history, I didn't hesitate when Maxis brought
out Sim Tower. I was looking forward to running a whole skyscraper
like my grandpa, and operating, or at least managing, elevators
like my mother. Alas, it was not to be. Sim Tower wasn't
really about running a skyscraper; it was more about selling office
space in one. And for such a three-dimensional object, it was a
big disappointment to find myself constructing a two-dimensional
building. That wasn't the worst of it, though. The real problem
was the elevators.
mother's job was skilled but simple, and deadly dull. My job was
significantly harder. The key to success at Sim Tower was
programming the automated elevators, and I was hopeless at it. It
isn't as simple as it sounds, because in elevator programming the
ground floor is a special case. People arrive for work in huge numbers
at 8 AM, and they need to go all over the building starting at the
ground floor. At 5 PM, the reverse happens; they come from all over
the building, and all need to be transferred to the ground floor.
One of the things you have to figure out is, where's the most efficient
place for the elevators to wait when no one is using them?
read the manual repeatedly, fiddled, experimented, and tweaked.
No go. My little people stood for hours of game time, getting more
and more angry, waiting for elevators that never seemed to go where
I needed them to. I gave the people escalators as an alternative;
they sneered at them and continued to wait for the elevator. Tenants
moved out of my building in droves, and I went bankrupt. Elevator
management was clearly the heart of the game.
few years later I used this experience as an example in a lecture
about how to create fake artificial intelligence: impose an unfamiliar
task on the player, and don't tell him how to succeed at it. Give
the player the illusion of AI without having to do real AI. I couldn't
figure the elevators out, so I assumed that the game must be smarter
than I was.
After my lecture, a Maxis employee who shall remain nameless buttonholed
me. "You guessed right," she said. "Sim Tower
was built around a real elevator simulation program we bought from
a Japanese guy."
explained a lot. Sim Tower was an example of something I
call bottom-up game design, and even though this isn't a No Twinkie
column, I'm here to tell you now that it's a Twinkie Denial Condition
if there ever was one.
game design - which most often happens with simulations - consists
of taking a mechanism of some kind and trying to tack a game onto
it. Here's how it usually happens. You begin with some interesting
and complicated process - social interactions among a group of friends,
for example, or optimizing elevator behavior in a crowded building.
If you're a software engineer, your natural temptation is to figure
out how to program it and see how it works. What are the core mechanics
of the simulation? What is its internal economy? Should an elevator
be smart enough to know that it's full, so it doesn't stop for people
any longer until some get out? How long are people prepared to wait
for an elevator, anyway? And so on.
been guilty of it myself, back when I was a young programmer and
still thought that making computer games was about writing cool
software. Your head is fizzing along with data structures for representing
this and that, and algorithms for computing this and that, and the
very first thing you want to do is code it up and watch it go. But
this isn't a column to tell you "design your code before you
write it" - that's been said a million times already. The problem
with bottom-up game design, even if you don't write a line of code
for months, is that you don't know if it's any fun while it's just
was one of the weaknesses of Black and White, as I think
Peter Molyneux himself would admit. Molyneux is famous for creating
amazing, hugely innovative game engines, and only then figuring
out how to turn them into a game. If the gossip is right, he did
it with Populous, then with Dungeon Keeper, and again
with Black and White. Despite their success, all show signs
of having been written as a simulation first, and only then having
been turned into games.
can get away with this if you're Peter Molyneux, and you surround
yourself with brilliant talent and you innovate like crazy and work
like a dog (and are able to face down - or fake out - the publisher
when you're six months late). Lesser mortals are seldom so fortunate.
If you start with a simulation and count on turning it into a game
later, you run a serious risk that a few months before gold master,
you'll suddenly be asking yourself the dreaded question: "Why
isn't this more fun?" And then you're in real trouble.
game design is based on an assumption that any process that is subtle
or interesting to program is also going to be interesting to play
with. That doesn't necessarily follow. For years I was intrigued
by the challenge of programming a traffic simulation. The player
could widen roads, install traffic lights, and all sorts of things
to see how the flow of traffic changed under different conditions.
I mentioned this idea to my friend Anne Westfall, and she said politely,
"And who would want to do this?" The question brought
me up short. Not many people have a dream of fiddling around with
traffic-light timings. What's more, even I wouldn't want to do it
for very long, and I certainly wouldn't pay much money for the privilege.
I had gotten all excited about the software engineering problems
and ignored the fact that it needed to be enjoyable.
danger of bottom-up game design is the tendency to make the simulation
more realistic than it actually needs to be for the game. We're
all familiar with the problem of "creeping featurism"
- the temptation to "improve" your software with one more
feature, and then one more still, just because you can. In consumer
software, the result is usually a bloated, awkward mess like Microsoft
Office. In videogames, it's a game with far too much detail, none
of which is really that enjoyable to play with. I've played a number
of games that offered me tons of options, but I ended up only using
a few because those were the options that drove the engine of the
game. The others were legitimate enough, and someone had taken the
trouble to code them properly, but they didn't make sufficient difference
to the gameplay to bother with.
fact, the more variables you include in a simulation, the greater
the chances are that there's only one best way to play the game
- a dominant strategy, as it's called in game theory. The
reason is that in almost all cases, some of those variables are
going to have a greater effect on the internal economy of the game
than others. The player, trying to optimize her chances of success,
is going to concentrate on the most effective ones and ignore the
rest. The key to designing a meaningful simulation is to make sure
that all the variables matter enough for the player to use them
- and that means restricting the numbers to a carefully-balanced
few. Even though chess isn't a simulation, it's a good example of
what I mean: it's played with only six unit types. Adding half a
dozen more wouldn't improve it any. You would probably end up ignoring
most of them anyway.
too many variables also makes the game harder to test and balance,
and it's more prone to bugs. You're better off spending your time
balancing a small number of really interesting choices than you
are testing a large number of meaningless ones.
game design is an elementary mistake, usually made by programmers
and other people who like to build worlds and fiddle with them.
It is one of a large class of design and development errors that
is characterized by one common fault: failing to put the player
first. A videogame's purpose is to create enjoyment for the player
through gameplay, so good game design always begins with the player.
It doesn't begin with the puzzles, or the art, or the story, or
- in this particular instance - an elevator simulation.