I claim that these two failures are also categorically different. In both cases, I find my demise at the end of the spikes. In the GIF on the left, I fail at executing the correct sequence of actions that would give me the outcome I had planned — getting the strawberry. In the GIF on the right, I press the buttons correctly, but doing so does not lead me to the result I intended — reaching the wall across the gap. The former is an instance of failure in execution; the latter is a failure in planning.

Why is a taxonomy of failure useful?

If we have a vocabulary that allows us to describe how we as game designers are making our players fail, we can investigate whether these failure instances match our design intent. This specificity gives us the ability to separate expected failures from failures to be avoided. This separation can further allow us to intervene when we think the player is failing in a non-desirable way, such as not knowing the elementary controls. With the taxonomy I am constructing, we can designate the type of challenge we want our game to pose and use it to ensure our players are not failing for reasons that are outside the core promise of our game.

For example in a competitive board game like Chess, as designers we expect most of the exciting challenge of the game to revolve around failure to form effective plans (and counter plans or counter-counter plans) rather than worrying about players not knowing how pieces can move or how to physically move a piece without dropping it. If a player failed because they didn’t plan correctly, that matches our designerly intent, however, if the player is failing at moving the chess pieces around we better design better pieces!

In the high pace platformer Super Meat Boy, you have a game that is about mastering movement in a spiky and dangerous world. If you fail at making that quadruple wall jump, that’s okay! However, if the player is struggling because they don’t know the affordances of the game, for example, that you can wall jump, that’s a problem. On the other hand, if you are playing the methodical puzzle game Baba Is You and you are struggling to move the character where you want it to, that’s an issue. Discovering what you can do with the game systems by repeatedly failing, on the other hand, is a big part of the fun! Whether a class of failure is good or bad mainly depends on your designer intent and the promises your game makes, but failures in some classes tend to be almost always undesired (e.g., failures caused by accessibility issues).

The taxonomy of failure emerged from me observing how players played games and understanding the possible areas where failure can occur. Let’s consider one possible breakdown of the steps necessary for playing a game:

On the most fundamental level, the player needs to know what actions allow them to communicate with the system (such as pressing buttons and making gestures on a touch screen). They must also be able to parse the response given by the game. If the player doesn’t know which buttons are active or can’t read the text in a text adventure, they can’t even engage with the system.

With the basics out of the way, the player has to start building a conceptual model of the game. A part of this model is understanding the rules that govern this system. Another part is learning the goals of the game, as well as the information necessary to be successful. Of course, this model is built through play, including inference from past play experiences for other games. The player makes a plan such as “I want to jump over that platform” and then attempts to execute it. Depending on the result, the player updates their model.

The classes in the Taxonomy of Failure

Using this simplified model of play loosely, I propose six categories of potential failure. Let’s look at each one to understand what they represent.

The six categories of failure.

Each of these cells represents a Class of Failure: a category where the player can fail.

Encoding Input refers to the player’s knowledge of the elementary controls and the physical capability of using them. Can the player on the most fundamental level even interact with the system? Is the player aware of the correct buttons to press, gestures to make, or in general, actions to take? Furthermore, is the player physically capable of taking the actions the game asks them to take?

Example Failure Instances in the Encoding Input class:

Not being able to play a student game because the game does not state what its new innovative control scheme is (No, I am not salty.) The failure to use a UI element due to a physical limitation

Decoding Output refers to the player’s ability to parse the raw information presented by the game. Can the player understand and absorb the content the game is delivering? Is the text too small to read? Can the player understand the language?

Example Failure Instances in the Decoding Output class:

Encoding Input and Decoding Output groups cover the fundamental requirements for any player to give input to the system and receive clear feedback as an output. Various accessibility issues fall under these two classes.

Affordances refer to the player’s understanding of the game’s mechanics and the space of actions. In other terms, does the player know capabilities of the tools they are given? In certain games, exploring this space of actions is the joy; in others, the tools of the game are supposed to be clear, and the players’ task at hand is mastering the usage of these functions.

Example Failure Instances in the Affordances Class:

Not figuring out that bombs can break cracked walls in Zelda Getting electrocuted in Prey because the player does not realize they can patch up electrical outlets using the foam gun

Knowledge refers to failures arising from a lack of information to make effective progress in the game. While the affordances class is concerned with the mastery over the game mechanics, knowledge class refers to information that allows the player to figure out what to do next and how to do it effectively.

Example Failure Instances in the Knowledge Class:

Unmade progress because the player does not know what their objective is The player losing all their mechanical units in Starcraft because they didn’t know that the Stalkers unit can inflict extra damage to armored targets The player giving up in Zelda due to missing the NPC that shares where to go next

Affordances and Knowledge together take the form of a conceptual model that the player uses to play the game. This model is built through both by engaging with the system at hand, and also drawing from the player’s past experiences relating to games and otherwise.

Planning is the player using their model of the game to decide what they will do next. A plan might just span the next few actions if the game is a twitchy reflex game, or a plan might be an elaborate battle strategy in a complex turn-based 4X game. Failures that fall into this class include the failures that arise from making a bad plan and the failures at simply making a plan.

Example Failure Instances in Planning Class:

Not being able to construct the correct sequences of moves to win at chess. Picking the wrong platforms to jump on and getting stuck in an unfair platformer. Me giving up playing the overwhelming grand strategy game Crusader Kings II because of the difficulty of deciding what to do next.

Execution is the ability to implement the plan formed by the player. There is a failure in this class whenever a player flops at doing something they had planned.

Example Failure Instances in the Execution Class:

Falling down a pit in Mario after trying to jump over it. Knocking down a piece while trying to move a knight from one square to another while playing chess Losing marines to enemy banelings because of a failed split while playing Starcraft

The Taxonomy in Action

Let us now apply the taxonomy I have constructed to Baba Is You and Super Meat Boy as a short comparative case study.