Ever wanted to set your own seed in a random number generator? Ever wanted to see what one looks like? Well have no fear, since this simple piece of code shall show you how it looks like!



The major caveat is that it's a Lehmer Random Number Generator (which I think is what Math.random() uses anyways), which means it cycles a full period multiplier (that is modulus compatible) every (2^31-1)nth time. For most cases it is useful though. The benefit of having this separate is because Math.random() doesn't seem to allow you to set your own seed which is crucial when testing things out or making sure your gameworld is unique from someone else's, and remains the same uniqueness by storing the seed.

It's also useful for anti-cheating. Imagine a chest that has randomized loot. If the seed was selected "at random" (by using the system clock), then each time you reload your game and open that chest something different appears, which could be a good item, and so you could save-farm it for a good item. However, by storing the seed you are no longer picking "at random" anymore and you'll get the same item out of the chest each time. By choosing a different seed per game means different items per game, which means no two games are the same, but two saves of the same game will at least be the same, which is a good property to have to combat "random" cheating.

But, I myself abuse randomness all the time in games. The downside is it can be predictable. In the game Kings Bounty, the turns are based on a saved seed (which is based on the last 'n' turns you did). That means I can load the game, go into a battle and if I do the same moves I expect the same retaliations from the enemy. I can then die, reload, and then restart knowing exactly how they'll retaliate and be ready for it. So there is this downside as well! So case in point, some things need to be truly "random" while other things should not. As a game designer you choose what should and should not be stored as a seed.

There you go guys! I hope I've enlightened you on some things.

To use:

Code: (javascript) [Select]

// setup random generator with system-clock time.
var rand1 = new Random();

// setup random generator with fixed seed.
var rand2 = new Random(123456789);


var r = rand1.next(); // exactly the kind of number you get from Math.random()

This is cool, thanks. The real use of it will be in network-synchronized games, where you send the seed to all clients to ensure they get the same random number.
I don't know enough about statistics to know how good its distribution is. Does it give reasonably even number distribution? (i.e. you don't tend to get numbers less than 0.6 or you don't get more even than odd numbers etc - I recall reading somewhere (Effective Java, back when I was into horrible languages) that a lot of random number algorithms have uneven properties like that.)

It gives a uniform distribution by default, we can call it 'equilikely'. So it's not like C's Rand function that (used to) alternate between even and odd numbers. A good random number generator should at least be perceptibly random, of course it's not totally random and doesn't repeat the same number more than once within its period. So, it's not akin to catching values from atomic decomposition which might be truly random? There are other cryptopgraphic ways of making a random number generator but they are far more theory intensive and really only needed for true key obfuscation they may not even rely on a seed. Games really need to use a seeded RNG, for the ideas I and you mentioned above.

Oh, and you'll get better results sampling over the entire 2^31-1 field of possibilities. If you only take the first 'n' you may not get a good distribution. That said, the multiplier I use 48271 has been shown to make a decent equilikely distribution all around and so is a good, safe number to use even for the first 'n'.

Remind me to fork the Gist soon to use a Mersenne twister