Question

When grabbing Random().nextInt(int) integers for two entirely separate mechanics (e.g. attack rolls and superficial random animations), is there any reason to use separate Random() instances for each mechanic? For example, might it help ensure a more even dispersion of random values for each mechanic?

–

Similarly, in a continuing game where an even dispersion of random values is important, is there any reason to store a Random()’s instance or seed with saved game data — and pick up where it left off when the game is loaded — rather than creating a new instance each time?

For example, in a turn-based game where the player may be lucky or unlucky on each turn, is it possible that creating a new Random() instance on game load could bring about a situation where a player is abnormally lucky or unlucky?

–

(Note: When I say “creating a new instance”, I mean using just “Random random = new Random()”, with no seed specified.)

Thanks!

Answer 1

No. No reason. Use the same instance.

With some exceptions:

1. The predictability of the pattern is desired. For instance, to seed a particular “solitaire game number” or to “ensure the same random events occur” (e.g. stop save/load “cheating” 😉 It may require extra work to utilize the PRNG repeatability as the internal state is not exposed. This is a business rule.
2. Threading is used, and there is a performance issue with using the same Random instance. (Random is Thread-safe in Java, I previously misspoke.)

The issue with same-seeding is that the PRNG sequence will start the same (and thus be known or, usually more often, causes the same [colliding] sequence and “lack of randomness”). The quality of the randomness of the sequence, however is not affected.

As an aside: thankfully Java has a pretty good default Random constructor:

Creates a new random number generator. This constructor sets the seed of the random number generator to a value very likely to be distinct from any other invocation of this constructor.

In JDK 6 it is implemented as:

this(++seedUniquifier + System.nanoTime());

(Of course, it’s possible to imagine/contrive a degenerate scenario with the above implementation as well…)

Happy coding.