[Noldona]

Like some (and probably many) of you, I have found myself programming the quintessential dice roller program. Others, along with myself, have written it in many different languages many of time. The problem I found with the standard format (which is written in pseudo-code below) is that it tends to roll lower then real dice do. As such, the program is really only preferred when there are no other means of rolling dice. Heck, paper-craft d6s roll better on average then a dice roller software does. For example, when rolling 3d6, you have the possibility of 3 to 18. When rolled with a dice roller you average about 10. When rolled with real dice, you average is closer to 13. Thus, the dice roller usually rolls lower then real dice. Most likely, the problem with dice rollers stems from the fact that the standard format used the randomize function built into many different languages. Even seeding it with the timer still only gives us a pseudo-random result.

RollDice (# of dice, # of sides) {
	total = 0
	for 1 = 1 to # of dice {
		total = total + (rand() * # of sides) + 1
	}
	return total
}

I was wondering if someone had an idea on a better way to write this function to make the results more like real dice? Is this even possible to do? Is there maybe a better algorithm to generate the random number then whatever the one built in is?

[grimpirate]

Without using a random number generator there is no way of generating dice rolls. However, this doesn't mean that the real world and computer example are not linked. In face the bell curve for a 3d6 roll is as follows:

[3d6] => Array
		(
			[3] => 1
			[4] => 3
			[5] => 6
			[6] => 10
			[7] => 15
			[8] => 21
			[9] => 25
			[10] => 27
			[11] => 27
			[12] => 25
			[13] => 21
			[14] => 15
			[15] => 10
			[16] => 6
			[17] => 3
			[18] => 1
		)

As you can see the most commonly occurring rolls are 10 and 11. Which means that your computer dice roller is behaving correctly. However, the bias which exists in the real world, as you put it, is due to the fact that you're likely not using precision dice. Due to the difference in moments of inertia that that pits and markings put on each side there is a bias which causes deviation from actual mathematical probability in the dice. Your program isn't non-random, it is in fact your dice that are.

[Noldona]

I see your point, and you are right the dice used by the typical tabletop roll playing group is not precision dice like you would find in Las Vegas where the pips have been filled in so all sides of the die weight the same.

Nevertheless, rolling higher is often the preferred result for most rolls. In such cases, real dice are preferred over a dice roller due to the bias of the real dice. Now this normally is not an issue as most people who play tabletop rpgs have 1 or more sets of dice which to roll with.

However, in cases of software designed to help run games (as such is the case with my current project), it would be better if the software were to roll the dice for the GM when automating tasks such as rolling up monsters. If the software could roll more like real dice even if the real dice do have a bias, this would be preferred. Is there a way to write this function as to simulate that bias of real dice when rolling?

[NickDMax]

the default random number generators used in computer languages are rubbish. To top this most people use the modulus operator which only compounds the problem by only using the lower bits.

One thing you can do is use a better Pseudorandom number generator. The Mersenne twister is much better than the Linear congruential generators used by rand() and the like.

There are also libraries for generating random data from stochastic processes (like turning on your sound card and running the input though a high pass filter and extracting bits). These kinds of random number generators are in someways better than pseudo-random number generators, since there is generally not "formula" that someone can use to guess the next bit, BUT often these are not always statistically ideal.

If you would like an introduction to random number generators I have a tutorial here on DIC. There is also a snippet on the Mersenne Twister. There is also a tutorial on trying to improve the random distribution of pseudorandom number generators.

Of course these were all in C++, but it is not hard to find these algorithms in other languages.

By the way... perhaps a better way to roll a die is to use the random number generator to "shuffle" an array of 6 numbers, and then choose one side that is always considered "up".

[grimpirate]

I agree with what NickDMax is saying, however, I will again note that it's not so much the randomness factor that you need to look at as it is the introduction of a bias into the random generator. One way you could do that is to look at the different probabilities of rolling certain scores using different software dice, for instance, d8s will have a higher percentage of rolling the number 13. Then, rather than generating 3 random numbers you could generate a number from 0 to 100 and use that in comparison to the probabilities of the d8 rolls, but to a maximum point value of the d6. For instance, with 2d6s the values range from 2 to 12 with 2d8s they range from 2 to 16. Use the probabilities of the 2d8s from the 2 to 12 range in order to act as the 2d6 probabilities, generate the percent number and take the result accordingly.

[Noldona]

@NickDMax, I will definitely have to check those links out. As for the examples being in C++ that is no problem for me. I have programmed in that for many years along with several other languages. My current project is being written in Java due to the ease of portability and the fact that I just recently moved to a new programming shop for work and had to learn Java. But, it should be easy enough to translate any code that I might use.

@grimpirate
I had been thinking of doing something similar to that. In the idea I had been sketching down, I figured I would calculate the probability of each possible result and then generate a random number (i was thinking 1 to 100) and multiply that number by the probability the result would come up. The possible result with the highest random number * probability would be the one that is rolled. After reading you reply about the bell curve though, I figured I should add that into calculating the probability and just skew the bell curve a bit so the high end would fall a couple numbers higher then it normally would. Although, the thing about doing it that way would be that you would only get the total and not each individual die roll. My current code that uses code similar to what I originally posted has 2 functions that return an int of the total and a string that has all the dice rolls as well as the total.

[NickDMax]

Another thought would be to actually model a die and use a "random walk" from one face to another to another etc. This would simulate "rolling" more efficiently than just choosing random values.

By not exactly using a random walk, you could actually add the ability for users of a game to choose how they roll. For example you could allow one option to only use tip upwards and tip to the right... and then even allow the user to choose a weight for each direction (more up than to the right etc.)

This would give the user a sense of control, and yet not really make much difference in the outcome (you may notice some statistical oddities, but chances are they will all be in the head of your users who WILL invent superstitions about what is the best way to roll the dice).

Just a thought...

[Bort]

NickDMax, on 13 Aug, 2008 - 07:27 AM, said:

Another thought would be to actually model a die and use a "random walk" from one face to another to another etc. This would simulate "rolling" more efficiently than just choosing random values.

By not exactly using a random walk, you could actually add the ability for users of a game to choose how they roll. For example you could allow one option to only use tip upwards and tip to the right... and then even allow the user to choose a weight for each direction (more up than to the right etc.)

This would give the user a sense of control, and yet not really make much difference in the outcome (you may notice some statistical oddities, but chances are they will all be in the head of your users who WILL invent superstitions about what is the best way to roll the dice).

Just a thought...

Oh, I love this. I know how superstitious my RPG group is

[Noldona]

Don't know if I want to implement the who user input about "how" they roll thing. At least not for the first version. Maybe release that as a future plug-in. However, the "random walk" method should be relatively easy to implement as long as the number of sides is even. On real dice (well at least the properly laid out one, I have seen ones that don't follow this) the opposite sides always equals the number of sides + 1. So you only have to figure out the he placement of half the numbers which there should be some pattern for. Will have to look into this.

[Noldona]

I checked out the links that you posted NickDMax and with some modifications to make it work in Java, and some test rolls, I think the code Voodoo Doll posted works pretty well. Only problem I have seen so far with it is the seeding. Since it only excepts longs, I modified the default value to seed with the current time instead of 1 which, as we know, is the number of milliseconds since Jan 1, 1970 00:00:00 GMT. I know this is part of the issue with the built in random number generator but it is the best way I know how to ensure you never have the same seed.

After some more testing, it looks like it works well with given a range of 3 - 18. This has good distribution over the possible numbers. However, when you give it the range of 1 - 6 and do it 3 times then add the results together, you get the same issue as you do with the built in random function. So I guess next up is to try that "random walk" idea out.

This post has been edited by Noldona: 14 August 2008 - 07:49 AM

[mpriest1]

Noldona, on 11 Aug, 2008 - 09:23 AM, said:

Like some (and probably many) of you, I have found myself programming the quintessential dice roller program. Others, along with myself, have written it in many different languages many of time. The problem I found with the standard format (which is written in pseudo-code below) is that it tends to roll lower then real dice do. As such, the program is really only preferred when there are no other means of rolling dice. Heck, paper-craft d6s roll better on average then a dice roller software does. For example, when rolling 3d6, you have the possibility of 3 to 18. When rolled with a dice roller you average about 10. When rolled with real dice, you average is closer to 13. Thus, the dice roller usually rolls lower then real dice. Most likely, the problem with dice rollers stems from the fact that the standard format used the randomize function built into many different languages. Even seeding it with the timer still only gives us a pseudo-random result.

RollDice (# of dice, # of sides) {
	total = 0
	for 1 = 1 to # of dice {
		total = total + (rand() * # of sides) + 1
	}
	return total
}

I was wondering if someone had an idea on a better way to write this function to make the results more like real dice? Is this even possible to do? Is there maybe a better algorithm to generate the random number then whatever the one built in is?

I think for this code that you are trying to run is the same code that I just finished working on in my class and I would suggest researching the Math Function by doing a Google search - God how I love Google anyway It was a great deal of help for me to get the code to run with a random number and I hope that it is what you are looking for. Good luck.
[quote]

[Momerath]

Noldona, on 11 Aug, 2008 - 09:23 AM, said:

For example, when rolling 3d6, you have the possibility of 3 to 18. When rolled with a dice roller you average about 10. When rolled with real dice, you average is closer to 13.

Unless you have warped dice, no it isn't. The average roll on a 6 sided die would be 3.5 (1+2+3+4+5+6 = 21/6 = 3.5). Rolling 3 dice would average 10.5.