Rules, Mechanisms, Problems and Systems Much of conventional wisdom around videogame design takes a ‘top-down’ approach. The designer first creates a list of thematic requirements for their game, and then attempts to form reasonable mechanics around them. These requirements might contain settings, characters and story events, but will rarely contain concrete rules. This approach has a lot in common with ‘authoring’ a story or a painting. To contrast with this approach, the clockwork (and related) schools of design have provided a bottom-up approach. They argue that a game is built in layers, and the elements of the previous layer can be combined in novel ways to create the next layer. This approach has more in common with engineering than it does authoring. In general, the proposed layers look like this: Rule combine to make mechanisms. Mechanisms combine to make systems. Or, seen in another way, Rules → Mechanisms → Systems. This approach has some clear benefits. By defining systems in terms of more primitive parts, we make it easier to think up and implement changes to some of those parts. You can identify when a part isn’t working, and try to replace it with another part that fits better. One big problem, however, is there’s a pretty large gulf between mechanisms and systems. It’s generally quite easy to combine a small handful of rules into a mechanism, but generally quite unclear how to choose appropriate mechanisms for the system you want to create. Clockwork Game Design proposed the following solution to the problem. First, you pick a goal. Then, you pick a core mechanism that directly interacts with the goal. Finally, you pick some supporting mechanisms that obfuscate how the core mechanism can reach the goal. I’m going to propose another solution - one that is complementary to the clockwork approach. This solution is to add another layer to the hierarchy. I’ve named it problems*. Rules → Mechanisms → Problems → Systems. * since ‘problem’ is already a commonly used English word, it could get confusing later if multiple definitions need to be used near each other. If that happens, we could use ‘problem’ to refer to the colloquial definition, and ‘Problem’ (capitalised) to refer to the prescribed definition. This might actually be a good practice for all our prescribed definitions in cases of confusion. So what’s a ‘problem’? This ‘problems’ layer was inspired by Complexity Theory in computer science, which, in a nutshell, is about finding ways to classify how ‘easy’ or ‘difficult’ different kinds of computing problems are. Here problem essentially means ‘something I want to compute’. I’ll prescribe a more useful meaning later, but let’s run with this for now. The maths behind complexity theory is pretty complicated, but it has proven some rather surprising results that are also quite easy to understand. One such discovery is that certain types of problem that are inherently hard to solve. Not because of some specific limitation of the human brain, but rather because these problems naturally resist solution. In particular, there’s a class called NP that contains some problems that are easy to describe, but very hard to solve. Indeed, the only way to make real headway on an NP problem is to use heuristics to approximate an answer, rather than hoping to calculate an exact solution. One classic example of the NP class is the ‘bin packing problem’. You have a number of bins, and a number of objects. The objects can have varying integer sizes (i.e. size = 1 or 2 or 3…). Each bin also has an integer size, perhaps 10 or 20. You are tasked with packing all the objects into the smallest possible number of bins. A bin can have some excess empty space left over, but you cannot ‘overfill’ a bin by exceeding its capacity. This problem looks deceptively simple. A reasonable person would likely think “yeah, I can do that.” But there is no efficient algorithm (sequence of logical steps) to solve this problem. There is no ‘magic bullet’, so to speak. So as the number of objects and bins rise, you’ll quickly lose all hope of ever reaching the perfect solution. Instead, you’ll opt for a ‘good enough’ solution. This makes it possible for people to continually improve at solving the problem, by forming better and better heuristics, without ever truly solving it. There also likely exists some number of objects and bins that sits right on the edge of human intelligence. A ‘problem size’ that is almost solvable, but not quite. Another interesting discovery is that the bin packing problem is exactly equivalent to a lot of other problems that look, on the surface, very different. There's a wide variety of problems that share this type of difficulty. Let’s put the theory aside now, and try to glean something relevant to game design from it. In summary, there exists many problems that are inherently Easy to understand (Practically) impossible to solve Possible to improve at, through building heuristics Can have their difficulty tuned by increasing or shrinking the problem size This perfectly fits the bill for a contest of decision making. So by ‘problem’, what I mean is a cluster of mechanics that satisfy those bullet points. They create an easy to understand goal that is impossible to actually reach but possible to gradually travel towards. I’m going to be using this definition from here. Can you give me some examples? If you have at least one problem, then you can make a contest of decision making. But like how the most interesting games have multiple overlapping mechanics, the most interesting games will likely have multiple overlapping problems too. After all, the whole purpose of the bottom-up approach is to come up with a shared toolbox we can apply in novel ways. So I’m going to list a few example problems. I came up with these examples by looking at various games and trying to extract common patterns from them. The list is not supposed to be exhaustive. Rather, it’s meant as a starting point. These examples are also not supposed to be the only way of looking at their games. There are probably many different ways to view each of the games used in my examples. This list is meant as a prescriptive tool for new games, rather than a perfect descriptive taxonomy of existing games. Indeed, many of the examples overlap a bit. Finally, I tried to stay away from themed words as much as possible, like ‘map’ or ‘person’, and instead use generic words like ‘graph’ or ‘token’. Navigation You are tasked with finding a good route through a graph. The challenge comes from avoiding hazards or obstacles, and identifying safer paths. This might look like, for example, crossing a world map, escaping from a maze, or sneaking through a gauntlet of security guards. Placement Here you also use a graph, but instead of navigating through it, you place tokens onto it. The challenge comes from picking the best locations to place them. It might look like, for example, placing stones in go to secure territory, or placing towers in a tower defense game to defend your base. Sliding Given a graph with some tokens already placed on it, you must move the tokens into a desired configuration. They generally can’t move through each other, and so the challenge comes from ‘sliding’ all the tokens around or over each other. This might look like, for example, passing a football, or pushing monsters into the water. Cashflow You have a bunch of bars that fill up or deplete. They are connected to each other, so filling one bar might deplete another, and the challenge comes from filling the correct bars. It might look like, for example, growing your economy as fast as possible in Civ, or depleting your opponent’s HP before they deplete yours. Prediction You have to use information from previous decisions to fill in the hidden information of a current decision. The word ‘predict’ is chosen to be distinct from ‘guess’ and ‘decide’. A guess is based on no reliable information at all. A decision provides you with all the relevant information, even though the long-term consequences are not totally clear. A prediction hides some of the relevant information, and so you have to rely on the statistics of previous decisions instead. The challenge comes from accurately making these predictions. This might look like, for example, choosing the right deck in hearthstone, or ‘yomi’ in a fast-paced realtime fighting game. Rationing Here you have a fixed pool of resources, and a series of obstacles. Each resource will typically have multiple effects, allowing it to solve multiple obstacles at once. The challenge comes from squeezing the maximum value out of each resource. You don’t want to waste a resource by using only a portion of its effects. This might look like, for example, choosing the best spell in hearthstone, or crafting the most useful tools in a survival game. Timing You are faced with several rhythmic patterns, and must detect when they are about to overlap. These rhythms can be pretty varied, with differing tempos and patterns. The challenge comes from maneuvering between these overlapping points in real time. This might look like, for example, crossing a room full of Super Mario enemies, or fighting a slow-moving boss in dark souls. Parrying This is when two agents take turns to push and pull on each other, each using a similar toolset. The simplest example would be pong, where you each control an identical paddle which moves vertically to deflect the previous player’s move. More generally, this happens in any reasonably symmetric multiplayer game, and also in singleplayer games with a simulated opponent. This problem is generally applied ‘around’ another problem, and the challenge comes from grappling with another agent that is trying to undo your progress in that sub-problem. It might look like, for example, giving and taking influence in go, or alternatively playing spells in hearthstone. How can they be combined? Lets look at some games that use multiple problems together. Frogger is a simple navigation problem (cross the river), combined with a simple timing problem (traverse between moving logs). But they mesh together quite tightly to make a significantly bigger challenge than either sub-problem alone. You must look at nearby logs to correctly transfer, but must also look at the river as a whole to identify when you should backtrack. The two problems have approximately equal importance. This can lead to paralysis, however, when it isn’t totally clear which problem should take precedence. Sometimes players will panic and make a mad rush for the exit, or get cold feet and try to go back to the last safe location. At least, that was my experience with the game. Hearthstone is a parrying problem, applied around a rationing problem. You need to get more value out of each card, on average, than your opponent does. This is all surrounded again by a prediction problem, where you need to bring the correct deck to the fight. The consequences of bringing the wrong deck are so serious they sometimes render the other two problems irrelevant. The ‘outside’ problem of prediction can throw you into unwinnable ‘inner’ problems, even if you have a generally strong deck. These problems aren’t meshing so well. Auro is primarily a sliding problem, where you need to slide monsters into the water and also slide Auro away from harm. This is supported by a rationing problem of drawing the maximum possible value out of your spells, many of which have a potential payoff ranging from zero to several kills. By having both a ‘core’ problem and a compatible ‘supporting’ problem, the player can address both of them without getting overwhelmed. Civ 5 is mainly a cashflow problem, where you try to optimise the growth of your civilisation in terms of land, tech, finance and culture. But most of your time is spent performing a sliding problem where you push individual soldiers around a large map. The cashflow problem stays pretty much the same size throughout the game - you have maybe 5 relevant options, and you choose the best for your long-term goals. But the sliding problem keeps growing almost indefinitely. It works okay when there’s 2 or 3 soldiers, but once you reach 30 soldiers it becomes a huge slog to push them all across the map. The depth of the problem also collapses as it grows, since the interactions are very flat. In general, the bigger army wins. Civ should shrink the sliding problem’s size drastically, and introduce some good supporting mechanisms for it that increase depth and connect it to the cashflow problem more directly. How many problems do I want? Something worth noting is that chess and go are both parrying problems that use a single subproblem (sliding and placement, respectively) but with a huge problem size. I think this is partly responsible for the ‘analysis paralysis’ these games cause. A single problem with a large problem size leaves you with many possibilities that all look very similar. You don’t have many heuristic footholds, and instead need to ‘math it out’, analysing as many possibilities as possible and as fast as you can. Only after prolonged play do you start to see the heuristics behind good moves. If we instead have multiple smaller problems you can find a good answer for each of them individually without resorting to as much ‘mathing’. But since the problems overlap, you can still have ambiguity. If you had a dozen problems that interrelate, you’d probably reintroduce the analysis paralysis since you can’t really make heads or tails of which problems should be considered first. You’d just have to try a whole bunch of possibilities. So I think there’s a sweet spot of giving the player multiple tasks that Are each small enough that good candidate moves are easy to identify, Yet they combine in interesting and understandable ways. This adds back the ambiguity that was lost when shrinking the problem size of each component problem. I’d speculate that this sweet spot is around 2 or 3 simultaneous problems. Closing thoughts In closing, I’ll present a few questions that can be used as lenses for improving a design. What problems are in my game? Are there too few? Too many? How large are they? Are they too big? Too small? How are they connected? Do they synergise? Do they conflict with each other? Do they connect at all?