This article, while a nice summary, does miss some details that are quite important. TGM in particular uses Mersenne Twister as its PRNG, whereas NES Tetris probably uses a linear congruential generator (as was common for many games on 8-bit game consoles to the best of my knowledge.) MT behaves dramatically differently than LCG, and while it may seem like a minor detail, actually feels quite different to play from Math.random implementations I've tried, even when using the same TGM algorithm.
Maybe it helps to think of these randomizers as noise generators, and then try to figure out what the ideal noise "color" for fun play would be? I guess blue noise for example would be like too predictable random bag generators.
flip note: I dunno which 'Math.random' you mean, the Java version should not be used for anything meaningful (perf. related) as it is a shared 'java.util.Random' that exhibits a contention point, albeit a CAS (not synchronized) but a contention point nonetheless.
Also generating a double (from 2 ints) to be converted to an int is a bad idea. Should be just 'random.nextInt(7)'
In particular I’m thinking of JavaScript, but the same thing could be said about libc random. In at least a few puzzle games, the PRNG used has noticeable side effects.
I understand the issue with modulo bias, but there's plenty of techniques for dealing with that issue. (Not to say that people always do, even in real-world code, but oh well.)
