Depth in games is very much a thing in which I am interested. I like games in which I can lose myself, and I like feeling that there is an opportunity for genuine mastery to be built within a set of rules. It sometimes confuses people then that I am so dismissive of complex game systems. So today I am going to write up part three of this occasional series of Epitaph’s Immutable Rules, and the rule is this: Have simple systems, but complex consequences.

Complex game systems are (in my view) those in which there are too many steps required to accomplish a goal, and one (or more) of those steps is so shrouded in external factors that you cannot *quickly* extrapolate a likely outcome from your available data. At the end of the scale farthest away from complex, we might have something like a D&D ‘difficulty check’, whereby you are given a number (let’s say 10) and a twenty sided dice to roll. You know what the likely outcome is (50/50 chance you’ll accomplish what it is you’re trying to do – we want to roll over the difficulty check) and it doesn’t take more than a trivial understanding of arithmetic to arrive at that understanding. It is, however, a tremendously inexpressive system because it doesn’t take into account context. It is then, *too* simple.

We move a little bit farther up the complexity scale when we add in ‘modifiers’. Calculating modifiers is an additional step before we roll the dice, and it will influence the likely outcome of your action. Modifiers are generally expressed as a plus (which makes things easier) or a minus (which makes things harder), and are applied to the dice roll. Given the job of climbing a rope (a difficulty check of 5), you might modify the roll for being in the rain (-5 modifier) and for the player carrying a full pack (-5 modifier). Now it gets a little bit trickier to work out the likely outcome. It’s still relatively simple – your target is 5, and you are going to roll a twenty sided dice and subtract ten from the result. That means that you need to roll at least a fifteen to pass the check. There’s a 25% chance you’ll pass that check. Again, straightforward and something you can pretty much intuitively tell ‘at a glance’.

You build complexity into game systems each time you add a step or increase the amount of calculation that goes on at a particular single step. You also increase the complexity each time you have the factors from an earlier step feed into future steps. Each time, you are making it more difficult for people to judge the consequences of their actions because they need to spend more mental energy computing things, and remembering all of the things that should go into those computations. Even in the relatively streamlined fourth edition of D&D you can end up with mind-bogglingly complex situations such as ‘Okay, you need to roll a 10 to hit that target with your bow, but you’re at +2 because you moved to there and got combat advantage, but they get a +2 because they are prone. First though you have to roll against your periodic damage and use your free shift given to you by the use of the daily power John used at the start of the encounter, and then…’. The more complex the situation is, the more chance things get forgotten, ‘forgotten'[1], or approximated[2]. When working with a human doing the calculations (as in a role playing game), this all has a real impact on game balance and if it gets out of hand it’s no better than just flipping a coin except that it’s a hundred times more frustrating.

Complexity can also be a consequence of bad ‘chunking’. Individually in a D&D combat round, nothing is very complicated – almost all of D&D revolves around the idea of the difficulty check, and that as we have seen is a very simple system. The problem really comes from the number of places which have consequences that impact on that difficulty check. I need to pay attention to what the enemies are doing, what my allies are doing, what I’m doing, what’s happened to me in previous rounds, and what my friends and enemies have been doing in previous rounds. There is no logically discreet point at which the consequences of those actions are ‘finished’ except at the very end of combat. I am constantly needing to feed new information into my decision making processes, and that’s good in a way (it makes combat feel fluid), but each new piece of information is a new level of complexity in my gameplay.

Ongoing effects (which you take damage from every round until you save) and player power bonuses are especially troublesome from this perspective. To take a random example of this, one of the warlord powers in 4E has an effect that says… ‘Until the end of the encounter, when you or an ally hits the target, that attack also deals ongoing 5 damage’. By itself, a very cool power – but everyone in your team has very cool powers like that, and they’re all using them too. One power by itself is a great flavouring in a combat, but combine that one with the power that gives people a +1 to all defences while they stand within a particular set of grid co-ordinates. Then add in the passive bonus granted by warlords that gives everyone on your side who can see you a +2 to initiative and the +1 shield bonus that was applied to everyone who was around Samantha at the time she used her power. Suddenly, combat becomes a number crunching exercise rather than a system of deciding narrative outcomes. You’re now spending your time filling in columns of a spreadsheet rather than saying ‘I will hit that guy, because that is exciting to me’

Chunking the numbers can greatly reduce that complexity by limiting where previous steps in a process impact on future steps, or by encapsulating their impact in some simpler abstracted mechanic. There is a huge difference in our ability to mentally process ‘I get a +5 to damage against this guy’ as opposed to ‘I get a +8 to damage, but he gets -5 from armour, but my weapon is +2 and I’m currently in my offensive stance which gives me a +2 versus his -2 from being in a defensive stance’. The game impact is identical, but what differs is the ability of people to comprehend that game impact.

Chunking also refers to the way in which earlier parts of a process feed into future parts – it’s about simplifying the inputs and outputs of stages and discarding (or abstracting) those elements that no longer matter. If you’re making a sword blade from a metal bar, I don’t need to know any more about how good a miner you are or how good the ore was – I just need to know how good this bar is. Thus, when I smelt the ore I take my own skills and the quality of the ore, and then abstract that into a single measure that is ‘quality of this metal bar’. That’s a form of chunking both by collapsing two points of data into one, and by having the production of the bar of metal being a logical end point in a process.

If I’m making a sword using a sword blade, I don’t need to know how good the metal was, I just need to know how good the sword blade is. We can accomplish good ‘chunking’ by making stages of a workflow temporally independent – we need to assume that stages of a workflow aren’t being followed to the letter, one after another with no pauses. We need to assume that if someone makes a sword blade that the next step (making a sword) may happen in a month’s time or even by someone entirely different. When we assume that, we need to make decisions about how much information we need and how we can realistically get hold of it. That in turn encourages us to be frugal with our requirements. We need to assume a paucity of data, and that greatly limits what our necessary inputs will be. That in turn greatly simplifies the decision making for our players.

When a game is running on a computer, you don’t need to worry about how well someone can understand the rules in order to evaluate them – on Epitaph, the code we have for doing a skill check is monstrously complicated when compared to the single dice roll that drives D&D. That’s okay from our side, because computers can do all of that math flawlessly and all but instantly. It’s also okay from the side of a player, because most of the calculations aren’t related to ‘pass’ or ‘fail’, they’re related to things like ‘did you get a TM from this action’, or turning our single digit difficulty and difficulty modifiers into an actual numerical target. It’s not the complexity of the math that’s the problem in computer game systems, it’s the tractability of player decisions.

My view on games is that they are engines for generating scenarios in which people must make interesting decisions. Too much complexity takes away how interesting a decision it is, because the two responses we have as individuals are ‘calculate the math’ in which case it’s simply picking the better number, or ‘making a decision based on imperfect understanding’, which is moving dangerously towards ‘making random decisions’.

Complexity seems like an excellent way to make player decisions matter, but they only *matter* if they’re being made from a position of understanding. It’s fine to force people to make snap judgements on complex game situations, but in doing so you need to ensure that the situation can be comprehended (although not necessarily optimised) at a glance. If someone has two seconds to decide what they’re going to do, then they should be spending those two seconds weighing up their own synthesized view of all the factors, not simply saying ‘well, I can’t know here so I’m just going to do the first one’. The only way to really do that is to make sure that each ‘chunk’ of the decision they are making is tractable. An interesting decision might be ‘I am low on health so I need to take out the main damage dealer. I’m closer to the guy with the scimitars than I am to the guy with the rocket launcher, but the rocket launcher is doing most of the damage and I think it’s probably better overall to spend the time getting to him’. The rule is basically the same for decisions with no time constraints – if you can’t make the decision before you’ve spent five minutes with a calculator, your game is too complex. Calculators are for optimisation of decisions, they shouldn’t be *requisite*.

It’s not complexity by itself that leads to deep games, it’s the interaction of game systems and the consequences of your interactions within them. All the stages in constructing a sword might be very simple, but when taken together they may have a very deep impact that is informed by all the decisions you made – the type of hilt you chose, the type of cross-guard, the material and shape of the blade, your own skills as a crafter, the random number gods, etc, etc. All of these can continue to be factors provided you make those ‘player decision’ parts of the process as simple as possible. ‘Steel is a better metal than gold for durability, but less valuable. I am making a sword blade, so I am interested only in the durability. Thus, I will make my sword blade out of steel’. That is a decision anyone can make. ‘This is the best sword blade I have produced, but it is curved. I want a straight blade, but the quality of the one of those I made is quite bad. Thus, I will go with the curved blade even though it is not quite what I want’.

By virtue of making all those small decisions, you can end up with a complex outcome… choosing a curved blade has an impact on the type of damage, the material impacts on weight, durability and value. It’s not that my outcomes are any simpler, it’s just that the factors that went into the outcomes were chunked well and each individual decision was not overly taxing. Thus – simple systems, but with complex consequences.


[1] As in, you remember about them but you know nobody else does and so you sneakily don’t remind the DM that

you should be taking 20 ‘spiders in my veins’ damage every turn.

[2] God, there are fifteen modifiers here. Let’s call it an even 10.