The Bevy Foundation

Any plan for Physics? There is no mention on front page of the website.

When do the team think the would be comfortable telling people they can build and release game on it?

Physics is 3rd party currently, but it's on our roadmap for "some day, definitely". Writing your own physics engine is... a lot of work, and not something that I'm excited to volunteer the engine itself for immediately.

There are two popular physics engines used in Bevy today: Rapier[0] and bevy_xpbd[1]. Both are candidates for upstreaming, but both have their own challenges. I've spent some time working with each of the authors recently, laying out my concerns and thoughts.

On the Rapier side, the documentation is sparse and aggressively mathematical, it uses a distinct math library from the rest of Bevy, the API to work with Bevy is sometimes clunky and unidiomatic, and it can be quite hard to figure out how to do Ordinary Game Dev Things with it.

On the bevy_xpbd side, the performance is subpar, there can be physical stability issues, it's generally immature, and the XPBD solver that they use is, unbeknownst to the young author at the time of the crate's creation, patented by NVIDIA [2] :(

Both of them are working to improve (and I'm very pleased to see that even independent of this discussion), but neither is ready for imminent official endorsement or integration. One day we'll have a Blessed Choice though.

As for telling people "go forth and build your game!": things are stabilizing, and key functionality gaps are gradually getting filled. I have a terrible tendency to be overly honest, even in my marketing text, so there's going to be a long period of time where the actual answer is "it depends on what you're making".

Today, if you're building a weird game-adjacent bit of software (think CAD) for desktop platforms: totally ready! There are several very happy companies doing that. If you wanna mess around with Rust and nurse the Next Great Solo Dev Science-Based MMORPG Voxel Game: you'll have a blast, and it won't affect your chance of shipping a whit. If you want to build a simulation-y desktop game with lots of procedural generation and complex logic: honestly probably a good fit. You'll hit bugs and limitations, but you will in every other engine you use so...

If you want to ship high-performance web games, AAA graphics or mobile: eh, probably doable but dicey. If you want to ship to console: uh we'll find out if we can jump through all of the hoops and convince the right people to get Rust on console before the Steam Deck knockoffs devour the market (please!).

These will all slowly change, but an answer for "is it ready" will be hard to pin me down on until it's a full-fledged competitor to Unity, Unreal and Godot.

[0]: https://rapier.rs/docs/

[1]: https://github.com/Jondolf/bevy_xpbd

[2]: https://github.com/Jondolf/bevy_xpbd/issues/346

If you are trying Bevy for the first time, and it runs slow, put this on your Cargo.toml

    [profile.dev.package."*"]
    opt-level = 3

Yes. But when I tried the tutorials, the performance issue was an instant turn down.

With this, the frame rate immediately went from 13 fps to 60 fps.

The curse of "zero cost abstraction" strikes again :/ A 5x performance difference between debug and release mode isn't uncommon in C++ either and a real problem for game development (plus the slow build times, but those two problems go hand in hand - you can have "high-level abstractions" that build slowly and run fast, or build fast and run slowly).

That's why there's so much advice to write C-like C++ and also ignore the stdlib in gamedev circles. The Rust equivalent is probably to write "embedded style Rust".