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

[Veteran designer Ernest Adams reviews nine more game design mistakes in the tenth anniversary of his long-running 'Bad Game Designer, No Twinkie!' series, ranging from psychic AI as exemplified in Oblivion to magic perfect cover in shooting games to the ongoing reliance on grinding in MMOs. For those looking to read previous instalments, here are links to #1, #2, #3, #4, #5, #6, #7, #8, and #9 in the series.]

Another year, another collection of game design errors. I've got a whole mail folder full, and I'm always eager to hear about more. I'm so busy with my regular work that I don't get the chance to play the variety of games that I would like to, so every year I count on submissions from you loyal readers to find the broken ones for me.

We'll start with two from role-playing games sent in by Kris Kelly. (Why are so many Twinkie Denial Conditions in RPGs? Complex game mechanics, probably.)

Psychic AI

Kris's own words are perfectly clear: "In The Elder Scrolls IV: Oblivion, the guards are so good at their job, they instantly know when you've committed a crime (i.e. killed someone in a building, stolen something), even when they were never in the area. They'll sometimes run all the way across town to try and arrest you.

"Another Oblivion issue is the stolen items thing: merchants will happily accept items you've 'liberated' from the corpses of your enemies, but if you take a candlestick in, you can't even offer it to them, never mind get refused."

The underlying design problems are actually different here. The psychic guards have access to global information when they really should have access only to information about their local region. The other is that the merchants have a peculiar sense of morality: they condone mugging but not burglary. What's that about?

Teleporting NPCs

This one is particularly bad because it violates the player's perfectly reasonable expectation that an enemy can't be in two places at once, and ruins a clever ploy.

Here's Kris again: "I can only think of one occurrence of this, but I'm sure it happens in other games. In Neverwinter Nights 2, there's a large battle involving fire giants and a red dragon. You are expected to fight on the side of one or the other but I, being a sneaky type, decided to start the battle on the side of the red dragon and then sneak out while he was fighting the giants and raid his lair.

"I wander over to his abode, loot sack at the ready, only to be confronted by a fully-healed un-harrassed-by-giants red dragon who is hell bent on fighting me, I beat him up a bit (and he reciprocates), then decide to go back to the giant fight (because it was easier) and there he is again, fighting the giants and fully healed once more."

Neverwinter Nights 2

Look: a dragon is either guarding its lair or it's fighting giants somewhere else. Not both. Clearly the designers implemented two dragons and led the player to believe they were both the same. Not fair and not fun.

Level Designs that Over- (or Under-) Use a Game Feature

Pascal Luban, a French freelance game designer I've known for many years, writes:

"A great game feature does not make a game, it is the way it is implemented that does. The best game feature is not enough to support a game by itself, because the best feature eventually becomes boring when you have done it too many times in the same circumstances. I see that on a regular basis in games.

"The level design does not create unique situations tailored to the use of the unique game mechanics of the game. That's why level design is so important: because it allows designer to create diversity and challenge around a given mechanism."

Pascal was reluctant to name names, but he does mention as an example a famous shooter in which the player has super-jump or super-strength abilities, but none of the levels make good use of it.

I've often said that game designers determine what sorts of "LEGO blocks" the game will be made from, but level designers actually construct the game out of those blocks. If the level design doesn't make good use of a feature, then the feature is wasted. If it is used too many times in exactly the same way, then it becomes tiresome.

An example of good design with a limited feature set is Sonic the Hedgehog. Sonic only had two moves, jumping and super-spinning, yet the level designs offered enough variety to keep the game interesting.

Incomplete or Ambiguous Design Documents

I normally think of Twinkie Denial Conditions from the viewpoint of the player, but game design errors can make life hard for the rest of the development team too. Anything that a designer doesn't specify, the programmers will have to figure out for themselves, which wastes time. Worse, if they start pulling in divergent directions, the results will be incoherent or even disastrous. David Mullich writes of a project that he had to rescue:

"The original game designer typically described only the main flow for any system or UI. He didn't describe the alternate flow or extreme circumstances, leaving it to the programmer to identify what those situations were and how to handle them.

"I wound up rewriting much of the game design document so that it included pseudo-code (thanks to my programming roots) that specified the required logic a little more clearly. But even beyond the logic, the designer left a lot of other details -- such as the exact text to use for alert and confirmation pop-ups -- to the programmers.

"Plus, when the programmers stayed late, the designer did not hang around to answer questions or ensure that his design was being implemented correctly."

The fact that Mullich had to take the project over is evidence enough that things weren't working out. I know this is going to be unpopular with some designers, but every game design team must have somebody with programming experience on it.

No matter how much we talk about aesthetics and games as art (and nobody loves such talk more than I), video games are software, and to design software requires the ability to communicate clearly about algorithmic systems.

And there's no excuse at all for leaving out the text that needs to appear in dialog boxes. That's just laziness. It may be boring, it's part of the job. Bad game designer! No Twinkie!

Designer Ignorance of Technical Limits

While we're on the subject of designers who annoy their dev teams, let's include those who don't understand what their target hardware can actually do.

Gregg Tavares wrote: "I know lots of designers who might, for example, want 25 enemies on the screen at once when the engine only supports only 10 at most. Or they want the engine to be able to see forever. Then they force the programmers to spend months on technical engine design instead of fun gameplay.

"I think if you look at most of the best games, the designers figured out a way to be creative within severe technical limits. Metroid Prime was a perfect example of designing within technical limits. So is the Zelda series of games."

Metroid Prime 3: Corruption

This was a serious problem when Hollywood tried to take over the industry in the early '90s -- a lot of so-called "game designers" arrived from the film world knowing nothing about how computers actually work, and they drove their development teams mad with unrealistic demands. Their ignorance is one (of several) reasons why the takeover failed. But a lot of money went down the tubes in the process.

Know your hardware. It's compulsory. If you're not a technical person, then you'll have to ask your programmers and trust what they tell you, because arguing with them isn't going to change anything.

Mocking the Player

I already listed this one in my Bill of Player's Rights, but it bears repeating as a Twinkie Denial Condition. I don't play online games with strangers, because I dislike their rudeness and poor sportsmanship. I also don't like it when a single-player game mocks me, and I'm not alone in this. Owen Clark wrote in to say, "Don't mock me! If I fail a specific part of the game or whatever there's no need to rub salt in the wound!"

Now I realize there's fun in smack-talk. As a long-time member of the Madden team, I know that the right way to play Madden is with a lot of friends around all talking trash. The key word, though, is friends. Friends know when enough is enough.

When a game mocks the player, it's not jovial banter, it's rude, like insulting a stranger. It's really the designer mocking the player, and that's not fair because the designer holds all the cards and the player can't respond. Don't mock the player for his failures. It's juvenile and self-indulgent.

Essential but Unobtainable Items

The same Owen Clark also wrote, "Don't make must-have items avoidable! If I need an item that I'm supposed to pick up in the early levels of a game which is then vital later on, then it should mandatory that I get this item. No ifs, no buts, no making the item optional but I have a huge disadvantage. There is almost nothing more annoying than having to restart a game from scratch after three to four levels because you missed something in one of the early levels... just give me the damn thing."

If you fail to give the player something that she absolutely must have to win the game, then the game is unwinnable and that's a bad design for sure. If the player has the option of leaving something critical behind when she passes through a one-way door, it also makes the game unwinnable - this is why many adventure games let you pick things up but don't let you put them down again.

The (very) old game Monty on the Run required the player to choose some items to take with her before the game started. If she chose the wrong ones, the game was unwinnable at a later point, a truly severe design flaw.

There's a fine line here, because Clark wants to be given things that are not technically essential but extremely valuable; he cites the sniper scope in Crysis as an example. The player is at a major disadvantage without it. I don't know if I would really call hiding the sniper scope a Twinkie Denial Condition; I think it's a problem in managing the game's difficulty. If the game is nearly impossible without it and reasonably easy with it, then the sniper scope itself is more valuable than it should be (or the game is too hard without it).

Crysis

Grinding

Ben Matson wrote to me about this all the way back in 2004, and maybe it's completely obvious by this time, but it needs to be in the No Twinkie Database, so here it is. He said, "Sinking hours and hours of your life killing gnoll smallfists just so you can spend twice as long on gnoll bigfists has always been a huge annoyance to me. I love MMORPGs, but eventually it seems to all reduce to filling experience meters. There has to be something better. Examples are EverQuest, Dark Age of Camelot, etc..."

It isn't just MMORPGs, but single-player offline RPGs as well. The early RPGs had randomly-generated levels and there wasn't much to do in them but grind. They get excused because they had to fit on a few floppy disks; but even then, the better games managed to avoid it.

A game can get away with being slow-moving if it provides variety in the gameplay (e.g. an adventure game); and it can get away with only offering one kind of gameplay if it's exciting (e.g. Tetris). But if your game is both slow and dull, you've screwed up. And that's grinding in a nutshell. Boring, outdated, unnecessary.

If players really want to grind, they can play Progress Quest.

Magic Perfect Cover in Shooter Games

We'll go back to Pascal Luban for one last item. He writes, "Sometimes, you can see a section of an enemy's body sticking out behind or above a cover and your bullet cannot hit it. That's because the designers don't want to you to be able to hit an enemy while he's in cover. That's OK when a few pixels stick out but when it is half of the skull, it gets very frustrating!"

Yes it does. Any soldier can tell you that it's not a good idea to stick your head out of the trench even if the rest of your body is still in it. Either the designers have created some kind of magic perfect cover that works no matter how much of the target's body is sticking out, or there's something wrong with the relationship between the physics and the graphics engines.

If you can see something within range, you ought to be able to shoot it. (In the first Gulf War, an American tank destroyed an Iraqi tank that thought it was under cover by firing through a sand dune. There's no such thing as perfect cover.)

Conclusion

Reading back over this, I see these Twinkie Denial Conditions aren't all as funny as some have been in previous columns. Still, I think there are some valuable suggestions here - mistakes to watch out for, errors to avoid. Keep sending them in to [email protected]! Be sure to check the No Twinkie Database first, though; after ten columns I have already covered many of the most egregious ones.