[tasubotadas]

>Bevy is a refreshingly simple data-driven game engine built in Rust

All frameworks set out to be simple, clean, and fast implementations of something more established but they lack more fancy bells and whistles. Then as they catch up in features, they became the same complex beasts and the cycle repeats.

[_cart]

This is a reasonable "broad strokes" view of the lifecycle of a software project. But it could be applied to literally any claim about software simplicity / ease-of-use, so I don't find it to be a particularly helpful critique. The takeaway appears to be "all easy-to-use software that adds features is doomed", which seems a bit dramatic.

Do you have specific ideas (or concerns) about how Bevy is architected (or how it adds new features)? We're doing our best to avoid this fate.

[jms55]

I don't disagree, but Bevy has something going for it that most other frameworks don't - modularity. Not just in concept, but something that's proven to actually work out well in practice.

Tiny glade is a game that uses bevy_ecs, but doesn't use bevy's rendering crates at all. Personally I have several WIP PRs that implement alternative rendering paths (raytracing, GPU-driven meshlet + visibility buffer rendering) and nothing internal to Bevy really changes. For users, again nothing really changes, they just add a FeatureFooPlugin to their app and then use FooComponent or whatever and it all works.

While individual crates/plugins might get bloated, Bevy as a whole will be fine. Users can choose to ignore those plugins, and use something else that works better for them.

I would also like to point out that this is a game engine - by definition, they're bloated and complex beasts, and absorb every feature under the sun because _someone_ will have a use case for some kind of game. The key is how the feature bloat affects ergonomics. It's totally fine to have 1000 features, as long as you don't _need_ to interact with most of them unless you want to.

[shizzy0]

I think the test is for this is whether the project is willing to break with the past to _keep_ the api simple, clean, and fast. You're right that is easier for new projects who have no backward compatibility to speak of. From what I've seen bevy has a strong culture of demanding good ergonomics for the users and reducing the api surface, and maybe it's thanks to rust's packaging, but they're very willing to break with the past to get it, which I appreciate.

The nice thing too is with cargo, should you ever commit to bevy, they can break the future, and you don't have to chase a moving target. You can just stick to your version. But they also provide guides to make moving up to the latest and greatest easy. Or at least that's been my experience as a bevy dabbler.