Dice Systems

I’m a big fan of dice and cards, both at a table and when used as an abstraction in video games. I find they add a certain delightful physicality to what would otherwise be a boring random() call.

Dice systems form a language of sorts, with various nouns (numbers and dice) and verbs (operations on them), allowing a player or designer to form sentences (“ $3 d 6$ exploding on sixes”, “ $2 d 20$ keep highest”)—and there exist a number of formal languages encoding that dice–roll language into a form understandable for computers.

Dice System Aesthetics

Certain dice–roll sentences are more aesthetically pleasing or fun to use than others—they exhibit particular desirable properties. Those are, in my opinion, and in vaguely descending order of importance:

Non-Arithmeticity: a roll does not involve operations other than counting and comparison. An example is a roll that succeeds if at least one of a pool of six–sided dice comes up with a 6; a counterexample would be something like “the sum of $2 d 20$ , minus 2, multiplied by 3”.
Monadicity: a roll resolves in one operation. The obvious example is the roll $1 d 6$ ; an extreme counterexample would be playing a full round of blackjack to determine success or failure.
Criticals: a roll can be exceptionally (critically) successful or unsuccessful. The simplest example is $1 d N$ with critical failure on a 1 and critical success on $N$ ; a counterexample is $1 d 6$ with success on a 4+, which only results in failure or success.
Augmented Success: a roll conveys more information than just success or failure. The best example is Genesys, which uses separate symbols for Success/Failure and Advantage/Threat, allowing for success (“Yes”), success–with–threat (“Yes, but…”), failure (“No”), and failure–with–advantage (“No, but…”).
Constrained Dice Pool Size: as few dice as possible are involved in a roll. $1 d N$ is ideal; rolls involving dozens of dice are unwieldy, prone to miscounting, and can make players run out of physical dice to roll, forcing them to memorize prior results and reroll already–rolled dice instead.
Simple Dice Pool Construction: constructing a dice pool does not require complex calculations or lookups in tables. An example system with very simple dice pool construction would be one where the player rolls as many same–sided dice as they have points in a skill.
Uniformity: all rolls are constructed the same way. For example, every random event is resolved by rolling $1 d 100$ ; a less obvious example is rolling as many dice as the character has points in a skill. A counterexample would be systems where e.g. every type of weapon uses a different kind and number of dice for calculating damage.
Estimatability: the odds of success are easy to estimate. Blood Bowl is a great example, since it only uses six–sided dice, very rarely more than two, and never more than three per action. Players very quickly pick up that e.g. rolling 4+ on $1 d 6$ with reroll only fails $(\frac{3}{6})^{2} = \frac{9}{36} = \frac{1}{4}$ of the time, or that 3+ on the higher of $2 d 6$ with reroll fails only $(\frac{2}{6} \times \frac{2}{6})^{2} = (\frac{4}{36})^{2} = (\frac{1}{9})^{2} = \frac{1}{81}$ of the time. Rolling percentage dice under a target number is also a great example, since the target number is exactly the percentage chance of success.