Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
The Designer's Notebook: Bad Game Designer, No Twinkie! XI
View All     RSS
November 27, 2021
arrowPress Releases
November 27, 2021
Games Press
View All     RSS
If you enjoy reading this site, you might also want to check out these UBM Tech sites:


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

December 2, 2010 Article Start Page 1 of 3 Next

It's the end of the year, and that means it's time for another roundup of game design errors sent in by loyal, yet outraged, readers. This year I have eight, which isn't very many, but I look at them in a little more detail than I did in earlier columns.

Offering Irrelevant Help

When a game offers help or advice, players normally trust it because they assume that the game knows better than they do how to win. Consequently, few things are more confusing than help that isn't helpful -- help that comes at the wrong time, or is irrelevant in the current circumstances.

Ben Ashley writes, "Tips need to be pertinent! Battlefield 2: Special Forces suffers from this. The grappling hook is an item of equipment that is only carried by the assault class.

"So, when playing another class, why on earth does the game come and helpfully tell me I can use my hook to get on the ledge above me? I don't have a hook. This causes quite a bit of confusion for the new player."

AI-generated advice is tricky to tune well, and advisor characters in complex economic simulations often get things wrong. But when a game advises you to do something that is currently impossible to do, that's more than a tuning problem, it's a Twinkie Denial Condition. Bad game designer! No Twinkie!

Time Limits in Pure Puzzle Games

Many games include both rewards and punishments. In Space Invaders, you get points for shooting aliens, and you lose lives when they shoot you. Simple. The trick is balancing them appropriately. As a general principle, you should always reward more than you punish.

When it comes to time limits, it's good to reward speed, but not good to punish slowness. The jockey who comes in first wins the prize money, but the one who comes in last doesn't have to pay a penalty. And nowhere is this principle more appropriate than in puzzle games. People have differing amounts of brain power, and puzzle-solving requires time and patience. Someone calling himself "Aguydude" wrote in to say,

"When I call a game a 'pure' puzzle game, I mean that the game does not require any sort of reflexes or timing. I'll occasionally play a pure puzzle game with a time limit, which is bad. Equally bad are puzzle games that use lives or something similar to limit the number of attempts the player can make at solving the puzzle. Forcing a player to redo all of the previous puzzles because they made errors in the current one only serves to discourage them from playing, if they want to avoid meaningless repetition."

A puzzle game with lives? A puzzle game that punishes you by making you repeat solved puzzles? That is serious wrongthink. If you want to reward the player for solving a puzzle quickly, be my guest. But don't punish him for taking his time. As we say in the world of game accessibility, "there's no such thing as too slow."

Bad, Boring Boss Battles

In Bad Game Designer VII, I condemned extreme rule changes when fighting boss characters. The opposite is just as bad: bosses that are nothing but more powerful versions of enemies the player has already seen. My friend Gabrielle Kent recently started a Facebook discussion about boss battles, and several people chimed in with their own pet gripes.

Gabby said that to her, the things that make a boss battle boring are, "stupid amounts of repetition, ridiculously high/replenishing energy [i.e. boss health] combined with unimaginative gameplay (yawn), and powered up versions of previous bosses."

She also hates boss rushes -- having to defeat the same batch of bosses that you've already defeated once before. I agree. This shows a lack of imagination (or time) on the part of the game designer.

Sarah Ford added, "One of the worst I've sat through is at the end of Final Fantasy X. Spend the whole game chasing this epic whale thing and the last boss is a bin lid with legs. Total anticlimax. What's worse, you can't even die. What's the point in that? It's not even a short symbolic battle, it stretches out forever and the thing keeps healing itself. Rubbish."

Harryizman Bin Harun also wrote to me from Malaysia to complain about endlessly self-healing bosses. I think it's fair to say that gamers hate them on a global scale.

Someone named Jessica mentioned bosses that are utterly invulnerable to all but exactly the right attack, as in the Lord of the Rings action games: "Sure, a seven foot tall Uruk-Hai is going to be tough, but after fighting eighty of his minions, I would think that whacking him in the head with a sword would do something similar to what it did to them, even if I wasn't whacking him in the head at the time when he was most vulnerable.

"I would have been satisfied if the special moments did more damage, and the conventional attacks did less, but the way it was left me totally unsatisfied, and uninspired to continue and finish the game."

Jessica also pointed out that in Call of Cthulhu: Dark Corners of the Earth, at one point all it takes to defeat a certain boss is to press a button -- but you must wait until the boss attacks you, and not press it early. This is a severe conceptual non sequitur. The button and the boss attack are not related, so to avoid getting whacked, it makes sense to push it as soon as you can. She was doing the right thing in a sensible way, and the game punished her for it.

So, a few rules for boss battles:

  • Bosses must be different from other enemies.
  • Bosses must not be so different that nothing the player has already learned is of any use.
  • Bosses should not be invincible to all but exactly one thing (that makes it a puzzle, not a battle).
  • Fighting bosses should include variety, not endless repetition.
  • Bosses should not heal themselves (or not very much, anyway).
  • The key to a boss's vulnerability should not be a conceptual non sequitur; it has to make sense.
  • Dead bosses should stay dead. (See Bad Game Designer V.) If they come back, they should be interestingly different each time (think of Dr. Robotnik in Sonic the Hedgehog).

I'm sure you can probably think of some more.

Good boss battles cited in Gabby's discussion thread included GlaDOS from Portal, the Colosssus in God of War 2, various bosses in Yoshi's Island, Scarecrow in Arkham Asylum, Malocchio in Interstate '76, and Shadow of the Colossus, which was a game consisting entirely of bosses! All worthy of study.

Article Start Page 1 of 3 Next

Related Jobs

Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Senior Systems Designer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Senior Combat Designer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Senior Games Writer
4A Games
4A Games — Sliema, Malta

Senior Animator (Malta/Kyiv)

Loading Comments

loader image