When I wrote the first Bad Game Designer, No Twinkie column over 10 years ago, I thought of it as nothing more than a personal list of gripes -- published today, forgotten tomorrow. I didn't expect so many people to take it seriously, and to be so eager to offer examples of their own.

After last year's column I got a flood of new suggestions from frustrated players and developers, so here are nine new Twinkie Denial Conditions for the ninth installment of Bad Game Designer, No Twinkie!

Failure to Explain Victory and Loss Conditions

This is a bad one -- one of the worst. Unless the game is an open-ended sandbox toy like The Sims, the player must know what he's working towards -- the victory condition -- and, even more importantly, what he must avoid -- the loss condition.

Tim Elder of Blue Alto (big up for using your real details, Tim) writes, "I was playing through the single player missions in the Dawn of War expansion Winter Assault when I got to an Eldar mission that involved blowing up an Ork power generator to cause a distraction. My first time through the mission, I read the mission briefing, which stated that we didn't have enough troops for a full assault, so we had to blow up the generator to bring the Orks to it, and we could go around them."

"My troops approached the generator, killing the small numbers of Orks along the way, and all of a sudden the screen faded out and a message popped up saying 'You have failed the mission.' Huh? Why?"

So he tried something else, and got the same response. And again, and again. "Reload after reload and I still have no idea why I failed the mission, even after once having destroyed the stupid generator. Surely win and loss conditions should be well spelt out, so that the player knows what they need to do, and avoid doing." You're damn right they should. It's one of the most basic principles of design. Bad Game Designer! No Twinkie!

Time-Constrained Demos

Most of the Twinkie Denial Conditions I write about have to do with poor gameplay, controls, balancing, or content. This one's a bit unusual -- it may even be a marketing decision rather than a game design issue. Rob Allen writes, "Take the Harry Potter and the Order of the Phoenix demo, for example. I was admiring the tasteful surrounding of the academy when, lo and behold, 'You have one minute remaining.' I dashed all over the place to find what I was supposed to do and, again, got the screens telling me to buy the game. Why would I want to now?"

EA Games' Harry Potter and the Order of the Phoenix

"The thing just annoyed me by presuming that I wanted the game bad enough to eat up my bandwidth to get the intro screen, and that would make me buy it... Don't even get me started on the pointless mini-game that I could not finish that sapped up 10 minutes."

Now, you might say, "Tough! You can't complain about something that was free." I would disagree, though. Lots of web-based games are free; that's no excuse for delivering a crummy experience. And Rob's got a point about bandwidth. With Comcast announcing that it is placing a hard limit on users' data transfers, we're going to have to think carefully about how many gigabyte-sized demos we're prepared to download. If they eat up the download allocation we have to pay cash for, demos are no longer free.

We already know the demo is going to be limited anyway -- it'll only include part of the content and part of the gameplay. Why force us to quit after a fixed amount of time? The longer we play, the more likely we are to get involved and want to see more. Compare this with Doom. Id gave you the first ten levels, which you could play as much as you wanted.

It was brilliant and made them a fortune. Suppose the Doom demo had stopped in the middle of the first level with the words, "You're out of time. Go buy the game." People would have yanked the floppy disk out of the drive and set fire to it. They certainly wouldn't have bought it in such numbers.

Obvious and Cheap Reskins (also known as Cookie-Cutter Games)

Patrick Perrault of Airborne Entertainment writes, "It's common practice in the mobile space [i.e. cell-phone games] to take an existing engine (or entire game) and reuse it to do another, usually branded, game."

"While some companies (like Gameloft with games like Splinter Cell, Prince of Persia, and all its platformers) do a good job at adding new functionalities to each iteration, other publishers will stop at loading different graphics and modifying existing levels. Some really, really greedy publishers will even stop at changing only the game's title and splash screen."

"But if you want to be greedy, at least be smart! If you are reskinning a game, making sure you remove all mentions of the old title in the credits is smart. And so is making sure the characters from the original game do not appear in the new game. Failure to be smart is sure to result in players not buying any more of your games."

Leaving old characters and credits to turn up in the new game is one of the funniest screwups I've ever heard about. It doesn't get much more sloppy than that. Alas, if this were only a new problem.

Certain companies in the early '90s were infamous for turning out cookie-cutter platform games on the Genesis and SNES. And it's hardly confined to the mobile space these days; there are plenty of clone shooters around. I think the FPS is the side-scroller of this generation: there are way too many of them.

Computer Crashed While Saving? Game Over!

Someone named Ilya writes, "If you save and the game crashes while it's saving, your game's corrupt. Why not save a file with a .sa2 extension if there's one with a .sav one and delete the .sav when you're done?"

Ilya's right -- this is freshman year computer science. Unless storage space is limited, basic caution says you don't overwrite someone's old data until you know their new data has been safely stored away. (If there is a shortage of space, you can warn the user that their old save is being overwritten -- along with a "don't show this warning again" checkbox, of course.) The implementation is trivial, so get it right.

Friendly AI Characters That Do More Harm Than Good

I've often complained about stupid AI wingmen in flight simulators -- they're supposed to be watching your back, and instead they get killed in the first ten seconds of battle. Steven Taylor points out that this can be generalized to include escort missions in which the character you're escorting is an idiot, and in fact I think it really applies to any AI-controlled ally character.

He writes, "If the person being escorted simply followed the main character, or stayed in one place, this wouldn't be a problem. Instead, the escorted character runs around unpredictably in such a way that the player loses control over the situation and instead has to react to whatever nonsensical move the AI makes. Tactics are thrown out the window as the escorted character runs into the next source of gunfire."

Shawn Lucas independently offers a good example from The Elder Scrolls IV: Oblivion: "I remember a quest where the player was tasked with rescuing a peasant girl who had been kidnapped by a group of cultists. After journeying to their hideout and freeing the girl from her cell, I attempted to flee with the prisoner. However, it seemed that the girl was more interested in attacking the hostile cultists than she was in getting to safety. The second she spotted one of the cultists she attacked him and drew other enemies to our position. As it turned out, she was no match for them, nor was I. After numerous deaths and reloads, I was able to take out the cultists one by one, by means of cheap tactics, but it put me off from playing the game."

Rockstar Games' Grand Theft Auto: San Andreas

And he had another example as well: "There was one mission in Grand Theft Auto: San Andreas that required the player to follow alongside a train on a dirt bike while shooting enemies who were riding the train. The dirt bike was driven by the player and the friendly AI sat on the back and had to shoot the enemies. However, the friendly AI would often choose not to shoot at the enemies, despite having a clear shot. There was also a time limit for this mission, which made my partner's lackluster performance all the more aggravating."

You occasionally see this played for laughs in movies, where our hero is stuck with an ally who is more trouble than he's worth. (Indiana Jones's sidekick Wilhelmina "Willy" Scott from Indiana Jones and the Temple of Doom is a good example.) But a movie is different -- it goes forward no matter what.

As a player, if I'm constantly being held up or killed on account of my moronic companion, I'm strongly tempted to shoot him myself. I object to confronting stupid enemy AI (Stupid Opponents is a Twinkie Denial Condition too), but I really object to having to cooperate with, and compensate for, bad AI that's supposed to be on my side. If you can't make your AI NPCs smart, at least make them cautious and predictable.

Fake Interactivity

This is another biggie: a very, very wrong and bad TDC in an otherwise good game. I'll let a lady named Jessica explain it: "This damaged the ending of Shadow of the Colossus for me -- and it happens in other games too. You allow the player to control their character during a sequence, but no matter what the player does, the sequence can only go one way. Since it's not clear that it would ever happen, when it does happen, it makes you want to try the sequence again, but that only gives you the same result."

"If it can only go one way, make it a cutscene. If the player has control of the character, let the player's actions make a difference, and affect the outcome. If it's a part of the game's 'style' to let the player 'play' through what are essentially cut scenes, then make it that way throughout the game so that we know the game is going to be this way, and don't just surprise us with it at the end."

John Funderburk adds, "I also hated Tomb Raider Legend's and Resident Evil 4's 'interactive' cut scenes. 'Push the button when I tell you to' -- what game is that?" People play games in order to overcome challenges, make interesting choices, and generally express themselves. Game sequences that don't provide any of those experiences shouldn't be interactive. We expect that when we have control of the avatar, the avatar's actions will affect the game world in some way. If it affects the game world in no way at all, then there's no point in pretending that it's interactive.

A word of caution, though -- this is not an argument against linear stories in games. With a linear story, overcoming challenges earns the player more story (usually in the form of a cutscene), even though the player can't change its content. That's OK -- the very act of overcoming the challenge unlocks the next phase of the story, and the player knows and understands this.

Capcom's Resident Evil 4

The problem arises when we lead the player to believe her actions do matter, and then it turns out that they don't, but the player wastes hours and hours trying. If you want to tell a tragic story -- the doomed hero or the hopeless cause -- you must not lie to the player and tell him that he can escape his fate if he just tries hard enough.

For tragedy to really work, the audience must know in advance that the hero is doomed, or at least come to realize it without spending fruitless hours trying to avoid it. We can still make games about Napoleon, or the Americans in the Vietnam war, even though the player knows the ultimate outcome will be failure.

Bad Gamepad-to-Mouse/Keyboard Conversions (and vice versa)

This is a classic mistake and once again, what's most surprising about it is that people persist in making it. Jacek Wesolowski writes, "One factor that harms my entertainment is that some developers treat mouse and keyboard as secondary setup. The difference between those and gamepads is significant, because usage patterns differ."

"For instance, keyboard is better suited for 'broad' interfaces, assigning a key to each action, whereas gamepads rely on the 'deep' variety, in this case -- button combinations and sequences. Simply mapping buttons onto keys, or vice versa, is often insufficient. But that is exactly what many developers do."

"A good example of this is Assassin's Creed. Its controls make a fairly good sense when playing with gamepad, but the keyboard/mouse mapping is unwieldy and counter-intuitive. Even worse, the developer has imposed an artificial, and very severe limit on mouse sensitivity, probably to match it with the maximum turn rate available with gamepad. There is no gameplay reason for this, because instant 180-degrees turns are available anyway, as well as looking behind avatar's back. In other words, higher mouse sensitivity would not give me any real advantage, other than being able to play comfortably. While playing, I felt as if my preferred control device was sabotaged deliberately."

Jacek has put his finger on one of the reasons I'm a PC gamer rather than a console gamer: I'm not coordinated enough to manage combos, and I prefer to have separate buttons that each do one thing (or better yet, a smart button that does what I mean). However, my preference doesn't make it a Twinkie Denial Condition. The bad mouse/joystick adaptation is one, though.

Mouse-based interfaces work poorly on joysticks, and usually joystick-based interfaces work poorly with the mouse too. They don't do the same thing. A mouse is a pointing device. A joystick is a steering device.

A mouse doesn't automatically return to center the way a joystick does, and a joystick can't move indefinitely in the same direction the way a mouse can. If you're going to make a system for both, don't privilege one over the other or kludge one to fit the other. Design the user interface for each separately as if it were the only input device you will be supporting, and make each as good as it can be.

If you discover that this gives the joystick player a big advantage over the mouse player, or vice versa, don't solve the problem by sabotaging one player's control system! Build in a handicapping system that the players can manipulate themselves and mutually agree upon. It works for golf; I see no reason why it shouldn't work for video games.

Alternatively, under the principle if you can't do it well, don't do it at all, drop support for the device that you can't implement properly. That's better than selling the player an inferior experience.

Setting the Player Up to Fail

Someone who calls himself "One Man Science Team" wrote, "One design flaw I think definitely calls for Twinkie denial is level designers unreasonably demanding the player break previously established rules and risk associated consequences in order to meet goals. Even games considered 'good' do this sometimes -- in order to find every secret in the original Donkey Kong Country you have to try jumping into every pit on every level."

"You will get Game Over many times if you don't go to a FAQ first. Another example is in many RPGs, with impossible battles where you're punished for actually trying to win through the wasting of healing items but rewarded for losing because that's what the story wants you to do."

He goes on to say that he doesn't mind level designers changing up the rules now and then, but they have to give hints that they have done so -- some kind of visual indicator that things are different.

"But if accomplishing a goal that the developer can expect/predict a player might go for (finding all the secrets) involves violating the very rules of play the designers put forth (and the player getting punished repeatedly for it!) then the trust that exists between the player and designer is eroded."

Yes it is. Unlike with board games, video game players don't know the rules when they start out -- they have to learn them by trial and error, and that means they have to trust that you're not going to lie to them.

Your Only Save is Immediately Before Your Death

We'll end on a simple one. Nathan Sturtevant teaches computer science at the University of Alberta, and he writes, "What has bugged me in a number of games that do allow saving, is that they let you save your game as you die. I think I last saw this in Neverwinter Nights, but I'm fairly certain I've seen it in other games as well. In NWN it can happen either in battle, or if you're about to walk over a trap. It's quite frustrating to discover that you are reliably killed 0.2 milliseconds after loading your game."

I've been bitten by this one myself. Now, I'm a big believer in letting the player save whenever he wants, and it can be difficult for the computer to predict that death is truly inevitable if the player still has a few hit points left. (It certainly shouldn't save if he already is dead.)

But I also believe in letting the player make multiple saves. OK, the player saved in the last instant before an inevitable death -- so let him restore an earlier save. Problem solved. If you only have storage space for one save, then checkpoints might be a better option -- just make sure they're placed in such a way that the player is definitely healthy when he saves.

Conclusion

That's it for this year. I'm always interested in more suggestions, although last year I was rather bad at getting back to people and thanking them. I promise to do better!

In the meantime, if you know of a really egregious Twinkie Denial Condition, drop on over to the No Twinkie Database to see if I've already covered it. If not, by all means send me a note at [email protected].