"After consulting with several other Rioters, our team settled on developing a new PRNG implementation based on XOR-SHIFT."
I wonder why?
I wonder why?
The problem with the xorshift family is that it doesn't implement the nice auto-scaling (and thus auto-testing) that PCG has. Re-parameterizing it means inventing whole new numbers from scratch and hoping you plug them in correctly. Xorshift also has a rare-but-severe "stuck near zero" problem.
The problem with the PCG family is that its trusted way of scaling (nobody likes the `_k` variants) relies on 128-bit multiplication (a modern member of the family at least reduces that to a mixed 128x64 multiply), which remains notably slow, unlike xorshift which only uses small integers.
(But I must emphasize: all RNGs from other families either have worse variants of these problems, or give up on performance entirely. These concerns should be used only to select your preferred tradeoff between the two, there is no excuse for ever using any other RNG family unless you need cryptographic security)
Its distribution is not flawless, but I would agree that it's good enough for gameplay.
The reason we didn't use crand was just code ergonomics. C-style rand has global state (by default) and we wanted our own interface to be explicit in the code so you knew when you were using a gameplay-impacting random number.
Other techniques, such as linear congruential generators, require multiplication and division.
As a sidenote on a project the size of LoL, the time, size and cost of implementing a PRNG based on a known one is a rounding error.