I need a probability calculation script that works with various dice and dice pool sizes, that accounts for a mechanic that allows you to reroll up to X dice that are failures, but ONLY once per die. For example, if your dice pool is 5d10, and you roll four successes, you only get one reroll no matter how many rerolls you actually have. Essentially, I am trying to determine if a "limited" rerolls mechanic could be considered equivalent in usefulness compared to directly increasing your dice pool, or if there is a significant difference in the power level of these two mechanics.

This should be fairly simple for the right person, but I am no good at probability nor at using Troll or Anydice, so here I am. Thanks in advance.

  • 3
    \$\begingroup\$ @KyleWilley Read the question statement again: the user isn't saying "You're not allowed to use an existing tool or do the math," they're saying "I don't know how to do this using existing tools or pure math, so I am asking you to show me." \$\endgroup\$
    – Alex P
    Commented Feb 24, 2014 at 4:50
  • \$\begingroup\$ Varna, it's actually pretty tricky with AnyDice, though we have figured out how to do it. Check out this question for a possible starting point. Is this the kind of thing you're looking for, just for d10 dice pools? Is the target number (N for which d10 >= N is a success) fixed or variable? \$\endgroup\$
    – Alex P
    Commented Feb 24, 2014 at 4:54
  • \$\begingroup\$ @Tridus, it's not off-topic, it's talking about probability and stuff that falls within tabletop game design canon. It's addressing not knowing how to do something, but it's still on topic, as it's useful to other tabletop game designers. \$\endgroup\$ Commented Feb 24, 2014 at 5:02
  • \$\begingroup\$ @AlexP, I don't actually know that AnyDice supports this function any more easily than it would be for me to teach Varna to write the PHP from scratch, which essentially just runs through 10,000 tests as if they were normal to simulate the effects of an actual probability calculator. \$\endgroup\$ Commented Feb 24, 2014 at 5:02
  • 3
    \$\begingroup\$ @KyleWilley That is off topic. Probability this complicated belongs on Mathematics.SE. Writing a script to do this belongs on one of the code stacks, depending on exactly how and what gets asked. This is not RPG & Advanced Probability Script Writing SE. \$\endgroup\$
    – Tridus
    Commented Feb 24, 2014 at 5:06

5 Answers 5


Rerolls are almost always identical to just adding dice.

The only time that rerolls would not be taken as just being additional dice is, to my knowledge, in only two cases: when enough dice succeed to prevent all the rerolls from being used, or when there are too few original dice to make the rerolls practical. If you can reroll failures again, this becomes less significant, but even then you're still doing not much more than doing the addition process again.

I even wrote a script to test this, if you feel like giving it a whirl. In some rare cases it might be possible to game the mechanics to do something other than just adding dice (I'm an English Education major, so take that with a grain of salt), but at that point you'd be designing a mechanic around creating interesting probabilities rather than making a game that rewards rerolls.

You could experiment with using modifier on rerolls or original results, which would produce results distinct from just adding a die, or using different dice, but I don't think that's what you intended.

Rerolls become less meaningful when the target number is low and when the reroll pool is large relative to the total of dice, and are more meaningful when you have a high target number and/or lots of dice. Each subsequent reroll opportunity is exponentially less valuable than the one before it.

  • \$\begingroup\$ Note that you can leave values on the script to 0. If you want to see what I mean when I say that there's no meaningful difference between rolling 10 dice with one reroll and rolling 11 dice with none, just put the appropriate values in. \$\endgroup\$ Commented Feb 24, 2014 at 5:28
  • \$\begingroup\$ Wow, that was fast. This answered my question entirely. It does seem that adding dice and rerolling dice in this manner are about on par statistically, and the relationship between the dice pool size limiting the maximum rerolls will work nicely for making sure whichever stat gives rerolls isn't simply increasing a player's total potential for every pool. Thank you very much, I appreciate the effort. \$\endgroup\$ Commented Feb 24, 2014 at 5:47
  • 2
    \$\begingroup\$ You may want to add something about the conditions you tested before concluding that it's "almost always identical". My first test run was 10 dice, no rerolls (avg. 6.0057 successes) vs. 5 dice, 5 rerolls (avg. 4.2061 successes), using d10s and a target of 5 both times. 6.0 successes vs. 4.2 is fairly significant... \$\endgroup\$ Commented Feb 24, 2014 at 12:09
  • \$\begingroup\$ @DaveSherohman You are correct. I wrote this right before going to bed and I forgot that important caveat. If you have too few dice to take advantage of all the rerolls you will have fewer successes. However, I doubt you'd see a lot of practical play conditions where you'd have that many rerolls; they're not preferable to having more dice (ever!), and unless the success threshold is high there's a decent enough chance of just succeeding on the first time. \$\endgroup\$ Commented Feb 24, 2014 at 14:53
  • \$\begingroup\$ @DaveSherohman I originally tested d10s and did some various runs with TN of 7, but I was also testing low amounts of d4s (5 with no rr vs 3 with 2 rr), with a TN of 2 and a TN of 4. For this, in the case of lower TNs, more dice does become preferable by a decent marigin, but the way the mechanics work for what I am designing makes this acceptable to me. Thanks for pointing that out, though. \$\endgroup\$ Commented Feb 24, 2014 at 19:46

I can't give you exact probabilities, but I can say that an extra die is strictly superior to a reroll. ("Strictly superior" meaning that it's sometimes better and never worse.)

Given this particular set of options, an extra die is nearly always superior. Both are equivalent only when there is no chance of success. In all other cases, an extra die is superior.

Why is this the case? "One die with a reroll" is equivalent to "roll two dice, but only count one success, even if both succeed".

For a concrete example, if there's an 80% chance to succeed and 20% to fail (equivalent to a d10 with target 3+):

  • One die with reroll has a 4% (0.20 x 0.20) chance to completely fail, leaving a 96% chance of one success. That's an average of 0.96 successes.

  • Two dice have the same 4% chance to completely fail, but they also have a 64% chance (0.80 x 0.80) of getting two successes, leaving a 32% chance of one success. Being able to get two successes raises the average total to 1.6 successes.

As the chance of each individual die succeeding shrinks, the two methods come closer to parity - at 10% succeed/90% fail you average 0.19 successes for one with reroll and 0.21 successes with two dice - but two dice will always remain better until you reach 0% chance per die and you're guaranteed to get no successes either way.


I suspect that it depends on how you count failures.

Is "5 dice, 4 successes, 1 failure" better/worse/equal than/to "6 dice, 4 successes, 2 failures"? If both the number of successes and failures count, it is a tricky question to answer (easy-ish to simulate, though). If the number of failures do not count, I would agree with Dave Sherohman that extra dice are always "never worse" in a strict succeed/fail system (no criticals either way).


Solution on AnyDice


function: INITIAL:s reroll up to MAX_REROLL:n using DIE:d {
 BAD: -[maximum of -DIE]
 NUM_REROLL: [lowest of [count BAD in INITIAL] and MAX_REROLL]

function: N:n pool DIE:d reroll up to MAX_REROLL:n {
 result: [N d DIE reroll up to MAX_REROLL using DIE]

output [5 pool (d10>=6) reroll up to 1]

In fact, this can reroll any dice that rolled the lowest outcome on any type of dice, not just success-counting dice.


I recently went through the question of limited-reroll dice-pool probability on the Math Stack Exchange (although specifically in the context of limited rerolls of successes, and figured that it's probably worth going through the math I did for this question here, even if it's a smidge late to the party.

Step 1: Unlimited Rerolls

Let's start with the simpler case, where we have unlimited rerolls. Let's define n as the number of dice, h as our target number of hits/successes, d as the number of sides on our dice, t as our success target, and a as the target number for rerolls. Since we're talking about rerolling failures, d > t > a. We'll also assume, for the time being, that our targets are "greater than or equal to". That means that the probabilities of our three dice states S (for Success), R (for reroll) and F (for Failure) are going to be:

$$S=\frac{d-t+1}{d}, R=\frac{t-a}{d},F=\frac{a-1}{d}$$

Now, when we think about this, it's clear that at some point, all our dice have to land on either success or non-reroll failure - after all, landing on our reroll means we roll again. What this means is that, ultimately, we're going to be doing a lot of rerolling before landing on the base distribution for success-based dice-pools, which is the binomial distribution. Binomial distributions have a well-known mass function that we can plug our probabilities above into:


The bit at the front is the binomial coefficient, and it's job is to count the number of ways this particular combination of results can occur, and you calculate it like so:


Now, the last thing to deal with is our reroll state. One thing to note is that this probability can't contribute to our success count - there's actually an infinite number of possible rolls in this system that will have h successes, and we need to add up the probability of all of them to get the actual probability. Fortunately this is something we know, because we're basically describing an infinite geometric sum, and mathematicians cracked that one a long time ago:


We're not quite done yet, because there's one last wrinkle - we need to go from 1 dice to n dice, but that's very simply done by multiplying the single die result by itself n times, or...


So, that's pretty simple! Now, here's the amazing part - we just need to multiply our original binomial formula with our result here, and when we do, a bunch of things cancel out, and our formula becomes this:


So, this kinda gives the game away - an infinite reroll of failures is equivalent to removing any rerolled faces from the roll. In fact, this makes the expected value of such a roll really easy to calculate:


Step 2: Limited Rerolls

Limiting our rerolls makes things a smidge more complicated, but the concept is ultimately the same - We figure out the equation for our rerolls, figure out the equation for our non-rerolls, then multiply them together.

There's a couple of ways to look at this, but probably the simplest is to note that in a roll where you have, at most, r rerolls, then it's only possible to hit your reroll condition r+1 times - r times you reroll, and the (r+1)th time you're stuck there. So, we just need to sum up the result of r+1 possible rerolls, rather than an infinite number of them. Again, finite geometric sums were well and truly cracked a few centuries ago, so we can calculate this very straightforwardly:


Which, if we take to the nth power:


What we're seeing here is the interplay between the dice that have "exhausted" their rerolls (the bracket to the k-th power) and the dice that haven't exhausted, and thus have landed on a non-reroll (the bracket to the (n-k)th power). Which makes sense - any die that hits reroll r+1 times is stuck there - it can't contribute to a success or failure state. This means that we need to adapt our binomial equation from above to take this into account:


And once again, all we need to do from here is multiply it all together (and again, take advantage of those sweet, sweet cancellations) to get:


With the expected value of such a roll being calculated by:



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .