Gamasutra: The Art & Business of Making Gamesspacer
The Designer's Notebook: Bad Game Designer, No Twinkie! X
View All     RSS
October 24, 2014
arrowPress Releases
October 24, 2014
PR Newswire
View All

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! X

December 7, 2009 Article Start Page 1 of 3 Next

[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.

Article Start Page 1 of 3 Next

Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

University of Central Florida, School of Visual Arts and Design
University of Central Florida, School of Visual Arts and Design — Orlando, Florida, United States

Assistant Professor in Digital Media (Game Design)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Game Designer


Glenn Storm
profile image
Thanks again, Ernest! These are always good, but the inclusion of the development-related twinkie denials is great! I particularly like Pascal Luban's comments on level design and the denials for designers who shun the tech. LOL, at Magic Cover; I'd never heard of that. Doesn't LOS provide all the cover insurance you need? If you're gonna go so far as to flip a can't-hit-me bit, at least flip another to make them invisible. ;)

sukru tikves
profile image

I have a comment on "Magic Perfect Cover in Shooter Games". Sometimes it's the technical difficulties that makes shooting through cover impossible. The game engine might just not have an advanced hitbox system that will register the shots. (For example old doom engine had transparent sprites, but they were essentially walls with "holes" in their textures).

Matthew Johnson
profile image
My favourite Psychic AI story was in the old Ultima II game, where (as in the example given in the article) the city guards knew immediately if you killed someone in a city, even if there was no way they could have seen it. The funny thing was, they were perfectly OK with you blasting people with a ship's cannon -- even if you were blasting other guards... (Also, in that game you absolutely _had_ to kill guards to be able to win, since that was the only way to get keys to get into locked areas -- a far cry from the later sequels' moral standpoint!)

Jamie Mann
profile image
Xbox Live Indie Games has been throwing up a few twinkie denial examples of late:

1) Bad control layout. The X360's controller has four triggers in addition to the four face-buttons, but several real-time games insist on forcing the player to use the face-buttons in conjunction with the right analog stick. One thumb does not map well to five separate controls, especially when they need to be used simultaneously!

2) Overly in-your-face nag-screens. Quite a few demos default to the "buy me now" option on the main menu, presumably in the hope of fooling people into an accidental purchase. Distinctly annoying! Admittedly, there's worse: a few games from one specific developer claim that A will start the demo but instead load the XBox payment screen. No demo and questionable behaviour: no twinkie!

3) Hidden or missing help. A lot of XBIG games (some of which are fairly complex) have no help whatsoever or simply include a diagram of the controller layout. Of those which do, there are two recurring twinkie-denial themes:

a) The main menu doesn't list a Help option: instead, the help is located under the "Options" menu. Obviously. This issue is surprisingly common!

b) The help option isn't available in-game. Instead, the only way to confirm something is to quit out of your game and return to the main menu.

To set the context: XBIG games are only available online, generally have very limited "community" support (e.g. no entries on and usually don't have the budget or resource to put together an interactive tutorial. Meanwhile, they've got a maximum of 8 minutes to prove their worth to the player before the hardwired timer kicks the player back to the dashboard. Clear and easily accessible help is vital to demonstrating what the game has to offer - or it's no sale, never mind no twinkie!

Ed Alexander
profile image
I already can't wait for the next installment. :)

Great stuff every time.

[User Banned]
profile image
This user violated Gamasutra’s Comment Guidelines and has been banned.

Jim McGinley
profile image
I always like these entries. Having said that:

Article Twinkie Denial

- Not linking to games you reference i.e. Progress Quest

- Only linking to pages on your own site

Adam Bishop
profile image

To be fair, those things have all been raised within the XBLIG community. Some developers just stubbornly insist on doing things that anger their customers because they think they know better than everyone else. I've personally tried to convince a number of developers of #s 2&3 from your list, but it's often an uphill battle.

Glenn Storm
profile image
@Jim: LOL

Jeremy Reaban
profile image
Grinding isn't just even in MMORPGs/RPGs. In both Gran Turismo PSP and Forza 3, you have to do a lot of easy races just to buy all the cars you want. Forza 3 is especially bad, at most you earn about 250k credits an hour, some cars cost 15 million or more.

Like RPGs, where quests should provide sufficient xp and such to level up, racing games should provide enough cash/cars just doing the races in game once, without having to do them over and over.

Ian Barkley-Yeung
profile image
On "Essential but Unobtainable Items":

I still remember the first Leisure Suit Larry... In one of the first areas, there was a guy selling an apple. You could buy it anytime from near the start of the game. And you needed that apple for the VERY LAST girl in the game -- I think the very last command you entered to win the game was "give apple to Eve".

And you could eat the apple when you got it. In which case it was gone and you could never buy another one. So basically you could lose the game within ten minutes of starting, and not know until the very last screen. I still remember the facepalm feeling when I read her nametag and realized what I had to do. Good thing a friend had a near-the-end save file and let me see the ending.

Carlo Delallana
profile image
@sukru "Sometimes it's the technical difficulties that makes shooting through cover impossible. The game engine might just not have an advanced hitbox system that will register the shots. (For example old doom engine had transparent sprites, but they were essentially walls with "holes" in their textures)."

This is where the game designer needs to collaborate with artists. Sometimes things are created for aesthetic purposes and practical use isn't always considered. When in doubt always make cover objects larger than the possible hiding states for opponents and the design should SCREAM "I'm a valid form of impregnable cover!" As a final form of feedback the player should see bullets spark/bounce off this sucker.

Jamie Mann
profile image
@Adam: I don't doubt they get raised on a regular basis :) Though to be fair, XBIG was meant to be a sandbox for new developers and this sort of thing is all part of the learning curve...

The thing with hiding the help in the Options menu does confuse me however: given how often it happens, is there some sort of default design guideline or sample code which uses this structure?

Andrew Smith
profile image
@juice uk

There are TCR's and guidelines for XBLA games that lean developers towards having the Controls and How To Play screens hidden in the Help and Options submenu... maybe XBLIG devs are looking to their big cousins for inspiration and seeing the precedent.

Jamie Mann
profile image
@Andrew. Thanks for that!

It makes (some) sense to have Help under a "Help and Options" menu item; it makes far less sense to have Help under an "Options" menu item. Though to be honest, I'd argue that for "DLC" games, Help should be a top-level option anyway...

Anthony Rosbottom
profile image
I hadn't really heard of Mr Adams until this article. I'm now a bit bemused after looking him up on mobygames, as his slim list of projects (credited on five IP's plus two unpublished IP's) doesn't really marry up with ten lengthy articles that condescend designers with MUCH more 'shop floor' experience.

Phil OConnor
profile image
"I hadn't really heard of Mr Adams until this article. I'm now a bit bemused after looking him up on mobygames, as his slim list of projects (credited on five IP's plus two unpublished IP's) doesn't really marry up with ten lengthy articles that condescend designers with MUCH more 'shop floor' experience."

My thoughts exactly.

Jim McGinley
profile image

"I hadn't really heard of Mr Adams until this article."

Mr. Adams should really fix this.

"I'm now a bit bemused after looking him up on mobygames, as his slim list of projects ..."

"... with MUCH more 'shop floor' experience"

There was a link on Moby Games to the "Designer's Notebook - Ernest Adams' professional website".

I realize it's an extra click, but it's worth the workout.

While more effort, you could also try using Googling "Ernest Adams".

"... ten lengthy articles that condescend designers ..."

As the articles show, most (if not all) of the twinkies are submitted by other people (mostly players).

Being an elder statesmen of gaming, Ernest makes the perfect player ombudsman.

It's a fantastic service.

Anthony Rosbottom
profile image
@ Jim McGinley

I don't want to labour the point but Gamasutra describe Mr Adams as "veteran designer" and I'm suggesting that his track record doesn't tally up with the label "veteran designer".

Call him "Elder Statesman of Gaming", "Perfect Player Ombudsman" whatever, but they are subjective descriptions of his role in the industry with no correlation to his credit list.

Jim McGinley
profile image
Hmmm... I know better to be caught in a flame war...

but I can't help myself!

Opinions I can handle, but ignorance... NAY!

- - -


I'd like to belabour (rather than labour) the point.

"I'm suggesting that his track record doesn't tally up with the label "veteran designer"."

The Track record from "Moby Games" you mean?

Did you visit his site as I suggested, or just read my response.

I thought I was clear about working out that finger.


- - -

Let me browse Ernest's site for you:

From his posted resume:

"20 years as a design consultant, lead designer, producer,

and software engineer in the game industry,

following 7 years as an engineer in the CAD industry."

Since I realize that might not be good enough:

1992 - 2000

8 years game programming/design experience.

That would be the "shop floor" experience you were looking for.

(I'm ignoring his executive experience)

2000 - Today

Game Design Consultant and Trainer

Making a living for 9 years as a games design consultant is not easy.

You need to be good at what you do.

It certainly helps my "veteran designer" argument

Also of interest:

"Since 2000 I’ve been consulting and writing,

so most of my work has been uncredited.

But I’ve worked for a lot of really interesting people!

See the Consulting page and my Client List for more information."

Crytek and Evolution Studios (Motorstorm)

hired him to do some game design training.

They might know something you don't.


- - -

His cumulative experience led to my "subjective descriptions" of

"Elder Statesman of Gaming" and "Perfect Player Ombudsman"

I've also seen Ernest speak.

He's smart, articulate, and passionate about the future of games.

I haven't bought his book yet, but like what I've read.

What led to your "subjective description" Ernest is not a veteran designer,

and the implication he's not even qualified enough to write ten lengthy articles?

Anthony Clay
profile image
I just got around to the God of War collection - and was reminded of why I took my twinkie and ran at the climax of the game:

Spending an entire game building a character, learning/mastering moves, and building skill just to have it all taken away and replaced with a crappy over-sized sword with only 4 moves...only two of which are useful.

Jamie Mann
profile image
A quick look at Ernest's website shows his involvement in twelve published games (starting in 1989) and ten unpublished ones, together with consultancy work for around 30 companies and over 50 educational facilities across fifteen countries.

To my mind, those are fairly impressive credentials.

That aside, I personally think the Twinkie database is a useful resource which is presented in a light-hearted way (and as has been highlighted above, a lot of the items have been submitted by third parties). It's not intended to be condescending, and while there may be exceptions or justifications for some of the things it points out, the database serves as a good set of basic principles for Game Design 101 - and most usefully of all, it contains "real world" examples of where the problem can be seen.

The only worrying thing is how often these basic rules are forgotten: having played and reviewed over 500 Xbox Indie games ( *plug*), I'd say that virtually every single thing which is highlighted in the database is present in one or more titles...

[User Banned]
profile image
This user violated Gamasutra’s Comment Guidelines and has been banned.

Luis Guimaraes
profile image
@John Smith

Definitely a secret ending, plus the biggest joke of the game, as everything now comes down to that very first momment and all you should have done was get and keep the damn apple. That's the point where you stop serious role-playing and laugh at the miserable luck of your poor character.

David Tarris
profile image
In reference to the section "Incomplete or Ambiguous Design Documents", I think this is an interesting point of discussion. Certainly, I'd agree that while games are artistic, they are, at the end of the day, software ("artistic software", one might say). However, something about the notion of writing pseudo-code in the design document (or as we in the software engineering world might call it, the requirements specification) just rubs me the wrong way.

I remember one year at the GDC, Damien Schubert gave a great talk about writing design documents, and the importance of not going into implementation-specific details (provide that what, not the how, of the requirement). It seems to me that the better way to go would be to, again taking a page from software engineering principles, just focus on robust requirements that encompass functionality in terms of what the player can do, address boundary cases, and develop plenty of user scenarios (which will come in handy during testing, as well).

I suppose the point was primarily that designers should know about programming, but I might slightly disagree and say that designers should know about software engineering and technical writing.

Jacek Wesolowski
profile image
This reminds me of something that happened in one of my previous jobs. We were working on a low budget game. 9 months, 15 people, everyone sitting in the same room. The game had a very simple premise, and we made no documentation at all (with one important exception - see below). The project lead knew what he was doing, but he was an animator by trade, so our design discussions were very informal. Believe it or not, the project went smoothly for the most part.

Except for the final boss battle.

The boss behaviour was a little more complex - it reacted differently depending on where you hit it, it had to do two different things at the same time, it had to act in a few different ways depending on what the player was trying to do, etc. The lead had a very clear vision of what kind of enemy that boss would be, and he would actually give you a good - informal - description of its actions, reactions, the general feeling and pace, and so on. He was actually the best lead I have ever worked with -- but he just wasn't specific enough when he talked to the programmer responsible for the implementation.

The result was that the programmer did put the desired functionality in place, in that he implemented all the use cases he had been told about. But he didn't quite know how to handle the logic governing the various actions and reactions. It worked; but it wasn't enjoyable. There were also a few numerical parameters, and the programmer didn't know what values would be appropriate, so he used random ones. For two weeks (an eternity when your project scope is nine months) we had a kind of deadlock - everybody felt the boss battle wasn't very good, but no one seemed to know how to improve it by just tweaking the numbers.

I was responsible for the level where the boss battle occured. So what I did was play the boss fight in my head, then draw a state transition diagram on our team whiteboard, complete with descriptions of all boss actions in each state, and all conditions for all state transitions. I actually used pseudocode for the sake of brevity, and I did end up listing all the variables, their value ranges, and their default values (and yes, we did need to tweak them a bit afterwards).

So, all in all, we ended up having a piece of very formal and very low-level documentation. And it was exactly what we needed. The funniest part was how me, the project lead, and the programmer spent a couple of afternoons standing by that whiteboard, discussing the content. It was a hardcore state graph, and yet it wasn't beyond an animator's comprehension. It proved to be an efficient way to bridge the mindset gap between a programmer, a designer, and an artist.

That being said, I wouldn't necessarilly recommend super-detailed and super-formal design documents, because:

- the form should match the purpose - all the other enemies in that game were so simple we got away with not documenting them at all;

- the technology has moved on;

Back on that project, the programmer's job was to write a relatively low-level code which implemented that particular state graph. A different graph would call for a separate piece of code. So drawing a state graph on a whiteboard belonged to code specification.

Today, I can build an equivalent of that graph directly in my CAD software, not even touching the keyboard once, and the game engine interprets it for me on its own, without me having to involve a programmer directly. So building that graph belongs to design implementation now.

sukru tikves
profile image
@Carlo Delallana: I see what you mean. Both teams try to push things separately, and the end user suffers due to lack of coherence.

I usually tolerate cover issues, if they are rare (being unable to shoot a slightly uncovered foot). But, sometimes they are pretty persistent in a game (e.g.: SW: Force Unleashed, which has a completely broken targeting system), or the game obviously forces it (i.e.: to save a boss, until the circumstances are ready). If I feel more capable than the game engine offers, and it forcibly hinders intelligent progress, then the game design is a failure.

Javier Arevalo
profile image
"something about the notion of writing pseudo-code in the design document [...] just rubs me the wrong way"

A detailed design document must describe what can happen, and, equally important, when it can or can't happen. The most concise way to write that up is usually some form of pseudo-code. Even cooking recipes are basic form of (non-branching) pseudo-code.

Jeanne Burch
profile image
So I’m reading along, and I recognize some of the examples.

“Hey!” I think. “The author stole those from the textbook in my game development class!”

Then I look at the name under the title, and realize the author WROTE the textbook in my game development class.


David Tarris
profile image
Javier, I'd say there's a difference between using logical structures (e.g., if this, then this, else this, etc.), and pseudo-code, which implies some sort of lower-level approach (iterate through this list, do this, whatever). That's the job of your programmer, and your designer shouldn't be wasting his time pretending to be the master of data structures and algorithms. Maybe we're just think about pseudo-code in two different terms. If by "some form of pseudo-code" you mean using hierarchal lists to encapsulate functionality and flow, then I'd agree with you, but if you mean, as Wikipedia would put it, a "high level description of a programming algorithm that uses the structural conventions of a programming language", one would be making two fundamental mistakes by using said pseudo-code in a design document:

1. You're having your designer waste time on something that isn't his area of expertise.

2. You're telling the programmer his business, and may not even be right (implementation-wise).

It's basic comparative advantage. Your designer's talents are better spent on the what, not the how, and your programmer can figure out the implementation himself, as is his job.

John Mawhorter
profile image
@David "using hierarchal lists to encapsulate functionality and flow"

Google and Wikipedia do not give good examples of hierarchical lists and/or how to use them. Are there books on technical writing or software architechture I should read to help my write better design documents?