BGA_rand is not very random

[espenvh]

I've had the same feeling. I guess all you have to do to check this out is run random generator a huge number of times and check the statistics.

[RicardoRix]

Is 500,000 samples big enough?

https://boardgamearena.com/forum/viewto ... and#p59122

[byte5115]

Is 500,000 samples big enough?

https://boardgamearena.com/forum/viewto ... and#p59122

Yeah , that's big enough . I am very surprised that the bga_rand is using random_int . But oh well , maybe i write a small PRNG component for php.

[RicardoRix]

BGA Staff have very carefully considered the random topic here. After all, their livelihoods partially depend upon it. But as previously stated they will not respond, and they don't go down rabbit holes. If you look at the backgammon forum for example, you can't blame them.
You'll need to provide actual proof to the contrary.

bga_rand() is the answer. And it works.

[Rampoulin]

I am new to BGA dev, but why are you not using PHP base function mt_rand?

[robinzig]

I am new to BGA dev, but why are you not using PHP base function mt_rand?

From the docs:

Code: Select all

bga_rand( min, max ) This is a BGA framework function that provides you a random number between "min" and "max" (inclusive), using the best available random method available on the system.

This is the preferred function you should use, because we are updating it when a better method is introduced.

As of now, bga_rand is based on the PHP function "random_int", which ensures a cryptographic level of randomness.

In particular, it is mandatory to use it for all dice throw (ie: games using other methods for dice throwing will be rejected by BGA during review).

Note: rand() and mt_rand() are deprecated on BGA and should not be used anymore, as their randomness is not as good as "bga_rand".

[Indubius]

I am a professional systems tester, albeit retired. Based on the collection of user experiences there “is” something wrong with the random number generation; or rather, the output of the gba_rand() function that is received by the game in the current PHP scaled environment. This problem is not discoverable with single-instance testing.

I can’t picture each game being run on its own virtual machine. That would be very expensive hardware-wise. BGA must be trying to run their games using scaled instances of each game. It is well known that PHP if not properly architected can be wonky in its behavior when it otherwise runs fine in a single instance.

Recommend the following Architecture: Have a separate process that continuously generates random numbers placing them in a queue. Have a separate process doing queue-pops using a process lock algorithm. This will guarantee that every game will get a new random number with every request. (A single game requests the resource and locks the game to the random number generator process until it gets its random number then releases the process allowing another game to get a random number.)

If the random number generator process proves too slow due to the lock algorithm, multiple random number processes can be run each creating a resource that is specifically assigned upon game generation.

Just some thoughts. I have seen issues like this before.

[Kayvon]

There have been many elaborate (and less elaborate) suggestions for "fixing" the RNG. All suffer from one single problem: A lack of evidence that a problem occurs. At best, players complain that they've witnessed an unusual incident. The problem with that reasoning is that an unlikely incident that happens every 1 in 10,000 games will happen several times a day on this site. When millions of games are played a week, we'll see hundreds of such incidents every week.

Before proposing a fix, you need to establish that there's a problem. That can only be done with a large sample size, not a few cherry-picked games.

As previously posted, here's proof that it's random in the form in half a million random samples:
https://boardgamearena.com/forum/viewto ... and#p59122

Your move. Show us, don't just tell us, how it's biased. We need a large sample set that's blindly gathered, not a general feeling or unlucky game. After all, even real life dice get "stuck" on certain numbers from time to time.

[Indubius]

Fair enough.

The testing you linked did not recreate the conditions that I identified that were the source of the problem.

I accept the challenge, but it is going to take me a bit of time to code such a recreation.

I will be back in touch.