Add random number generator resource (optionally specified with a seed)

[LegNeato]

Objective

• Make bevy "random aware" and allow seeds to be controlled by bevy

Solution

• Move random number generators into bevy as a resource.

I'm new to bevy and would love guidance if this even makes sense to do. If so, I'll clean it up and add tests.

[james7132]

IMO, unless these PRNGs are required for a mission-critical official crate, I think this should be done by the end-developer instead of having it globally configured provided by the engine itself. There is a sizable number of open questions regarding how the PRNG is used that is entirely dependent on the developer's requirements:

• What performance characteristics is desired?
• How random does the outputs need to be?
• How is the PRNG seeded?
• Does the output need to be secure?
• Is random state shared between threads? Between isolated systems?
• How does the PRNG's use impact determinism-sensitive systems?

These questions all have use case specific answers and there is no one-size fits all solution. Using it as a bevy_core provided resource makes the choice here for several of these questions and that might not be what's needed for every use case. The thread_rng cases in the examples seem to be sane enough for it's use and is a cost that only the developers who need it will pay.

[NathanSWard]

I think this should be done by the end-developer instead of having it globally configured provided by the engine itself.

I agree.
There are to many variables when it comes to using some sort of RNG that providing it in the engine doesn't seem to be very beneficial imo.
Also since adding the rand crate to your own project and setting up an RNG is quite trivial, this is probably best left to the end-developer.

[mockersf]

While easy to setup, it's still a nice feature to have a random number generator available by default (Godot offers one, Unity also).

Could you put it behind a feature flag so that it can be removed if needed?

[LegNeato]

Yep, I'll clean this up and put behind a feature flag by the end of the weekend

[vgel]

Instead of being in core, it might make more sense for this to be a separate bevy-random crate / plugin that gets included as part of the DefaultPlugins group:

bevy/crates/bevy_internal/src/default_plugins.rs

Lines 54 to 95 in e3fb23d

	impl PluginGroup for DefaultPlugins {
	fn build(&mut self, group: &mut PluginGroupBuilder) {
	group.add(LogPlugin::default());
	group.add(CorePlugin::default());
	group.add(TransformPlugin::default());
	group.add(DiagnosticsPlugin::default());
	group.add(InputPlugin::default());
	group.add(WindowPlugin::default());
	group.add(AssetPlugin::default());
	group.add(ScenePlugin::default());
	#[cfg(feature = "bevy_render")]
	group.add(RenderPlugin::default());
	#[cfg(feature = "bevy_sprite")]
	group.add(SpritePlugin::default());
	#[cfg(feature = "bevy_pbr")]
	group.add(PbrPlugin::default());
	#[cfg(feature = "bevy_ui")]
	group.add(UiPlugin::default());
	#[cfg(feature = "bevy_text")]
	group.add(TextPlugin::default());
	#[cfg(feature = "bevy_audio")]
	group.add(AudioPlugin::default());
	#[cfg(feature = "bevy_gilrs")]
	group.add(GilrsPlugin::default());
	#[cfg(feature = "bevy_gltf")]
	group.add(GltfPlugin::default());
	#[cfg(feature = "bevy_winit")]
	group.add(WinitPlugin::default());
	#[cfg(feature = "bevy_wgpu")]
	group.add(WgpuPlugin::default());
	}
	}

I also agree it would be nice to have this by default -- little things like this add up, and while it does add a little bit of overhead for people who don't use it, I think that overhead is fairly minimal and if it's behind a feature flag it's not too difficult to remove. Having it as a plugin will also make the feature flag a bit easier to implement.

[james7132]

I also agree it would be nice to have this by default -- little things like this add up, and while it does add a little bit of overhead for people who don't use it, I think that overhead is fairly minimal and if it's behind a feature flag it's not too difficult to remove. Having it as a plugin will also make the feature flag a bit easier to implement.

My main concern is that this is a source of non-determinism that is fundamental and accessible enough that it may alter game state in difficult to detect ways. For games that require it, like deterministic networked games, this is can be a hard non-starter. Other game engines like Unity and Unreal that have it built in require explicit management of these global PRNGs to avoid the side effects of one system altering another.

Re: having it behind a feature flag: this is marginally better, though I'm concerned that other first-party crates will become dependent on it as a source of randomness, which will make it transitively required for certain core engine features.

IMO, any first party crate requiring a PRNG should use local PRNGs embedded in resources/components from the crate itself. This both keeps the dependency tree smaller and isolates the effects of one crate/system on another.

[LegNeato]

Apologies, I may not understand as I haven't worked in games professionally. The reason I put up this PR is precisely because I need bevy to be deterministic and I want anything that can change the world logic and state be driven via bevy.

IMHO a source of randomness should be a feature of the world...multiple examples have already naturally included it. Happy to make the change elsewhere / in a subcrate, but I couldn't see how to get at the very early bevy stages outside core...any pointers would be swell!

I can remove the default os randomness if that is desired. The idea was for people who care about determinism, they pass in their own seed (as in the example I added). For people who don't, they get an out of the box experience as with other engines 🤷‍♂️. For example, this is how Godot works AFAICT...default is osrandomness but you can specify a seed.

[james7132]

Apologies, I may not understand as I haven't worked in games professionally. The reason I put up this PR is precisely because I need bevy to be deterministic and I want anything that can change the world logic and state be driven via bevy.

A global PRNG means the execution order and presence of systems that depend on it will affect the current state: i.e. the particle system emitter will affect the PRNG outputs will affect the power-ups generated. It's for this reason why I think it's better to have system local PRNGs instead. Those that require control over the PRNG of multiple systems need to put in more work, but there's no spooky action at a distance by default.

[LegNeato]

Ah, I now get what you are saying!

I assumed that people would indeed add their own additional rng resources when they needed
specifc guarantees or segmentation...but I think in the most general the distinction one would care about is insecure vs secure so those were baked in.

Isn't it also preferable to have a single source of randomness all others descend from? It helps determinism as there is one place to set the seed and all callsites respect it. As it is there is nothing preventing a system in a dependency using rand directly and causing non-determinism.

Perhaps instead of an rng implementation what we need as a resource is a "genesis" random seed / source of entropy that all rngs use to seed, something similar to https://docs.rs/rand/0.8.4/rand/trait.SeedableRng.html#method.from_rng.

[Nilirad]

I like the idea of a seed generator. However we need to make sure that the local PRNGs are seeded deterministically.

[LegNeato]

Looking for a little more guidance on where to take this

[LegNeato]

I put up a PR with a new plugin called bevy_entropy in #2504. If that lands I'll rebase this on top of that and continue the discussion. I still think it is useful to have built-in rngs, as many of our examples use them...which likely means that many games would too. But we'll see what happens with the lower-level building block PR first.

[LegNeato]

Closing in favor of the entropy PR. Will revisit this in the future.