[the__alchemist]

The language of the article (starting at the top) reinforces a suspicion that Bevy may be developed with a goal of prioritizing its ECS system over practical goals, or facilitating the game dev itself. I see this in early Rust OSS tools regularly. Actix the web framework marketing, articles, and community being focused on the Actor paradigm; Embassy in Embedded being focused on the Async paradigm; the older gen being focused on the Typestate, Ownership-of-peripheral, and Trait paradigms.

It's OK to have a backbone concept you're proud of and anchors your lib! If it becomes the ends rather than the means, it's worth re-evaluating.

[jokethrowaway]

Building a game engine is a titanic effort.

Bevy has the best developer experience of any game framework I've ever tried (I have worked with mainstream engines - which warmed up to ECS over time - and engines that started with ECS like ECSY and playcanvas) but it's too low level for most studios.

I get your point about actix and actors but I think the difference there was that the author wanted to build Elixir in Rust, while the community wanted an Express (from node.js). The vast majority of web services I see don't need an explicit actor model.

ECS instead has a significant impact on developer experience, so I appreciate their focus on data structures.

[all2]

Architecture > UX?

I'd love to avoid this in my personal projects. Programming paradigms are useful within their bounds, but at some point UX has to take the front seat.

[hresvelgr]

It's solving problems that are so far down on the list of priorities of a video game project that it will never evolve beyond a mere toy unless they really wise up. "My performance is bad because I didn't design this in a data-oriented way" is a different problem when 65% of your game is finished as opposed to solving it at "Hello, world." Hell, you can't even solve that problem unless you understand what your actually real game is doing at a data level in the first place.

Before software can be reusable it first has to be usable. There is a good reason why every existing popular engine was purpose built for a game in its infancy.

[elcritch]

Makes sense to me. Lots of folks attracted to Rust seem to enjoy code-golfing more than solving problems. Designing the “perfect” game architecture vs shipping games seems to match that and my take on much of the Rust ecosystem.