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

I took a break from The Designer's Notebook during 2014; I haven't published anything since last year's Bad Game Designer, No Twinkie! XIV column. There were a lot of distractions this year, particularly "GamerGate," which turned out to be the most irritating waste of our time since Jack Thompson's efforts to censor video games. However, I couldn't possibly miss the annual No Twinkie column! I brought the No Twinkie Database up to date, several people have suggested new Twinkie Denial Conditions during the year, and I've also trawled through old correspondence for a few more. Herewith, ten egregious game design errors:

Text that Vanishes While You’re Reading

If a game gives you something to read while the game is loading, it needs to give you enough time to actually read it. Quentin Thomas wrote:

I'm the kind of gamer who appreciates a good story in games. I heard through the grapevine that Dark Souls has a pretty good lore. So the guy's fighting this huge gargoyle and I know he's going to die but I'm rooting for him... to no avail. He dies and the game goes to a loading screen, bringing him to the last checkpoint. While he's on this loading screen, there's a item in the upper left corner with about 7-8 sentences.

I go "Oh goody, time for some of that Dark Souls lore I heard so much about." 

So I start reading the first sentence and it just abruptly cuts back to the gameplay without warning. 

You couldn't let me hit the X button myself when I was ready to go back to gameplay? 7-8 sentences and you expect me to read them all within 5 seconds? 

BAD GAME DESIGNER! NO TWINKIE!

I asked Quentin to do a little further investigation, and he discovered that this doesn’t happen on consoles, only on high-end PCs where the loading is very fast. This is essentially a corollary to one of the oldest Twinkie Denial Conditions, Games That Run Too Fast. The designers assumed, without checking, that the machine would be slow enough to let the player read the whole thing. If it’s not, he’s out of luck. But in any case, this is a usability error. For all you know, the player has low vision or dyslexia and has to read slowly. Let him decide when he’s ready to go on, not your CPU’s clock speed.

Disrupting the Player’s Inputs

The player’s input devices lie on the boundary of the magic circle; they are where real-world player movements get turned into game-world actions. It’s OK for these controls to be difficult under the right circumstances. I well remember discovering, all the way back in Chuck Yeager’s Advanced Flight Trainer, that the storied Sopwith Camel was a beast to control -- as indeed it was in real life, until you learned how to handle it. But arbitrarily disrupting the player’s controls is not cool. James Youngman writes with an example:

The game Earthbound contains enemies who can cause a mushroom to grow on the player character's head. During battle, this does nothing, but once the player is back in the field, their directional input will periodically rotate itself 90 degrees, circling the D-pad until the player can remove the status. The spells and items available to the player cannot achieve this; the player must find a speak to a particular NPC at the town's hospital, a task complicated by the lack of hinting and by the regularly changing movement controls.

Changing the player's controls without their permission is disruptive in and of itself; forcing them to discover and navigate to rare locations to stop the disruption exacerbates the issue, forcing the player to chose between progressing or making the long walk back to the last place they can get healed, just to face the same dungeon, with the same status-effect casting enemy, all over again.

Disrupting the player’s inputs destroys immersion and creates a cheap, frustrating challenge that is unrelated to the game’s actual point. Don’t do it.

Character Classes That Can’t Finish the Game

Here’s one that’s completely self-explanatory from Petra Rudolf:

Back in the old times, I wanted to play Neverwinter Nights with the Underdark add-on with an unusual character, a bard/assassin. I knew already that it was easy to beat the game with any kind of mage or fighter, harder with a rogue or priest kind of class, and even worse with the standard D&D support classes like druid and bard, who cannot stand on their own legs without a fighter to slay things for them. Thanks to followers, I made it through about half of the add-on, and then was stuck without a possibility to level up (no other quests left) or to change my tactics.

Of course this could be seen as a part of bad balancing, yet it has an obvious reason: support characters can't fight alone. Bad game designer, leave them out of the game or change the whole class.

Now, you could argue that if a player chooses to fight tanks with a jeep, she deserves what she gets; but RPGs are supposed to be heroic fantasy, and that means they’re supposed to be winnable with whatever kind of character the player starts with. If it’s completely impossible to play through a single-player game with a given character class as the protagonist, that class should not be available to be a protagonist.

Fun-Destroying Verisimilitude

Longtime readers of this column will know that I’m generally a fan of verisimilitude, or at least a level of accuracy sufficient to sustain a fantasy. Working for six years on Madden NFL, it was imperative, because our players were comparing what happened in our game to what happens on the field. But it’s possible to overdo it, especially if the effect is to harm the fun. Mikhail Merkuryev pointed out that although real-world kart racers have no mirrors or reverse gear, they should have them in video games. In the real world, a track marshal can push a kart backwards by hand, and the driver can turn his head to look behind him. But in video games there are no track marshals, and if you turn your head, you’re just going to see your living room. This is a case where it’s appropriate to add necessary features that the real vehicles don’t have.

Don’t be a slave to reproducing the real world to the point that you harm the fun. 

“Filler” Quick Time Events

There’s a lot of debate about Quick Time Events generally -- does mashing a single button just to advance a scene really constitute interactivity? It’s certainly not making an interesting choice. I’m not ready to declare all Quick Time Events to be Twinkie Denial Conditions, because I think they can be made to fit a situation and storyline appropriately, but certainly some of them are pointless. Robert Doughty writes,

I think Quick Time Events are used a little too liberally to fill in any part of a game that the player isn’t in direct control of, such as during cutscenes and cinematics. Biggest examples of this are in Resident Evil 5 and 6. The problem with this use is that it feels very tacked on, and more importantly it detracts from the action/events of the cutscene, prying the player from something that was storyboarded out and designed to look fantastic. I guess this kind of applies to any use of a mechanic that is just tacked on to cover a small (possibly inconsequential) part of a game, just so you have something during that section, violating that key thing of giving the player a breather.

Certainly if you have a fantastic movie or some other kind of narrative content, there’s no point in screwing it up with unnecessary Quick Time Events just to create some meaningless interactivity. Games are not supposed to be movies, but cinematics are a legitimate feature at times, and there’s no point in ruining a good one. Just let the player enjoy it.

Non-Portable Experiences for Portable Games

Here’s another one about input devices from Garrick Williams:

I think some handheld game designers forget that their game is meant for portable devices. 

Legend of Zelda: Phantom Hourglass has a part where you're unable to continue unless you scream into the Nintendo DS's microphone at the top of your lungs. Now, portable gaming systems are meant to allow a player to play games while on the go, at the doctor's office, on the bus, or in a restaurant waiting for food. Yet the game designers expect me to randomly scream my lungs out in public. It may be amusing to the designer, but not to the player who has to decide between publicly humiliating themselves or quit playing the game until they get home.

Kid Icarus: Uprising intentionally had controls that made it impossible/uncomfortable to play the game and hold the 3DS at the same time, forcing you to lay the game system on a table and/or use a peripheral that doesn't fit well in your pocket.

The scream-at-the-microphone gimmick is annoying even in the privacy of your own home; it becomes downright anti-social when it’s required in public -- which is where a lot of portable games are played. And a portable game that can’t be played while you’re carrying the device? That’s just nutty.

Making the Player Earn (or Pay For) A Decent User Interface

Our new approaches to monetization have led to all sorts of abusive practices, but this one was new to me. Jon Gaull writes,

I hate when a game has crappy UI for letting me do something common and they make me work for 3 months to hit level 20 when I can unlock that item that gives me a better UI for the task.

My example comes from Backyard Monsters [a tower defense game]. Working on her base and tweaking the layout is something a player does every time she visits the game. Most players visit the game 3-5 times a day!

In Backyard Monsters they make you click a building, then click the move button, drag it to the position you want to place it, and then click again to drop it. If something is in the way you need to go through that same process with the impeding item first, then place the item you wanted to place to begin with. It's incredibly annoying when you could have over a hundred tiny little defensive walls surrounding your base, which is very tightly packed full of all your important defensive structures. Rearranging a base can literally take hours.

Fortunately, the developer has a solution to this problem. Unfortunately it's an expensive building you don't unlock until you've been playing the game for a month. Then, once you've unlocked, collected the resources, and finally placed the building you have to go through the silly social games time delay before you can even use it!

[Name deleted] believes we should allow only players willing to pay to have a way to circumnavigate our crappy UI!

I’ve seen games where you learn to do something rather slowly and inefficiently at first, and then get a better way to do it later on – but this is usually just in the tutorial, to show you how things work. A decent UI is not a reward or an achievement, it’s a right, and it’s absolutely not something the player should have to pay extra for!

Speaking of the silly social games time delay...

Free-to-Wait

Look no farther than Dungeon Keeper for mobile phones, also known colloquially as Dungeon Sleeper. No more need be said about this dire game design failure. Not necessarily the worst case, but certainly the most infamous.

NPCs Who Won’t Repeat Instructions

Well, darn. I’ve looked all over the place for the Magic Thingy that my Generic Mentor Character told me I had to go find, and I can’t see it anywhere. Maybe I missed something in his instructions. I’ll go back and ask him. Oh. Suddenly he doesn’t want to talk to me any more.

Michael Brandse wrote: “In Zelda Twilight Princess there was a NPC in the beginning who said where to go next to your next destination. But, if you asked him a second time, he would only say some useless things about himself. He would not repeat what he said before, no matter how many times you would ask him again.”

Am I supposed to take notes? Screen captures? If the NPC won’t repeat himself, then my current quest should at least be recorded in a diary or available by some other means.

Punishing Curiosity

According to some Eastern religions, it is best to refrain from all actions except those that are necessary, for by acting we throw a cause of things into the world like a stone into a pond, and no one can tell where the ripples might end up.

No video game ever made adheres to this principle. The default player behavior in a video game is to act, not to refrain from acting. Players play to explore, to have adventures, to do things. If you put a big red button in the game, the player will press it, and she will press it even if she is told explicitly not to. It’s a natural extension of the dramatic principle of Chekhov’s Gun: “If in the first act you have hung a pistol on the wall, then in the following one it should be fired. Otherwise don't put it there." Peter Silk writes: 

Players shouldn't be unduly punished for mere curiosity, except when such curiosity has been clearly labelled as dangerous (maybe it's not a good idea to consume the potion with the skull and crossbones on it).

I’ve already complained about instant death with no warning in an earlier No Twinkie column: “You have 30 seconds to figure out this level before you die.” This one is related. If you make a cave, it is normal and natural for the player to enter it -- even if it contains a dragon. If you don’t want the player to do something, then don’t tempt them to do it. Of course it’s OK to put dangers in a game, obstacles that must be overcome, but player death should occur as a result of avoidable failure, not as an arbitrary punishment for exploring or curiosity.

Conclusion

Last year, thanks to Ian Schreiber’s suggestion “Hiding All Your Best Content Behind a Paywall,” I added a new category to the No Twinkie Database, Bad Business Models or Monetization Schemes. Free-to-Wait is obviously another one, and I'm sure we will uncover many more. If you have suggestions, please feel free to send them, as always, to [email protected]. Happy Solstice!