undefined | Better HN

0 pointsnoelwelsh2y ago0 comments

Most games have different states. For example, you have the main menu screen and perhaps different levels. Each of these could be a state. I think Bevy already has an abstraction for this[0] but it only records the current state. There is no other information associated with it IIUC.

What I think would be useful is essentially an arena allocator associated with a state. So any components and entities created when a state is active would be removed when that state is exited. Otherwise it seems that one must do manual GC, which is error-prone and will almost certainly lead to slow leaks over time.

[0]: https://docs.rs/bevy/latest/bevy/ecs/prelude/struct.State.ht...

0 comments

alice-i-cecile2y ago

Ah okay! I can see the need for this. This is a large part of why the States machinery exists, but I see your point about it being error-prone to remember to tag and then despawn everything.

I'll chew on solutions here: we might be able to get away with a nice well-documented convention in user-space code, or we may need to add a small extension to the internals to make this more robust.

harrisi2y ago

Isn't the typical way to do this by using a janitor? This would typically need to be done in user space (the framework doesn't know what cleanup you want to do), but Bevy could provide an interface for it with callbacks or whatever is more idiomatic in Rust/Bevy.

tomtheelder2y ago

Last time I was using Bevy I had a cleanup system to solve exactly that issue. It queried for entities with the AssociatedWithState component, or whatever I called it, and destroyed any where the was a mismatch.

I could see an efficient version of that being a nice thing to have built in, though. It’s definitely a very common thing.

j / k navigate · click thread line to collapse