The Designer's Notebook: Bad Game Designer, No Twinkie! IV

I'm not going to write this month's column. You are. Or rather, you already did. After last year's "Bad Game Designer" column, I asked readers to submit their own peeves about games, and hooo-eeee, did I get letters! So herewith, a compendium of design flaws and irritations sent in by various readers. I'll try to give appropriate credit where I can, but some E-mailers don't use their real names, and in that case there's nothing I can do.

Bad Guys With Vanishing Weapons

Many people wrote to complain about this one. It's the corollary to the "birds that carry swords" complaint I mentioned in the previous "No Twinkie" column. You spend forever trying to take down some major bad guy, and when you finally do, his weapon has disappeared. Evan McClanahan said, "If I sneak up behind someone and knife them in the back with one of my characters, as he's keeping my other characters pinned down with The Inexhaustible Machine Gun of Perforation (+2), I expect to get that gun, not an empty corpse with three Futuristic Monetary Units and a stick of gum."

Now, in online games this is understandable in some respects. Monsters respawn all the time, and if they dropped a big weapon every time they died, the world would soon be awash in such weapons. But in single-player games, you have the freedom to balance the game properly, and can compensate accordingly for these issues. If it unbalances the game too much, you can limit the player's ability to use the weapon -- OK, you killed the troll and got his club, but actually you can't wield a 30-kilo tree trunk all that conveniently. Or maybe you get the big bad guy's amazing gun, but the only ammo available for it is what he's got on him at the time. If you insist on lugging that gun all over the place hoping to find more ammo, well, that's your choice.

Another corollary to this, sent in by Chris Oates, is the demon woman in a leather thong bikini who drops a full suit of plate armor when she dies. What, she had it with her but didn't feel like putting it on for battle? Did it need to go to the cleaners or something?

I have played games that got this right. You kill a little kobold, you get a little knife. You kill fifty little kobolds, you get fifty little knives, none of which is really worth your while to fool with, so you just leave them behind-which is what you would do in real life.

No Variable Skill Levels

This one's a bit tricky because I know what it costs to implement. Balancing a game for multiple skill levels takes more time than balancing it for just one, and time is money in game development. Still, not all gamers have the same degree of skill, and not all of them want equally hard challenges. (Making games that are nightmarishly hard just because you can is a sign of designer self-indulgence, as I discussed in an earlier column, "What Kind of Designer Are You?") By giving players different skill levels, you actually increase the longevity of your game, because players can crank it up and play through again. More importantly, you increase the size of the market. If a game is too easy, it'll get a bad reputation among the hardcore gamers; if it's too hard, it'll get a bad reputation among the casual players. If you offer variable skill levels, you can appeal to both groups.

Overuse of Darkness

Trent Lucier wrote in to complain about games that you have to play with the blinds drawn and the monitor brightness cranked up in order to see anything. OK, for the first five minutes it's all creepy and atmospheric, and after that it's just annoying. And how come all the bad guys can see in the dark a whole lot better than I can? I agree completely on this -- I don't object to "dim," but I don't get much enjoyment out of "dark." Peering around like a mole and bumping into things all the time isn't my idea of being a cool, stealthy thief/assassin/ninja. The whole point about stealthy assassins is that they can see well in the dark.

Charlie Byers also pointed out that this is a problem with a lot of Mac ports of Windows games: Macintosh monitors have different gamma values, and he says the gamma correction feature in the Unreal engine doesn't seem to work properly on Macs. Port programmers take note!

Sloppy Shell Menus

Various people complained about crummy user interfaces in the game's "shell" -- the set-up screens that you have to go through before you get into the main gameplay mode. These are never very interesting to design; they're just configuration screens, save and load slots, and so on. As a result, they tend to suffer from one of two problems: either they're done hurriedly, with poor layout and awkward organization, or they're much fancier than necessary. In an effort to disguise the fact that they are computer-oriented bookkeeping functions, and make them fit in better with the theme of the game, all the menus are done in rotating letters of fire, with sparkle effects on the currently highlighted item.

The best way to make the game's shell work for the player is not to gussy it up with a lot of meaningless effects, but to make it well-designed and easy to use so that he can get into the game as quickly as possible. Create a font that fits with the theme of your game by all means, but make sure it's easily readable, too. Try not to have menus any more than two layers deep. Be sure you have reasonable defaults for everything so the player can jump right in, without having to make any changes the first time he plays. (Given the variability of PC hardware, I know this can be tricky.) The first page of the manual of the old Borland Turbo Pascal compilers -- even before the title page -- was called, "How to Get Started Immediately," because they knew everybody was going to want to dive in headfirst. That's even more true of players.

Never forget: while the shell is the least interesting part of the game, it's also the first thing the player is going to see, before he gets into the real experience. As they say in the job-hunting manuals, you only get one chance to make a good first impression.

Time-Wasting Random Encounters

So you've cleared the entire town of Squelching-in-the-Marsh of the nasty rats that were making life miserable there, gained a few experience points, and now you're off to greater deeds of derring-do elsewhere. But of course, you have to return to Squelching every now and then to sell your loot and replenish your stock of Crossbow Bolts of Extra Pointiness +3. Problem is, every time you come back, you get attacked by rats again in random encounters. By this point you've got the strength to take on ferrets or even juvenile badgers, so it's a complete waste of time. Rather than stand around fighting rats for the measly few experience points they get you, you actually find yourself running away from them just to avoid the problem!

A variant on this nuisance is that you get back to Squelching only to discover that it has mysteriously repopulated with a whole lot more rats, only now they're five times as mean, and you have to do it all again. They look and act exactly like the last lot of rats, so there's no new gameplay, just another meaningless challenge.

This is clearly a Twinkie Denial Condition. A moment's thought will give the correct approach. 1) Any region that you have denuded of a given species of creature should remain denuded of them for a while (that's basic ecology as well as good game design). 2) Random encounters with creatures too small to represent much of a threat should result in those creatures fleeing in terror (that's basic animal behavior). That way you don't waste the player's time with pointless combat.

Not Being Able to Save After Fine-Tuning Things

Regular readers of this column will already know where I stand on the "save game" debate: I think players should be able to do it when they want to, and if they reload all the time to get through a tough patch, that's their privilege. However, I'm prepared to acknowledge that there are other points of view on this.

But it's really annoying, as Brendan Sechter pointed out, when the game requires you to fine-tune your units/weapons/whatever at the beginning of a level in order to face its challenges, then gives you no way of saving that work. Tuning the disposition of your forces can be a fun part of gameplay, but not when you have to do it repeatedly every time you restart a level -- after a while it's just boring bookkeeping.

Bad (or Nonexistent) Camera Controls

Dave Wilson brought it to my attention that there are some third-person 3D games that give the player no control over the camera at all. Bad game designer! That's what 3D environments are for: it costs you nothing, zip, nada, to provide freedom of perspective. Look: the ordinary human field of view is about 120 degrees wide. The width of the field of view varies considerably in games, and will get larger as HDTV becomes commonplace, but it's nowhere near 120 degrees in any case. In order to compensate for the fact that the player is effectively trying to play while wearing a box over her head, she needs decent camera controls. It can be done well. Look at Spyro the Dragon or Toy Story 2 for the original Playstation, and you'll see excellent examples of smooth, intuitive, player-controlled cameras.

Creatures That Can Resurrect The Corpses of the Fallen

I've seen this in a couple of places, and it feels like a fun and natural addition to a fantasy game's gameplay. The Dark Necromancer has the power to resurrect the bodies of his fallen enemies and make them fight on his side as zombies or some such. Great touch… or so it seems. Unfortunately, if it's not properly handled, it unbalances a game something fierce, because it creates uncontrolled positive feedback: the more units you lose, the more the enemy gains. As I've said elsewhere, imagine what would happen to chess if you got to keep the pieces you captured to use as your own: the game would be a whole lot shorter. Any game mechanism that enables one side to take over the other side's units is going to require great care in balancing.

Dungeon Keeper actually had no less than four mechanisms for turning enemy creatures into "friendlies," and they were all balanced in different ways:

In short, Dungeon Keeper is an example of a game that managed to get this right, and one to learn from.

The other problem with resurrecting the corpses of the fallen is that often the resurrecting unit is something very strong: a mighty warlock or something similar. As a result, any group with him in it is well-nigh invincible. If you're going to give a particular unit the power to perform such resurrections, consider making him weak and vulnerable by way of compensation.

Conclusion

I've still got lots more Twinkie Denial Conditions that I didn't have room to use this time around… I'm thinking of setting up a database! But I'm always interested to learn about new ones. Drop me a line at [email protected] and tell me about the game design flaws that really hack you off. (You might check the previous columns first to see if I've already mentioned them).