Bevy: A Game Engine in Rust | Hacker News Reader

Bevy: A Game Engine in Rust

bevyengine.org

96 pointsmoomin42 comments

Previous discussion from 20 days ago (556 points): https://news.ycombinator.com/item?id=24123283

Possibly OT but: For a very experienced dev who knows numerous languages ranging C/C++/Go to Ruby/JavaScript to Elixir, what's the most effective way to learn enough rust to be dangerous?

I like the Rust book a lot but it's a bit too slow moving. It explains concepts I already know so I have to skim, but then I miss something.

Perhaps the best thing doesn't exist yet! Maybe I'll write it someday. But I thought I'd ask ;-)

Rust By Example helped me to get off the ground pretty quickly and give me some ideas when I was stuck. But honestly just making something is the best way to learn rust, the compiler will hold your hand enough for it to be a pretty good learning experience

I assume by "the Rust book" you mean "The Rust Programming Language".

There is also "Programming Rust", which you might like better.

One of the smartest people I know swears by “Too many linked lists”.

I agree that the Book unfortunately moves a little slow for an experienced programmer, but I think it's still important to push through at least most of it and get all those little tidbits.

After that I really like this resource, which gets much more practical about problem-solving borrowing issues and introduces some really important tools from the standard library: https://rust-unofficial.github.io/too-many-lists/

If the Book teaches you what features Rust has, this teaches you how to use Rust in practice. It also taught me that it was a fool's errand to go and try to implement all the core data structures as a part of my learning process, because that kind of pointer-twiddling is one of the hardest possible things to do in safe Rust :)

Oh wow, thanks for the recommendation! This is remarkably similar to how I learned C++ back in college. It was a data structures class and we built a few of them. Nothing cemented the concepts as well as building our your own linked list. I will definitely give this a read :-)

I'd suggest picking something small that you personally want to get started. For me, I wrote Dingus (https://github.com/davidarmstronglewis/dingus), which is really just a simple CLI that reads environment variables from a file and either executes a command with those loaded or drops you into a shell. I was finding myself constantly populating my shell environment with different variables depending on various contexts and figured I would canonicalize the process and learn more about Rust in the process.

I still use the tool today (although I'm still not sure it's the most elegant solution :P), and I've taken that knowledge I picked up in the process for other projects I've since done in Rust.

If I were where you are, I'd do something similar: carve out a simple project that you could complete in a day (or two) in a language you're more familiar with, and try to do it in Rust.

I'd also recommend joining the Rust Discord channel to field any immediate questions you might have (and going to the Forums if there's something more involved you'd like opinions on).

Good luck :)

Not a resource, but some advice for learning:

Even though the two concepts are intertwined, you'll master borrowing well before you master lifetimes. And that's okay.

Early on you'll probably not need to author many structs that require lifetime annotations. If you think you need to, you're either purposefully building something complicated and/or memory-limited, OR you're using the concept without understanding and not needing to do so.

If you can stay away from writing your own explicit lifetimes on structs and interfaces while you're learning, it becomes a much easier process.

Once you've mastered this stuff, Rust is seldom more difficult than any other language.

It's like that quote from the Matrix. You get used to it. Pretty soon you won't even see the borrow checker.

Solve some of the Advent of Code challenges and you should be good to go.

For someone with better first hand experience, how does this compare to other Rust game engines [1] [2] [3]?

Is Bevy flexible enough to let you drop down into raw OpenGL?

I'm writing code that does a mix of point cloud rendering and traditional asset rendering (I'm new to all of this), and I'm wondering if I should adopt an engine instead of rolling everything myself with a mix of OpenGL, matrix math, and Imgui.

I'm trying to do due diligence, but I'm too new to games and 3D to know what to look for.

[1] https://github.com/amethyst/amethyst

[2] https://github.com/PistonDevelopers/piston

[3] https://arewegameyet.rs/ecosystem/engines/

Right now bevy only supports webgpu. Webgpu is going to take over the world.

For that specific comparison, I recently read https://community.amethyst.rs/t/bevy-engine-addressing-the-e...

While I haven't tried either of these engines seriously yet, I really enjoyed reading that thread.

Thanks for that link. I think that's a wonderfully judicious and maturely big-picture perspective on Bevy.

The rendering backend is a work in progress. In the near term, it'll let you use several levels of rendering abstraction, down to wgpu, which is what it currently uses, and eventually vulkan as well.

At the very least, you should move to a more modern rendering api like vulkan, wgpu (though I'm biased), metal, or dx12.

How long does OpenGL have until it's deprecated?

I'm not sure OpenGL will ever be deprecated, but it's always been a pretty awful and very complex api.

While the page mentions the project being in an early stage, I skimmed through the Bevy Book and what I read so far looks promising. The text is detailed, relevant and has good grammar, which to me inspires confidence.

On the page https://bevyengine.org/learn/book/getting-started/resources/ however I am not able to navigate to the next page after it on mobile, because the arrow linking to the next page is almost entirely off-screen and can not be touched. This is in Safari on iOS 13.6.1

On the surface it sounds similar to Godot. Is that a fair assessment?

Could be an interesting alternative - C# is a popular choice to avoid C++ and I always find myself really worried about performance and correctness compared to C++. I'm more productive but there's no const-correctness (for example)

From other docs on the site:

“Bevy aims to be a general purpose game engine capable of handling any 2D or 3D workload. However Bevy is still in its infancy. We are currently in the prototyping phase: important features are missing and APIs will change constantly. If you are currently trying to pick an engine for your Next Big Project™, we recommend that you check out Godot Engine. It is currently much more feature-complete and stable. And it is also free, open-source, and scriptable with Rust!”

https://bevyengine.org/learn/book/introduction/

A big distinction for me is not having a nice UI for level design and 'arranging' everything that isn't the code, though a lot of the other aims do seem pretty similar

There's going to be an editor, but these things take time.

of course, just pointing out that right now it's a pretty large distinction between the two

It's very early stage.

Why every time I read about Rust the title is in form "xyz written in Rust"?

For example Unreal engine is a game engine. Not "a game engine written in C++".

Because the default is generally C++?

Since when it's been the most interesting thing about the software in which language it's been written in?

I mean sure sometimes it is but show me a Rust software that didn't advertise itself being written in Rust.

There are a lot of “X in C++” posts here on HN as well. I don’t think it is really new or specific to rust.

I also dislike the emphasise on the programming language, but many people seem to find it important.

Generally it's interesting when almost all of that type of software isn't written in the advertised language.

Ripgrep?

> Since when it's been the most interesting thing about the software in which language it's been written in?

Presumably because I'm going to be writing the same language when I interface with it. Rust can export to a C API but if I'm using Rust myself the API is going to be better.

It's to get adoption by that particular group that uses X and has to deal with the issues of that domain and the default language they all use ... It's a way of saying: you could be doing all your _real_ development in Rust

I write software in Rust, so to me it is relevant to learn about new libraries and frameworks that are written in Rust.

There are enough existing and new game engines and frameworks that if the title was simply “Bevy: A Game Engine”, then I might not have bothered to clicked on it only to find that it was written in C++ or Lua or Python or what have you. I use other languages too, mind you, it’s not that – it’s just that aside from Unreal, Unity and Godot, the only other game engine or framework that I am interested in knowing about at the moment is one that is written either in Swift or in Rust.

Conversely, stating it upfront also allows anyone that does not want to write in Rust to avoid this particular game engine at the moment.

I see only benefits of stating it.

It's interesting if it's truly unexpected. For example, there's a game that's been in development called Black Annex that's written in QB64 which looks quite complicated for having been written in a BASIC variant. But for Rust, which is commonly advertised as a C/C++ replacement, it seems unnecessary. I think that developers include that information because they don't feel that Rust's traction isn't being given enough recognition.

When I go to a store and buy Milk the carton doesn't say "Milk made by Cows". When I go to buy Milk/Milk-substitutes from other sources they'll be called "Almond Milk", "Goat Milk", etc.

It seems like you stop saying "made by Cows" when it's not surprising that the Milk you'd be buying is from cows.

I think it's actually pretty common that when a fairly typical thing is written in a newer/modern/less common language, it's often stated as "X written in <new language>"

The first thing I look for in a game engine is what language it's written in. The second thing I look for is what language(s) it lets the user write games in.

I think the people rationalizing are wrong. You're right that you see a lot of posts with "X is a Foo written in Rust!".

A few years ago I saw a bunch about Go, too. That seems to have died down.

But I think the real reason is that people are excited to use Rust for "real stuff". And a lot of Rust fans don't get to use Rust at $dayJob or whatever. There's also a bit of naysayer criticism that it isn't a practical language, etc.

So, no, it doesn't really matter that something is written in Rust. It's just Rust fans being hyped up about it. It might be a little annoying, but replies like yours aren't really any better, honestly.

Because it implies that it is extendable/scriptable in that language.

Unity and Unreal, for example, are not scriptable in Rust. Anyone interested in writing games in Rust would surely be more interested in an engine that supports it.

OP here: without being clickbaity, the idea was to choose a title that gave people some idea of why they might want to read about it. And titles can’t be that long. I’m told Bevy does really interesting things with traits, for instance, but even that is too long for a title.

In this case, the thing we're talking about is a library that uses Rust data types and interfaces.

It might be possible to create language bindings for C or C++ (or whatever language you want to use), but the docs on the website seem specifically targeted to Rust users. So for now, the only people likely to be interested in using this are Rust developers (though people coming from other languages might find the general design interesting).

Reply on news.ycombinator.com