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

31–40 of 71 posts

Re: Game dev in Rust: a year later

#31

Post by sylware »

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

Had serious interaction with the tiny glade devs (and I own the game on native elf/linux on steam):

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.

Re: Game dev in Rust: a year later

#32

Post by littlestymaar »

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…

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

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)

Re: Game dev in Rust: a year later

#33

Post by littlestymaar »

pjmlp wrote: post #25
littlestymaar wrote: post #21

Earlier quoted context omitted.

> 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, ther…

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

Do not confuse the fact that they don't spend enough in testing with the idea that they don't care about it: even if they release the game with the bug, it's going to cost them money later on to fix it when players complain about it, and slow down the development of other projects.

Re: Game dev in Rust: a year later

#34

Post by xqt40 »

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…

There are plenty of passion projects that have been successful. So this is not an excuse. I've abandoned rust because I don't find it useable to me with unneeded complexity to code. Also with graphics most of the code was not safe. So believing only took me that far.

Re: Game dev in Rust: a year later

#35

Post by xqt40 »

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…

I'm afraid, you would sooner see safe code in assembler with the help of ai than in rust. You can argue that ai can be used to enhance rust, but at this point why bother if ai will be writing code by your instructions.

Re: Game dev in Rust: a year later

#36

Post by dismalaf »

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…

> A significant fraction of games today is actually written in C# (Unity) and most games don't need to push the hardware at all.

??? Unity is a C++ engine, C# is just used for scripting...

Re: Game dev in Rust: a year later

#37

Post by pjmlp »

littlestymaar wrote: post #33
pjmlp wrote: post #25

Earlier quoted context omitted.

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, ther…

> 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. Do not confuse the fact that they don't spend enough in testing with the idea that they don't care about it: even if they release the game with the bug, it's going to cost them money later on to fix it when players complain about it, and slow down the development of other…

As former IGDA member and GDCE attendee, still catching up on GDC Vault and Digital Dragons, regular EDGE, MCV Develop and RetroGammer, I kind of well aware of how things are, and not confused at all.

Re: Game dev in Rust: a year later

#38

Post by pjmlp »

dismalaf wrote: post #36
littlestymaar wrote: post #21

Earlier quoted context omitted.

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

> A significant fraction of games today is actually written in C# (Unity) and most games don't need to push the hardware at all. ??? Unity is a C++ engine, C# is just used for scripting...

Since Burst compiler was introduced for HPC# subset, that C# is used for engine internals as well.

Unity is like doing AI with PyTorch, or CuPy, yep there is a low level C++ layer for the GPGPU code, that hardly anyone touches directly.

By the way, CAPCOM goes even further, they have their own .NET Core fork, and games like Devil May Cry for PlayStation 5 were made with it.

Re: Game dev in Rust: a year later

#39

Post by pjmlp »

xqt40 wrote: post #35
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…

I'm afraid, you would sooner see safe code in assembler with the help of ai than in rust. You can argue that ai can be used to enhance rust, but at this point why bother if ai will be writing code by your instructions.

Some people haven't yet understood that the transition into AI is similar to how optimising compilers mostly replaced Assembly programming.

While not yet there, eventually AI based code generation will be good enough to generate native code directly, without going through existing languages code generation.

So while we might get the equivalent of a -S compiler switch, to dump the AI compiler decisions and fine tune the prompts, that isn't something everyday dev will be bothering with.

Re: Game dev in Rust: a year later

#40

Post by pjmlp »

sylware wrote: post #31
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

Had serious interaction with the tiny glade devs (and I own the game on native elf/linux on steam): 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"…

The points 1 and 2 are why cross platform 3D APIs like those managed by Khronos are "portable", and in some extreme cases have enough execution paths with vendor extensions, and OS/driver/GPU workarounds, that is hardly different from middleware engine.
Post reply on HN