Indeed, and I should have said "pseudorandom". What I'm trying to say is that it's fully predictable.
Yes, they could have used rand() with an appropriate srand(seed), communicated between machines. They could even have used a DRBG built with an AES cipher, except it would have been too slow. However, even a bad implementation of rand() usually uses an algorithm which is essentially just "seed = seed * m + a", which is slower than a table lookup.
Anyway - the interesting thing is that a 256 entry table is sufficient for game purposes (not obvious to players), is fast, and makes the synchronous multiplayer setup work.
>Yes, they could have used rand() with an appropriate srand(seed)
rand() is shared across the whole OS, so another program calling rand() could make you skip a number; or another program could reseed rand. Then you've lost determinism.
Even if that weren't the case, you don't want you FX system to call rand() and "steal" the next number that that AI system was expecting.
With Doom's table, each system can keep a separate index into the table; now calling getRand(myIndex++) from one system doesn't interfere with other systems.
> rand() is shared across the whole OS, so another program calling rand() could make you skip a number; or another program could reseed rand. Then you've lost determinism.
Is there actually any implementation of rand that does this? I feel like this would be a buggy implementation, or at the very least, goes against the spirit of the standard,
> If srand is then called with the same seed value, the sequence of pseudo-random numbers shall be repeated. If rand is called before any calls to srand have been made, the same sequence shall be generated as when srand is first called with a seed value of 1.
> The implementation shall behave as if no library function calls the rand function.
But isn't rand() deterministic too? It's only governed by the seed.
Only /dev/random is "really" random, AFAIK. And even that is only as good as the nearby entropy.