A Complex Conundrum

Welcome back to our little slice of the Internet. By now, we’ve covered the bare basics of what design is, the core things you need to start working on a game, and which issues you should try to avoid during the process.

Now I want to tackle a subject that is useful to both beginners and more experienced designers in general: A classification of the different types of complexity that exist with regards to game mechanics.

Note that this isn’t the only possible classification, it’s just my interpretation of things based on my experience with the matter, since classifications like this tend to be arbitrary.

Without further ado, let’s get to it, in no particular order:

Tracking Complexity

The complexity of tracking the state of the game or individual parts of it, and tracking any changes to that state. Also affected by how often that state changes, and what the players need to do to update it.

---

This is one that I personally put on a bit of a pedestal. Tracking complexity was the first important hurdle I faced when starting to expand on my concepts. This is something that, at least in my opinion, can be a real game-killer, and that’s why I made up this simple-but-effective reminder for it:

Each second spent tracking is a second spent not playing.

Remember this one. Tracking turns tedious very quickly, and can usually point to more core problems in the design. If you have too many moving parts, it may turn out that some of those are redundant and can be streamlined or removed, decreasing the complexity that way.

Do note that complexity isn’t necessarily bad, and even extremely complex games can be very well designed, and more importantly, very fun. However, try keeping things simple where possible and make full use of the mechanics you have already implemented. Before adding a new thing to track, try seeing if you can reuse some existing mechanic/component for that purpose, or if it’s unavoidable, try keeping it the simplest it can be. Here, simple means minimizing the overhead that the tracking creates for the players. Don’t let the tracking take over most of the gameplay.

Tracking complexity is also a pretty subjective thing, and no single empirical metric exists for it. Different people have different tolerances for it, and ideally you want to handle and tweak this within the context of the specific game you’re making.

Memory Complexity

The complexity/overhead that exists due to players having to keep part or all of the game state in memory, and how that overhead changes over the course of the game.

---

Memory complexity is more or less a subtype of tracking complexity, but it has some specifics that warrant a bit of standalone commentary.

Memory complexity is everything that you need to set aside for the moment, and come back to it at some other point in the game. Things like delayed triggers or edge cases that are common enough that you have to remember them, but rare enough that you probably forget them by the next occurrence.

Memory issues are a lot worse than tracking issues, since memory is a lot more fragile when it comes to tracking the state of a game. The last thing you want is to have some mechanic that causes players to freeze in place and need to roll back the current turn because a key step is hard to remember/easy to forget. Delayed effects are even worse here, since more often than not, the game can still go on even with a missed trigger, albeit with a ‘wrong’ game state, and players will feel really bad if and when they realize that they made a tracking mistake a few turns back.

The solution for this is to make anything you need to track very explicit and very obvious, i.e. make the required steps and decisions during gameplay near impossible to forget.

Decision Complexity

The complexity that dictates how difficult it is for players to make a decision in gameplay, or how long the process of making that decision would be.

---

There’s a neat term that’s used to describe scenarios where too much decision complexity takes its toll: Analysis Paralysis (AP). This isn’t specific to games, but it’s something that can appear very often during them. AP can outright kill the flow of gameplay in an otherwise good game, and for many players that might be enough to ruin their opinion of it, even though they like the other aspects.

Decision complexity is a byproduct of the game’s interactions and rules—more specifically, how clear and intuitive those interactions are. The two previous types of complexity contribute to this one, though it’s possible for high decision complexity to arise from other factors. The goal isn’t to force players to push through the complexity in order to get some enjoyment from the game, it’s to prevent those issues from ever occurring.

A reasonable strategy for combating high decision complexity/AP is imposing limits on the decision space. Now, to do this without taking away from the gameplay itself is definitely not an easy thing to do, however it’s often simpler than it seems. Keeping the individual actions and results of those actions simple and straightforward can really help keep things in check. The main thing to take care of is that specific actions should be as focused and predictable as possible; don’t let a single move cascade into multiple different results unless it’s necessary*. Players would need to take into account all outcomes when planning a move like that, and the more overhead you create that way, the easier it is for players to fall into analysis paralysis.

*Situations where it’s necessary include pretty much all combos in games, however these are a bit of an exception, since the players themselves usually build the combos and therefore know what outcomes are possible. This is in contrast to situations where the core game mechanics create domino-effect situations too often, which is the thing that leads to high decision complexity.

To be clear, there’s a big difference between the game requiring the players to carefully think about their moves and the game confusing players with the volume or difficulty of decisions possible. To mirror what I said in the tracking complexity paragraph:

Each second spent in AP is a second spent not playing.

Rules/Parsing Complexity

The complexity of first clearly reading – and then understanding – the core rules of a game or the contents of game objects like cards, effects, objectives etc.

---

Some would argue that the first ‘point of failure’ for your game is the rulebook itself. I tend to agree. I’ve been reluctant to learn about a game more than once because the rulebook didn’t present things clearly. This gets even worse if the rules are fine, but then the components are hard to wrap your head around, especially in card games.

While the way the text itself is written is very important, a lot more things go into parsing than just that. Taking card games as an example, there is so much to talk about regarding proper representation of info on card templates that I’ll definitely do more than one article on that in the future. Everything from the text, to the symbols (if any), to how the info is laid out, how it’s prioritized… the list goes on. There are a million resources online regarding writing rulebooks/guides, proper UI design and the like, but like with most of game design, you have to make the mistakes in order to stop making them.

If someone who doesn’t really play board games can pick up your game, read the rulebook and play without (m)any hiccups and especially without your intervention, chances are that you made things reasonably understandable. If, on the other hand, players keep getting confused about some counterintuitive rule even on their third or fourth play, you have to start making changes.

The best way to reduce this type of complexity is to avoid it in the first place. Here, the iterative approach to getting feedback works really well. Make a first draft, get feedback on it. Refine according to that feedback. Rinse and repeat, and move in the direction that streamlines things. While not a scientific metric by any means, try keeping the number of WTFs per minute when players are reading your game as low as you can.

---

That seems to be about it as far as categorizing complexity is concerned. While one can technically come up with more categories, these are the ones I considered general enough to be able to be applied to any game. In future articles, I will almost certainly use the things mentioned here when discussing specific games or concepts that affect complexity in some way, so it’s nice to have a quick reference like this.

For the next article, I think I’ll tackle something I’ve been meaning to write about from the start, but needed to set up the context for it first: my MOPED design principles. I’ll probably throw in a Sidequest describing my current projects, too.

Until then, here’s the obligatory tunes:

This is InvertedVertex, signing off.