"Cards" by Victor Gijsbers
Lab is a room.
Card is a kind of value. The cards are ace, king, queen, jack.
After looking:
let i be 0;
while i is less than 10:
let n be a random card;
say "[n] . ";
increase i by 1.
Gives me the following results on rerunning it a few times:
queen . jack . jack . jack . king . ace . king . king . jack . queen .
queen . king . ace . jack . queen . queen . king . jack . ace . ace .
queen . jack . king . jack . jack . ace . king . king . king . queen .
queen . king . ace . jack . queen . queen . king . jack . ace . ace .
queen . king . ace . jack . queen . queen . king . jack . ace . ace .
queen . jack . king . jack . jack . ace . king . king . king . queen .
queen . jack . king . jack . jack . ace . king . king . king . queen .
queen . king . ace . jack . queen . queen . king . jack . ace . ace .
queen . jack . jack . jack . king . ace . king . king . jack . queen .
As you can see, it starts with āqueenā every single time. But even after that, it is far from random; if Iām not mistaken, there are only three different sequences among these. How is this possible? Can I do something about it?
This is Inform for Windows 10.1.2.20220830. Iām compiling to Glulx and I do not have āmake random outcomes predictable when testingā turned on.
The problem seems not to happen for a release version, so maybe I shouldnāt be bothered, but it did influence some testing I was doing just now.
I canāt quite understand whether the problem affects games in their Released version or if it only concerns Inform 7 with the IDE, when the author is testing their game within the interface. The thread is very interesting and quite long, and I must admit I donāt fully understand half of it yet. Some parts are still too technical for me (or refer to developer habits and tools that Iām not familiar with).
The problem was in the interpreters (Glulxe, Git, etc.) rather than the story file, so it affects both authors and players when they use an interpreter version from before that thread. New versions with improved RNGs have been released, so the problem wonāt occur in the newest version of e.g. Gargoyle or Lectrote or Spatterlight. However, there hasnāt been a new release of the Inform IDE yet, so authors are in some sense more likely to run into the problem than players.
Understood, thank you very much for these additional information. Tell me, if the workaround code provided by Dr Peter Bates remains in the released version, is it a problem ? Should we remove it before releasing and/or use the ānot for releaseā feature ?
I would not recommend using the second workaround that replaces random, even for testing. Itās not a complete solution on its own, and replacing the RNG entirely provides lots of opportunity for introducing a similar problem again (only now itās storyfile-specific and canāt be addressed by patching the interpreters). Itās cool that itās possible but I wouldnāt want to stake my gameās functionality on it when thereās an easier way.
The first workaround of āprimingā the RNG at game start, shouldnāt cause much harm. Itās an unnecessary waste of time and electric power on new interpreters, but it may avoid a disappointing experience for some players who arenāt on the newest version. However, I would not add it ājust in caseā, only if the RNG problem is actually observable in the game in question. It also becomes less useful as time goes on and especially as new Inform versions get released, because eventually enough people will be using up-to-date interpreters that itās not worth keeping the workaround in place.
However, this is is a judgement call - others may come to a different conclusion.
Thanks for your reply. Since the playerās experience is what matters most here, placing the workaround in the ānot for releaseā section seems ideal, which aligns with your point, as interpreters with newer versions are not affected by the bug. I havenāt really delved into interpreters yet; so far, Iāve tested Lectrote, skimmed through Vorple, and noticed that you can create a release with Parchment (which can be updated). The first workaround (the one Iām currently using) allows for testing the presence of the bug regardless of the chosen option. We could even consider an auto-test that activates the workaround only if the bug is detected. On second thought, thatās probably what Iāll do. Thanks again!
Well, it may be naive, I would try this : by randomly drawing, at the start of the game, a series of numbers between 1 and 4 and comparing the resulting sequence with one of the four identified by Dr. Peter Bates:
I have manually tested, every test conveys to one of these sequences. I imagine that from 8 digits onwards, the probabilities become low enough to reasonably estimate that the interpreter is affected by the bug.
The prime the random number generator rule is listed after the seed random number generator rule in the startup rules.
The prime the random number generator rule is listed before the update chronological records rule in the startup rules.
This is the prime the random number generator rule:
let Sequence01 be "3424412223";
let Sequence02 be "3214332411";
let Sequence03 be "3444212243";
let Sequence04 be "3234132431";
let Random1-4 be "[one of]1[or]2[or]3[or]4[purely at random]";
let RandomSequence be "[Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4][Random1-4]";
if ("[RandomSequence]" exactly matches the text "[Sequence01]") or ("[RandomSequence]" exactly matches the text "[Sequence02]") or ("[RandomSequence]" exactly matches the text "[Sequence03]") or ("[RandomSequence]" exactly matches the text "[Sequence04]"):
say "RNG bug detected [line break]"; [for test purposes]
let dummy be a number;
repeat with n running from 1 to 100:
now dummy is a random number between 1 and 4; [warm up the RNG for Git]
let b be a random number between 1 and 32633; [a high prime number, but not so high as to cause a significant delay to start-up]
repeat with n running from 1 to b:
now dummy is a random number between 1 and 4; [range used here makes no difference]
Itās not a bad idea but some comments in the old thread mention that Git and Glulxe (in certain configurations) have a similar problem, but different sets of possible sequences. From a quick glance through the thread I also canāt rule out itāll vary by operating system or something. So Iād be worried that this approach only catches the particular flawed RNG in the IDE but not an equally-flawed RNG in the interpreters players are using. But perhaps itās a decent middle ground between putting in way too much effort into it vs. not trying to mitigate the problem at all.
I canāt find an exact equivalent in the TADSās EventList, but seems that the bug involuntarily gives a potentially convenient randomised list, with a fixed first element (useful in the case the player is informed of something, then reminded about that something)
This can be useful in dealing with the issue, bugs stemming from scrapped tentative features arenāt uncommon, I thinkā¦
