Hacker News Reader

Comment by the__alchemist | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

Reply on news.ycombinator.com