Blog: "The Game Engine that would not have been made without Rust"

[blonk]

As someone who dabbles with gamedev using Rust, I found this to be interesting: Vermeil Soft Tech Blog

(No affiliation, just randomly stumbled on it)

[simonbuchan]

TLDR: a baby(?) ECS, networking and specifically rollback multiplayer. Neat stuff!

An interesting note is the need for a deterministic ECS for rollback, but I think most ECSs should be deterministic when used "normally", right? Certainly you can pretty easily break it if you try, but my understanding is despite breaking tasks up across threads by system and entity, if you only make changes via the system parameters the declared dependencies should always resolve the same. The obvious exception being the "tick" needs to be independent of rendering time, but that's a requirement of rollback regardless of implementation.

[kpreid]

@simonbuchan

I think most ECSs should be deterministic when used "normally", right? Certainly you can pretty easily break it if you try, but my understanding is despite breaking tasks up across threads by system and entity, if you only make changes via the system parameters the declared dependencies should always resolve the same.

My impression is that the author thought there would be a problem and did not confirm that there was actually a problem, just decided not to go there.

That said, it’s easy to accidentally have systems which can observe each other's effects and at least not think about their ordering, though whether this translates into actual run-time nondeterminism depends on the scheduler behavior (in bevy_ecs it can):

fn update_1(mut q: Query<&mut Foo>) { ... }
fn update_2(mut q: Query<&mut Foo>) { ... }

Nothing about these two system functions’ dependencies can tell a system scheduler what order to run them in.

[scottmcm]

@simonbuchan

An interesting note is the need for a deterministic ECS for rollback, but I think most ECSs should be deterministic when used "normally", right?

I think it'd be very easy for an ECS to accidentally depend on hash table order somewhere, for example. Or otherwise have subtle downstream impacts from giving out different Entity ids from equivalent runs that then end up running something ordered by Entity id later that then has a subtle difference.

@simonbuchan

The obvious exception being the "tick" needs to be independent of rendering time, but that's a requirement of rollback regardless of implementation.

This is also something that you should just always do, even if the game is single-player and doesn't have rollback.

Games basically never bother using perfectly-time-step-independent integrators and such, so a fixed timestep just makes everything more consistent, avoiding "why does this feel weird on a slow/fast machine?" problems.

[simonbuchan]

@kpreid

That said, it’s easy to accidentally have systems which can observe each other's effects and at least not think about their ordering, though whether this translates into actual run-time nondeterminism depends on the scheduler behavior (in bevy_ecs it can):

fn update_1(mut q: Query<&mut Foo>) { ... }
fn update_2(mut q: Query<&mut Foo>) { ... }

Nothing about these two system functions’ dependencies can tell a system scheduler what order to run them in.

Yeah, this is pretty much the example I thought would be deterministic, as in that bevy may interleave the updates running them in parallel, but each entity would see the same order of each every time, presumably the order they were added to the World. Turns out this isn't the case, which is quite surprising to me!