The Z-machine Standards Document includes the following:
However, the interpreter in the Inform 7 IDE, when given a seed S < 1000, will return 0, 1, 2…S-2, S-1, 0, 1, 2, et cetera. Do other interpreters share this quirk? If so, what is the “safe value” beyond which the RNG will generate random-looking numbers?
(There is a note in the Standard suggesting that this mode can be useful for testing, but it does not seem to be part of the Standard itself.)
When play begins:
seed the random-number generator with 100;
Every turn:
let N be a random number between 0 and 16384;
say "[N].";
(Note that “seed the random-number generator with 100”, in Z-code, invokes the opcode @random -100.)
On the Mac IDE I get the sequence 13435, 5882, 6634, 1130, 3930, 474. In Frotz I get incrementing numbers from 0, so this must be a Frotz behavior. Fizmo doesn’t have it. I don’t know if any other interpreters do.
If you want predictable random numbers for a game purpose, you should write your own RNG in I6 or use one of the extensions that does.
[code]Seeding the RNG with is an action out of world applying to a number. Understand “seed [number]” as seeding the RNG with.
Carry out seeding the RNG with a number:
seed the random-number generator with the number understood.
Report seeding the RNG with a number:
say “Random seed set.”
Randoming is an action out of world applying to a number. Understand “rand [number]” as randoming.
Report randoming a number: say a random number between zero and the number understood.
There is a room.[/code]
In the Windows interpreter (which presumably uses Frotz), “seed 1. rand 256. rand 256. rand 256.” gives 0, 0, 0; “seed 2. rand 256. rand 256. rand 256.” gives 0, 1, 0; and so on.
This doesn’t occur in any Glulx interpreter I’ve tested, so it seems it is Frotz-specific. Interesting.
After thought, I disagree with that comment in the spec. I don’t think the incremental mode belongs in the interpreter. If the game does want an incrementing random mode, it can trivially implement one in I6 code; this is better than relying on a not-really-specified interpreter behavior. And the incrementing mode is more likely to break games than to generate useful testing, anyhow. (It puts you right back in the alternating-odd-and-even mode that has caused real-life game bugs.)
Whereas fizmo actually does implement a predictive random generator, one has to explicitly activate it using the --predictable command line parameter or use the /predictable command in-game. Since that doesn’t conform to the current spec, I’d currently consider implementing the double-seed behavior for some future update.
In case there’s some kind of consent that this doesn’t make sense – personally, I’d agree that this should be outside the interpreter – maybe we could update the updated Z-Spec.