[james7132]

I'm one of the maintainers of Bevy. In my opinion, Godot clearly has a significant lead in many fronts, some moreso than others. A clear few that are lagging behind are:

Editor: Godot has one, Bevy does not. Animation support: Godot has support for complex animation blending and animating anything that can be serialized. Bevy does not. Audio: Bevy's audio is pretty simple right now and lacks direct world entity driven spatial audio. Rendering: Godot has pretty deep support for higher performance and higher fidelity rendering techniques like automatic instancing and

Everything in this list is being worked on, but require time to bake. Everything else more or less has most of the core pieces in place that Godot has, though may be missing a few small features here or there.

Where is Bevy ahead?

Multithreaded CPU performance. I can almost guarantee your average Bevy app will have higher thread utilization than your average Godot/Unity/Unreal game, and this will continue to scale as more complex computations are required for various engine systems are added.

Testability: ECS makes it really easy to write dependency injection based unit tests, something otherwise difficult to test end-to-end with engines like Godot and Unity.

Extendability and customization: Bevy is plugins all the way down. Godot definitely takes a much more monolithic approach to building an engine, and making significant changes to the core engine will require forking. Where Godot requires exposing deeper APIs for exposing functionality, Bevy already supports ripping out the relevant plugins and subsituting just those with your own.

Memory safety: As the mantra goes, every 1k LoC of C/C++, there's one CVE that is yet to be found, and 70% of those are memory safety issues. Bevy heavily leverages unsafe in the ECS, but rarely touches it in the other core engine crates. We can with high confidence say there are no memory safety problems or problems caused by undefined behavior in Bevy due to Rust's strong safety guarantees.

[echelon]

Thank you so much for this answer!

This question might be a little less fair -- what's the state of Bevy vs Fyrox?

And if you have a guess, how long will animation and editor support take? A wild guess is fine (though if you break out animation a bit, I'd be grateful).

[james7132]

Fyrox definitely has a better end-to-end feature offering right now, but I personally think Bevy has the stronger ecosystem.

Animation support is growing rapidly. I'm one of the two SMEs (subject matter experts) focused on this area, and we just rounded out the final parts of the animation composition RFC. I'm hoping to get that feature to land in 0.11, but may take until 0.12 to be fully available. There's also an open PR for animating morph targets, the primary other way of deforming meshes for animation, which I think should land in 0.11. I'm also working on inverse kinematics implementation, which should round out the core "animate to move things" features. More powerful animation features are likely going to be reliant on an editor going forward though.

The editor is definitely something we're pushing hard on. Cart recently just opened a PR rewriting the asset system to better support preprocessing and more complex asset interactions, something we desperately needed for the development of an editor. I'd like to say we'll break ground on the editor before Q3 of this year, but that might be an overaggressive target.