It’s going to be a mathsy one this week, I’m interested in thinking about different ways to interpret dice rolls and what they mean for game design. It’s not going to be as off the wall as I was in 6, this isn’t about considering stuff like the position of the dice relative to the other dice, but even within those constraints there are still a lot of ways to interpret the number showing on the dice.

There are three common approaches to generating a random number of a die or pile of dice.

The first is to roll one of the dice and read the number straight off it (As in Talisman). It’s a classic approach that everyone is familiar with. The probabilities involved are easy to understand. The component count is low. There’s a lot to love about the classic “grab one die and roll it” approach.

The second is to roll several of the dice, read the numbers and add them together (As in The Settlers of Catan) On the surface this feels a lot like the first approach, everyone’s familiar with it, it’s easy and you don’t need many dice. However the probabilities it generates are dramatically different, as we’ll get to in just a moment.

The third is to roll several dice, but rather than adding them normally, to count how many of them exceed a particular value (As in Arkham Horror). This is a less intuitive approach, but that has some neat mathematical features. It also feels viscerally good to roll a big pile of dice. On the other hand, it requires a big pile of dice.

I’d like to compare these three approaches, using a few different systems which have the same average result.

Straight roll: 1D7 (Yeah, I know, seven sided dice look daft)

Total roll: 2D3

Pool: 8D6, counting each 4+ rolled as 1 point

Here we see the odds of rolling each number 0-8 for the three different methods. A few features of this that pop out:

Compared to the other methods the straight roll is much more likely to produce extreme results and much less likely to produce an average result. Whether this is desirable or not depends upon whether you’re looking to design a game in which outrageous swings of fortune are common or if you’re aiming to weight player choices more heavily compared to die results.

The outcomes for the pool and total approaches are quite similar – though bear in mind we’re talking about small dice (D3s) so the patterns would become more exaggerated with typical use. The pool generates a wider selection of outcomes – it’s just about visible on the graph that rolling a “0” or “8” is not quite impossible. By comparison the total approach will never generate a result of ‘0’ ‘1’ ‘7’ or ‘8’. Whether a wider range is desirable again depends upon the nature of your game – do you want players to be able to take a million to one shot that just might work?

Bear in mind that this is a consequence of starting with an average result (In this case 4) and asking how different systems behave. You could generate a totalling and dice pool system with the same range, but different averages – for instance comparing the 2D3 to a dice pool of 4 dice that adds 2 to the result. However the pattern remains that the pool system generates low probability edge cases, approximating a normal distribution.

Another important facet of different dice systems is that they modify modifiers. The meaning of giving a player a “+1 bonus” changes depending on the dice being rolled. It’ll be easier to illustrate this if we look at some cumulative probabilities.

In this case the graph shows “What are the odds of rolling X or higher”. The odds of rolling 0 or higher is 1 (Meaning that it will happen every time). The odds of rolling 8 or higher is much lower (0 for everything but the pool, in which it’s very small). The drop off in between is different for each system.

So what’s this got to do with modifiers?

Well, if you look at the difference between two adjoining results you can see how much of a difference a modifier will make. With the straight system a +1 modifier will improve your odds by about the same amount whatever your situation. With the other two distributions it should be obvious that going from needing “5” to needing “4” massively improves your odds, but going from needing “3” to needing “2” produced a much smaller improvement.

Again, whether this is desirable depends on your game, but it does offer a designer a neat option: The ability to implement diminishing returns without requiring the player to do any complicated maths.

When it comes to mathematics in game design I’ve always felt that the purpose is for the designer to do the number crunching, but to hide it so that players don’t have to. This is a perfect example of that.

Diminishing returns have a place in game design for all sorts of reasons. They can help to stop a runaway leader. They can maintain some uncertainty (where the designer felt it desirable) where otherwise it’d be completely eliminated. They can suggest diversification as an optimal strategy, encouraging players to explore all aspects of the game rather than hammering just one really hard. There’s probably a whole article in the uses of diminishing returns in board game design – but so far as we’re concerned it’s enough to say that it’s sometimes desirable, awkward to deliberately implement by hand and automatically implemented by dice pool and dice totalling systems.

These systems offer a lot of play beyond what I’ve explored here. A dice totalling system can involved more than 2 dice, when you do the probability curve stops being a pyramid and becomes more normal. A dice pool system doesn’t have to make the odds of success 50:50 and that changes things dramatically. It also offers the option to have a few levers, letting you modify the total successes needed and what counts as a success independently.

All of these are options for the game designer’s toolkit. What I’m trying to get at here is a greater understanding of how and why different systems are implemented. Hopefully that’s enough to give you a grounding in exploring what sort of system will best suit your game – or as a player why your favourite game behaves the way that it does!

Just going to throw out that for those interested in number-crunching on dice mechanics, anydice.com is really great for doing this. For instance, a simple anydice program to do the analysis greg described above can be seen at http://anydice.com/program/80fd and just reads:

output 1d7

output 2d3

output [count {4..6} in 8d6]

You can look at the results as tables, graphs, chance of getting at least/most, etc. It’s quite simple to learn how to write especially if you’re not doing anything very complicated and I’ve used it quite a lot to analyse mechanics in roleplaying games (though some of the stuff I’ve written has admittedly been pretty convoluted, often because I’m actually chaining mechanics together).