Hacker News Reader

Comment by _cart | Hacker News Reader

Bevy's creator and project lead here. Feel free to ask me anything!

We're building a fairly big WASM app in Bevy (relative to our company's size), and it's been a pleasure to work with the engine.

Bevy and the community are awesome. We needed a couple of tickets worked on, and it was so easy to find one of the core contributors to sponsor and push our request over the line (morph targets).

Thank you so much for everything, Carter! You're building something incredibly important that has fantastic momentum behind it.

Bevy is wonderfully easy to deploy to the web, and people should be checking it out. The community is great, and it's easy to find help.

Thank you for the kind words! Messages like these are what help me push through the hard days.

I'm put off by the limited docs. I've read the Bevy book, only takes a few minutes, and just like that I'm out of resources to turn to when I get stuck.

When will the docs improve? I look at the release notes and ideally every one of those features would have several pages of docs. I understand that's a lot of work, and maybe things will have to stabilize before we get full docs?

The examples in the github repo are fantastic and cover a lot of ground. That's usually my goto when trying to figure things out.

There's an unofficial complement to the docs that covers a lot of different topics here: https://bevy-cheatbook.github.io/introduction.html

Unfortunately it's somewhat out of date

I mean, Bevy 0.12 was released... Yesterday.

Most pages are for version 0.11 or 0.12 already, and not much changed between the two versions besides the assets, if you already have a game written in 0.11. Together with the release notes, you'll survive :)

The cheat book is written for some smeared set of versions since it's inception. It is out of date for 0.11 as well. The effort to keep it up to date is somewhat low since Bevy changes so much an so often in its current development.

Among Bevy contributors (including myself) there is a general hesitance to invest too much time in official learning material that will be obsolete by the next release. Bevy's APIs are beginning to stabilize ... and the appetite (both from users and from Bevy devs) for official material is increasing. The time is coming (soon)!

While you wait, there are a sizeable number of tutorials on YouTube, and we have learning material linked in https://bevyengine.org/assets/#learning as well.

Nit: developers who use bevy should be called bevy devys.

Bevy does have plenty of documentation here: https://docs.rs/bevy/latest/bevy/

What's missing is tutorial type documentation, but individual features are generally documented.

I've been writing https://taintedcoders.com/ for a while and will be keeping it on the bleeding edge. Hope you find it useful.

Thanks for posting - hobby game dev here, know just enough to be dangerous.. if I was going to start a new project, it would be in your engine, seems like it splits the diff between Love + Godot, more robust than Love, not as geared towards novices as Godot.

How opinionated is bevy? Have you ever had to make tradeoffs between features and developer accessibility?

What is the "ideal" project to use bevy for right now?

Bevy tries to have its cake and eat it too. We have a large, opinionated featureset (ex: how should rendering code look, high level materials, sprites, meshes, animation, scenes, etc) where everything works nicely together. However we are extremely modular to the point that you can do pretty much anything in Bevy. People build their own renderers, do command line only terminal UIs, custom UI systems, etc etc.

We make tradeoffs all the time. We prioritize accessibility / developer UX to a pretty high degree. But this very rarely means cutting features. The hard part is generally _how_ we expose a feature, not _if_.

"What is the "ideal" project to use bevy for right now?"

Bevy is well suited to many project types. The biggest missing piece is a lack of a visual editor (we are working on this, and while you wait you can use programs like Blender or ldtk to compose your scenes). I'd say the ideal project is (1) Small-to-medium-sized in scope, to help mitigate the risk of using a younger engine (2) doesn't need a full Bevy Editor / can get away with code driven or external-editor-driven scenes.

Yeah, that's not a bad way to describe its positioning.

Currently not a lot of batteries included: the experience is much more like "writing a web app using a framework" than it is "boot up RPG Maker".

Generally speaking, Bevy is extremely flexible, with pretty generous defaults for enabled features to let beginners avoid worrying about toggling feature flags and controlling plugins.

In game engine development, features are typically strictly additive, so features vs developer accessibility isn't a great way to frame the tradeoff. Instead, we often push work into the third-party plugin ecosystem to ease maintenance burden or let it mature.

As for the ideal project, I would either say "solo programmer who wants to learn Rust and game dev for fun", or "small, serious team looking to build an unusual systems-heavy game".

What (dis)advantages does writing a game in Rust (with Bevy) have compared to other languages? Keen to hear about performance, safety, and dev velocity.

I gave a talk about this recently![0]

But, to answer your question directly:

- Rust performance is comparable to C/C++, but Bevy has had much less time to get optimized than C/C++. Our ECS is fast, but slower than flecs, and our rendering performance is about Unity level IIRC.

- Safety / correctness is a huge benefit. Memory safety is obviously nice for reducing horrible segfaults, but ultimately I end up really loving enums, traits and the ease of unit testing to make refactoring games (and the libraries they rely on).

- Talking to experienced game devs, velocity is quite good! Once you're off the ground, a ton of your time comes from a) refactoring b) bug fixing c) adding bog-standard but tedious functionality like localization. I've talked about the first two, but Rust's first class packaging ecosystem (and Bevy's modularity) means that you can actually share work for that, rather than rewriting it at every company like you see in a lot of other game dev.

Gameplay features are wildly easy to write, but GUI creation is still miserably tedious with a fragmented ecosystem.

On development velocity, I will note that Linux's compilation times for Rust are meaningfully better than Windows, although M1 Macs are compelling too. The lack of visual editor tooling definitely slows things down too, even though good ecosystem options for that are emerging.

[0]: https://elk.zone/mastodon.gamedev.place/@alice_i_cecile/1113...

Also, consoles are out of the question, right? Well, maybe Xbox.. maybe. And what about mobile?

That's a big leap, what makes you say consoles are out of the question?

The console toolchains are proprietary and locked behind NDAs. An engine cannot be both open source and support consoles. What it can (and Godot does) is have a closed-source version of the engine (or just plugins) that you are only permitted to license once Sony/Nintendo/MS has approved you. That version or those plugins can then contain the code required for the consoles.

Yes, exactly this with an added hurdle of Rust which isn't supported by any of the mainstream consoles.

An engine can be open source with proprietary extensions.

Steam Deck functions great, Xbox is a well, maybe. Playstation and Switch are "negotiate with the console owners" situation.

Mobile is functional but immature, same with XR.

You need to be comfortable with Rust and with ECS.

If you’re coming from a GC language and `Player extends Entity` mutable OOP approach, you will have to completely re-learn how you architect games.

The upside is that Rust is pretty fast, and Bevy takes advantage of Rust’s relatively easy multi-threading.

The biggest disavantage is that no one uses Rust to create games, it's all C++ or C#. So all the documentation, knowledge, libraries etc ... are missing and / or different.

Or JavaScript, surprisingly. Vampire Survivors is the most famous recent one. Pretty cool to think about.

when we will see dynamic systems and other features necessary to unlock first class bevy scripting?

there are some scripting plugins (mainly focusing on rhai atm) but I feel that they are stonewalled by lack of proper bevy support

i mean regardless of whether the current bevy focus is in rust-only games, there is demand for scripting and people are already scrambling for third party solutions. I don't expect to see first party bevy scripting just yet but I think that bevy should adopt foundations for third party crates to work with

Any chance for some sort of "Bevy Studio" app to appear in the future?

It's not that I don't like programming, I'm just brutally time-constrained (kids).

Not the author but there's a Bevy Editor on the roadmap.

Yep. Built with Bevy similar to how Godot is self-hosted. They are still figuring out the details like which UI framework to use and how to save scenes. Which abstractions to introduce - nodes like Godot, objects+components like unity, etc? Then debate on how "prefabs" are designed - are they just bundles? Entity and component serialization.... Tons of architectual decisions.

It's coming together.

The UI framework will be bevy_ui just like godot uses godot ui library. What needs to be done is improve it so it can actually work for making a complex app.

Yup! The Bevy Editor is our current highest priority. The first step is building out a new Scene / UI system that will serve as the foundation for the editor (as the Bevy Editor will be built as a Bevy App).

I have a post about this (with working prototypes) here: https://github.com/bevyengine/bevy/discussions/9538

Oh wow, that is a detailed post. Thank you for your hard work!

I’m a rank beginner at game programming, GPU programming, and Rust.

Is it possible to access compute shader functionality through Bevy / Vulkan? Basically, offload arbitrary GPU appopriate calculations to the GPU?

Yup! Here is a Bevy example that simulates Conway's Game Of Life in a compute shader: https://github.com/bevyengine/bevy/blob/main/examples/shader...

Thanks!

Sweet! Always a suprise to see how much ends up in a release. It seems like the last three weeks there are as much features merged as in the rest of the release window.

Technical question: will there ever be a guide that talks through how the rendering part of bevy works? The graph and all is great, but really difiicult to get into without the help of discord.

Haha yeah we have a tendency to merge a lot of "ready" work near the end.

We do plan to have a thorough rendering guide. We've just been putting it off as the renderer has been (and still is) in flux. Once the dust settles a bit we'll start investing in "documentation on-ramps".

Thanks for creating and maintaining Bevy! Has there been much thought given to embedding Bevy in regular GUIs, say if I wanted to display a 3D model inside of an Iced app? I was only able to find things that worked the other way, embedding Iced in Bevy.

Maybe this would come as part of the Bevy editor that's planned?

Learning here - long time sw eng, but mostly back ends. So I’m starting down the emulator path. Would this work with the display/ui portion of an emu like an 8080/chip8? Since the logic is in the opcodes, most of what I think is needed is displaying vram, ui, windowing (screen, options, stack etc). It is still fuzzy where “ui” ends and “game engine” begins.

Your pages are great and readable!

I suspect that as a visualizer for an emulator, Bevy would be a reasonable fit. You could use Bevy UI or build your own for the emulator interface. You might want to build a custom shader to display emulator outputs. You could also consider doing a custom renderer in Bevy if you see the need. Theres also always the option of dropping down a level and using a graphics api like wgpu (which is the "low level" api we use under the hood that allows us to target Vulkan / DX12 / Metal / OpenGL / WebGL2)

Thanks! I’ll give it a try!

Have you considered moving off of 0.x.x? You have people consuming this software, it's public, and if you plan on breaking it quarterly, just be upfront with people and move through major versions.

LÖVE made the same mistake for years, and their version history looks odd as a result due to the sudden jump from 0.10 to 11.0.

You'll be working on Bevy for years. When do you decide it's ready for public "stable" usage, and how do you plan on communicating this to users?

> and if you plan on breaking it quarterly, just be upfront with people and move through major versions.

Isn’t that exactly what a 0.x version means? This seems far more up front with people that releasing a 1.0 that bumps to 2.0 3 months later.

I think until the engine is baked enough that the API avoids breaking changes for years at a time it should remain pre 1.0.

What will most likely happen is that there with be large subsets of Bevy users who never use a formally stable Bevy codebase, and then leave for something different, because there are no guarantees.

Maintainers of all sorts of different projects also signal to their users their investment value in working with a large critical dependency.

I think it depends on how the developer views 0.x releases. In Bevy's case there has been discussions around backwards compatibility and I think it'll happen but right now it doesn't make sense until the major systems are in place.

My impression from being in the community for awhile is that the devs don't want to perpetually stay with 0.x releases. It's just that a game engine is a big thing with a lot of moving parts.

> What will most likely happen is that there with be large subsets of Bevy users who never use a formally stable Bevy codebase, and then leave for something different, because there are no guarantees.

But naming it 1.0 won't give them guarantees either. If it's assumed, it would just be annoying when breakages do occur. What you're really asking for (it sounds like) is for there to be less breakages or longer term releases .. and that's a staffing issue imo.

If users avoid it because they don't want churn, and the devs are choosing churn - then everyone is in agreement currently, no? The bevy devs are writing software in a way that fits them currently, and users who prefer to wait for 1.0 are doing so currently. Everyone gets as advertised.

Do you see it working differently?

But you haven't asked for them to release a formally stable Bevy codebase. You just asked them to change to a 1.0 version that implicitly promises a stable codebase. You specifically asked:

"and if you plan on breaking it quarterly, just be upfront with people and move through major versions."

That's not being up-front with people. A game-engine that breaks quarterly absolutely isn't ready to be versioned with a major-version. As I said in response to your first post, a "0.x" versioning system *is* being up-front with people.

If instead of suggesting: "can you switch to a 1.0 major version that you increment quarterly", you're instead suggesting: "can you stabilize the API and not release breaking changes quarterly" I think those are two entirely different requests. Your first post made the former request, which is what I was responding to.

We've discussed this pretty recently on GitHub [0].

I'm personally in favor of shipping 1.0 within the next year or so. The most interesting part of that to me is figuring out how to decouple the crates without creating major confusion, in order to reduce trivial plugin churn.

For the most part, this is just marketing and semantics, but Bevy is nearly ready for commercial users and we should start communicating that. Quite a few brave users are already building production games (and non-games), and feedback is generally very good! [1]

[0]: https://github.com/bevyengine/bevy/discussions/9789 [1]: https://github.com/Vrixyz/bevy_awesome_prod

I'm hoping public/private dependencies RFC will help some. One idea we have for a follow up is to declare that you should get the version req for one crate from another.

It can be communicated when it becomes stable and goes to 1.0.0 for the version. Until then it shouldn't dare move past 0.x.0 just because people think it should.

Reply on news.ycombinator.com