Common Misconceptions about Computer Game Design

Although I no longer design computer games for a living, I was a game developer for 25 years, starting at around 1983. During that time I learned a lot about the craft of game design and what makes a good game. But I’ve also met a lot of people who had some fairly serious misunderstandings about what is involved in designing a good game.

Here’s some of the more common ones:

Misconception #1: Game design is easy

Game design is like writing prose, or composing music, or any other creative endeavor: it’s actually much harder than it looks from the outside.

Think of it this way: anyone can make up a bedtime story for their son or daughter. But that doesn’t make them a great novelist, nor mean that anyone else would enjoy hearing that story.

Similarly, anyone can make up a game, but that doesn’t mean other people will want to play it.

I suspect part of the reason for this misconception is that, growing up, a lot of us “invented” games for ourselves and our friends. We remember how much fun we had building sand castles and playing hide-and-seek, and think that it “can’t be all that hard” to re-capture that experience.

But I think what we forget is that the fun we had wasn’t because of our cleverness in inventing a new game. It was because we were children, and everything was new and exciting, and our close friends were just a joy to hang out with. If you took that same game and encoded it into a computer, the experience would be very different.

Misconception #2: “Computer games” are games

Most computer games aren’t actually games. They are puzzles.

Before computers, the word “game” typically referred to some competitive activity played between friends or teams — card games, board games, sports games, and so on. The common element in all of these is that they are (a) intrinsically social, and (b) have an aspect of competition between players. While there are computer games that do have these elements, they are in the minority.

A “puzzle” on the other hand is a challenge in which a player attempts to navigate a complex set of rules in order to achieve some goal. An example is a Rubik’s Cube, in which the rules are the set of allowable transformations of the various faces of the cube.

But “puzzle” could also describe an adventure game. Or Solitaire.

The vast majority of computer games are “single player vs. the environment” games, which means that they have more in common with puzzles than traditional games.

(Unfortunately, “computer puzzles” just doesn’t have the same ring to it.)

Misconception #3: “Fun” is just a matter of following the right formula

One of the hardest parts of designing a game is obtaining that elusive quality of “fun”.

Of course, there are some obvious things to avoid — if the game is too easy, too hard, too repetitive, too unpredictable, or simply unwinnable, then obviously it’s not going to be fun. But simply avoiding all of those things won’t guarantee a fun game.

Even experienced game designers struggle with this. There’s no formula that you can follow that will always produce a fun game, other than making an exact clone of a game that is known to be successful.

There are some very bright thinkers who have delved deep into the philosophy of fun, and they can give you some good rules of thumb. For example, all fun games share the quality that they change who the player is as the game progresses — that is, by the time you are done, you are a different person than you were when you started, even though that “difference” may just be the fact that you are better at pressing a particular combination of buttons.

But there’s no set recipe that you can simply follow that leads to a fun game, any more than there is a recipe for writing a great novel.

In mathematical terms, a “constructive” theory is one that allows you to compute an answer, whereas an “existential” theory only proves that the answer exists. Unfortunately, there’s no constructive theory of fun.

Worse, it can be hard to tell whether a given game design is fun. For decades, I’ve been propounding Talin’s First Law of Game Design:

There’s no way to know how much fun a game will be until after you have built it.

In other words, you can’t actually look at a game design and know in advance how much fun it will be. You have to actually play it.

Part of the reason that it’s so difficult is that the process of making and designing games is also fun. There is a lot of pleasure to be gained out of crafting a really good game engine or designing a really clever dungeon.

And it’s easy to confuse the fun of making the game with the fun of playing it. That is, when we imagine a hypothetical player navigating the contortions of our clever dungeon, the warm feelings we get are partly feelings of satisfaction from having created it. We can’t easily envision the player’s experience in an objective, unbiased way.

What innovative game designers often do is iterate over designs. They create multiple throw-away games (cheaply made with cut up artwork and sound), play them, and then take the best ones and modify them, play them again, and repeat until they have achieved something satisfactory. Only after they have found the “fun” do they spend the resources to give it high quality graphics and sound.

And then, when all that’s done, they iterate some more. When I worked on Sim City 4, I ended up re-implementing one of the user interface dialogs twenty times, because the design kept changing. But I didn’t mind, because that twentieth iteration was a lot better than the first one.

There is also the opposite problem, which is burn-out. When developing a game — or a book, or record album, or any other creative work — you have to experience it dozens if not hundreds of times. Repeat this enough times and eventually you become emotionally numb. You can no longer recapture the pleasure you once had from playing the game. It no longer feels “fresh”.

The solution here is to rely on feedback from other people, particularly people who are not involved in creating the game.

Misconception #4: All you need is the right subject matter

My mother once asked me, “why don’t you make a game about arsonists?”

That wouldn’t be the last time someone had proposed a game idea to me. Almost invariably their suggestion is entirely about some theme or subject matter:

In each of these cases, you had someone who loved a particular activity, and was certain that that excitement and pleasure would carry over into a computer game.

The problem is that playing a game on a computer isn’t scuba diving, or wine tasting, or hiking. It’s a completely different kind of activity, and what makes a good game enjoyable has almost nothing to do with what makes scuba or wine-tasting enjoyable.

Even professional “game designers” fall into this trap. (I put “game designers” in quotes here, because even though the specific people I am thinking of got paid to design games, they weren’t actually very good at it.)

I’ve seen numerous pitch documents that start out like this:

What all of these have in common is that they are trying to get the reader invested by describing an exciting and dramatic situation. They are implying that since the imaginary situation is so awesome and compelling, therefore a game based on that must also be awesome and compelling.

In the end, however, the subject matter is almost unimportant — it’s main function is to serve as a hook to get the player’s attention. What will keep their attention over the long haul is the player’s interaction with the game rules.

Noah Falstein, one of the luminaries of the game industry, once gave a talk at CGDC on adapting movie plots to games. Specifically, his company had been hired to create a game based on Indiana Jones and the Temple of Doom.

Rather than trying to recapitulate the movie plot in game form, what they did was take one of their unpublished, in-house game designs that was known to be fun — in this case, a car racing game with multiple parallel lanes — and give it a new coat of paint. The cars became mine carts (echoing a scene in the movie) and the roads became metal tracks.

Although the game barely had anything to do with the movie, it was a hit. And the reason it was successful is that the hard part — coming up with a set of rules that were fun — had already been solved.

Misconception #5: Realism is Desirable

Once upon a time there was a simulation game that allowed you to experience life of a captain of a modern cargo vessel. And it did a very good job — it accurately let the player feel all of the boredom of being a cargo ship captain. Cargo vessels are very slow, and it takes days for a ship to go from one port to another; this game accurately simulated that duration.

Similarly, I once worked with a “game designer” (scare quotes again) who was a military history buff. He knew that in real medieval battles, armies always formed long lines of soldiers facing the enemy (so that each soldier could not be attacked from the sides). So his idea of a medieval battle game involved deciding where to place the units — do we want to put the archers in the center, or on the left? The problem, unfortunately, is that this exercise was interesting for about three minutes, after which the game became repetitive and tedious. Most popular medieval combat games involve decisions and strategies that are very far from what this designer would have considered “realistic”.

Game players often say that they want games to be “more realistic”. But what they actually want is not realism — they don’t want the game to be a faithful re-creation of the real world. What they want is the illusion of realism, but with all the boring bits cut out. There’s a word for this — verisimilitude.

Realism is never desirable in my opinion (unless you are building a teaching simulation), but verisimilitude often is. Even in games which are fantastic or surreal, you often want some sort of internal consistency that allows you to invest in the experience as if it were real. But that is not realism.

However, that’s not the end of the story. I’ve often thought that there is a priority order for what aspects a game should have, similar in concept to Maslow’s hierarchy of needs:

The aspects are ranked, such that a higher-ranked item always takes precedence over a lower one. So if there’s some aspect of the design in which two aspects conflict, choose the higher one. For example, if there’s a game feature which is fun but lacks verisimilitude, choose fun.

Social interaction comes at the top of the list, however it only applies to multi-player games. Game features that facilitate social interaction should always be given the highest priority — even at the expense of fun. That is because social interaction is the reason why many players are online in the first place.

Here’s a concrete example of what I am talking about:

In the massively-multiplayer game EverQuest, the way you invited someone into your party is by clicking on their character and pressing the “invite” button. This meant that you had to be in close proximity to the character in order for them to join your group. Reasonable, right?

However, when World of Warcraft came out, one of the first things I noticed is that you could invite someone into your party even if they were half-way across the world. This was much better — it meant that it was much easier to form groups (social interaction), even though it was less “realistic”. And that made the game more enjoyable, because it made it easier to find people to play with.

There were many other subtle advances in social interaction that the WoW had over it’s predecessors, which allowed it to quickly overtake them in popularity.

So the next time you see a game advertised as having “more realism!”, you may want to think about what that really means.

See also:

More Game Development Misconceptions

More Essays by Talin

I’m not a mad scientist. I’m a mad natural philosopher.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store