Game dev in Rust: a year later

Bevy is the most advanced Rust engine, and it doesn't work well if games that succeeded commercially, did so by not using most of the ecosystem to start with.

Game development, what could be more unsafe than Assembly coding and taking advantage of hardware tricks pushing the hardware to the limits, aren't going to rush in grooves to Rust due to safety.

Rather what can an engine, written in Rust, offer that they aren't having already wiht existing engines, also noting that the safety aspect is already taken care by Java/C#/Verse/Blueprints/Lua/Python/JS scritping.

It's because these are mostly passion projects by hobbyists. A lot of the stuff is written by undergrad students with a lot of time on their hands, and once they graduate and move into professional life they no longer have the time and the projects get abandoned.

Creating high quality, reusable components (like game engines) takes a lot of effort. It's unlikely to happen without funding.

And that's only half of the story, to make an actual game (or other product) you'll still need the art content which is expensive.

I'm about 3 years worth of Saturdays and 20kLOC into my current project in this field and I haven't even released anything because I don't need anyone to tell me it's "half baked". While I have some stuff that's starting to be in a shape where it could be usable to others, it would still need a lot of effort to make it friendly for others (e.g. api docs, examples and stuff) to jump in. That again takes effort (there are only so many Saturdays in a year) and it's much less interesting work than doing the research-ey bits and experimental work.

Unfortunately I think this is a chicken and egg problem. No-one with the funds and the staffing to build a game or an engine isn't going to jump in to unproven technology. Not using Unreal or Unity is a huge gamble to take with your business venture.

[1] https://veloren.net/

1 - The proprietary vulkan drivers were a massive pain, nvidia or AMD, and whatever the OS. Had no issue with AMD vulkan mesa.

2 - It seems there are critical bugs in GPU hardware which this game did manage to hit.

3 - rust toolchain is missing a "-static-libgcc" option in order to work around libgcc ABI issues, "bug" which is opened on microsoft github since 2015... Which makes rust unsuitable for 'correct' elf/linux generation of binaries for games.

4 - that game is really good.

mature, battle tested engines don't pop up overnight.

The distinction here is crucial—by having no combat, management aspects, or any sort of objective or failure state whatsoever, there is nothing to balance or iterate on design-wise.

It looks very nice, and I'm sure it took quite a bit of effort to make it look as good as it does. But taking an existing product's design (Townscaper) and adding more features and prettier graphics is not indicative of Rust being useful for game development, because game development entails a lot of design-wise balancing and iteration.

Almost certainly but it depends on what you're making. If it's something that requires huge object graphs and GC then you'll probably have a bad time in Rust.

The compiler guarantees, dependency management, and modern toolchain is miles ahead of C++. I find that you have to be a wizard in multiple areas that don't necessarily involve programming when you're working on a C++ project. This comes on top of being a wizard in the language itself since it's huge and the std library has warts due to the "ABI compatibility over everything" mindset.

Such as? There are only a couple of ones that come to mind, for very specific use cases.

What's underwhelming about Rust's enums and pattern matching? Lacking indexed types/GADTs?

> I even wonder if it's necessarily a better choice than modern C++ for someone starting a new project.

The same enums, matching and other language features that aren't related to safety and yet allow the developer to write less boilerplate, alleviate the need to remember implementation details of the code used. And as someone said here, safety is not only about security vulnerabilities.

Not once I had problems with the borrow checker. Maybe it depends on the domain, requirements or project size. While I haven't finished any game in Rust, I am writing one (as a hobby/learning) and I try to avoid unnecessary and noticeable performance hits. Though I am working under the assumption that some runtime checks that are present in safe Rust and not in C++ are a net positive due to easier debugging. I'm not convinced that "unsafe" code and asm are necessary in modern gamedev.

It's not “circumventing” the rules, it's adding automatic runtime check that the invariants are properly maintained when you cannot prove them at compile time.

The default restrictions are here so that you can have safe code without any runtime cost but, every once in a while, such limitation presents you from doing what you want to do. The various data structures you're talking about[1] then make sure that you can write the program you want but that it will not trigger undefined behavior, at the expense of some runtime cost, be it a branch (for RefCell) a reference count increment (Rc, atomic increment for Arc) or a lock.

[1] it's not “a myriad” though, merely 6 of them: Rc & Arc for shared ownership / being 'static, and RefCell, Cell, Mutex and RwLock for shared mutable state)

C++ has decades of infrastructure, and is still the standard for games, so it's almost certainly not the better choice if your goal is shipping.

It's arguably better for best practices and may be a standard in the far future, but you're going down an untrodden path if you make that choice. you'll be spending just as much, if not more time fighting your tools than making a game. (unless you're comfortable with the few stable-ish Rust game engines).