3 ms·

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 go

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.

all2 1y ago
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.
elcritch 1y ago
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.
jokethrowaway 1y ago
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.
hresvelgr 1y ago
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.

all2 1y ago

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.

elcritch 1y ago

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.

jokethrowaway 1y ago

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.

hresvelgr 1y ago

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.