Hi guys,
I’m using @FManga 's online Python editor to make a game as I’m trying to ease myself into getting to learn Python.
My current problem is random number generation is like shooting in the dark. I’ve tried various methods explained here https://www.pythonforbeginners.com/random/how-to-use-the-random-module-in-python of which none work.
I found Frogitto’s random method ‘getrandbits’ but it doesn’t make sense, as I put in random.getrandbits(3) to get a number between 0 and 3, and it returns all kinds of random numbers, like 50, 33, 11 etc. It’s all over the place.
How can I find out what methods the random module has in pygame that can give me what I am looking for?
Hi
random.getrandbits(3) gets a number between 0 and 7.
7 comes from 2 to the power of 3 minus one
3 bits (its getrandbits) in binary is 111 which is 7 (2^0 + 2^1 + 2^2)
You see, this is a very fast random number maker (it needs to be) and powers of two are always the fastest on a simple chip like the Pokitto runs on
To make a number between 0 and 3 you would just do random.getrandbits(2) because 2^2 - 1 = 3
1 Like
Thanks for your reply jonne!
I kinda figured that out 5mins after posting this thread hoho.
Also found your pokitto wiki which shows the API calls which answered my other questions like how to display text on screen and audio playback.
2 Likes
Great!
By the way, I always try to reply at length not because I think the question is stupid. I am always thinking that someone else is probably wondering about the same thing. So I like to err on the safe side.
1 Like
Thanks jonne!
I’ve noticed I keep getting the same random numbers being generated in the online editor.
Will this happen on the real hardware too? (I suppose I can just throw the bin file in and check…)
Otherwise, is there a way to set/change a seed?
There is a way, have a look at this:
It would be nice to be able to seed the generator though, for example If you wanted a maze game to have the same layout for each specific level but also want it generated.
Thanks FManga. That’s exactly what I’ve done 
I was hoping to use a seed though but this will suffice.
PS. I’m really having fun coding for the Pokitto!
4 Likes
You’re probably better off using a specific PRNG engine for that anyway, so that you always get the same layouts, even if the library changes its PRNG or if you decide to port the game to something else.
C++11 makes this easier because it has several decent PRNGs built in thanks to the <random> header.
(Specifically ‘linear congruential’, ‘mersenne twister’ and ‘subtract with carry’.)
For micro Python, Java or C++03/C++98 (or if you wanted to use a specific engine that isn’t one of the three available in C++11) you’d probably have to write your own classes or find a 3rd-party library that works.
A linear congruential generator is probably the easiest to write,
but its randomness is pretty poor in a lot of cases.
A lot of the better engines have more complex state and are a bit harder to write.
(Though they’d be a lot easier to write if most articles discussing them used actual code instead of mathematical symbols.)
Personally I recommend an xorshift generator.
Very simple to write, has an excellent period and the 128-bit version passes the diehard tests.
I second that one. Even a smaller xorshift generator works perfectly well in games and is extremely fast, which is important if many random numbers are needed during the game cycle.
1 Like
Just to complement the information: in FemtoIDE’s Java you probably wouldn’t need to implement your own RNG.
The java.util.Random class is a xorshift without modulo bias.
By calling Math.random(min, max) you get numbers seeded by the realtime clock (no need for the splash screen trick).
If you want to specify the seed, use:
var rng = new java.util.Random(seed);
int number = rng.nextInt(max-min) + min;
That’s non-standard though, so that can only be relied upon for Pokitto-specific code.
The standard java.util.Random uses a linear congruential generator instead (according to Oracle’s documentation at least).
Usually for something that’s generating random terrain it’s better to be certain about the engine and implement it in a portable way so it’s easier to reason about the behaviour.
It’s less important for something where randomness is only determining small inconsequential details and where consistency isn’t important, in which case probably any PRNG will do.
(There will no doubt be modulo bias in most cases anyway.)
That’s true, it’s non-standard. I figured Math.random would be used more often, in which case better quality and speed mattered more than the actual engine used.
Not sure what you mean.
When using the functions for clamping the random number into a certain range, usually there’s a modulo backing that and it introduces modulo bias.
It’s not super important for most cases, but for some applications of PRNGs it can be quite noticable.