     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Perils of Bottom-up Game Design
Back 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. With 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. My 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? I 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. A
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. That 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. Bottom-up 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. I've 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 a simulation. This 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. You 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. Bottom-up 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.
Another 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. In 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. Including 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. Bottom-up 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. ______________________________________________________
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The
Perils of Bottom-up Game Design
Designer's
Notebook 
|
|
|