Greetings!
I'm not sure if someone asked Casey about this or whether or not he talked about it but I was wondering what are the implications of using a global random_series instead of passing it around to random functions? Will this cause problems if more than one thread is accessing it, or are there any reasons not to make it global?
Thanks!
elxenoanizd/vexe
I'm not sure if someone asked Casey about this or whether or not he talked about it but I was wondering what are the implications of using a global random_series instead of passing it around to random functions? Will this cause problems if more than one thread is accessing it, or are there any reasons not to make it global?
Thanks!
elxenoanizd/vexe
I believe using global variables messes with the memory model necessary to do live code reloading - all the memory used by the actual game needs to be managed by the platform layer so that it doesn't get altered when reloading. I'm not sure if I'm using the right terminology here, but I think that's the idea.
That's a good point indeed. But even if that's the case, we could certainly store the actual random_series in the game data structure which lives in the game's persistent memory, and maintain a global random_series pointer that we assign to the actual random_series in the game's data inside GameUpdateAndRender, so we're still persisting and it's still easy to use.
As long as global random table is constant (we don't change it) and we don't keep pointers to it (we don't), the live code reloading will work fine without problems.
Accessing it from multiple threads is also not a problem. As long as each thread uses its own random_series variable to access table everything will be fine.
Accessing it from multiple threads is also not a problem. As long as each thread uses its own random_series variable to access table everything will be fine.
The reason we don't use a global random number generator is not because we are worried about live code reloading, although there are some reasons why you might care there (eg., you would at a minimum want the global random number state to be in the save/restore block for looped live code editing, so it should not be a static, etc.)
The reason is because the random number generator may be used for different types of things. A global random number generator would be fine if you never _rely_ on the global random number generator to give repeatable results. But since we are planning on having randomly generated worlds, and we want those worlds to potentially be transmittable as a unique key (eg., "world 48A8FGB2"), we need a way of ensuring that each piece of code knows specifically where its entropy is coming from.
For example, suppose the world generation code needs to run on a separate thread, because it takes too long and we don't want to show a "generating world" screen. Well, if it uses a _global_ random number generator, then depending on who else might be grabbing random numbers at the time, it may generate a completely different world on different machines. If instead we ensure that world generation uses its own entropy stream, that doesn't get used for things like per-frame particle effects or whatnot, then we know that we'll always generate the same world from the same seed.
So it tends to be good discipline to always pass the random number generator to your leaf functions, because you never know who might be using those functions, and you want to ensure that when they're used by the world generation code, they use one source, and when they're used by other code, they use a different source. If instead you have a global one that people use sometimes, you are very likely to make a mistake where you forget that some leaf function uses the global entropy stream, and oops, you happen to call something that calls that function, and now your world generation is not repeatable.
SAD PANDA.
- Casey
The reason is because the random number generator may be used for different types of things. A global random number generator would be fine if you never _rely_ on the global random number generator to give repeatable results. But since we are planning on having randomly generated worlds, and we want those worlds to potentially be transmittable as a unique key (eg., "world 48A8FGB2"), we need a way of ensuring that each piece of code knows specifically where its entropy is coming from.
For example, suppose the world generation code needs to run on a separate thread, because it takes too long and we don't want to show a "generating world" screen. Well, if it uses a _global_ random number generator, then depending on who else might be grabbing random numbers at the time, it may generate a completely different world on different machines. If instead we ensure that world generation uses its own entropy stream, that doesn't get used for things like per-frame particle effects or whatnot, then we know that we'll always generate the same world from the same seed.
So it tends to be good discipline to always pass the random number generator to your leaf functions, because you never know who might be using those functions, and you want to ensure that when they're used by the world generation code, they use one source, and when they're used by other code, they use a different source. If instead you have a global one that people use sometimes, you are very likely to make a mistake where you forget that some leaf function uses the global entropy stream, and oops, you happen to call something that calls that function, and now your world generation is not repeatable.
SAD PANDA.
- Casey
Simply speaking entropy is how to measure if how random is system. High entropy means that system is very random, each state has equal probability. Low entropy means that there is something that is more probable that anything else (or you can say there is some specific pattern).
In previous post from Casey you could replace word "entropy" with "random/randomness" - there it means almost same thing.
In previous post from Casey you could replace word "entropy" with "random/randomness" - there it means almost same thing.