On Simplicity

Words: 3770 Approximate Reading Time: 25-30 minutes

Video games have become increasingly complex over time. By this “complexity” I mean not simply that they’ve gotten longer, or bigger. Rather, I mean that the very mechanisms for playing the game have gotten more complex. Including systems that only work in particular contexts, or a wider variety of ways to traverse the world or engage in combat, are what I refer to by this complexity.

This complexity is most prevalent in bigger games, which often have large development teams. And it is very common to see increased complexity in games that are sequels within an ongoing series. Often smaller, indie titles are more likely to be fairly simple.

In this essay I want to offer a defense of keeping things simple. The argument I want to make is that simplicity is a kind of virtue in game design that should be embraced as much as possible. There are, of course, going to be pressures for making a game more complex, and so avoiding complexity entirely is going to be impossible (especially since “complex” is going to be a somewhat relative term). Nevertheless, I wish to offer here that it is still important to step back and think carefully about the necessity of various game mechanics and their ultimate contribution to the gameplay. Finding and removing unnecessary mechanics is an important part of the process of making games simpler.

I’ll begin by laying out why games being overly complex can be a problem, and then proceed to explain why games can end up being too complex. I’ll then finish by laying out some basic principles for stepping back and thinking about how to avoid complexity. The rules I offer here will necessarily be imperfect, but my hope is that they can be helpful for thinking about how game mechanics fit within the larger structure of the game itself.

Unnecessary Complexity

Games can be complex in a variety of different ways. But the easiest way to think about this complexity is by asking two major questions.

Firstly, there are a variety of basic actions that player can perform to interact with the world. Movement is one. Another is combat. You can also think of things like picking up items, opening doors or chests, talking to characters, and so on.

So with these basic actions, how many different ways can the player engage in this interaction? Take movement. How many different ways are there for a player to move around the world? You might start with walking, which might then have an option for running. Maybe the game also has some form of transportation, such as a horse or a car. Maybe there are even more methods on top of these.

The question in this case is “how easy is it to understand how these different methods work?” Each mode of transportation will have its own rules: how do you move forward; how do you turn; can you attack while using it (and if so, how does attacking work? is attacking different depending on how you’re moving around?); can you interact with the rest of the world (such as picking up items or engaging in dialogue), and do those systems change depending on how you’re moving around the world? These questions are all important.

Simplicity does not simply mean that there is only a single method for moving around. A simple game can still have multiple modes of transportation. But these different modes need to not simply make sense, but feel intuitive with respect to their control schemes.

Imagine, for example, that when walking around, you had one control scheme: you move the left control stick to move around, and the right stick to turn (assuming, for the sake of argument, a first-person perspective).

Now further imagine that when you get into a car, the control scheme changes: to move forward you have to press a face button, and to turn you have to press a trigger button.

The control schemes might be workable. You can even get used to them. But these kinds of changes would be unnecessarily complex: it’s making the player engage in a degree of learning that shouldn’t be required, as you should be able to set up the driving mechanics so that there is more overlap with walking around.

Obviously control schemes don’t change this radically. But the basic idea is important to keep in mind. The more a player is forced to alter how they think about what buttons to press depending on how they’re getting around, the more the game is getting complex, and needlessly complex at that. You want more overlap, because more overlap means that the player is thinking about what they’re going to do, rather than how they’re going to do it.

If this first problem is about complexity across different components, the second problem is about complexity within a single component. That is, we can pose the question “how many different things you can do just to accomplish a specific task?” And those tasks can be as simple as “getting from Point A to Point B” or “attacking the enemy.”

It’s most common to see this second kind of complexity in combat systems. There are a lot of elements that are shared across games: light/quick attack; heavy/strong attack; block; dodge. There’s some basic stuff that’s common and gets incorporated into many games nowadays.

But often games add on these basic elements. Maybe there are special stances that the player can switch between, or the player can switch the weapons they use mid-battle, which are then useful in different circumstances or against particular enemies. Maybe there are side weapons that can be used in general, or to counter specific attacks from enemies.

Adding this stuff in, though, can lead to three new issues. I’ll cover them in the order of their importance. At the lowest end is that some of the additional stuff can feel useless. Every component in a game is added to solve a problem. But the utility of a given component is going to depend on A) how often the problem comes up, and B) the need for that particular component in solving the problem. But if a particular component, say a side weapon, is only useful in a very rare set of circumstances, and especially if the problem can be solved some other way (such as through normal combat), then that component can feel useless.

I think a good example of this is smoke bombs. I’ll note that smoke bombs are not useless in every game. But in games that have some kind of stealth component, they’re often thrown in. And it makes sense: smoke bombs are designed to make stealth more viable, specifically by allowing players to evade detection and enter back into stealth. But in many games that have stealth as a secondary element to its gameplay, smoke bombs essentially play little role: you can very easily get through the game without ever using them. If, for example, you can more easily shoot an enemy to kill them – as opposed to using a smoke bomb, evading detection, and then stealthing around to kill them or move forward – then what point does the smoke bomb really serve? At best it serves a purpose in a very narrow circumstance where the player is actively trying to get through the game as stealthily as possible while killing as few enemies as possible, but for normal gameplay the component is effectively useless.

The second issue is that adding so many components can make combat feel dull. Often in order to solve the problem of futility created by the first problem, or as a way of helping the components make sense, they become effectively mandatory. The result is that those components essentially make combat a square-block-in-square-hole puzzle. Rather than having to effectively react to things, or planning out attacks, or some other method of getting through, the player can see an enemy and know that if they do X, then the enemy will shortly be dead.

The contextual idea of “this stance or weapon is effective against this type of enemy” is an example of this problem. A recent example that comes to mind is Ghost of Tsushima, where after a certain amount of time working on your character, the game has a stance system where each stance is useful against a particular enemy. If an enemy just has a sword, use X stance. If they have a shield, use Y stance. If they’re using a spear, use Z stance. So combat boils down to “you’re fighting this type of enemy, so switch to the appropriate stance, kill them, and then move on to the next enemy and change stance as appropriate.” But that just turns combat into a kind of rock-paper-scissors where you always get to win. Fighting normal enemies thus feels dull after a while, because combat is essentially a solved problem.

The third, final, and most important issue is that having more and more systems means more and more unique inputs. Because you can’t keep using the same button for different attacks. So the player needs to remember what each button does. So far, this is normal. But as more components are added, the context for when each component is needed becomes more convoluted. The result is that the various inputs can easily be confused with one another.

This confusion can pose a special problem if the game relies on reacting to different enemy attacks. So if you are given information (an enemy is attacking), you then need to figure out how to react. But part of that reaction time shouldn’t be taken up by “okay, so I need to respond this way, but which shoulder button will pull up that menu so I can activate that response?” Because in some cases that extra step (trying to recall which button you need to press) can be the difference between responding correctly and getting hit. I don’t offer this confusion as “this can be a problem if you’re just starting to learn the controls.” I mean that this confusion can exist even if you know what you’re trying to do and have spent tens of hours with the game already.

So these are the ways in which games can end up being too complex, and why that complexity can pose a problem for players.

Why Make Things Complicated?

If these are the problems, then why would these complicated mechanics get added in? Surely designers aren’t intentionally trying to confuse players or add in systems that make the game dull, right? Yet these results would seem completely at odds with those intentions.

We can reduce the primary causes of this complexity to three issues.

The first is the attempt to make the game unique. Given that there are so many games that are going to share in basic mechanisms (think back to “light attack, strong attack, block, dodge” from earlier), a designer is going to want to add something on top of that to help set their game apart. If a game feels generic, after all, then it doesn’t necessarily matter how much work was put into the rest of it.

Of course, one way to make a game unique is by having a different take on the basic system. So altering how the player fights or moves around, for example, might be distinct on its own. This doesn’t necessarily prevent the game from becoming too complex, but it does prevent one of the pitfalls for overly complicated systems. But coming up with genuinely unique mechanics is tough, and so the easier way to carve out a space is through this addition.

The second cause is time. Games generally take a long time to make, and the long development period tends to favor throwing stuff in. Obviously there is a continual process of coming up with ideas, trying them out, rejecting some and keeping others, and then trying to see what ultimately works. But even when this process is going on, it’s much easier to keep things in that work “okay” and end up making the game complicated without directly harming the overall experience. Because the tendency is going to be looking for things that don’t work, rather than things that work, but might not be absolutely necessary. Only if there’s a straw that breaks the camel’s back, and things get so out of hand that it’s easy for everyone to notice, will there be a requirement to really start from scratch. But as long as certain mechanics can get in under this radar, then they’ll generally survive the process.

The third cause is the size of a development team. By this I don’t mean that it is only when there is a team of people that you’ll get games that are overly complex. It’s possible for a team to make a game that feels simple in a good way, and it’s possible for a game developed by a single person to be unnecessarily complicated. But the likelihood of excessive complexity gets larger as you have a larger team.

The premise is that teams are composed of people with different ideas to contribute. And since it’s hard for a single vision to be shared among a group of people (hell, it can sometimes be tough for a single vision to be shared among a single person), the ideas won’t always mesh well. Call it a problem of having too many cooks in the kitchen: the more different ideas, the more likely the final product will end up spoiled. Not, of course, because any individual contributor is inept, or because any given idea is bad on its own. But sometimes the different ingredients simply don’t work together. In this case, with so many people presenting their ideas for what they think should be in the game, it can be difficult to remove things that lead to too much complexity, unless as I pointed out before, these mechanisms are causing actual problems.

So much as developers attempt to avoid complexity, there are quite a few pressures that lead to games being too complex. And getting around these pressures is tough, perhaps even impossible.

Getting Back to Basics

So how would we go about trying to avoid making games too complex? Is there some way of identifying the point at which something is too complex? Unfortunately, it’s not quite that easy. Complexity is more of a scale than a mere category, so there are shades of complexity, and identifying when there’s too much is going to be tough.

It’s also hard because games will often need some amount of complexity, for some of the reasons I’ve described above. So it’s not as simple as just trying to avoid making games complex. There are, of course, games where very simple systems would work best, and when a game can bear that simplicity it should be embraced entirely. But the key here is figuring out how to avoid having too much complexity.

However, I think there are a few ideas that can be helpful for trying to root out systems that are making things too complicated.

The first useful rule comes from the world of writing: “kill your darlings.” This is more of a mindset, but the basic idea is still important. The premise behind this rule is that whenever we come up with ideas, we have an attachment to those ideas because they are ours. There’s a value to something you can point to and take direct credit for. And that value can make us blind to the problems that our idea might be causing. Just as important is that it makes it tough for us to see the idea objectively: it always makes sense to us why the idea is important (because we can see how everything fits together and how cool the idea will be when it is properly implemented), but that doesn’t always work the same for others.

So it’s important for everyone to be ready to step back and consider any ideas proposed not through the lens of “this is mine,” but through the lens of “is this good for the game?” I feel like this rule is most important as you start going up the chain of management. On the one hand, because many of the stories you hear about mechanics being shoehorned in tend to point the finger at the top. On the other hand, because the structures of management can make disagreeing with those at the top much harder, even if their idea isn’t that good. If there’s a genuine problem, they might be convinced to abandon the idea, but when it’s something that’s merely creating a little bit of confusion or making things too complicated? That makes the job tougher. Not that every example of needless complexity is the result of some inept director. Just that they add an additional pressure that can get in the way of simplicity.

The second rule is to be always asking “why is this here?” Every mechanic should serve some kind of function. Sometimes the function may be purely for entertainment or immersion, such as the ability to stop and play an instrument or do a little dance. But it’s still important to feel like there’s a purpose behind everything. And not simply a purpose that makes sense from an internal perspective, but from an external perspective.

Which means to help with this question, we need two further questions: “what problem is this mechanic solving?”, and “can the problem be solved some other way?” When we’re talking about adding in things to combat, or extra minigames, or more modes of travel, we want to be asking if there’s an existing problem that the new mechanic is going to help with. If no, then we’ve got a good clue that the system might be superfluous. But sometimes it is solving a problem, which brings us to the latter query. Is there another way to solve the same problem within the existing systems? What’s the relative value of this new system compared to the older ones? Because if you can just as easily – or worse, more easily – solve your problems by just using the “normal” response, then anything added on top is going to end up being ignored.

The third rule is to ask “how many steps are needed to accomplish an action?” Note that I am here referring to very basic actions, such as movement or attacking. But let’s say you want to move somewhere. You’ve picked a spot, and so you move the control stick to commence movement. So that’s a single step (maybe two, if you then have to press a sprint button).

By comparison, imagine needing to switch combat styles. So you say to yourself “I want to attack this enemy,” but first you might need to target the enemy, then press a button to pull up the styles, then press a button to select the style, and then press the attack button. So call that four steps. For a basic function of attacking. Comparatively, simpler games would have one or two steps: just press a button, or press a button to target and then press a button to attack (or if you prefer shooters, press a button to shoot, or press one button to aim and then a button to shoot). So if we’re roughly doubling the number of steps to get to our goal – especially if that goal is something is something as common as “attacking an enemy” – then we’re potentially looking at something that’s too complex.

Finally, we should be asking “how likely is a player to get confused or make a mistake?” Since adding systems can require making use of inputs, we need to ask how likely a player is to screw up an input. And if they do screw up, will that cause a massive problem? How important is it that they get the inputs right within a short timeframe? You can think of games that rely heavily on reaction, such as the Dark Souls series and the like, but the number of possible inputs to react to situations is fairly low, and there’s little likelihood of confusing one input with another.

But what if you have a single input perform multiple commands, depending on the context? For instance, a button might be used for picking up items, or could be used to enter cover or cling to a wall. So what’s the likelihood that those two commands might be mixed up not simply by the player, but by the game? You’re trying to pick up some ammunition, and you end up entering cover in an empty house. These kinds of issues are important to avoid, and even among really good developers these problems can still come up from time to time.

Or imagine that holding the shoulder buttons will pull up some radial menus to select something (an attack, or a style change, or weapons). How likely is a player to simply get those mixed up, and if they do mix them up, how much of a problem could that cause? Could a player accidentally switch out weapons and make themselves vulnerable when they simply wanted to, say, select a healing spell, simply because they hit the wrong shoulder button? These kinds of questions, asking essentially how players could get inputs confused, and then asking how to prevent that confusion, is important. Because some mistakes can be chalked up to mere human error, but there is a point where these mistakes are a problem of design.

Concluding Remarks

I started out this essay with the idea that we should embrace simplicity. And I still hold to that claim. We should be looking at games in terms of how complex they are, and to what degree that complexity is necessary. Could the game be made simpler? If it has a lot of systems, how much does each system contribute to the overall experience? What is the problem being solved?

But “simplicity” is tougher than just trying to have as few mechanics as possible. The virtue of simplicity is about trying to make the game as simple as possible given the inherent complexity of the underlying game itself. Which means some games have to be more complex than others. So we aren’t trying to figure out if one game is more complex than another, but how complex a game is compared to how complex it should be. It is not about comparison (unless that comparison might give us insight into how complex a game ought to be), but about measuring a game against itself.