Rules, Mechanisms, Problems and Systems

Discussion in 'Game Design' started by Lemon, Nov 9, 2015.

  1. Lemon

    Lemon Well-Known Member

    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:
    1. Rule combine to make mechanisms.
    2. 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
    1. Easy to understand
    2. (Practically) impossible to solve
    3. Possible to improve at, through building heuristics
    4. 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
    1. Are each small enough that good candidate moves are easy to identify,
    2. 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?
     
    Last edited: Nov 9, 2015
    Batlad, cpudreams, Jon Perry and 5 others like this.
  2. Bucky

    Bucky Well-Known Member

    Past discussions here have pointed out that NP is usually reserved for Puzzles, whereas well designed Games are usually PSPACE-hard.
     
    Lemon likes this.
  3. Lemon

    Lemon Well-Known Member

    It would make sense that harder problems are more suitable. My aim was not to suggest a particular complexity class to draw from directly. Rather I'm trying to suggest how we can classify sources of uncertainty, creating a bridge between mechanics and entire systems.

    I think multiple NP problems could maybe do a better job of creating interesting uncertainty than a single PSPACE problem though.
     
    Jon Perry likes this.
  4. keithburgun

    keithburgun Administrator, Lead Designer Staff Member

    I just wanna clarify some stuff about the Clockwork Game Design pattern.

    You don't really "start" with a core mechanism. Sometimes you can do that, but in practice it's very hard to do and in my experience isn't that common. What you really have to generally do is experiment with a bunch of possible core mechanisms or even just loose mechanics in a bit of a soup. You also often have to start with thematic scaffolding to help you start understanding this big soupy goop that you have.

    The point is that during this process, once you have something, as early as possible you want to identify your core mechanism so that you can support it as well as possible. It can be hard to actually *start* with one, though.
     
  5. Lemon

    Lemon Well-Known Member

    This soupy goopy process is the weak point in your design process. You just have to throw stuff at the wall and hope something sticks, which is very similar to how patchwork games are made. The clockwork lens is subtractive like that. It removes things far more easily than it adds them. It turns a bad game into a good game far more readily than it turns 'nothing' into a game.

    This process can be structured much better if you've classified some sources of uncertainty. You can pick a few Problems and fuse them together, creating something you know will contain considerable uncertainty.

    You can then use the clockwork pattern to boil it down and refine it. One of the issues with boiling down games is that they often don't have much left afterwards. Most games have very little substance to distill. But if you've originally constructed you game out of problems you can be confident there's more substance to it.

    It could also be useful later in development. Once a clockwork pattern has settled into something reasonably elegant, it becomes hard to justify adding new mechanics. You'll have found a local minimum, where most mechanics are going to make the game slightly less elegant overall. But if you look at a higher level and say 'can I add a new Problem to this game' (a new source of uncertainty) it could suggest a cluster of mechanics that will work well, when combined.

    Also, while the clockwork pattern works well for games it isn't going to have similar success on toys. Toys need a lot of edges, but also need something to occupy the users mind. Being able to think in terms of adding Problems to the system will help you keep a more 'spread out' system interesting.
     
    Last edited: Nov 10, 2015
    Jon Perry likes this.
  6. Nachtfischer

    Nachtfischer Well-Known Member

    @Lemon: Your problems kind of look similar to cores though. So isn't it still the same issue? You need to come up with a problem from "nothing" just as you'd need to with a core/system.
     
  7. Erenan

    Erenan Well-Known Member

    I think the idea is that for someone who wants to make a game but really has no idea how to proceed, it might be helpful to peruse some examples of known problems and try to think about how to adapt those for use in a game context. Not sure if this is how Lemon meant it, but it's how I understand it.
     
    Lemon likes this.
  8. Elliot George

    Elliot George Well-Known Member

    @Lemon: So would you say that players mentally chunk games into problems? Most of your example seem to indicate that problems are more of a category created by players than implied by the mechanics. This is very similar to how I think about design, kind of like breaking down the experience of playing into it's constituents.
    If that's the case, I don't really disagree with anything you've said here, except that maybe problems are just a different way of thinking about systems, and mechanics don't map neatly to problems, maybe problems are the human response to a group of mechanics?
     
  9. Lemon

    Lemon Well-Known Member

    @Shifty McSly
    I don't think players chunk games into problems. I also think players don't chunk games into mechanics. Rather, they chunk games into heuristics.

    The act of chunking games into mechanics is a tool for the designer. It lets you do thinks like, for example, clockwork game design. Your players don't need to understand how your game is a clockwork system, they just need to be able to discover heuristics.

    Similarly, chunking games into problems is a tool for the designer. It's a higher level tool, using a 'broader brush'. The soupy goopy stage Keith talked about is, I think, a symptom of the huge gap between systems and mechanics. It's very difficult to go from 'I want a contest of decision making' to 'I should have these mechanics' (or even 'I should have this core mechanic').

    But the gap from systems to problems is much smaller. You can say "my game will get its uncertainty from sliding these tokens around, and you have to ration the kinds of 'slide' available to you". From there you can much more easily make the jump to a set of mechanics.

    And it can also work in reverse. You might find that your game just isn't 'working'. The mechanics you chose aren't bringing the depth you want. You you can look up a layer and say 'well, what problems are my game most similar to?' You can then identify mechanics that aren't supporting that problem. It could also suggest new mechanics that will combine well with the existing ones.

    It could also solve some other issues. If your game is causing analysis paralysis, you could try to shrink the primary problem and add a secondary, supporting problem. This can leave you with a smaller number of options that are each more unique.

    @Nachtfischer
    A core will want to be unique to your game. The problems are meant to be patterns found in many games. They are kind of like 'genres', almost. The idea is you can choose a couple of problems you like, and they can then suggest some candidate core mechanics to you.
     
    Jon Perry, alastair and Nachtfischer like this.
  10. Lemon

    Lemon Well-Known Member

    In writing these posts I've found it difficult to avoid confusing 'problem' with 'Problem', so I'm considering renaming 'Problem' to 'Challenge'.
     
  11. ALavaVatChild

    ALavaVatChild Well-Known Member

    Odd, I find 'Problem' a really appropriate word to use. I wonder if that's a regional thing with English.

    This seems like an interesting path to pursue. I was talking to a friend who lectures on game narrative and she has a lecture that sounds similar to this, described it as presenting '17 different types of puzzles' to the students. I'll ask her about it and see if she's talking about the same thing.

    I particularly liked this because it's exactly what Through The Ages does - there's no map at all, military strength is a multidimensional cashflow function of your continuous ability to support population (by producing food) combined with one-time investments in the form of science (developing better tech) and material resources (actually training a new unit).
     
    Lemon and keithburgun like this.

Share This Page