Sponsored By

The original Bad Game Desginer, No Twinkie! was so overwhelmingly popular, that Ernest Adams decided a sequel was in order. Now, from games that run too fast to impossibly large breasts, Ernest rants about five more game design issues that really, really annoy him.

Ernest Adams, Blogger

March 31, 2000

10 Min Read

Just two years ago I wrote a column called "Bad Game Designer, No Twinkie!" filled with what I saw as design flaws - things that annoyed me about computer games. It elicited a fair amount of E-mail, most of it saying "Yeah! Me, too!" but some of it pointing out that I was occasionally being unfair. In any case, it was clearly a popular (and potentially controversial) topic, and so I started keeping a list of additional things that annoy me. I've got five here, and more that I don't have room for, so it's time for Bad Game Designer, No Twinkie! II. Some of these are programming faults, not design faults, but you get the idea.

Games That Run Too Fast

I know this sounds weird - since when is running too fast a problem? But I like to play old games, and old games, designed for old hardware, often run much too fast when played on newer machines. Obviously this isn't an issue for console games, but for PC games it's a major problem.

From a business perspective, of course, publishers are unlikely to care. To them, a five- or ten-year-old game is ancient history. They've made all the money they can from it; it's no longer supported; the customers are supposed to be plunking down money for new games, not playing old ones. But from an engineering perspective, there isn't any excuse for it. It's sloppy programming. If your game is running unplayably fast, that means you're not really keeping track of how fast it should run, and worse, you're wasting one of your most precious resources, CPU cycles. There are all kinds of things you could be doing with extra CPU time, as well you know:

  • Generate additional animation frames and therefore smoother animation. This is only possible if your animation system is capable of generating in-between frames, but more and more of them are nowadays.

  • Spend the time on extra AI. Calculate further down the game tree; let your pathfinding algorithm look farther ahead; give your monsters a bigger brain. Scalable AI isn't trivial, but if any part of it, like pathfinding, involves repetitive and indefinite calculations, that part is an obvious candidate for making use of extra CPU time.

  • Generate extra polygons. A fair number of games compensate for slow machines by cutting down the total number of polygons their 3D engines generate, with predictably ugly results. How about going in the opposite direction? Design a game that would look amazingly fantastic on a hypothetical 3 gigahertz machine, then build in scaling routines to accommodate today's hardware. As hardware advances, your game will just keep looking better and better. Obviously there are issues about memory and other resources besides CPU time, but this is a technique that seems worth the research effort.

The first game I ever programmed professionally had to run on hardware that ranged from a 4.77 MHz 8086 to a 25 MHz 80386 -- and because it was multiplayer, it had to run at the same speed on all of them. I managed this by basing everything on timers. The main loop ran as fast as it could to provide maximum responsiveness to the keyboard and mouse, but all the display routines were tied to timers, and they only ran when the timer expired. I haven't tried it, but I suspect it would still run at the same speed on my 400 MHz Pentium II.

No On-Demand Save Game and/or No Pause Game

The "save game" issue has been the subject of arguments among game designers since day one, but I know where I come down on this issue: on the side of the player. A lot of designers don't like "save game", because it makes it possible for the players to restart any time any little thing goes wrong, which means that they get through the game quicker and lose less frequently. In short, they don't get to experience the full amount of suffering and disappointment that the designer has planned for them. Too bad. Replaying an entire level because you made a mistake right near the end is frustrating and boring. As a designer, is that really your goal?

To me, the bottom line is that it's the player's machine. It's not fair to penalize him just because he has to go to the bathroom or answer the phone. Players should be able to pause when and where they want, and they should be able to stop when and where they want, without losing all that they have accomplished. If pausing the game would substantially affect the gameplay as in, say, Tetris, then black out the screen while the game is paused.

Obviously this doesn't apply to multiplayer games.

Deadlocks

A deadlock, or in rather romantic British terminology a "deadly embrace," occurs when two processes are each waiting for the other to do something, and so neither goes anywhere. Deadlock prevention is a classic computer science problem for multi-tasking systems: process A has allocated resource X but still needs resource Y; process B has allocated resource Y but needs resource X, so each waits indefinitely for the other to finish and release its needed resource.

Which came first: the stones, or the stonecutter's hut?

In game terms a deadlock can occur when you need a resource to construct a production mechanism to produce more of the same resource. I first noticed this problem playing Settlers 3. I didn't have enough stone to build a stonecutter's hut, but without a stonecutter's hut I couldn't get any more, either. This wasn't really Settlers' fault, because the game had given me enough stone to start with, but I had allocated it all to other things. Of course, in some cases you may want a deadlock to be a loss condition: in a wargame, if the player loses all her construction units and she loses the only building that produces construction units, the system can detect this and tell her that she's lost.

The more complicated your economic model is, the more likely deadlock situations become. Settlers 3 has an unusually complicated model. When I created my deadlock, my community was thriving and I wasn't under attack at that point, so I couldn't really be said to be losing the game; I simply made an economic mistake. Fortunately, the game provided a workaround: I could demolish other buildings and regain some of the raw materials. Eventually I demolished enough to get the stone needed to build a stonecutter's hut, and I was back in business.

Another way to avoid deadlocks is to provide an alternate source for the resource, even if its value is minimal. This is the function of collecting $200 when you pass "GO" in Monopoly. Even if you don't have any properties earning rents, you're still guaranteed to get that $200.

Deadlocks aren't always design errors, but you need either to provide a way to break the deadlock (pass "GO," demolish buildings, etc.) or a way of detecting it and ending the game. Games that go into deadlock conditions and sit there indefinitely (and I've played one or two) are annoying.

Moving Impossibly Large Chunks of Stone

So here I am, playing the demo of Indiana Jones and the Infernal Machine, and I can't get out of the very first room. I haven't played a lot of these kinds of games, because they're generally too twitchy for me, but I figure I can trust LucasArts not to demand too much hand-eye coordination. I try everything I can think of, with no luck. Can't even get out of the first room… boy, am I a loser! Eventually I break down and go find a walkthrough.

Oh, here's the answer! There's a cube of stone, about five feet on a side, that I'm supposed to drag someplace… WHAT?

Let's see, the density of rock is about 340 pounds per cubic foot, the block is about 125 cubic feet, so it weighs on the order of 21.25 tons. That's about how much the giant uprights at Stonehenge weigh. And Indy's supposed to drag this around just by pulling on it, is he? Gosh, I wonder why I didn't think to try that.

Indy's great and all... but could he really move that?

OK, I know the physics in video games is mostly ludicrous - the first time I saw Sonic the Hedgehog change direction in midair I heard a strange whizzing noise: Isaac Newton spinning in his grave. Maybe this dragging-huge-rocks-around concept is such an accepted convention by now that I should just put up with it. Still, I always thought of the Indiana Jones games as set in something resembling the real world. Puzzle games involve lateral thinking, but lateral thinking itself has to be bounded by some limitations on what it's reasonable to consider -- otherwise you'd never stop thinking. For me, I tend to rule out obvious physical impossibilities. I suppose it depends to some extent on the genre, but in this case, it annoyed me. Indiana Jones is a human being, not Superman.

Huge Breasts and Other Juvenilia

Some years ago, EA had a couple of artists create animations of cheerleaders for a cartridge edition of Madden NFL Football. What they turned in was a feeble little 4-step cycle of women with completely improbable breasts jumping up and down. We fired them and had someone else do it over. We didn't fire them just because they had done a poor job; we fired them because they were morons who were more interested in indulging their own snickering voyeurism than in delivering what the company needed, and they had wasted our time and our money.

I've got a message for the no-talent clods who insist on putting puerile humor and outrageously-breasted women into computer games. How to put it diplomatically? Oh, I've got it:

Grow up.

You're an embarrassment and a disgrace. It's because of the example you set that the rest of us have to explain to our in-laws, friends, and for that matter, Congressmen, that we're not all tasteless money-grubbing louts, only you guys are. I have spent a lot of time trying to convince non-gamers (but people who vote) that you drooling peep-show habitués are actually a minority whose imbecile products and total lack of judgment unfairly tarnish the rest of the industry. Of course, if you actually cared about what effect your self-indulgent display of adolescent lubriciousness has on the reputation of the business or its possible consequences for the political debate over regulating video games, you wouldn't do it, but no, you're too wrapped up in your own infantile fantasies to pay attention to anything beyond the ends of your priapic phalluses.

It might be tolerable if you were actually any good at it, but your products aren't even decent erotica. They're stupid, they're offensive, and they're not sexy or even funny. I take some comfort in the knowledge that as the market matures, you will eventually be forced out, or at least reduced to irrelevancy. In the end the porno kings stopped trying to pretend that they were legitimate moviemakers and went off to form their own industry with its own low standards of quality. Why don't you do the same? Then you can have your own trade shows, your own awards, and hang around with your own kind: sweaty-palmed, heavy-breathing sloped-forehead gonad-brains. Grow up or get out.

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