Live data from Hacker News

Bevy TLDR – Game development with Bevy summarized

taintedcoders.com

11–20 of 20 posts

Re: Bevy TLDR – Game development with Bevy summarized

#11

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…

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.

Re: Bevy TLDR – Game development with Bevy summarized

#13

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…

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.

Re: Bevy TLDR – Game development with Bevy summarized

#14

Of all the programming-first video game frameworks I've tried, including Bevy, I found Monogame to hit the sweet spot. C# is a super underrated language and Monogame has just enough batteries to get going without being in your way too much. For ECS, I've been using Friflo ECS and haven't had issues so far: https://github.com/friflo/Friflo.Engine.ECS

Oh wow, had no idea Bastion was made with Monogame and C#!

Re: Bevy TLDR – Game development with Bevy summarized

#15
post #14

Of all the programming-first video game frameworks I've tried, including Bevy, I found Monogame to hit the sweet spot. C# is a super underrated language and Monogame has just enough batteries to get going without being in your way too much. For ECS, I've been using Friflo ECS and haven't had issues so far: https://github.com/friflo/Friflo.Engine.ECS

Oh wow, had no idea Bastion was made with Monogame and C#!

Up until midway through Hades 1 development Supergiant was a c# shop with their own engine on top of libraries (the fact they rewrote their core tech in the middle of a game project that was already available to the public remains insane to me).

Re: Bevy TLDR – Game development with Bevy summarized

#16

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…

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.

Re: Bevy TLDR – Game development with Bevy summarized

#17

Of all the programming-first video game frameworks I've tried, including Bevy, I found Monogame to hit the sweet spot. C# is a super underrated language and Monogame has just enough batteries to get going without being in your way too much. For ECS, I've been using Friflo ECS and haven't had issues so far: https://github.com/friflo/Friflo.Engine.ECS

Interesting that the ECS you linked beats out Flecs .net bindings. I wonder if it is because of copying to/from the dotnet heap.

Looking over the readme.md I find it interesting they don't list dotnet 9 support but they do list 7 so they do seem to support non-LTS versions but skipped 9 (mind you maybe they just didn't update the readme?)

Re: Bevy TLDR – Game development with Bevy summarized

#18

Bevy is one of those things that I've tried to use, but quickly realized why people believe that "rust is changing too quickly". Well the language doesn't but the libraries do. It's changed quickly enough that docs, examples, copilot, agents, and chat assistants are all a few versions off from each other.

Bevy is very explicit about this in its guide, though!

People made games and software in bevy despite the API flux, and the migration guidelines are really good too.

Re: Bevy TLDR – Game development with Bevy summarized

#20

Of all the programming-first video game frameworks I've tried, including Bevy, I found Monogame to hit the sweet spot. C# is a super underrated language and Monogame has just enough batteries to get going without being in your way too much. For ECS, I've been using Friflo ECS and haven't had issues so far: https://github.com/friflo/Friflo.Engine.ECS

This looks great, thanks for sharing Do you know what the C# to wasm story is?
Post reply on HN