Bad Game Designer, No Twinkie! III

Well, it has been close to two years since the last "Bad Game Designer, No Twinkie!" column, so I think it's time for another one. I keep a collection of computer game misfeatures, design errors, and personal annoyances as I play, and it's now long enough to publish. Some of these are level-design errors or even programming weaknesses, but they're all things that a game designer has at least some influence on.

Adolescent Armageddon

"Conquer the world!" "The fate of humanity is at stake!" "Save the galaxy!" scream the boxes on the shelves down at the game software store. "No!" I'm tempted to scream back. "I don't want to! The galaxy can go stuff itself!"

Too many computer games are fulfillments of adolescent power-fantasies, and a meaningless apocalyptic scenario is a classic symptom. It's been quite a while since I was an adolescent, and I just don't believe them any more. Maybe that means I'm a boring old adult, no longer capable of grandiose visions… but let's face it, the people who run around yelling about conquering the world are nut cases. I think it's more accurate to say that I just don't care. I don't want to rule the world. I'm not terribly interested in saving the galaxy. It's too big and impersonal a task, and it's not credible that a single individual can do it anyway. Don't ask me to. I don't feel like it.

All stories require dramatic tension, and dramatic tension is created by establishing a situation that puts something, or someone, that the reader cares about at risk. Likewise, all games require a goal, something that the player is hoping to achieve, which creates what we might call "gameplay tension." The similarity of dramatic tension and gameplay tension is the reason that computer games so often have a storytelling element. But if you look at the great stories in literature, what's at risk is seldom something vast and incalculable like the fate of the world. Rather, it's the lives and happiness of individual people. There's more genuine tension in a novel by Charles Dickens - will David Copperfield survive the wicked machinations of Uriah Heep? - than there is in all the movies about earth-shattering asteroids ever filmed. And even those movies don't really try to engage our sympathy for the Earth as a whole. Rather, they engage our sympathy for the movie's main characters and their individual fates. Take When Worlds Collide, for example. They destroyed the Earth and everyone on it, but -- whew! -- our heroes got away safely. Thank goodness for that! Happy ending!

"But wait," I hear you cry in irritation. "Aren't you one of those Tolkien nuts? And isn't The Lord of the Rings about as apocalyptic as you can get?" Well, yes, I am, and yes, it is. But what sets The Lord of the Rings apart from most of its pale imitators is that it's not actually about how wonderful it is to save the world. It's about what passes away irretrievably even when you succeed. It's a book about the tragedy of saving the world, the price to be paid for doing it.

I think the success of The Sims demonstrates pretty clearly that it's not necessary to rule the world, and a lot of people don't even want to. They're busy just trying to keep the dishes washed and the newspapers picked up. Millions of them are perfectly happy doing it, and Maxis is making a fortune out of fulfilling that particular, if peculiar, fantasy. We don't need for games to be about adolescent armageddon. We only need for them to be about people that we care for, and in fact that allows us to make a much wider variety of games than "Save the world!" does.

Having to stand in (or select) exactly the right spot.

There's not a lot that needs to be said about this. If the designer has made a selectable region of the screen extremely small on purpose, it's just a trial-and-error time-waster, a boring puzzle. If the designer has done it by accident, it's a misfeature that should have been caught during testing. There's one problem with testers: they're such experienced gamers - and after a few hundred hours playing a game, so experienced with that particular game - that they may not catch design errors which would annoy the pants off mass-market, non-core players. As we make more and more games for the non-core market, we need testers who can think like a non-core gamer.

Bad pathfinding.

Pathfinding is the process of figuring out how to get a ground-based unit from here to there, avoiding obstacles on the way. Pathfinding can go wrong in a lot of ways, but the most frustrating is when a unit gets stuck behind something and can't figure out how to get around it. The original Age of Empires was notorious for its bad pathfinding until they released a patch for it. You'd tell a group of people to go somewhere, and they'd get stuck and wander haplessly around until you either gave them new orders or removed some trivial obstruction that a two-year-old could figure out how to get past. In addition to being frustrating, it destroys the player's suspension of disbelief and respect for the game.

Pathfinding is not a simple problem by any means - I used to program silicon layout and circuit routing tools for a living, so I know something about it. Game pathfinding is easier in some respects because soldiers don't create a short circuit if they cross another soldier's path on the battlefield. However, unlike routing chip traces, it can't be left to run overnight, either. When the player tells a soldier to go somewhere, that soldier needs to leave immediately, without visibly stopping to think about how he's going to get there.

Here are a few design rules of thumb about pathfinding:

It's not about what the troops can see, it's about what the player can see. Typically, the player is looking at an aerial perspective of a region, and can clearly see the path she wants her troops to take. Even if those troops don't "know" the terrain, and can't "see" the best route from the ground, they should use the player's degree of knowledge, not their own, to plan a route. Otherwise the player will be asking, "Why are you going that way?"

Foot soldiers should not be obstructed by their own side's equipment. In the real world, if a group of foot soldiers are trying to get past a row of friendly tanks, they can do it, even if the tanks are lined up axle to axle. They'll climb over, crawl under, or whatever. It may slow them down, but it won't stop them. That's one of the best features of the common infantryman - he may not have much armor or firepower, but he's more versatile than any other unit. Don't take that away from him by needlessly obstructing his pathfinding.

Groups of units should filter among obstacles similar in size to themselves, but should stay together when travelling around large obstacles. As a general rule, groups should stick together and follow roughly the same path, but not to the extent of all walking around the right-hand side of a tree. And how many times have you selected a group of soldiers, told them to go somewhere, and found that two out of the twenty of them are wandering off on some other weird route of their own? What's happening is that the two are treating the other 18 as an obstacle rather than a group that they're expected to remain part of. They've got a little too much independent thinking in their AI. You have to balance their freedom to improvise individual paths for themselves (filtering among trees or boulders) with their obligation to stick together (taking the same way around a hill or building).

Make it easy for the player to enter waypoints as part of her movement orders. This is your "escape clause" if your pathfinding has bugs. By entering waypoints, players can work around pathfinding problems. Obviously it's preferable to get it right the first time, but solving the problem with waypoints at least lets the player go on playing instead of giving up in frustration. And waypoints are generally useful anyway

Whole books are written about pathfinding, so I'll leave it there. Much of it is a question of testing and tuning. But do try to do it well; bad pathfinding will cause a player to dismiss your game as "stupid" more quickly than just about anything else.

Low-poly trees (and other models, too).

Oooh, you've got a 3D engine. We're all very impressed. The problem is, you've got too many objects to display with it, so you've decided to make them all with very few polygons. Everything in your game world will be strangely chunky, with odd edges, and they'll look nothing like their counterparts in the real world. Trees, for example, will look like peculiar umbrellas, with all their branches at the same height, and disturbing things will happen as the camera moves past their foliage.

Don't do it. It's ugly and tacky. Get your pixel artists to do nice sprites instead, and stick 'em on a single rectangle, if you don't have enough polys to go around. Yes, they will pixellate as you get closer to them unless you MIP-map them, but so will the textures in your walls; we're used to that. Remember how the creatures in Doom only had one sprite when they were lying dead on the floor? And when you went around to the other side of them they still were facing the same way, following you like the eyes in one of those creepy paintings? And remember how that was OK, and we didn't really mind? The same is true for trees - even more so, in fact. Unless it's significant to the gameplay somehow, it doesn't really matter if a tree's orientation is always the same way with respect to the player no matter where he is. It's still better to have a nice-looking tree sprite than some weird blocky green umbrella thing.

Too few audio clips for a given situation.

I hate hearing the same damned audio clip over and over whenever a particular situation recurs in a game. It doesn't matter if it's just a confirming beep - in that case, it should always be the same sound, so it sends the same cue to the player - but if it's a person speaking, it gets annoying very fast. I was the audio/video producer for Madden NFL Football for many years, so I've been guilty of this one myself on occasion. We had a limited amount of recording time with Mr. Madden each year, so we couldn't record everything we wanted. The audio script for Madden NFL Football was typically about 75 pages long, and I would have written twice that much if I could.

If you're going to have voice clips associated with particular situations ("I'm hit!" and so on), then record a lot of them. My own rule of thumb is that there should never be fewer than five audio clips for any situation, even the rarest; and for common events there should be at least two dozen or so. You don't always have to record completely different sentences; sometimes the same sentence delivered with a slightly different emphasis will do. In the game, have the software keep a list of them and choose one at random to play when the situation calls for it, then mark it off the list. The next time the situation arises, choose at random from the remaining ones, and so on. When you've run through them all, reset the list except for the most recently played clip. That way the players will never hear the same clip twice in a row.

Birds that carry swords.

Argh! Our party is under attack by evil doom-chickens from the foul fowlyard of Kafoozalum! We're in danger of being pecked to death a la Tippi Hedren. We hack. We slash. We cast spells of Oven Roasting+3. Some of us get hurt in a vague, numerical sort of way that doesn't actually seem to involve blood or pain. Eventually we kill the last of the chickens (no evil creature is ever smart enough to run away, even when it's hopelessly outnumbered; an admirable sense of duty for a bird). Searching the bodies we find that, as with all evil creatures, even blind cave-dwelling slimeworms, they're carrying money and human weapons and armor around with them. How fortuitous! Evil doom-chicken #3 (second from the left, but otherwise indistinguishable from doom-chickens #1, 2, and 4) had a Great Big Nasty Sword of Serious Hurtfulness+5. Funny, I didn't notice that sword anywhere on its feathery person while it was still alive. If it was so heavily armed, why didn't it use it in the fight? Come to think of it, where was it keeping all this gold, too? In its gizzard? Eeeeew!

You get the idea.

Conclusion

Well, that’s my catalog of complaints for another year or so. If you’ve been responsible for any of these mistakes, bad game designer! No Twinkie for you! And if you’ve got a few personal peeves and game design gaffes of your own, by all means send me some E-mail and tell me about them. It’s time to start making a new list.