A top-down approach to puzzles in games

Why this topic and this article

Designing problems/puzzles in games is not easy. Seeing how many games get it wrong or simply rehash is puzzling. In particular the contrast in how puzzles in two different games I played made me feel, sparked inquiry (in an upcoming article I will take a deep dive in one of these experiences). Seeing problems/puzzles can be useful for both designers and critics. Designers can more easily implement the right problem/puzzle and critics can point out what is it that makes a problem/puzzle feel ‘off’.


What is a puzzle really? Puzzles are often seen as related to problems. To make a clear distinction I will further define a ‘puzzle’ as a ‘problem’ where there is exactly ONE solution. A ‘problem’ can have no solution, one or many. What is a ‘problem’? A problem is any situation where some needs are to be met or longing to be fulfilled and actions might lead to resolving of the needs. A solution than is a set of actions that lead to the resolving of needs with a high degree of certainty.

This broad definition is best illustrated by a large number of examples:

  • Being hungry and eating something
  • Being a government and trying to improve welfare
  • Driving somewhere
  • Commanding a team of firefighters
  • Making an exam
  • Managing a busy monthly schedule
  • Healing from disease
  • Solving a mathematical question
  • Beating a boss in a game
  • Solving the infamous puzzle from Legend of Zelda, Oracle of Seasons/Ages

In this article we will limit the definition to game design related topics only. That is to say, math problems and game theory (from economics) are relevant and included as well.

In addition, we will be focusing on problems/puzzles that are mainly cognitive in nature. Action plays a secondary role, while thinking problems through a primary one. We will be looking at managing RPG character teams rather than Dark Souls boss strategies. Sim City city planning rather than getting highscores in the average First-Person Shooter game.

Why a top-down approach

Why one would design a game from a top-down approach, or any software project really, is simple: it makes the project more manageable and the end product more cohesive. Top-down design forces developers to think about the end goals first. Do you want to create a scary game? Should the game learn the player something about life? Using what controls? Do we want a cooperative aspect?

The Mechanics-Dynamics-Aesthetics (MDA) framework (wikipedia link)is a simple tool to help the top-down process. This article heavily hinges on this tool. The short of it is that a game consists of layers: Aesthetics, Dynamics and Mechanics. The first layer is a general feeling a player gets of a game. There have been a few select sets analysed in literature, such as Discovery, the feeling of exploring an (abstract) space. Take note here that I don’t see Discovery as a solely spatial thing. Dynamics are the interactions between Mechanics of a game. These taken individually, are not easily visible to players. Mechanics are the (mathematical) rules of the game. What does every button do exactly, how fast does the player go and things of this nature. The Dynamics then are for example how a player character can play ‘fluidly’ because jumps and climbs can be chained together.


Problems are one form of game design that can cause affect (feeling) in the player. In this paragraph we go over a selection of feelings a player can get from problems in a game.

In short, every MDA Aesthetic can be achieved through a problem. For Fellowship, this immediately contains a sidenote, that either multiple players work together on a problem — such as Portal 2 (2011) — or players can meaningfully share discoveries/findings (workings of complex games, Dark Souls secrets, Subnautica (2014) strategies). The next two that are also slightly less about cognitive problems are Fantasy and Narrative. Fantasy is about giving the player the feeling of a believable game world. Problems can be a means to get there by allowing exploration of this world. Vague goals and making the player use cognitive skills in accordance to the logic of the world. Examples of this are sandbox games (Terraria (2011) has a lot of dynamic problems, even if more on the action spectrum). Narrative is closely related: the player wants to see a drama unfold. Problems can tie into a story, think of detective stories for instance. Beyond that, problems can influence the story, as is the case in some WRPGs (Baldur’s Gate (1998), early Fallout (1997), Disco Elysium (2019)). The player can use their cognitive skills to influence the story to where they want it to head.

Expression is already more strongly tied to problems. An easy example is ‘fashion souls’: or the idea of outfitting your player character in SoulsBorne games and many other RPGs. Options is the keyword for Expression affection problems. Sandbox games again, offer a large chunk of expression in being able to tackle problems in your own unique way (Hitman (2016), Factorio (2016/2020), Sim City (1989)).

The other three Aesthetics have even stronger ties to problems.

Challenge: ranging from very tight and complex puzzles to sandboxes

Submission: explored thoroughly already in What Makes a Good Puzzle? and What We Can Learn From A 2000 Year Old Puzzle. Interestingly enough, these are some of the hardest to design well. Making a mobile puzzle game with just the right curve to feel casual is a hard design problem.

Discovery: especially strongly present in survival/roguelike and adventure games. It involves simply guessing, but also resource management and heuristics. Hollow Knight (2017) can be seen in this category.


Now that we have a grasp on how and why problems relate to affect in gaming, we can start refining classes of problems that have specific affects. This is the most important concept of this article: as a game designer being able to implement a fitting implementation for a required Aesthetic. The following list is proposed as all the different feelings for a player through a problem (in a mental problem context):

  • S: player feels smart
  • P: player feels pressure
  • U: player feels stuck or ‘stumped’
  • O: player feels progress through overcoming an obstacle
  • C: player feels mastery in planning/solving, a purely cognitive challenge or conundrum
  • W: player feels connection to the world
  • M: player feels no difference between challenge and presented story; Mirroring story
  • L: player feels lost
  • E: player feels satisfaction through self-Expression (unique/creative solutions or otherwise personalizing)
  • BX: player feels betrayed/angry/frustrated/overwhelmed

These classes both signify a feeling and a type of problem: pressure can hardly be felt in a tutorial puzzle but limited time puzzles make players sweat, feeling lost is not felt on a linear path and so forth. Now let’s discuss every class in more detail.

S class

The S class is about making the player feel smart. This does not need to arise from complex large problems or puzzles. Making a puzzle be in the S class is often one of the most difficult design challenges. The player will feel smart when presented with a problem that they did not have a direct solution for, thinking about it, then being able to execute the solution without further problems. Often, a players history plays a large part in this first step: do they recognize the problem for earlier? A chess master might not feel very smart after beating a few chess puzzles. The second factor to keep in mind is making the problem about the solving step, and thus feeling smart. When the player found a solution but it takes too long to execute (is boring) or is disturbed by random elements such as unpredictable enemy patterns, dice rolls etc., they player will not feel smart.

P class

The P class is about making the player feel pressured. This does not always need to be in a story context, hence why it is its own point. We find applications in thrilling action or horror games or even just boss fights in many games. Out of all classes this one is the least based on pure mental problem solving. Pressure always involves a limited resource, often time. In turn-based management games we however see pressure arising from limited in-game resources and having to balance interests. Problems that can only be attempted a finite amount of times, (in a single playthrough) are a definitive example of P class problems.

P starts out being easy to implement, but hard to refine. Pressuring players too much will cause panic if they are unprepared. P heavily appeals to Challenge and a bit to Narrative/Fantasy as well.

U Class

The U class is about making the player feel stuck or stumped on a problem. These problems are based directly around the players understanding and history: when players do, the problems collapse into an O class (see further).

This appeals to Challenge and Discovery. The Discovery parts comes from when a player thinks “I must have missed something”, prompting exploration.

U classes are rare in isolation: they will often resolve into an S class, through the (U -> lateral step -> O) S solved chain.

Creating a U class problem is about slightly subverting expectations. A classic case is the door/switch/item tucked behind a corner where most players won’t immediately look. In a non-spatial scenario, the player has to take an unconventional action in order to solve the problem.

O Class

The O class is about making the player feel lightly challenged and/or entertained. The problem should be relatively simple, taking into account the players history of learned mechanics. These can often be used to cement new mechanics for players, be a breather between challenging sections and simply pad out game time. The O class appeals to Challenge and Submission (pastime), though it can have its use in Sensation as well. When designing a layered problem, using this class can greatly help in the implementation. As part of a larger U class for example, we often do not want to challenge the player further.

C Class

The C class is about making the player feel mastery. It appeals to Challenge and Submission (pastime). The latter is not surprising when we think about the time it can take to for instance, solve a Sudoku puzzle. C class is about mental prowess and that often takes time, in the forming of planning and structuring, alternated with brainstorm phases. Completing a C class can be sometimes broken down in a chain of S class puzzles.

Speedrunning can be a form of a C class puzzle. The planning phase and diving deep into the mechanics of a game, to arrive at an optimal route, is a complex cognitive task. We see this class arise in sandbox games or (city)builder type games.

What is to be carefully considered in a C class problem is randomness or unknown variables. While (real-time) strategy games sometimes show that the unknown increases the mastery factor, too much randomness will make players turn away from planning ahead. C class problems are easiest to make in a fully explained and deterministic (non-random) game world.

W class

The W class is about making the player feel connected to the world. This is a broad class that is more of a label than directly implementable. It appeals to Fantasy. They might also appeal to Sensation as a bonus. Memorable visuals and audio can immerse a player further. To design W class puzzles it is most productive to leave randomness out and introduce exploration. That is to say, that the world ought to behave consistently, even if the player does not know this behaviour yet. The player will have to make (educated) guesses. When players explore a world themselves, making choices, the connection is stronger than without.

M class

The M class is about making the player feel connected to the narrative. M, obviously then, appeals to Narrative.

An obvious example is games with multiple endings, where all the choices combine form an M class problem: the one where the player wants to see the narrative end a certain way and has to think how to get there. M class problems can also mirror story events. In recent years this has been discussed a lot in game design theory, where gameplay should match the story mood and theme. Classic examples are survival games, detective and point-and-click games. As with the W class, the M class is more a broad label then a specific implementation. Mainly important is the idea of rewards and penalties. M class problems can be ones that cannot be redone (in a single playthrough). Failing to solve a problem or solve it not optimally, should result in ‘penalties’ in the story. Accordingly, succeeding in an M class puzzles/problems should be a ‘reward’ in the story.

L class

The L class is about making the player feel lost. This is different from the U class in a few key ways. The appeal is the same however: Discovery and Challenge. Unlike U, L is about either an unclear goal or fuzzy solution. L class is heavily based in spatial problems, such as mazes. While an easy implementation, designers can also think of sandbox settings with (initially) unclear goals. We can also think of an escape room scenario (so not a spatial problem but one of interactions), where the goal is clear (get out of place x), but the means are not clear. Players will have to try actions and discover a solution.

E class

The E class is about making the player feel special. Rather, they make themselves feel special, but the problem facilitates this, by providing meaningfully distinct solutions and approaches. This idea has been well known in game design theory. Even game reviewers sometimes analyse the meaning of choices, though more often in a narrative context. This class on its own appeals to Expression. Submission can be arrived at as well through for instance ‘fashion souls’. Sensation can be incorporated in these problems, see the Animal Crossing series with their pleasing visuals. Lastly in a multiplayer setting, players may feel the urge to diversify and feel unique, thus creating opportunities for E class problems to be implemented.

E class problems are related to C class problems; both classes often have many solutions within a given problem. Unlike the C class, E does not require a determined environment. Of the latter we find examples of how random loot in games can cause more engagement and planning how to trade up to desired items. The Hitman games and other games like it form the perfect example for the E class: open problems with a clear goal where players can find their own style and even be deliberately unique. The idea of the Rube Goldberg machine also exactly fits this class.

BX class

BX, is often what designers do NOT want to hand to the player. However, it can be useful. Especially horror games or dramatic story moments can apply these kinds of puzzles to strengthen the Aesthetic. The X is there just to signal that this is a special design, not to be used in large quantities. Indeed, when we start to analyse ‘bad’ puzzles or puzzle games, we will find this design implemented (whether this was conscious or not). Often we see a betrayal (hence the B) of player expectations.

The difference with U must be clarified: the U class often keeps mechanics intact or introduces a new one. For BX, the rules are either bent or they were so complex to begin with that the resulting problems are either extremely difficult or impossible.

Example usage

You as a developer, want to design a platformer game. The games has worlds and one of them has a theme where puzzles would fit. Maybe cyberspace? Or a dungeon rigged with traps?

Let’s further assume its not a casual platformer, but something the player can seek their teeth into. We can sprinkle some optional collectables in as well.

What Aesthetics are these? Fantasy, Challenge, Discovery.

We decide not to use the L class of puzzles, since we want the player to focus on the shorter challenges, not navigating the world. U seems like an amazing fit however. Especially for the collectibles this can be a good design: player spots the collectible and does not immediately know how to get it within the problem context. We want to appeal to Fantasy as well, which can be translated as implementing the overall puzzles using W. The player can use the moves from previous worlds to interact with the puzzles. Perhaps punching switches or jumping. We might lend some other ideas, such as switching platform/ground states on every jump. Another heuristics approach is turning the traps/problems against themselves: triggering some kind of hammer trap but dodging and letting it break the wall to progress. Lastly some S or O problem design can be useful. O as the underlying implementation of W. When the player found out how the world works, the mechanics can be expanded and turned into smart obstacles. A naïve example for an extra collectible: player sees collectible behind a close gate with some robot enemies nearby. The player already learned that gates can be switched on or off. Removing the gate however, bars the collectible with lasers… the player also knows that robots block those and can now combine this knowledge to solve this problem.

Furthermore, depending on the direction, it might be decided to make a world based around a C class problem. The player has to activate switches and conditions before traversing it proper. This distinction can help in implementing the puzzles concerning complexity.


When designing a game top-down we might wonder why and how to implement problems/puzzles. Using MDA-framework as a basis we have analysed ‘classes’ of problems/puzzles that make the player feel a certain way and also shape the problem/puzzle to be implemented. These classes can be mapped onto the Aesthetics of MDA and vice versa. Every class is discussed in detail. For example the U class: it appeals to Challenge and Discovery. Problems in this class are biased to guessing and have to take into account player history. Alternatively, problems with a lot of solutions can be in U.

We specifically addressed the BX class as a special design for problems, to be used for drama and sparingly. BX has many implementations ranging from impossible puzzles to simply subverting the mechanics known to the player.

Lastly we discussed an example imaginary game where the problem/puzzle classes were used to push puzzle design in the right direction.

Thank you for reading.

Student Software Engineer, interests in Lifestyle, Psychology, Games and dreams