What Is a Good Random Number Generator for a Game

What is a good random number generator for a game?

George Marsaglia has developed some of the best and fastest RNGs currently available
Multiply-with-carry being a notable one for a uniform distribution.

=== Update 2018-09-12 ===

For my own work I'm now using Xoshiro256**, which is a sort of evolution/update on Marsaglia's XorShift.

=== Update 2021-02-23 ===

In .NET 6 (currently in preview) the implementation of System.Random has been changed to use xoshiro256**, but only for the parameterless constructor. The constructor that takes a seed uses the old PRNG in order to maintain backwards compatibility. For more info see Improve Random (performance, APIs, ...)

What Type of Random Number Generator is Used in the Casino Gaming Industry?

For a casino gaming applications, I think the seeding of the algorithm is the most important part to make sure all games "booted" up don't run through the same sequence or some small set of predictable sequences. That is, the source of entropy leading to the seed for the starting position is the critical thing. Beyond that, any good quality random number generator where each bit position as has a ~50/50 probability of being 1/0 and the period is relatively long would be sufficient. For example, something like the Mersenne twister PRNG has such properties.

Using cryptographically secure random generators only becomes important when the actual output of the random generator can be viewed directly. For example, if you were monitoring each number actually generated by the number generator - after viewing many numbers in the sequence - with a non-cryptographic generator information about that sequence can lead to establishing information about all the internal state of the generator. At this point, if you know what the algorithm looks like, you would be able to predict future numbers and that would be bad. The cryptographic generator prevents that reverse engineering back to the internal state so that predicting future numbers becomes "impossible".

However, in the case of a casino game, you would (or should) have no visibility to the actual numbers being generated under the hood. Each time a random number is generated - say a 32-bit number - that number will be used then, for example, mod 52 for a deck shuffling algorithm....no where in that process do you have any idea what numbers were being generated by the algorithm to shuffle that deck. That is, most of the bits of "randomness" is just being thrown out and even the ones being used you have no visibility to. Therefore, no way to reverse engineer the state.

Getting back to a true source of entropy to seed the whole process, that is the hard part. See the Wikipedia entry on entropy for some starting points on techniques.

As an aside, if you did want cryptographically sequence random numbers from a "regular" algorithm, a simple approach is to take a few random numbers in sequence, concatenate them together and then run something like MD5 or SHA-1 on them and the result is just as random and also cryptographically secure. That is, you just made your own "secure" random number generator.

What RNG(random number generator) algorithm suits for poker cards shuffle?

8e+67 is a lot big number, but it is not very high in data size. It is only 226 bit in data length. 28 bytes.

You may consider using a CSPRNG, a cryptographically strong pseudorandom generator, i.e. an RNG which generates enough strong randomness to be usable for cryptography.

Sometimes also the CPU has a true random number source, it is fast. Here I describe the CSPRNG.

On Linux, you can simply read out the random bytes from the /dev/urandom character device file.

The best choice for random number generator

I only can speak about mwc-random.

1. It is fast ~15ns per Word32 on Phenom II. If you want to measure how fast is it on your computer it comes with benchmark set. Still it possible to trade period for speed. Xorshift RNG should be faster but have shorter periods 2^32 or 2^64 instead of 2^8222.

2. Randomness. mwc-random uses algorithm MWC256 (another name: MWC8222) which is not cryptographicaly secure but fares well in randomness tests. In particular mwc-random passes dieharder randomness test.

Random number generator game in C

Problems :

scanf("%d", userin); //you are sending variable 

• This is not right as you need to send address of the variable as argument to the scanf() not the variable

so instead change it to :

scanf("%d", &userin); //ypu need to send the address instead

---

and rand()%11 would produce any number from 0 to 10 but not from 1 to 10

as other answer suggests, use :

(rand()%10)+1 //to produce number from 1 to 10 

---

Solution :

And also include time.h function to use srand(time(NULL));

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
    srand(time(NULL));

    int userin;

    printf("Guess a number from 1 to 10\n");
    scanf("%d", &userin);
    int r = (rand() % 10)+1;

    if (r==userin)
    {
        printf ("you are right");
    }
    else
    {
        printf("Try again");
    }

    return 0;
}

---

Why use srand(time(NULL)) ?

• rand() isn't random at all, it's just a function which produces a sequence of numbers which are superficially random and repeat themselves over a period.

• The only thing you can change is the seed, which changes your start position in the sequence.

and, srand(time(NULL)) is used for this very reason

What is the best pseudo-random number generator as of today?

Try MT's successor: SFMT ( http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html ). The acronym stands for SIMD-oriented Fast Mersenne Twister.
It uses vector instructions,
like SSE or AltiVec, to quick up random numbers generation.

Moreover it displays larger periods than the original MT: SFMT can be configured to use periods up to 2²¹⁶⁰⁹¹ -1.

Finally, MT had some problems when badly initialized: it tended to draw lots of 0, leading to bad quality random numbers. This problem could last up to 700000 draws before being compensated by the recurrence of the algorithm. As a consequence, SFMT has also been designed to leave this zero-excess state much quicker than its elder.

Check the link I've given at the beginning of this post to find the source code and the scientific publications describing this algorithm.

In order to definitely convince you, you can see here http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/speed.html a table comparing generation speeds of both MT and SFMT. In any case, SFMT is quicker while laying out better qualities than MT.

-- edit following commentaries --

More generally, when you're choosing a PRNG, you need to take into account the application you're developing. Indeed, some PRNGs fit better to some applications constraints. MT and WELL generators for instance aren't well suited for cryptographic applications, whereas they are the best choice when dealing with Monte Carlo Simulations.

In our case, WELL may seem ideal thanks to its better equidistribution properties than SFMT. Nonetheless, WELL is also far slower and he's not able to display periods as large as SFMT.

As a conclusion, a PRNG cannot be stated as best for all the applications, but for a particular domain and in particular circumstances withal.

What is a good random number generator for a game?

George Marsaglia has developed some of the best and fastest RNGs currently available
Multiply-with-carry being a notable one for a uniform distribution.

=== Update 2018-09-12 ===

For my own work I'm now using Xoshiro256**, which is a sort of evolution/update on Marsaglia's XorShift.

=== Update 2021-02-23 ===

In .NET 6 (currently in preview) the implementation of System.Random has been changed to use xoshiro256**, but only for the parameterless constructor. The constructor that takes a seed uses the old PRNG in order to maintain backwards compatibility. For more info see Improve Random (performance, APIs, ...)

Need for predictable random generator

I agree with the earlier answers that real randomness in small runs of some games is undesirable -- it does seem too unfair for some use cases.

I wrote a simple Shuffle Bag like implementation in Ruby and did some testing. The implementation did this:

• If it still seems fair or we haven't reached a threshold of minimum rolls, it returns a fair hit based on the normal probability.
• If the observed probability from past rolls makes it seem unfair, it returns a "fair-ifying" hit.

It is deemed unfair based on boundary probabilities. For instance, for a probability of 20%, you could set 10% as a lower bound and 40% as an upper bound.

Using those bounds, I found that with runs of 10 hits, 14.2% of the time the true pseudorandom implementation produced results that were out of those bounds. About 11% of the time, 0 critical hits were scored in 10 tries. 3.3% of the time, 5 or more critical hits were landed out of 10. Naturally, using this algorithm (with a minimum roll count of 5), a much smaller amount (0.03%) of the "Fairish" runs were out of bounds. Even if the below implementation is unsuitable (more clever things can be done, certainly), it is worth noting that noticably often your users will feel that it's unfair with a real pseudorandom solution.

Here is the meat of my FairishBag written in Ruby. The whole implementation and quick Monte Carlo simulation is available here (gist).

def fire!
  hit = if @rolls >= @min_rolls && observed_probability > @unfair_high
    false
  elsif @rolls >= @min_rolls && observed_probability < @unfair_low
    true
  else
    rand <= @probability
  end
  @hits += 1 if hit
  @rolls += 1
  return hit
end

def observed_probability
  @hits.to_f / @rolls
end

Update: Using this method does increase the overall probability of getting a critical hit, to about 22% using the bounds above. You can offset this by setting its "real" probability a little bit lower. A probability of 17.5% with the fairish modification yields an observed long term probability of about 20%, and keeps the short term runs feeling fair.

---

Related Topics