This is a writeup of a twitter thread I posted a couple months ago! I figure it'd be better written up here and not lost to twitter's endless churn. Here's the original thread—all the replies and QRTs are on the first post.

The basic idea: a cycle of dice pools

Here's the setup: You have 3 dice pools and 10 6-sided dice (10d6). The pools are in a cycle: pool A → pool B → pool C → pool A. The dice are split between the pools, with each pool having 0–10 dice.

Here's the action: You roll one pool at a time (as long as it's got more than 0 dice). For each result of 1–5, “pull” another die from the previous pool (unless there are no more dice left). For each result of 6, “push” that die to the next pool. For instance, when you roll pool B, you'd pull from pool A and push to pool C. When you roll C, you'll pull from B and push to A.

For example: let's say there 3 dice in A, 7 in B, and none in C. You roll B, and get 1, 1, 1, 2, 3, 5, 6. That's six results of 1–5 and one result of 6, so you pull 6 dice from A and push 1 die to C—except there's only 3 dice in A, so you can only pull those 3. That leaves you with 0 dice in A, 9 in B, and 1 in C.

Ouroboros mechanic example

The outcome? The more dice there are in a pool, the faster it can pull dice from the previous pool—but also, the faster it pushes dice to the next pool. The more dice, the faster it grows, the faster it drains. Since the stat's pretty high (6 on d6) you're way more likely to pull than push, so pools grow faster than they drain until they pull all the dice out of the pool before them. Then, they can only drain, so they slowly drain into the pool after (pushed by rolling the pool itself or pulled by rolling the next pool) until eventually it, too, empties out. Then that happens with the next pool in the cycle, and eventually the dice loop back around to the first one.

How does it work in practice?

I coded a model in MATLAB to test this out. It's a super-basic setup that just picks a random pool (as long as it's got dice), generates a random number from 1–6 for each die, and moves dice according to the results. I set this up to roll 100 times, and here are the results: it loops from A to B to C, with each pool holding most/all the dice for 1–2 rolls before the dice move to the next pool:

And here's the pools plotted separately. You can see how pools usually peak at 7–9 dice, but can peak as high as to 10 or as low as 4 and be broad or narrow—in other words, the behaviour is, I guess you'd say, reliable but not predictable. You know the pools will peak and drop, but not exactly when or how high they'll peak.

Simulations with 10d6

Switching things up

This behaviour comes from the basic mechanics, not the number of pools or number of sides on the dice (though both of those can affect it). For instance, here it is with 10 pools instead of 3, running for 1000 rolls to show the pattern still holds:

And here it is with d10s instead of d6s (and the push stat set to 10, so 1–9s pull and 10s push):

Simulations with 10d10

Way more influential are the stats for when you push and pull dice. This mechanic is super-lopsided, since a die is 5 times as likely to pull than to push. That's what makes the pools pull in so many dice before draining out. If you balance things out, the peaks kinda… relax a bit. For instance, let's say you pull on 1–2, do nothing on 3–4, and push on 5–6. Here's what that does:

Simulations with balanced stats

Pools rarely go as low as 0 dice when using balanced pull/push stats.
Pool A has peaks, but they rarely rise higher than 5 dice; pool B rarely drops lower than 3
Pool A is dominant for roughly rolls 15–50 while dice trickle through pools B and C.
Pool C doesn't have a proper peak until almost roll 30.

The peaks get broader, less reliable, less-defined, sometimes they're barely or not even there. The stats are less extreme, so the dice flow more smoothly round the cycle and you don't get the clear buildups you get with 1–5/6.

What else could you try?

Here's some other ideas I never got round to testing:

Show me the average!

All the results above are from individual simulations, at most 4 simulations (of 100 rolls) with any given set of rules and stats. It's important to check out the average, too, especially since the idea here is that you can't predict where the peaks will be.

Let's say we average out hundreds or thousands of simulations. There're two possible outcomes we might see:

  1. If each pool levels out at a third of the total dice, then you can't predict where the peaks will be.
  2. If, however, there are still peaks, no matter how small, then you can predict where the peaks will be.

Here's the average of 1000 simulations with the original settings:

So basically, even though all 1000 simulations start with the same setup (10 dice in A, none in B or C), by about 20 rolls you basically can't see any difference. The lines are a little uneven because they're still only averages of 1000 simulations, but there's no pattern of peaks. Like I said way above, this mechanic is reliable but not predictable

What's this mechanic used for/can I use it?

I came up with this mechanic without really having an idea for where to use it, so it doesn't really have any colour or narrative to it, but a few things came up in the twitter thread:

And like I said at the end of the original thread, if you like this mechanic then go ahead and use it (you can't copyright game mechanics anyway).

Return to top