@MichaelBluejay: The algorithm the engine uses is the UNIX (POSIX) standard drand48 algorithm:
https://pubs.opengroup.org/onlinepubs/7 ... and48.html.
This isn't actually mentioned explicitly in the source-code - although given the name of the internal function (MCU_drand), and the engine's UNIX heritage it makes perfect sense... After all, as odd as it sounds, pseudo-random number generators have to be consistent - I suspect the engine originally uses a UNIX C library function, but when it was ported, its own implementation was needed so it gave the same results on different platforms.
The reason it isn't mentioned in the docs is because no-one has ever asked before, nor had a reason to need to know I guess.
I must confess the 'PCG' paper you cite does look to me a bit like various papers over the years I've seen claiming 'Ive found the best compression algorithm which compresses everything better' - I only skim read it, but couldn't actually find direct comparisons of the proposed PCG functions with the other test bed random number generators quoted (and thus can see why it was rejected, it looks like it spends most of the paper comparing other functions, without putting the proposed one up to scrutiny!).
Another red flag with the paper is that it attempts to compare arc4random with the others - arc4random is a pseudo-random number generator, certainly, but is designed to give cryptographic quality results by using an separate entropy mechanism to ensure the internal state from which the pseudo-random numbers are generated is essentially random -
https://man.openbsd.org/arc4random.3. (The point here is that this makes it completely unpredictable in any given instance as the state used to generate the number is not knowable).
Anyway, if you want a pseudo-random number generator - i.e. so you do have repeatability from a seed (which is really important for procedural generation, for example - e.g. a minecraft world is completeld determined by a seed value for such a thing) - then I don't think drand is bad but there are obviously others to explore.
If you actually want a much closer approximation to randomness (which is not reproducible via a seed) then you probably want to use the randomBytes() function - this returns 'cryptographic quality' random bytes using the host OS's generator of such. On mac/iOS it uses arc4random_buf, on linux/Android it uses /dev/random (
https://en.wikipedia.org/wiki//dev/random) - and on Windows it uses CryptGenRandom (
https://docs.microsoft.com/en-us/window ... tgenrandom).
[ Note: The reason we use arc4random where it is available - i.e. on mac/iOS - is because it has better performance than directly pulling bytes from the OS's entropy pool and is generally considered not to have any impact on the quality of the random data ]