How reliable are dice rolling programs?

Question

Dice programs and their use around the table are on the rise:

• Are there any characteristics, qualities, or quirks of results obtained by using dice programs which might detract from play? Improve it?

• Are there dice programs which are below standard in their generation of reliable results? If so, can such results be recognized and assessed easily?

  I am asking this question about the results obtained by using dice rolling programs, not the experience or tradition of using actual dice. Personally, I prefer using dice, but am often required these days to resort to programs. Some of these programs produce what I consider to be suspicious results in much the same way those soft blue dice used to from a certain boxed game in the '80s. However, being aware of my own diceward bias, but lacking the tools to determine the veracity of my suspicions about some programs for certain, I thought this might be the place to ask~

Answer 1

Any well written dice roller will give you perfect random rolls (well, pseudo-random — the difference doesn't matter for gaming).

Some dice rollers are not well written, or depend on the underlying OS/language's source of random numbers, which itself can be well written or not.

The vast majority of the time you will find dice rollers more random than actual dice, which, being physical objects, will be flawed.

I know of one product that had to change the library it used to generate rolls because the OS implementation was poor, but that is a rare case.

Answer 2

A dice rolling program is only as good as the worst of:

1. the random number return to die-sides algorithm
2. the pseudo-random seed generator

Most are close enough to be better than dice.

Since computers can not generate truly random numbers, no die roller is truly random. The pseudorandom numbers, however can be sufficiently random enough to be more random than real dice.

A recent study found that most commercial d6 are biased significantly. The study had some flaws, but generally showed a bias for low numbers on most commercially produced d6's. (In one company's run, almost to the point of 1's being 2/7 of 1d6 rolls!) No individual batch tested showed a truly even distribution.

Some technical details...

There are two methods of random number return used in programming:

1. A fractional return on a float or double-float (double). EG: 0.348826495
2. A whole number return on an int or double-int (long). eg: 25565

given a fractional, the norm is to multiply the sides by the returned fraction, giving a fractional number between 0 and sides; round that down, getting an integer from 0 to sides-1, inclusive; then add 1, to get an integer from 1 to sides, inclusive. Due to both the nature of the fractions, has a slight bias, but it's effectively below resolution, on 16 bit machines. On some 8 bit machines using single precision, it has a notable bias on larger die types. The use of rounding routines also can affect this; the most common is a truncation, which is mathematically acceptable. §

Given an integer return, the normal mode is to perform a modulus operation (in American: find the remainder). Then add 1. 1+ ( Return modulus sides ). This introduces a very slight bias except for d4, d8, and d16. That bias is for LOW numbers, and is (maximum_return mod sides) / maximum_return. On 8 bit machines, with single precision integer returns, that's (256 mod sides)/256, for 0 for d4, d8, and d16, 1/64 for d6 and d10, 3/128 for d10, and 1/16 on d20. It's 7/32 for d100... on a 16 bit machine, with a long return (32bit integer), it's negligible for all dice below 10000 sides...

But, without looking at sources, the methods and return values can't be fairly evaluated.

The random number generation, however, varies WIDELY by OS, random number generation algorithm used, the random number seeding method, and even programming language used.

Bottom Line...

On newer machines with 16bit architectures, the skew is usually low, and slight. On 32bit machines, the skew is usually low, and miniscule. As long as you're using one for a 16 bit or newer machine, you should be as random as dice, if not more random.

---

§ the specification for the applesoft floating point routines written by Wozniak is for a 3 byte and 5 byte, using a single exponent byte, and 2 or 4 byte mantissa.

A typical (IEEE compliant) float these days is 4 bytes long, using a 24 bit signed mantissa (for ±2^23) range and an 8 bit exponent. As decimals output, the limit of precision is about 6 places. A double (double precision floating point) is 4 bytes, 53 signed mantissa and 11 exponent. Quadruple Precision is 8 bytes long with a 113 bit signed mantissa and 15 bit exponent, reliably giving 30+ place decimal accuracy. Note that in all three, the sign bit leads, then the exponent, then the mantissa. Quads are not routinely available yet.

Answer 3

Computers and their kin are deterministic machines. They have no way for generating a pure aleatory variable.

However, there are a lot of very good pseudo-random number generation algorithms that generates a sequence of numbers where the correlation between a number and the next is so weird that a human being is unable to discern a pattern.
These algorithms usually start from a seed number. Being deterministic, the same seed produces always the same sequence of numbers. To circumvent this problem, the seed is usually made time-dependent, so that a user could introduce a true aleatory component (the moment at which he invokes the die rolling).

Basically, there could be differences among dice-rolling tools according to the algorithm they implement. However, these differences are not noticeable by a human observer nor relevant on the small number of rolls and the narrow space of possible results that are usually involved in a role-playing session (they may start to be relevant on large scale statistical analysis or simulations).

I think that some dice could be less reliable than most pseudo-random generators because of physical production defects in their weighting.

Answer 4

One observation that I have had with dice rolling programs on the iPad/iPhone is that there seem to be "cheat" settings allowing the user to bias rolls to be higher (or lower) than expected.

If you are doing online gaming and the players and the GM are all using a die rolled in a virtual game table or the like, then you probably don't need to worry about this, but if you are thinking of players using die rollers on their phones while playing face to face, this could become an issue.

Answer 5

random.org produces random results by reading atmospheric changes, so that's about as truly random as you'd get. Doing tests on Random's Xd6 roller I haven't seen anything suggesting a bias - you can occasionally get some absurd results like with dice, but rolling habits don't come in. I know the biggest thing with rolling real dice for me is sometimes based on how I pick them up, and what height I roll them from, they keep repeating the same results, so I can get a good or bad streak going. This doesn't happen with random.org.

Answer 6

I tend to write a simple dice roller as the first program I create when I'm working with a new programming language.

I create it so that you can roll xDy, and I also always put in a method that will roll 1D100 10,000 times (it's really not that slow on modern machines) and do some simple stats on the outcome.

In general, I've found that MOST languages (on Windows OS) tend to generate a fairly consistent spread over the 100 numbers across 10,000 rolls. It IS, however, possible for any pseudo-random number generator to fall into a predictable pattern, if poorly implemented. My methodology doesn't check for that.

Answer 7

Are there any characteristics, qualities, or quirks of results obtained by using dice programs which might detract from play? Improve it?

Most modern computer-based random number generators produce good quality numbers, indistinguishable from truly random data. There are tests for this (e.g. the Dieharder test suite) that someone creating a low-level random number generator should use. Modern scripting languages - Ruby, Python etc - mostly use the Mersenne Twister algorithm by default, which is fast and passes these tests.

My, perhaps singular, peccadillo on this subject is the need to feel that "I" have somehow generated or contributed to the number. Too many generators in my opinion focus on the mechanics of "really random" and ignore the connection between a person and the dice they roll or cards they shuffle. In fact I have gone as far as creating a utility for that (a Ruby gem called "pool_of_entropy"), but not any usable service or application.

Are there dice programs which are below standard in their generation of reliable results? If so, can such results be recognized and assessed easily?

Some online rollers and randomising utilities unfortunately use older built-in rand() functions which are not so good. But a dedicated dice app should not (if the authors know anything about the subject).

Friends of mine who play WoW claim that the built-in roller they use in chat for deciding treasure allocation does not use a decent generator. I cannot substantiate that, but it would make sense - writers of tiny built-in utilities may well just reach for a language built-in rand(), which may be quite an old algorithm for older languages - such as C - purely for backwards-compatibility.

Recognising that a roller or utility is biased or low quality is quite hard - unless it is very obvious then you have to collect a lot of statistics, and even then it is not easy to tell when a sequence is not random, because random means "any sequence is in theory equally possible". Well said in this Dilbert cartoon.

Answer 8

I also have tried to program several dice rollers in different languages, and usually the results seem to be random enough.

Other point is that by definition true randomness it's not really something you can verify but I agree that in general, most dice rolling programs can be as random or more than real dice.