3D dice results are not random

[Neovirtus]

Based on this thread I told my players about the potential issue at the beginning of last night's session and recommended them to use the manual mouse roll to truly randomize the initial vector of the roll (if they were concerned about the kind of imbalances you have calculated). I was particularly concerned that one player who had been having bad luck was going to instantly blame all his bad rolls on this...

Turns out he had been rolling with the mouse the whole time and didn't realize he could just double click to roll, lol. So fortunately no great strife resulted at my table.

[Weissrolf]

Frankly, at this point I fully expect manual mouse-movement to just lead to the very same distributions that I measured for click-rolling. Click-rolls use random vectors to initialize the 3D roll and unless FGU uses an external library specifically for this they use the very same math.random (C rand) RNG that is used in the Instant Dice extension (or /die).

So either the initial random vector creation is messed up in FGU (worse than FGC) or the whole 3D physics engine results in originally more random vectors becoming less random. Both are possible, but I wouldn't wonder if it was the latter, especially seeing how Classic seems to do better than Unity.

At least the Instant Dice extension allows to turn off 3D dice for click/automation-rolls while leaving drag-rolls intact. That's essentially what I was asking to be implemented as an option in the first post.

When you want less 1 and 20 results on D20 rolls, though, then better keep using 3D (click-)rolls.

[Neovirtus]

Hmmm, seeing as the roll is completely physics based, I assumed the distribution you saw would be tied to the only RNG aspect of that process, namely the initial random vector. I figure manually generating that initial vector would only improve things. As I've mentioned previously in the thread, I'm less concerned with the the distribution of results being off than I am with there being trends in the results. If nothing else, manual rolling of physical dice should limit trends I would think.

[Weissrolf]

If the random vector is based off the same RNG as /die and Instant Dice (math.random = C rand) then either creation of said vector is flawed or the physics processing afterwards. Classic looks quite a lot better and judging from the visible dice movements the physics are different, the RNG seems to be the very same.

It's worth mentioning that math.random = C rand is differently implemented on each platform (Windows, OS X, Linux). Especially OS X is said to suffer from its implementation (based/equal BSD).

[eporrini]

I hope the Smiteworks team decides to take this seriously. Not having some level of integrity with rolling is a significant and foundational game issue. I am torn with using the instant dice extension as no rolling animation at all takes away from the joy of rolling on the virtual tabletop. I am leaning towards asking my players to roll manually whenever possible for now, even though I know certain number of rolls will get triggered through click or automatically.

I am re-petitioning the developers to work towards a real solution for this ASAP as a priority over other enhancements. I feel this is significant enough that I would use it as a differentiator when deciding on what virtual tabletop I would want to use to play on. The physics don't need to add up to "perfectly random", but we need something dependable enough that we don't feel like we are playing a rigged game with weighted dice.

[Weissrolf]

Instant Dice only removes click-rolls and automatic-rolls. You can still drag every control onto the chat or tokens to do a 3D roll. So it's kind of best of both worlds. Make sure to download my mod, though, else it rolls the same results every time you restart FG.

[LordEntrails]

I'm still waiting for a comparison to physical dice. We know physical dice are not random, or anywhere near random, so until their is info that FGs dice are more or less random than physical dice, I don't personally have enough info to be worried about it.

The other point mentioned by Weissroff just a few points ago is that the math.random function is implemented differently based on platform, so curious how these comparisons change per platform.

Also, from what I can tell, all these results were created by a script and a as yet unproven methodology. Admittedly I don't understand much of what has been posted here, but I still don't know how repeatable these results are in a play situation versus script generation where the rolls are created at regular intervals.

Finally, I just don't see this having a big effect on my game, but understand that others might see it differently.

[Jiminimonka]

I'm still waiting for a comparison to physical dice. We know physical dice are not random, or anywhere near random, so until their is info that FGs dice are more or less random than physical dice, I don't personally have enough info to be worried about it.

The other point mentioned by Weissroff just a few points ago is that the math.random function is implemented differently based on platform, so curious how these comparisons change per platform.

Also, from what I can tell, all these results were created by a script and a as yet unproven methodology. Admittedly I don't understand much of what has been posted here, but I still don't know how repeatable these results are in a play situation versus script generation where the rolls are created at regular intervals.

Finally, I just don't see this having a big effect on my game, but understand that others might see it differently.

I have played around a table with dice and people have got upset that their rolls are always low. They never complain about the dice when they get a crit or max damage roll though.

[Trenloe]

I feel this is significant enough that I would use it as a differentiator when deciding on what virtual tabletop I would want to use to play on.

It can only be used as a differentiator if this is truly a big enough issues for you and your players, and if *exactly* the same tests are done on the VTTs you’re comparing. Otherwise it can’t be a differentiator if you can’t tell the difference.

The physics don't need to add up to "perfectly random", but we need something dependable enough that we don't feel like we are playing a rigged game with weighted dice.

You’re the second person to use this type of language in this thread. How does this mean you’re playing a rigged game or you’re getting cheated? Does FG pick a bad number for your roll just to cheat you or rig the result specifically to someone’s detriment or advantage? No, it doesn’t.

I think some perspective is needed here. Weissrolf has done an interesting statistical analysis. It’s very theoretical and doesn’t simulate the timing and spread of different dice rolls within an actual gaming session. Even if it did, the results don’t indicate anything regarding being cheated or playing in a rigged game.

[Weissrolf]

I'm still waiting for a comparison to physical dice.

No one can give you that, it's just not possible in a practical way. But I gave you a comparison to Classic's physics engine, which creates different and arguably better results to Unity's engine.

We know physical dice are not random, or anywhere near random,

We know that we all have a whole satchel full of dice that all behave differently and none of them move in the air and on the table like they do in FGU.

In FGU dice are always weighted the same. My chance to throw a 3 instead of a 20 are 16% higher in FGU and my chance to roll double 3s instead of double 20s are 37% higher. Does every of my physical D20 in my satchel follow that exact same pattern at every table ?

so until their is info that FGs dice are more or less random than physical dice, I don't personally have enough info to be worried about it.

Given the many years of discussion and "confirmation bias" arguments that seem to have happened in the past it does seem like other users are worried, though.

The other point mentioned by Weissroff just a few points ago is that the math.random function is implemented differently based on platform, so curious how these comparisons change per platform.

They likely won't. I already proved that my Windows 10 based math.random results are far superior to 3D dice results on the same computer, I do have access to OS X and Linux, but shy away from the additional work.

Click-rolls and automation-rolls are always based on a random seed, which is always prone to the same limitations as /die and math.random. Unless FGU uses a superior library or Lua based RNG for 3D dice randomness, that is. Would FGU allow Lua's "setmetatable" then we implement (copy & paste) free MIT license based RNGs ourselves. Or FGU could make use of a much better RNG than math.random (C rand) by using one of the free libraries out there.

Also, from what I can tell, all these results were created by a script and a as yet unproven methodology.

No, they were not. Autohotkey was used to either type "/die d20{enter}" into FG's chat window or to click on a character sheet button. Then FG's chatlog file was parsed (much of it manually) and converted to formats suitable for scientifically established randomness tests and Excel (for graphs and further calculations).

how repeatable these results are in a play situation versus script generation where the rolls are created at regular intervals.

Unless FG initiates a new seed with every roll it does not matter how long the intervals are and either random is random or it is not. Only rolls matter. I did try to use a new seed for every roll, but this was not possible in (FG's) Lua, only one seed per restart/reload could be set for math.random.

Finally, I just don't see this having a big effect on my game, but understand that others might see it differently.

Switching from Classic to Unity lowered my chances to roll a 1 or 20 by 10%. Sure makes for a less "extreme" gaming experience (crits & fumbles).