Sponsored By

Another year, and another chance to deny fattening snacks to developers too lazy or busy to put thought into the problems that plague their games -- Adams' Designer's Notebook returns with its 8th annual look at common mistakes, and a new No Twinkie Database.

Ernest Adams, Blogger

September 4, 2007

13 Min Read

It's time once again for another edition of that annual favorite, Bad Game Designer, No Twinkie! Since last year I've collected up another batch of Twinkie Denial Conditions from my readers, which I present for your edification and entertainment. I've also finally fulfilled an old promise to set up a No Twinkie Database of all the TDCs, organized by category. Just click the link and it'll take you to my website.

And away we go! Some of these are biggies that I really should have mentioned years ago.

Mandatory Wildly Atypical Levels

This one bugs the heck out of me, and I'm apparently not the only one. Joel Johnson writes:

I'd like to point out the painfully irritating sections of games where they "change it up." Mini-games are fine by me, but when the game is an FPS except for two levels where you drive a car, race style, that's not a lot of fun. It's just padding that hides the fact that there isn't a lot of content in the main game. Other examples of this include the obligatory "stealth mission" not uncommon in FPSs (if you want to make a stealth game, make a damn stealth game), on-rails shooting-gallery sections of FPSs, the rhythm sections of games like Grand Theft Auto, etc. Optional mini-games are fun, and can be a refreshing change of pace, but optional is the key word here. Levels where a player must complete a game that uses a completely different skill set in order to continue back to a point that uses the original skill set can be irritating as hell.

Bullfrog was often guilty of this -- I remember some wildly atypical levels in Dungeon Keeper, Magic Carpet, and Populous: The Beginning. They padded out the game, but because they made just about everything you had learned useless, they were very annoying. Keep them optional.

ge3.jpg

Populous: The Beginning

Failure to Provide Clear Short-Term Goals

The first time my wife sat down to the play the original text adventure, Colossal Cave, she saw the opening words:

You are standing at the end of a road before a small brick building. Around you is a forest. A small stream flows out of the building and down a gully.

>

Then it just sat there, waiting. "What am I supposed to do?" she asked the guy who was showing her the game. "Anything you want!" he said proudly (this was 1979, and games with parsers were brand new). But she didn't know what she wanted to do. The game didn't give her any incentive to do anything in particular, and we've lived with the same Twinkie Denial Condition for nearly 30 years -- it still happens, believe it or not. Andrew Harrison wrote to say:

When I played Metal Arms: Glitch in the System (PS2), it sometimes happened that I would start a game from a checkpoint without a clear indication of what it was that I should be doing: no information in the pause menu, no one to whom I could talk, no way to revisit an explanatory cinematic segment, not even a blip on my radar. Often I simply wandered around until I found enemies and then progressed in their general direction, hoping that their defeat was my goal. If the actual goal was to destroy some piece of machinery or flip a switch, I could potentially wander for a very long time before trying the right thing. I think that designers should try to avoid those situations.

You're darn right they should; in fact, it's one of Noah Falstein's rules for game design: provide clear short-term goals. And if he starts up a saved game, give the player a recap, a journal, or something else he can look at to see what he was supposed to be doing.

Dominant Strategies

"Dominant strategy" is a term from mathematical game theory. It refers to a state of affairs in which one particular course of action (a strategy) always produces the best outcome regardless of circumstances. A dominant strategy doesn't necessarily guarantee victory, but it is always the best choice available. As a result, there's never any reason to use a different strategy. A game with a dominant strategy is flawed, because it offers no meaningful decisions for the player to make.

Dominant strategies show up in ordinary games for entertainment, too. Joel Johnson writes,

Most games nowadays, be they action, adventure, RTS, or whatever, give the player a wide variety of options or methods of attacking enemy units. One of the bigger problems that I've noticed is that it is not uncommon for most of these [special moves/spells/units/etc.] to be completely useless, because one method is so overwhelmingly useful. For example, look at Halo. Pistol-sniping was the name of the game, at least for me and for most of the people that I played with. There was little incentive for me to use other methods of attack because I could kill someone across the level quite rapidly and easily. I had a lot of fun pistol sniping people who went for a sniper rifle. There was a certain ironic pleasure in that. At any rate, Bungie did their homework and nerfed the pistol something fierce for Halo 2. I was chagrined at first, but the game was a lot more interesting to play.

It's a perfect example of the problem. Choosing the pistol is a dominant strategy, or very nearly. Sometimes dominant strategies get into games because there just wasn't enough playtesting; sometimes because the designer was so in love with a particular feature that he couldn't bring himself to weaken it, even though that would bring the game into proper balance. Bottom line: there must be benefits and disadvantages to every possible choice that make them preferable at some times and not at others.

screenshot09.jpg

Many Halo players learned to dominate the game using the pistol

Amnesia at the Game's Beginning

Moving on from game balancing to storytelling, Andrew Stuart writes about games that begin:

"You wake up in a strange place. You don't know who you are or how you got here. You have amnesia and your objective is to find out who you are and what you are doing here." It's hard to believe but it seems every second game has me waking up with amnesia. It's okay after a night out on the booze, but in every second computer game? Enough!

Years ago I identified the Problem of Amnesia in a lecture at the Game Developers' Conference. The problem arises because the player doesn't know anything about the game world when she starts the game. In a lot of adventure games, the first thing she has to do is go through all the drawers in what is supposedly her own apartment to see what's in them -- which is ridiculous. A character in a real story doesn't have to do this, because the character already belongs to the game world. So in the game industry, we make a lot of games in which the player's character has amnesia to justify the player's own ignorance.

That's a cheesy solution to the problem, though. In reality, the viewers of a film don't know the film's world either, so movies have carefully crafted introductions that bring the audience up to speed gently. Occasionally, when the situation is really unfamiliar, movies resort to voiceover narration, but that's not necessary most of the time. Consider the following exchange at the beginning of the first episode of The Sandbaggers, the best spy TV show ever made:

Secretary: Wellingham rang. He wants to see you.

Burnside [starchily]: Do you mean the Permanent Undersecretary of the Foreign Office?

Secretary [equally starchily]: I mean your father-in-law.

Burnside: Ex-father-in-law.

In four lines, without even meeting him, we've been introduced to Wellingham, his job, and his relationship to the show's main character, Burnside. We've also learned that Burnside is divorced, but still has professional business with his former farther-in-law. Finally, we've noticed that Burnside is a bit formal about people's titles (not uncommon in 1978 Britain) and that his secretary can stand up to him. That's a lot of information in 10 seconds of dialog, and it beats the heck out of listening to some long-winded mentor character explain things in a video game. We need to study those film and TV introductions and learn how to do them too. In the mean time, no more amnesiac player characters!

 

Incorrect Victory Checks

Interstate '76 was a driving game that included a lot of fancy weapons on the cars. One level contained a funny, but annoying, mistake. The game told you that you had to find your way out of a closed area surrounded by a concrete wall. The "correct" solution was to find a hidden ramp, drive up it, and fly over the wall -- which landed you in a pit, but that was essential for the next part of the story. However, some clever players realized that they could drop a land mine near the wall, then drive towards it at speed. The explosion would blast the car into the air while forward momentum would carry it over the wall. If the car was sturdy enough, they'd land damaged but alive. They fulfilled the stated victory condition, but the game didn't recognize it, so the level never ended. The game was only testing for use of the ramp, not whether the car was outside the wall.

When you tell a player to do something, then check to see if he's done it, you have to test the thing you asked him to do, not just what you wanted him to do. In modern games with richly-simulated environments (e.g. the Grand Theft Auto games), there's a good chance the player will find a way to meet your victory condition that you never expected -- and he should get credit for it.

i76.gif

Interstate '76

 

Continuing in the same theme, we come to...

Illogical Victory Checks

Avoiding incorrect victory checks does not mean that you should nitpick the precise details. If the player performed some action that by its nature included the victory condition, he should get credit for that too. Andy Lundell explains:

It's bad enough when the mission objectives are illogical, but when you start punishing the player for making logical decisions, you've gone to far. You usually see this in FPS games or sometimes in the single-player parts of RTS games.

My favorite example is from Red Faction. There was a mission where you were told you had to destroy a particular computer on the space station. Once you got there you were told that you had to blow up the entire space station and run for the escape pods. So I, quite logically I thought, assumed that I could just blow up the space station and not worry about targeting the computer specifically. I blew up the space station, jumped in my escape pod and ... and ... the game glitched. We were supposed to blow up the computer then blow up the station. (They had no explanation for this duplication of effort.) Apparently the game couldn't handle the fact that the level ended without the computer being specifically blown up, so I just got dumped back to the main menu screen. All because I tried to do things intelligently instead of the stupid way the level designers wanted me to!

Here's a clue, level designers: if one victory condition (blowing up the station) naturally includes another one (blowing up the computer), there's no need to check the second one at all -- and doing so could get your Twinkies taken away.

Seizing Control of the Camera at Bad Times

Ever since 3D came along, we've had to work a whole lot harder to depict our worlds, especially in action games. With side-scrollers, top-scrollers, and isometric views, life was pretty simple. The 3D fixed third- or first-person perspectives aren't too hard either, but both have their limitations (what happens in third person when the avatar has his back to a wall?). Nowadays we put a lot of work into creating intelligent cameras, a la Ico, and we don't always get it right. Loren Schmidt writes,

You're playing a third person platformer. You're running down a hallway towards a huge, spike-filled pit you can barely clear in a single jump... and then the camera flips around 180 degrees, messing up your timing and causing your helpless character to plunge to its virtual death.

This is even worse when combined with a transition from controllable to fixed camera modes, as seen in the last two Prince of Persia games. Most of the game is played with a player-controlled camera, but occasionally your point of view suddenly leaps to a (sometimes poorly placed) stationary camera. This can be particularly lethal during combat sequences and potentially deadly jumps.

I understand the goal here -- right before an action sequence we often need to lock down the camera so as to guarantee the player a clear view of what's going on, and to fix the relationship between joystick and screen. But suddenly changing the point of view while the player is jumping, or fighting for his life, guarantees him trouble. Don't do it. It's better to leave the camera under the player's control, even if that's not ideal, than it is to disorient the player by changing his perspective without warning.

pop.png

Prince of Persia: The Two Thrones

That's it for this year. Amazingly enough, I didn't get any big complaints about configuration menus (a constant source of irritation). One person did write to object about lists of saved games that were un-sorted, or sorted inconveniently so you had to hunt for your most recent save, and while I agree that's a nuisance I figure it's not bad enough to warrant denial of Twinkies.

As always, I want to hear your gripes! Stop by the No Twinkie Database to see if I've already covered it, and if I haven't, send me mail at [email protected] and let me know about it!

Read more about:

Features

About the Author(s)

Ernest Adams

Blogger

Ernest Adams is a freelance game designer, writer, and lecturer, and a member of the International Hobo game design consortium. He is the author of two books, Andrew Rollings and Ernest Adams on Game Design, with Andrew Rollings; and Break Into the Game Industry: How to Get a Job Making Video Games. Ernest was most recently employed as a lead designer at Bullfrog Productions, and for several years before that he was the audio/video producer on the Madden NFL Football product line. He has developed on-line, computer, and console games for everything from the IBM 360 mainframe to the Playstation 2. He was a founder of the International Game Developers' Association, and a frequent lecturer at the Game Developers' Conference. Ernest would be happy to receive E-mail about his columns at [email protected], and you may visit his professional web site at http://www.designersnotebook.com. The views in this column are strictly his own.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like