Just Simple Questions on Dice

[Darren Hill]

Walt, where will these articles appear? This is a subject I find intensely fascinating.

[Ron Edwards]

Walt wrote,

... brings up a very deep issue, regarding game design and game criticism, of what it means to fiddle around with probabilities. I believe it also hints at why some game designers (I'll name no names, and let any who want to fess up do so) tend to be disdainful of some methods of fiddling, such as Julian's approach of testing 100,000 rolls and counting up the results in a computer program

I 'fess. No real need to discuss it further, pending Walt's articles.

Best,
Ron

[mneme]

One person has pointed out that the basic claim - that for chances of win-lose, die size doesn't matter - is not valid when odd-sided dice are used (e.g. d3, d7).

Actually, Ron, we had a conversation about a year ago where I ran the math and proved to my (and your) satisfaction that for chances of win-lose, die size most certainly -does- matter, regardless of even/odd dice -- that bigger dice favor (in comparison) the weaker side.

I can re-run the numbers or try to dredge up my logs of the emails if you like.

[mneme]

Eh.  Hadn't read to the end and seen the rather more in detail math than mine (and the fact that Ron had "closed" the thread) -- sorry about that.

[Ron Edwards]

Hi,

The thread isn't closed. Didn't say it, didn't imply it, don't know what you're talking about.

I have our emails too, but my reading of them is a little different. Rather than debate that, which doesn't strike me as productive, I prefer to let Walt's analysis stand as the reference for all future questions.

Best,
Ron

[Ben Lehman]

I believe it also hints at why some game designers (I'll name no names, and let any who want to fess up do so) tend to be disdainful of some methods of fiddling, such as Julian's approach of testing 100,000 rolls and counting up the results in a computer program. I think that's beyond the scope of this thread, but it's something I now plan to talk about in the series of "what game designers really need to know about probability" articles I've been working on.

I'll fess up, too.  My reasons are firstly a mathematician's disdain for the Monte Carlo method, and secondly but no less importantly some important game design stuff that I'll leave for your essay, as I'm sure you're also hip to them.

I'm really looking forward reading it, though.

yrs--
--Ben

[Walt Freitag]

Hi guys,

I can't tell you when the article will appear. It has been, and will continue to be, a challenging project. The idea is to juxtapose exposition of mathematical probability theory, starting from the most elementary level, with a treatise on "how to think about" probability and design issues related to probability that's much harder to explain. Kind of the reverse of the usual approach, which is to preset the theory (the easiest part to explain) while leaving it mostly up to the reader to figure out what it means and how to apply it.

Here's part of what I mean, conceptually. Take a typical probability "gotcha!" question and consider the different ways someone might answer it:

Q: You're rolling 2d10. If either of the dice comes up 10, what's the chance that the other die also comes up 10?

Possible answer 1: "One in ten. Duh!"
Possible answer 2: "I took out some dice and rolled a bunch of times, it looks like it's about once out of every twenty times."
Possible answer 3: "I [pick one: tabulated all the possible rolls / ran a Monte Carlo program with 100,000 tries / looked up a formula and plugged in the numbers / posted the question on a bulletin board] and the answer looks like it's one in nineteen. Is that really right?"
Possible answer 4: "One in nineteen. Duh!"

and let's not neglect the all-important

Possible answer 0: "I have no idea."

One key point is that the fact that answer 1 is dead wrong and answer 4 is right shouldn't blind us to the fact that they're very similar answers, in terms of how the answerer comes up with them. In both cases the "duh!" conceals the act of creating and analyzing a mental model of what's going on. For answer 1, it's "the 'other die' has ten sides, each side is equally likely to come up, so..." For answer 4, it's "twenty -- no, wait, nineteen -- rolls in every hundred have at least one 10, but only one roll in 100 comes up double-10, so..." Without such a mental model it's hard to trust, apply, or extend any results we obtain by other means (as I worded answers 2 and 3 to try to illustrate). But of course, without some kind of verification as per answer 2 or 3, it's easy to mistakenly trust a flawed model. Also, the types of testing listed in answers 2 and 3 -- some much more than others -- can be used to help derive a good model in the first place, especially when starting from answer 0.

There's a synergy, of which the principles and formulas of probability theory are a vital part but far from the only part. If you calculate or test but don't try to achieve an intuitive understanding, you can (correctly) see that the underdog's chance in Sorcerer increases with the die size but miss that the increases converge on a limit, and so mistakenly conclude that the game would get wildly random with larger dice than the ones you've actually tested. If you think you have an inuitive understanding, but you don't calculate or test, you'll never notice when you fall into any of numerous pitfalls relating to unwarranted assumptions, as the now-classic Monty Hall probem demonstrates. (See Wikipedia for a thorough treatment of that problem, if you're not familiar with it).

A case in point: in my long post above I made some statements that further calculation and testing have revealed to be mistaken. The calculated probabilities that I listed, and my main conclusions and description of the behavior of the system, still stand. But along the way I tossed off some side comments that turn out to be wrong. Specifically, I said that if the dice don't roll a high tie, then the players' chances of winning are equal to the limit values (player's # of dice / total # of dice rolled). And that therefore, if rolls with ties for high die were rerolled, then likewise the players' chances of winning would be equal to the limit values. Turns out those assertions are wrong. The error is that once you exclude (or reroll) rolls with ties for high die, it's no longer true that each die on the table has an equal chance of being the high die. On the contrary, the higher the underdog rolls, the more likely the roll will be a tie, so once rolls with ties are excluded or rerolled, the underdog's dice are slightly less likely, die for die, to be the highest.

So, that's what I'm up against. Darren, Ron, and Ben, thanks for your interest; I'll keep at it and keep you posted. And any comments or suggestions are welcome.

- Walt

[The_Tim]

A random aside.  I suspect that the odd sided dice = meltdown idea comes from treating the Sorcerer system as tossing high/low dice and comparing number of highs to number of highs.  Since Sorcerer actually doesn't reduce to that, except in the degenerate case where you flip coins instead of rolling dice, anything you get from that assumption is wrong.

[mneme]

One question one can ask with this stuff that is interesting is what methods one can come up with to produce similar results to a system via a different means.

FREX, one of our players, Beth, dislikes the Sorceror system asthetically -- she finds that the multiple comparisons ("Wha'ts your highest die? 8. "Ok, second highest?" "6" "I have 2 successes") interfere with her fun.  I don't, and nor do some of the other players, but the question remains whether one could find an elegant die-rolling system that has similar properties re probability, but typically involves fewer comparison (my gut instinct says that this may be true of a "higher than 5/lower than 6"  successes comparison system with high die as a tie-breaker will produce similar-enough results with (typically) 1 comparison, but that's a case of 6: "my first wild guess is that it's 1/20ish (or 1/20ish)" (on the above set of examples)).

Ron, I'm a little nervous about walking into the "this thread is closed" type landmine, given the site's practice of "closed by convention" thread closings, so I erred on the side of caution when encountering "I 'fess. No real need to discuss it further, pending Walt's articles."  Sorry about that.

[Ron Edwards]

We're all good! This thread is huggy-bunnies, so far.

Best,
Ron

[Andrew Cooper]

Huggy-bunnies?

Words I never thought to hear Ron utter.

[Darren Hill]

I have recovered from my mortification at missing the old (my dice)/(total dice) ratio, but that observation triggers a new question.
One thing I really like about the Sorcerer dice system is the way that successes gained on a roll don't scale linearly with number of dice rolled. In Vampire and all the other dice pool systems I can think of off-hand, if you roll twice as many dice, your expected average number of successes doubles. Roll twice as many dice, get three times as many successes. (On average, with all that implies.) Most of these games have pretty clunky ways of dealing with the problems this causes (along with the observation that getting a number of 'successes' isn't always 'successful').

Sorcerer doesn't work like this, which is fortunate for its currency system. I haven't found an easy way to calculate the chance of getting, say, exactly 1 success, or 3 or more successes, on a roll.
What's the simplest formulaic way to do this kind of calculation?

[Gregor Hutton]

Great analysis Walt. The "limit value" description that I find easier to think about is to start with any number and divide it by 2. Now divide that number by 2, and repeat. It will approach a limit value of 0 but never reach it.

[Walt Freitag]

Either there's no simple formula, or there's a simple formula but there's no simple way (that is, simple enough for me to have accomplished it) to derive it. I suspect there's no simple formula -- that is, the exact formula will be very complex, especially if the formula includes the number of sides on the dice as a variable. But I can't be sure either way.

The best I can do formulaically, so far, is to derive another limit ratio akin to the (my dice)/(total dice) ratio, which will converge on the real probabilities only if the number of sides on the dice are very large. That is, the derivation ignores the possibility of ties so it's only accurate when the number of sides on the dice are large enough to make the probability of ties small.

In that simplified model, if I get "two or more" successes, it simply means that the two highest dice are on my side of the table. The chances of that happening are the number of different ways to distribute the two highest dice that put them on my side, over the total number of different ways to distribute the two highest dice.

m = the number of dice I roll ("my" dice)
t = total number of dice
s = the number of successes "or more" I want to calculate the probability for

probability of s or more successes on my side = binomial (m, s) / binomial (t, s) = C(m, s) / C(t,s)

(Wikipedia "binomial coefficient" if you're not familiar with the binomial coeffiicent function C.)

Note that when s  = 1, the formula devolves to C(m, 1) / C(t, 1) = m / t as we had before.

If I get exactly two successes, it means that the two highest dice are on my side of the table, AND the next highest die is NOT on my side of the table. Overall, the chance of the (s + 1)th highest die being on my opponent's side is (t - m) / t, but I can't just multiply that by C(m, s) / C(t,s) because the two conditions are not independent. What I need is the chance of the (s + 1)th highest die being on the opponents side IF it's already established that the s highest dice are on my side. That's (t-m) / (t - s) -- that is, the number of dice on the opponent's side over the total number of dice not counting the s higher dice we're already assuming are on my side.

So, my probability of exactly s successes = C(m, s) / C(t, s) * (t-m) / (t - s)

Note that when s = m, (t-m) / (t-s) = 1, which means that the chance of getting m succcesses (all the dice I roll being successes) is the same as the chance of getting that many successes "or more," which makes sense because it's not possible to get more than m successes.

Note also that 1 - (t-m) / (t-1) is the probability of getting more than one success assuming you win (get at least 1 success) in the first place. Clearly the more of the dice are yours (the smaller t-m is), the higher that probability is.

Don't forget, though, that all this is only precisely true if we're rolling infinite-sided dice. Ties make it all much more complicated. For instance, if the (s+1)th highest die happens to be a tie with the (s)th highest die, then the probability of getting exactly s successes suddenly becomes zero (assuming also that no higher dice in the roll are disregarded due to ties, and that the (s+2)th die isn't also a tie), because it's either on my side and must represent an additional success, or it's on the other side and nullifies (at least) my (s)th success. Come up with exact formulas that cover these cases correctly? Sure, right after I finish off this little unifying-relativity-with-QM problem I've been working on.

However, even without exact formulas there's another way to calculate exact probabilities if you want to. All you need is a program that iterates through all the possible die rolls for a given m and t (and number of die sides n), evaluates each one, and counts up the wins and the numbers of successes. Dice probabilities being what they are, this is guaranteed to yield exact correct answers (without even rounding errors, if you express the results as fractions over n ^ t, the total number of possible distinct die rolls). Most programming languages on most computers should be able to handle rolls of 8 d10s (100 million rolls to score) in reasonable time. To get beyond that you might need to use C or another speed-optimized compiled language and/or do overnight or multi-day runs and/or iterate through the die rolls in a more sophisticated way. As an example of the latter, you can iterate through tuples where for instance (1, 3, 0, 0, 4, 0, 0, 1, 1, 2) represents a roll of 12d10 in which there's one 1, three 2s, four 5's, an 8, a 9, and two 10s. When the number of dice in the roll is close to or greater than the number of sides on the dice, there are far fewer such tuples than there are possible distinct die rolls. However, for each tuple you have to calculate how many different rolls generate that tuple, and weight the results counts accordingly. For the Sorcerer system you have to generate a separate tuple for each side's dice. Some general advice for these kinds of computations: Never use a built-in binomial coefficient function; instead, create a lookup table for the range of binomial coefficients you actually need (which is usually only for arguments up to the total number of dice in the roll). If possible use high-range integers rather than reals for all the results counts, dividing the various totals by the n^t denominator only at the end. Often, reducing those fractions will give you a better feel for the results than just displaying them as rounded real numbers.

- Walt