Welcome!

Welcome back to Design 101. If you missed the first installment, you can check it out here. Today we’re going to talk about one of the most controversial topics in game design: Complexity. Since time immemorial, arguments about this subject have raged through design teams and gamer communities alike.

Does removing complexity “dumb down” your game? When is complexity a good thing, when is it bad? Why do so many game designers treat complexity like a boogeyman to be killed, when a lot of players love it? There’s a lot to get into, so let’s get started.

What is Complexity?

As with many ongoing arguments, the controversy arises from a misunderstanding. Like many words in the English language, people use the word “complexity” to refer to several different things at once. As game designers there are three distinct types we care about. They are Comprehension Complexity, Tracking Complexity and Depth.

Why three types? Because each creates a very different player experience.

Comprehension Complexity - The Bad Kind

Comprehension Complexity refers to how difficult it is for the player to understand what the designer is communicating. This might be how difficult it is to understand a rule, a unit’s abilities, a mission objective, an interface or any number of other things. Here’s an example:

Take a moment and try to figure out what that form is actually saying. It takes some mental gymnastics. You probably find yourself re-reading it multiple times, trying to isolate certain fragments and generally feel like you’re mentally “untangling” something.

This takes a significant chunk of mental energy and can create a sense of feeling “lost”. The more mental energy we spend on figuring out what the game designer is trying to tell us, the less we have to spend on enjoying the game (especially if your game involves a lot of strategic decisions).

While the comic strip contains an extreme example, it’s not too far off from what a lot of games do. Many games are full of impenetrable instructions, counter-intuitive rules and multi-step interactions. Usually these aren’t as severe as the Dilbert example, but a reduced negative experience is still a negative experience. Dumping a spoonful of salt in your players’ water might not be as bad as filling the glass, but it’s still a distasteful experience.

Tracking Complexity - The Other Bad Kind

Tracking Complexity refers to the task of mentally keeping track of multiple things at once. Let’s do an experiment. I’m going to list 10 names, and I want you to remember all of them while reading the rest of this section. Here goes, “Alex, Jason, Kate, Michael, Wendy, Charlotte, Wan, Steve, Elizabeth, Jordan.” Got them all?

The process of trying to keep all those names in your head is probably causing you some mental strain right now. It’s probably making it harder to focus on this text as you’re reading it, and this text is the fun part. We’re talking about game design! I’m reducing your experience by asking you to remember all those names while reading this. Are you jumping back to keep checking them all? If you are, that’s breaking your flow.

Have you just given up and decided to keep reading? That means your brain has been overloaded, which is my fault as the writer of this article. You’ve decided to quit the task because the strain of mentally tracking all those names is sapping your enjoyment of what you actually came here for. Did you spend several minutes committing those names to memory before reading? If so, you’re probably in the minority and doing so messed with the overall pace of the article. All these things are negative effects on the reader’s experience.

Alright, stop trying to keep those names in your head if you haven’t stopped already. Unless you’re a person that enjoys memory games, that process probably felt like a mental strain. Unless my design goal is specifically to create that experience in the player, adding the mental strain of asking players to keep track of multiple things in their heads at once isn’t helping my design goal.

For most projects, you’re going to want to avoid forcing your players to mentally track things whenever possible. Every time you include an effect like, “Whenever a creature is played next to a lake, gain 1 life” in your game, the gameplay might be great but there’s a cost in tracking complexity. Each of your mechanics might be worth their tracking complexity on their own, but taken together they might overload your players’ brains.

Depth - The Good Kind (Mostly)

Comprehension Complexity represents how hard it is to understand how everything works.Tracking Complexity represents how hard it is to keep track of what’s actually going on. Once you’ve got all that, Depth represents how difficult it is to figure out the best possible move.

We hear Depth talked about most often in strategy games, but it exists whenever players have to make a decision based about what to do. This applies to options for character-building in an RPG, map control in an FPS, raids in an MMO, item building in a MOBA and much more.

Let’s talk about strategy games for now, because they’re the elephant in the room. Designers might be willing to accept that Flower and Dance Dance Revolution don’t need much depth, and so they’re fine with limiting complexity overall. On the other hand, Strategy games live and die on how engaging their decisions are. Isn’t removing complexity from a strategy game a bad thing?

This is where our definitions come in handy. Once you know what the factors involved in a decision are (Tracking Complexity) and understand your options (Comprehension Complexity), you finally get to start evaluating those factors and determining the correct play. This is the fun part of the game.

Here’s where the controversy comes from. People that claim to want more complexity. and are against, “dumbing down the game”, are usually defending Depth. People railing against it are usually trying to cut Comprehension Complexity and Tracking Complexity. There really isn’t a disagreement here.

Unfortunately many people perceive all three aspects as a single concept “Reducing Complexity”. Players thinking about Depth naturally don’t want to see it reduced. People thinking about Comprehension and Tracking complexity naturally want to cut it down.

How do we resolve this?

The Crucial Point

Comprehension Complexity and Tracking Complexity are almost always bad. They produce negative experiences for the player that push them away from the fun parts of the game. Unfortunately, it’s not possible to get rid of them entirely. Chess needs to have rules (Comprehension Complexity), and its pieces need to threaten other spaces on the board (Tracking Complexity). You’re going to have to include some of these negative aspects in your game.

Complexity is like a budget for your game design. You always want to cut unnecessary expenses and find ways to get the same result more efficiently. An ideal game meets its design goal while creating as little Comprehension Complexity and Tracking Complexity as possible.

Design Tool - A Tie-Breaker

This leads me to a useful tool. Last time we talked about how a clearly articulated design goal can help you decide which design choices are better for your game. However, sometimes you’re going to run into situations where you aren’t sure which choice is truly better at supporting your goal. When I run into these situations, I use the following tie-breakers.

First ask yourself, “Which of these options creates less Comprehension and/or Tracking Complexity for the player?” Since you aren’t sure which option is going to better support your design goal, go with the option that you know will create fewer harmful side-effects.

Second, if both options are equally simple for the player, ask yourself, “Which of these options is easier for the developer?” All else being equal, pursue the option that will be less work for you. You can spend that extra time and energy improving the game in other ways.

You might also run into situations where you aren’t sure whether adding something to the game is going to justify the Comprehension or Tracking Complexity that comes with it. In this situation, always go with the less complex option.

There are several reasons for this.

1. While it’s easy to be wrong about how enjoyable something will be, you know for sure that lower complexity is a good thing.
2. It’s much easier to add complexity if needed than it is to remove it later.
3. It’s better to try the game with the less complex option and see if it still meets your design goal. It’s very difficult to imagine the less complex version in action once you’re used to the complex one.
4. You know your game pretty darn well. If you think it’s the right level of complexity, it’s probably going to be a lot more complex for the player. The Tappers and Listeners experiment shows how hard it is to tune out your background knowledge.
5. You’re going to be biased to keeping your ideas in your game. Humans are naturally loss-averse, and it’s very hard to cut your own cool ideas. If you’re not 100% sure that the feature is worth the complexity, this bias ensures that it almost certainly isn’t.

You might be seriously worried that the game simply won’t be deep enough to meet your design goals without the added complexity. That’s a valid concern. And yet every single time I’ve been worried about this and ended up trying the less complex version; the game has still had more than enough depth for its design goals. Not once have I ended up adding the complexity back in.

Wrapping Up

If your gameplay is a candy bar, then Comprehension Complexity and Tracking Complexity are the wrapper. Candy bars need wrappers. If they didn’t have them they’d be pretty darn unsanitary. However, you want your wrappers to be light and unobtrusive, ensuring the candy itself is easily accessible. Imagine if they put candy bars in the kind of nigh-indestructible plastic packaging they trap electronics in.

Don’t do that to your game. You’re better than that.

See you next time.