d20 does not appear to be fair

[Fauxreigner]

After running a couple sessions with several rounds of combat where nobody, monsters or PCs, could hit, I decided to do some testing. After rolling 700 d20s I ended up with the following data. In this series of tests the 3 came up almost 14% of the time, and 17 and 19 came up a bit over 7% of the time each.

While I haven't yet done the math to determine if the 17 and 19 are statistically significant results (although with this sample size I believe they are at a 95% confidence level) the result on the 3 is clearly not the performance of a fair d20. Is there anything that can be done here?

d20 Count Percentage
1 32 4.57%
2 14 2.00%
3 97 13.86%
4 42 6.00%
5 24 3.43%
6 29 4.14%
7 38 5.43%
8 26 3.71%
9 26 3.71%
10 35 5.00%
11 29 4.14%
12 29 4.14%
13 24 3.43%
14 35 5.00%
15 23 3.29%
16 36 5.14%
17 52 7.43%
18 25 3.57%
19 52 7.43%
20 32 4.57%

[zabulus]

That's weird, we hardly ever see 3's in our games. Must be something in your configuration, do you think you could have malignant software installed that could make your VTT roll mostly 3's?

[Sigurd]

My table has certainly questioned the randomness of the dice on several occasions. Back when we used real dice.

I think a decent investigation of this sort of thing would be interesting but I think if everyone roles under the same system small irregularities are a wash.


Sigurd

[joshuha]

I did this in the order of 10,000 rolls and 100,000 rolls in an earlier thread with the results copied below. Also, others in the thread ran in the upwards of 1 million and had similar distributions that I had.

https://fantasygrounds.com/forums/showthread.php?t=7632



I ran the test 10,000 times again, this time recording number of times a number came up.

Rolls: 10,000
Total: 104791
Average: 10.4791

["dielist"] = {
[1] = 561,
[2] = 501,
[3] = 501,
[4] = 466,
[5] = 467,
[6] = 518,
[7] = 487,
[8] = 491,
[9] = 536,
[10] = 487,
[11] = 492,
[12] = 493,
[13] = 535,
[14] = 482,
[15] = 485,
[16] = 454,
[17] = 496,
[18] = 526,
[19] = 523,
[20] = 499,
}




["Total"] = 1.05066e+006,
["numrolls"] = 100000,
["dielist"] = {
[1] = 5148,
[2] = 5216,
[3] = 4845,
[4] = 4888,
[5] = 5136,
[6] = 5006,
[7] = 4912,
[8] = 5060,
[9] = 5004,
[10] = 4849,
[11] = 4658,
[12] = 4963,
[13] = 5040,
[14] = 5074,
[15] = 4928,
[16] = 4902,
[17] = 4943,
[18] = 5125,
[19] = 5155,
[20] = 5148,
}

[Fauxreigner]

Thanks for the data. For your 100k sample, I'm getting a p of 3.429e-08 for the chi-squared test for independence. That's a pretty strong indicator of nonrandom behavior. I see you ran your tests in Dec 07, I wonder if things would be more apparent in 2.3.6. Tried using your lua scripts posted there but I couldn't get it to work in my ignorance of FG scripting.

I'm also wondering if use of the throwDice function might explain why your datasets are closer to independent than mine; while my understanding is that throwDice simulates rolling a die rather than just querying the PRNG, it's still using a throw velocity defined in the function.

In my tests, since I didn't have the knowledge to make fancy lua scripts, I just rolled "handfuls" of d20s and recorded the results. Wondering if the typically lower/less consistent throw velocities used by players might be revealing nonrandom behavior in either A: the dice simulator or B: the randomizer that picks which face of the die is up when you pick it up.

[grider]

I don't like the way this is panning out. I want some random behavior in dice rolls. Maybe a dev will chime in and clear this up.

[Foen]

Joshuha's data seems to imply fairly random behaviour. The point about non-randomness being introduced by the way the die is thrown is true of physical dice as well. It is possible to pick FG dice up and just drop them again without rolling: just like the Real Thing(tm). But hey, GMs can tell that stuff both in face-to-face and virtually by seeing the way the dice move.

I guess I'm not that bothered by the whole random number thing, not least because half of GMing is knowing when to ignore the dice anyway ;o)

Stuart

[Griogre]

Sure, if you see a guy just drop a dice on a 20 then say it misses. :p The player will get the message. ;)

Seriously, players throwing dice by hand in a face to face game is less random than that number generator if you don't make them use a dice cup or bounce them off your screen in a face to face game. In my opinion, it is the *increased* randomness of the generator the players notice - not vice versa.

[Tenian]

Isn't there a video about the guy who made the original poly sided dice....something about dice bing mass produced on sprues and then being finished creating an uneven distribution.

[Fauxreigner]

Joshuha's data seems to imply fairly random behaviour.
No, it doesn't. The chi-squared test in fact demonstrates that it's almost certainly not random behavior. There's only a ~0.0000003% chance that a fair die would see variance more extreme than demonstrated here. Even though it's a PRNG and not a true random number generator, passing the chi-squared test is a common way of seeing if a PRNG is a good simulator of true random behavior.


The point about non-randomness being introduced by the way the die is thrown is true of physical dice as well. It is possible to pick FG dice up and just drop them again without rolling: just like the Real Thing(tm). But hey, GMs can tell that stuff both in face-to-face and virtually by seeing the way the dice move.

The problem with this is that I was generating multiple dice, which causes FG to select the orientation of each one, and getting strongly nonrandom results. That suggests (but does not prove) that FG is not picking the throwing orientation in a random way. It's like if a player always insisted on rolling with the 1 facing up on their d20. I'm doing further tests by throwing the dice and still seeing data that looks suspicious, but I don't have enough rolls yet to make a conclusion.

[unerwünscht]

I have seen this topic come up a few times now, and beyond the non randomness of the die roll there is one other thing that all these threads have in common. No one officially attached to Smite Works has commented on any of these threads.

I see a few possible reasons for this. The most likely being they don't want to have to be the ones to tell you "Random numbers used in computer programs are pseudo-random, this means they are a generated in a predictable fashion using an advanced mathematical formula. This is fine for most uses, it is just not random in the way you may expect it to be."

There is also a chance that they just do not care.. and I would also guess that this is partly true. Not that they don't care about what you or I or anyone else thinks, but they simply do not care how random the dice actually are. It is random enough for Role Playing, and that is probably all they truly care about.

Also, when/if you find a fix for it, please for the love of god let me know, I am tired of rolling so low all the time. :)

[Griogre]

Change you dice color. ;) It can't hurt.

[Berova]

I'm just waitin' for Smiteworks to "sell" new dice for FG2...

I would be interested in how many takers they get! :D

[Phystus]

Isn't there a video about the guy who made the original poly sided dice....something about dice bing mass produced on sprues and then being finished creating an uneven distribution.

Yep, back in the day Gamescience ran ads in Dragon explaining all about that. They do make nice dice.

Really, though, the players don't want random dice. They want biased dice, just biased in their favor! :D Only the GM wants random dice (ones that came with a certificate of randomness would be appreciated at times ;) ).

~P

[steev42]

I had done a study of these things on my own--even wrote a little C program to tabulate all the rolls that had happened in my game to date.

The results were interesting--on every single die size that had a statistically relevant number of rolls, the highest number on the die was rolled less often than it should have been. Interestingly, the d100, which only had about 8 rolls in total, had 6 of those 8 being above 90.

But for my totals--9 was the most common number rolled, occuring 5.79% of the time. 20 was the least common, occurring 3.98% of the time. If I remembered how to do Standard Deviations correctly (it's been quite some time), it was beyond 2 standard deviations; the number 6 was exactly 2 deviations away; 1s, 7s, 9s, and 15s were all 1.0 deviations or worse.

What that means, I don't know--but I had promised my players I would post about it, and since there was a thread already, I figured I may as well.

[DNH]

For those of us using the 4e_JPG ruleset, how does this apply to the functionality in there? We make the vast majority of our dice rolls using either double-click on the die fields or else drag-drop to the token/tracker. Does either of these actions trigger a dice rolling script different to the one used when grabbing a die and tossing it onto the chat window? If so, why? And does it make any difference?

My players have had a run of bad rolls just lately, which has been fairly consistent over the last three, maybe four, sessions. Tempers are getting frayed and people are getting disillusioned but there are no easy answers. FWIW, my own dice rolls as DM seem to be mostly as expected, which of course does not help with the aforementioned frayed tempers.

On a related note, and I know it is only really graphical sugaring, the "double dice" issue does very little to inspire confidence in the software's PRNG when neither of the results shown in the graphics is the actual result shown in the chat entry. This happens with alarming regularity; and when one or other of the numbers *does* get used (talking d20s here), it's always the lower one. Like I say, at the least, it's annoying, and it's getting close to being a deal-breaker.

Any thoughts?

[Spyke]

There seems to be an obvious way to get round this issue.

Switch to GURPS where you roll low to succeed...

;)

Spyke

[joshuha]

For those of us using the 4e_JPG ruleset, how does this apply to the functionality in there? We make the vast majority of our dice rolls using either double-click on the die fields or else drag-drop to the token/tracker. Does either of these actions trigger a dice rolling script different to the one used when grabbing a die and tossing it onto the chat window? If so, why? And does it make any difference?

My players have had a run of bad rolls just lately, which has been fairly consistent over the last three, maybe four, sessions. Tempers are getting frayed and people are getting disillusioned but there are no easy answers. FWIW, my own dice rolls as DM seem to be mostly as expected, which of course does not help with the aforementioned frayed tempers.

On a related note, and I know it is only really graphical sugaring, the "double dice" issue does very little to inspire confidence in the software's PRNG when neither of the results shown in the graphics is the actual result shown in the chat entry. This happens with alarming regularity; and when one or other of the numbers *does* get used (talking d20s here), it's always the lower one. Like I say, at the least, it's annoying, and it's getting close to being a deal-breaker.

Any thoughts?

The double click script and drag throwing uses the same throwDice function that I used when I tested upwards of 1 million rolls and found a fairly even distribution. As far as the double d20s thing that is a bug but only occurs in that ruleset due to the way drag dropping a dielist onto another list is behaving.

If people wanted, I could build into my log parser a way to spit out just the numbers rolled or something but unless you have thousands of rolls between multiple logs you aren't going to be able to get any kind of meaningful distribution.

[Dupre]

I can assure you the dice are as random as we could make them within the limitations of Turing machines and the logic from that perspective has not changed since FG was introduced. The dice are of course symmetric and evenly weighted.

When you pick up dice from the table, the orientation is randomized separately for each die using standard computational random functions. The point of release, impulse and direction of the dice throw comes straight from the user, which provides a good source of entropy. This entropy is lost when dice are thrown with a script, but for all practical purposes this should make no difference in how random the results are.

[EugeneZ]

DNH (re)raises one specific issue which is also fraying my groups' tempers: the double dice issue. DNH's description of his players' reactions are the same that I have seen in sessions where the players are rolling low. The graphical dice are great but they serve no purpose except as a target of anger when they do not show an accurate result. I think many, many users of FG would love to see that bug squashed more than nearly anything else.

[Foen]

The double-dice problem is a ruleset issue and not a bug in FG. Separately there is the bug that sometimes shows one result on the graphical dice and another in the chat - this happens so infrequently that you just need a house rule to deal with it.

[Tenian]

Based on posts in this thread, the double die graphic really does seem to be a FG2 issue not a ruleset issue:

https://www.fantasygrounds.com/forums/showthread.php?t=9731&highlight=phantom

[Foen]

Sorry, I wasn't being precise. The issue doesn't appear in the bundled ruleset or any of several others, but the clever stuff moon_wizard and Joshuha are doing with the unoffcial 4e ruleset cannot get around a problem with throwDice, dragdata and windowclasses.

The point I was trying to make is that we shouldn't throw stones (dice?) at SW for something that only arises in an unsupported/unofficial community ruleset. Although it would be nice to see a fix in the underlying FG engine which makes that ruleset more useable - along with the other fixes we'd like to see :o)

Foen

[Tenian]

Darn I was hoping you knew some secret way of making it work :)

[Dupre]

We want to provide an error free scripting interface of course and we will try and resolve any issues involving the script functions - including the double dice. We have not given this issue the priority it apparently needs.

Note however that we are not releasing patches during July due to holidays unless there is a critical issue.

[EugeneZ]

We want to provide an error free scripting interface of course and we will try and resolve any issues involving the script functions - including the double dice. We have not given this issue the priority it apparently needs.

Note however that we are not releasing patches during July due to holidays unless there is a critical issue.
This post sends warm shivers through my heart. Seriously. Thanks for the clear communique. And of course, have a good holiday. :)

Aside to Foen: The "not showing correctly" bug is very rare and forgivable as long as the single-dice is being thrown. With the double-dice issue specifically, the problem is exacerbated by the dice not showing the correct result more often than not.

[Zoso]

The players in my group hate it when one die showing a 20 and the "actual" die comes up as a 4 or something...but they're used to how it works now, only the reported number counts in our games, irregarless of what the 3d dice show.

[Lithl]

I'm personally satisfied with the degree of randomness in the dice of FG. Particularly since one of the players in our group is notorious for fudging rolls while nobody's looking, and another is notorious for horrendously bad luck. I figure, perfect or not, the digital dice even the two of them out :)

[jsuiter7]

The so-called glitch of the dice not showing the actual roll happened to my group 17 times over a course of three hours. It's not exactly a rare happening, or at least not in my group.