Scaling Bevy Development | Hacker News Reader

Scaling Bevy Development

bevyengine.org

98 pointssbt56720 comments

Neat to see this pop up: I'm Alice, one of the maintainers mentioned.

I ended up pushing pretty hard for this change (or something like it), and at least so far, I'm feeling optimistic about the result. This was fairly organic: it was becoming clear that there were experts in each area that we should be consulting before merging complex work there. So we formalized it.

The split between "generally competent, well-organized" and "deep expertise" is a nice one, and I'd love to see more orgs experiment with that.

It'll be interesting to see if Bevy or Fyrox takes off as "the" Rust game engine. We recently evaluated both engines for a future project and chose Fyrox as it edged out Bevy in the dimensions that mattered to us, though both are really solid. It was a hard choice.

Fyrox is a one-man super show, and its author Mr.Dimas is a 10xer if I've ever seen one. But that's also a major existential risk to the project. Having this level of community built around Bevy ensures that it will live beyond its creator. It's something I hope Fyrox can begin to build.

Bevy is doing great things, and their organization and community are only getting better.

I would love to see one or both of these engines to catch up with Godot.

Bevy is the de-facto Rust game engine already; by any possible metric, it's at least 10x as present as any other engine.

The big question is if Rust (and its engines) will be a viable/convenient platform for commercial gaming or not; the current landscape is essentially "homebrew".

Fyrox may get some traction if commercial games will start to be produced, since it's modeled after commercial toolkits (like Unity). But given the manpower behind Bevy, nothing prevents them from adding this tooling as well (I think an editor is in development).

I've been making a 2d game in bevy and it's a lot of fun. I would recommend trying it. I haven't had any issues that are common with rust like fighting the borrow checker.

FWIW, I think people mostly have these issues with async code, because the syntax is reminiscent of Python or Typescript, but actually behaves very differently under the hood. So, the similarity is only superficial. Most of the time you don't care about this difference, though. However, sometimes it can pop up. Funnily, I think like 80% of the time, you can just reorder code a bit to not hold stuff across await boundaries, and it will compile. The 20% can sometimes be tricky, though (often because working with external types, so to resolve it, it requires wrapping code).

The situation is getting better, though. Just not with every release.

I imagine work on async needs to be slow and more methodical due to how it interacts with the rest of the language. So a lot of language features are being added to support it more ergonomically. However, those features are also being designed very carefully, and as a result they ens up being just overall great boons themselves too.

So, tldr: async can suck a bit, but slowly getting better, and as a result it's making the rest of the language better too.

I don't think some people who complain about async in Rust don't truly appreciate how "high level" it feels and how unobtrusive—for the most part—it is for a systems programming language!

I’m excited to see how this organization structure works out.

BDFL works very well at the cost to the BDFL’s time and general well-being.

Is this SME approach kind of like a Voltron team of mini BDFLs?

What means SME and BDFL?

Edit: SME: "Subject Matter Experts (SME for short) are Bevy developers that have consistently demonstrated technical expertise and synchronized vision within a given "subject area" "

SME as defined in the article.

BDFL is benevolent dictator for life. A nice name put on that one person at the top of a project who makes all the decisions on controversial stuff.

In this context, "Subject Matter Expert" (it's explained in the article) and "Benevolent Dictator For Life" (humorous title applied to the leaders of Linux, Perl, Python, etc)

Yeah, that's a pretty good way to describe it :) Game engines have an alarming number of different areas that require deep expertise: the hope is that we can align on broad values and goals and then empower experts to make good decisions quickly.

Isn't this basically how kernel development is structured?

> and the second most popular game engine on GitHub

Strictly speaking, this is not exactly true, Unreal Engine has 24.8K stars as I wrote this. It is private though!

> It is private though!

It's source available, which is better than closed source. For a game engine, it has to be, but I wish more "closed" projects were available like this. I would love to tweak and rebuild iOS or Windows or Discord. Or just peer inside.

To get access to Unreal Engine's source code, go through their website signup process. They want to be able to track growth/engagement, send you marketing emails, and have you sign their TOS/EULA/license agreement. But from there it's all available and you can build the entire engine and editor from source.

Certainly but the repository itself is private so it has less public visibility, copy-pasted from the header:

> EpicGames / UnrealEngine Private Unreal Engine source code

www.unrealengine.com/

The fact that Bevy is Rust is a Blocker for me.

Haskell or bust.

Please don't bother replying about how Haskell can't do gamedev - I will ignore you with a smile :)

So what are you currently making with Haskell? And is there any game engine or libs that we should be using?

There aren't _really_ any common engines, but the libraries are there. Most people make their own "engine," which makes sense because the way people think is so diverse.

There's low-level graphics libraries for OpenGL and Vulkan (two different libraries for each actually). There are also some higher level graphics libraries like GPipe.

apecs is an excellent ECS library and probably the biggest commonality between devs.

linear is a great linear algebra library by kmett.

Haskell also has a great C FFI so any C library is fair game. You can honestly just do C-style gamedev in Haskell if you want. Although I'd recommend apecs on top for sure.

And there's all the same libraries people use for other stuff. All the abstractions you learn doing webdev or writing compilers or the other normal Haskell stuff still apply. It's cool to see how gamedev concepts fit into the typeclassopedia.

Overall, Haskell gamedev isn't easy but it is fun and I wouldn't even bother spending my time doing it if the Haskell factor wasn't involved.

Reply on news.ycombinator.com