Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Game dev in Rust: a year later

users.rust-lang.org

Post reply on HN
Print view View original

21–30 of 71 posts

Re: Game dev in Rust: a year later

#21

Post by littlestymaar »

pjmlp wrote: post #4
indy wrote: post #2

Tiny Glade ( https://store.steampowered.com/app/2198150/Tiny_Glade/ ) is an impressive example of a game written in Rust. Apart from that exception, Rust game development seems more about releasing half baked crates than actual games

Which follows the pattern of only partially using the ecosystem and doing the relevant parts themselves. 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…

> 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.

Tinyglade uses Bevy though. Granted it doesn't use all of Bevy but given who made it and how advanced the tiny glade renderer is, no commercial engine would have offered out of the box the rendering features the devs wanted for their project anyway.

> Game development, what could be more unsafe than Assembly coding and taking advantage of hardware tricks pushing the hardware to the limits

This vision is outdated by at least 20 years. A significant fraction of games today is actually written in C# (Unity) and most games don't need to push the hardware at all. It's mostly AAA title that do, and a significant fraction of that effort is made so that aging consoles can run the games. Unreal engine itself is more used because it is packed with features while being relatively fast, not because it's as fast as hardware can get.

> aren't going to rush in grooves to Rust due to safety.

In the context of gamedev, safety mostly doesn't mean security vulnerabilities, but fewer intractable multithreading bugs or UB. It affects velocity and that's why there's a tradeoff between Unity and Unreal: Unity being much faster to code with, but can very quickly become slow and you need to spend time optimizing your hot loops (gratuitous allocations being a #1 concern), code written in C++ for Unreal being much faster by default but also much more prone to bugs.

In theory Rust offers the best of both worlds, but the ecosystem is still years behind so no wonder why game studios don't rush using it.

"Can Rust catch-up?" Is an open question, and the first 5 years of gamedev in Rust (2015-2019) went pretty badly in that regard, but since then Bevy occurred and now there's legitimate hope that some day Rust may be a viable choice for most studios.

Re: Game dev in Rust: a year later

#22

Post by pornel »

pjmlp wrote: post #4
indy wrote: post #2

Tiny Glade ( https://store.steampowered.com/app/2198150/Tiny_Glade/ ) is an impressive example of a game written in Rust. Apart from that exception, Rust game development seems more about releasing half baked crates than actual games

Which follows the pattern of only partially using the ecosystem and doing the relevant parts themselves. 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…

TinyGlade's (co)developer said he's very satisfied with Rust and the crate ecosystem. They've used Bevy's ECS:

https://youtu.be/jusWW2pPnA0?t=3275

Using individual components instead of the whole big framework isn't necessarily a failure. The components are designed to be usable independently.

TinyGlade project started a few years ago, when Bevy's rendering was even more basic. The art style is central to TinyGlade's appeal, so it's not surprising they've built a custom renderer.

Re: Game dev in Rust: a year later

#23

Post by fire_lake »

pjmlp wrote: post #19
fire_lake wrote: post #18

Earlier quoted context omitted.

Of course it can be and has been done, but it takes much more developer time than writing less efficient code in a managed language.

Now take in consideration that when using a single language, doing in Rust takes much longer than C++, even without taking into consideration the existing middleware engines, and support for hot code reloading. Also that stuff like SDL and SFML are pretty much the go tool for DYI folks, and Khronos standards are all based in C and C++. Additionally, if a managed language is good enough, and does support compilation t…

I think we are agreeing :)

Re: Game dev in Rust: a year later

#24

Post by siknad »

raincole wrote: post #15
pjmlp wrote: post #4

Earlier quoted context omitted.

Which follows the pattern of only partially using the ecosystem and doing the relevant parts themselves. 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…

The weird thing is that there are already working interpreters of other scripting languages written in Rust, e.g. Boa (Javascript), mlua (Lua). But all Rust game engines seem to insist on one single language approach.

Bevy has support for dynamically described components and systems. Their main use-case is scripting language support. Can't agree that they insist on single language approach.

Re: Game dev in Rust: a year later

#25

Post by pjmlp »

littlestymaar wrote: post #21
pjmlp wrote: post #4

Earlier quoted context omitted.

Which follows the pattern of only partially using the ecosystem and doing the relevant parts themselves. 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…

> 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. Tinyglade uses Bevy though. Granted it doesn't use all of Bevy but given who made it and how advanced the tiny glade renderer is, no commercial engine would have offered out of the box the rendering features the devs wanted for their project anyway. > Game de…

While Unity is used a lot, it isn't as much as us managed languages fans would like, and the engine most folks are running for instead is Godot, written in C++, where GDScript is really taking getting used, instead of C# or non C++ extensions.

As big C# fan it saddens me, but things are as they are.

As you can see even by famous 2024 releases, multithreanding bugs or UB, aren't something most studios care about, there is always the next DLC.

And this an industry that was used to burn what used to be the golden copy of the game, before moving to the next game, there were no patches or upgrades.

Re: Game dev in Rust: a year later

#26

Post by [deleted] »

exDM69 wrote: post #7
indy wrote: post #2

Tiny Glade ( https://store.steampowered.com/app/2198150/Tiny_Glade/ ) is an impressive example of a game written in Rust. Apart from that exception, Rust game development seems more about releasing half baked crates than actual games

> Rust game development seems more about releasing half baked crates than actual games 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…

[deleted]

Re: Game dev in Rust: a year later

#27

Post by pjmlp »

fire_lake wrote: post #23
pjmlp wrote: post #19

Earlier quoted context omitted.

Now take in consideration that when using a single language, doing in Rust takes much longer than C++, even without taking into consideration the existing middleware engines, and support for hot code reloading. Also that stuff like SDL and SFML are pretty much the go tool for DYI folks, and Khronos standards are all based in C and C++. Additionally, if a managed language is good enough, and does support compilation t…

I think we are agreeing :)

In a way yes, although seeing something like Unreal in Rust, with the same tooling polish, would be quite interesting.

Bevy might eventually get there.

Re: Game dev in Rust: a year later

#28

Post by orf »

yodsanklai wrote: post #8

I'm learning Rust at the moment (I'm going to join a new team that uses Rust). I'd say it's quite fun and I'm not good enough to have a strong opinion on the language, but I have a few thoughts though. So far, I find the language design not super elegant. There are restrictive ownership rules, which are fine, but then a myriad of data structures that let you circumvent these rules. It feels somewhat ad-hoc. Regarding…

> but then a myriad of data structures that let you circumvent these rules

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

Re: Game dev in Rust: a year later

#29

Post by astrobe_ »

indy wrote: post #2

Tiny Glade ( https://store.steampowered.com/app/2198150/Tiny_Glade/ ) is an impressive example of a game written in Rust. Apart from that exception, Rust game development seems more about releasing half baked crates than actual games

Veloren [1] is also an actual game.

[1] https://veloren.net/

Re: Game dev in Rust: a year later

#30

Post by siknad »

yodsanklai wrote: post #8

I'm learning Rust at the moment (I'm going to join a new team that uses Rust). I'd say it's quite fun and I'm not good enough to have a strong opinion on the language, but I have a few thoughts though. So far, I find the language design not super elegant. There are restrictive ownership rules, which are fine, but then a myriad of data structures that let you circumvent these rules. It feels somewhat ad-hoc. Regarding…

> Regarding pattern-matching and enum types, I can see why a C++ programmer is impressed with such constructs, but it's really underwhelming for an OCaml/Haskell programmer.

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.

Post reply on HN