I've noticed that in most games the dice roll difference between the two players is almost always 0 or 1. Two parts of recent games:

5-6, 4-5, 3-3, 6-1, 5-4, 2-3, 1-1, 4-5, 3-3 … and

another game 2-3, 1-2, 5-5, 3-4, 2-1, 5-6, 4-4, 2-3, 6-6.

Is it just me, or is the game programmed that way ??

I had that feeling too and expected that it was only a feeling …

I checked it by the complete data of 10 of my completed matches, choosen random. Only looked at the first 52 turns.

You are right, the die rolls are not right!!!!!!!!!!!

The everage difference between 2 random die rolls should be 1,944. In my 10 complete games it was 1,984. That looks like a normal deviation. But …

A) The average difference of a throw by red compared to the former throw by yellow is 1,272.

B) The average difference of a throw by yellow compared to the former throw by red is 2,725.

Both numbers should be ca. 1,944.

I wait with my matches untill this problem is solved. The chance-calculation in the matches is even too hard for me when I must estimate how the computer 'randomizer' divides the die-rolls. And it's no fun to put that into your considerations in the matches.

Here the data:

A) 26 - 31 - 34 - 38 - 28 - 32 - 32 - 34 - 33 - 30

(sum of differences in 25 differences per match)

B) 65 - 63 - 69 - 67 - 61 - 65 - 69 - 66 - 64 - 66

(sum of differences in 24 differences per match)

:-(

Corné

In the data you see that it is not just coincidental in these 10 matches I looked at.

I now looked at the total difference between the 'die-rolls' of the 2 players when you add all 'die-rolls' per player. That looks more normal. A difference of 8 pips on the die between the 2 players, on average over the 10 matches. A difference of ca. 9 pips is normal.

By the way, I think that Richard programmed the kick-of-die-roll different to the rest of the game, in accordance to the boardgame. In the boardgame both players throw the die and the highest player starts with the difference between the 2 throws. So there are per player 5 chances to start with 1, 4 chances to start with 2, 3 chances on 3, 2 chances on 4 and 1 chance on 5. So “6” is not possible at the start and I didn't see a “6” in this version at the start too. While “1” happened often at the start. So that is normal, the data in my former message is not normal.

A computer cannot 'roll a die' completely fair (and a real die can't be completely in the right shape too) but this die-simulator is really wrong.

:-(

Corné

A computer can roll a die as fairly as you'd like, if it uses the timing of user input as a seed. If when a player moves, the miliseconds at the time of the move influences the roll of the next die, you're fine.

And for practical purposes, there are random number algorithms which are fairer than normal dice without resorting to user input.

There was really serious bug. I used this algorithm:

specialNumber = k1 * gameNumber + k2 * moveNumber + k3;

Random rnd = new Random(specialNumber);

dice = rnd.nextInt(6)+1;

It is now all right.

With a formula like that, don't you run the risk of someone deducing your Ks? Wouldn't it be safer to have a server-wide variable, which is used as the seed for the next random number and then gets the value of that random number as the seed for the next one? An advantage of that is that no one will be able to track the order in which the numbers are generated in all the games together.

I am currently playing a game with Barry (#78094) and in my first 7 moves I had six times 1 and one time 3! Is that my bad luck or a bug of the new die-throw?

If I understand you right, Richard, You use a new instance of class Random for every random number you need (or at least you did so until changing the algorithm).

Usually the random number generators are designed so, that one should initialise the generator instance (here: instance of class Random) only once, and then call the method for creating a random number (here: nextInt) for this instance every time one needs one, without resetting the instance in between.

I suggest to have only one instance of class Random for all games together, and modify the result of nextInt() with the game data:

Random rnd = new Random(1); // created only once and used for all games

…

int specialNumber = k1 * gameNumber + k2 * moveNumber + k3;

specialNumber &= 0x7fffffff; // prevent overflow into sign

int dice = rnd.nextInt(6) + specialNumber;

dice %= 6;

dice += 1;

k1 and k2 should be relatively prime to 6, i. e. they should not contain one of the prime factors 2 and 3. k3 is not important and can be 0.

This makes it very difficult for the players to determine anything for predicting the die throw, because the throw depends not only on the game- and move-number but also on the state of the instance rnd. And this state depends on the number of previous calls of nextInt(), i. e. on the number of moves made in all games.

I think it is even not necessary to modify the throw with 'specialNumber' (but it can't be a mistake).

http://www.littlegolem.net/jsp/game/game.jsp?gid=83092&nmove=29

Until move 29, in 7 out of 14 cases the dice for the yellow player shows an “1”.

Is the red player a yet unknown admin? ;-]

@Richard:

Last year I wrote a simulation program which permanently needs a lot of really random numbers. The best solution of many was to download and use one of the large random number files from www.random.org! These numbers are hardware generated and proofen to be perfectly random. For every StreetSoccer die just read out the next random byte(%7) from the file. At the end of the file jump back to the beginning.

Very easy to program and more random than any algorithm.

Errata:

random byte(%7) is wrong - must be:

die = random_org_byte % 6 + 1;

Richard, will be possible to change ramdon dice alghoritm with files from www.random.org ???

WHEN???

Thanks for info.

Burton.