Comment by armchairhacker | Hacker News Reader

Comment by armchairhacker | Hacker News Reader

To me, Bevy is a completely different way of making games vs traditional engines like Unity, Godot, etc.

There’s no UI or scripting, everything is done in Rust code. This makes it more like more like libGDX and Cocos2D-x.

But unlike those engines, it uses ECS and Rust which makes coding in it completely different. So it’s kind of in its own little island.

I’d love to see successful indie games use Bevy. However, I know most game developers aren’t going to prefer it over the more traditional tools which they’ve been taught and everyone around them is using. I’m not sure the intersection of people who want to make games and people who prefer Rust is large; and even within this intersection, most people aren’t going to dedicate considerable amount of time and effort into learning and using an experimental new engine, they’re going to use something with existing trust and resources.

Personally I think Bevy needs a sort of IDE and scripting language which is powered by Bevy and Rust. This won’t remove the “considerable effort into a new project” obstacle, but it would make Bevy much more inviting to newcomers who don’t have experience with Rust and who would be too intimidated to start from a wall of code (vs a canvas like Unity or Godot where you can have a very basic prototype within hours). Plus, I believe the developer is against scripting languages, but I really think that hot reload and more invasive debugging is necessary and can’t be effectively done in Rust (plus as just mentioned, many game developers will be overwhelmed with Rust and it’s borrow checker). But those are just my thoughts, and right now I don’t have the time, resources, and dedication to implement them myself…

Bevy is structured in a way that you really don't have to interact with the borrow-checker very much. Components and Resources will probably always use owned types, and Querys and Refs let you interact with them without having to worry too much.

I've been playing with Bevy a bit, and I just checked my repo; it has 0 lifetimes.

That is usually the case in Rust. One mostly deals with lifetimes in library code

>However, I know most game developers aren’t going to prefer it over the more traditional tools which they’ve been taught and everyone around them is using

IME, the most time consuming parts of game development is asset management,closely followed by the programming. An engine like Bevy does a lot to try and cut down on bug fix time, but the lack of some sort of asset pipeline means you lose those savings on the asset side. scripting language would help a bit, but the sort of people using Bevy at the moment don't have a strong need for it (very technical people, not necessarily full time designers).

I do strongly look forward to how the Rust community impacts game development, and I want to eventually contribute. But I'm sticking to C++/C# pipelines for the reasons you lay out. I can properly learn rust on the side and perhaps consider it for later projects as tools mature.

> Plus, I believe the developer is against scripting languages, but I really think that hot reload and more invasive debugging is necessary and can’t be effectively done in Rust

I understand where you're coming from, but consider another angle. Hot reloading is often a band-aid around when compilations times grow unwieldy. If your code compiles in 4 seconds on average (and lets say, 20 seconds for a full re-compilation. These numbers are completely arbitrary), then there's not as much need to focus resources on ways to get around full compilations.

That said, I hear Rust in general takes longer to compile programs, so I can imagine the need for scripting/hot reloading to come sooner rather than later. But current indie projects being worked on likely won't run into that barrier.

It should also be mentioned that there are a bunch of ways to improve compile times. Bevy for example has a feature to compile itself as a dylib, which helps avoiding the cost of relinking everything together. The Cranelift backend for rustc will also help reducing compile times in debug mode. In Bevy's case it could be used for the binary crate only, leaving Bevy itself and other dependencies built with optimizations and dynamically linked, while the binary crate gets rebuilt very quickly but with less optimizations.

Hot reloading still has a place for quickly prototyping thanks to not resetting the state of the running program, but this is a lot trickier to do with Rust. I think we'll likely see better scripting support (with hot reload for the scripts) instead.

IDE has been planned for awhile and I believe it’s top priority after this release.

Cart (the creator of bevy) believes bevy should be rust first. Personally I agree, but that doesn’t mean people can’t create plugins for various scripting languages. In fact there are some already.

Reply on news.ycombinator.com