bevy-inspector-egui VS rfcs

With egui and some bevy related plugins you can get pretty close to a game engine editor, obviously missing a lot of things: https://github.com/jakobhellermann/bevy-inspector-egui

Like /u/tarkin25 already mentioned "egui" can be integrated into bevy. Bevy Inspector Egui is a plugin that not only provides a helpful way to inspect different entities in the world, but also re-exports "egui" for use.

Firstly, Bevy has an internal crate called bevy_reflect, and it can handle most of the things you would usually use reflection for. For example, https://github.com/jakobhellermann/bevy-inspector-egui exists which uses Bevy's internal reflect derive to make the values available via an egui-based UI. Changing simple values (like an f32, or a boolean) can be done at runtime, and if I remember correctly all you actually need to do is to add the plugin. Taking a look at the README https://github.com/bevyengine/bevy/tree/main/crates/bevy_reflect you can "patch" types with new values, iterate over struct fields, serialize + deserialize, and generally do stuff like that.

Yeah runtime editing is definitely a weakness at this point. An editor is definitely a part of our plans though! We'll likely break ground on it early this year. In the meantime https://github.com/jakobhellermann/bevy-inspector-egui provides some nice runtime editing / inspecting / editor-like tools.

Here is the example

Bevy-inspector-egui is a most have, I think this game would not have been possible without, abuse it,

What do you miss from scriptable objects that you don't get from a class that serializes to JSON? Global access (read only access shouldn't prevent this right)? The inspector (looks like egui can help there?

There are also some super interesting experiments with hot reloading, both with code and on the fly value modification.

The one in bevy is nowhere near the requirements of a desktop application-level editor. I don't plan to involve bevy there at all. egui looks quite usable for low-level debug UI, though, especially with this crate.

For some good real-world use cases, check out this thread: https://github.com/bevyengine/rfcs/pull/39

I'm the author of the draft Many Worlds RFC. Current plan is to get scheduling sorted out, then pick that work up again.

Yep, we do this, it works great! We stole it from hecs and Amethyst before us. There's a nice write-up of the theory in the scheduler rework the team has been working on for the past few months.

I can tell you right now that there’s an entire channel in the Bevy discord server dedicated to making an out of the box api for multiplayer. If you want the current state of it, check out this RFC. https://github.com/bevyengine/rfcs/pull/19 I’m really excited for it when it eventually comes out.

I think making it easier for systems to observe the effects of Commands from other systems is a critical missing piece of the Bevy ECS puzzle. "Stageless" is a solid, holistic solution to the problem and we're seeing the community slowly establish consensus on that design. There is already a draft implementation in the works. And I think "stageless" is most likely the solution we will land on.

Cool! Looks like a nice complement to the RFC about keyboard navigation!

This should be fairly feasible: although you'll probably want to wait on (or implement) the dynamic components RFC. The comments above are more to the effect of "writing Rust is easier and more convenient than you might expect".

You will be happy to know that better/updated documentation is planned. It was briefly mentioned as "the new Bevy Book effort" in this paragraph of the blog post and there are a ton more details in this RFC. Your participation would be more than welcome!

So, several of us have been working on a relations feature for Bevy: first-class support for those sort of "target another entity with a component" patterns that keep cropping up. There's a lot to be done, and it's at a point where it can be chunked out, so if you're interested in helping out come say hi on Discord :)