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.
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.
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.
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.
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):
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:
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.
Here's some other ideas I never got round to testing:
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:
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
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).