7 ms·

Game dev in Rust: a year later

indy 2y ago
Tiny Glade (https://store.steampowered.com/app/2198150/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
- dwattttt 2y ago
  I was surprised to find out The Gnorp Apologue was written in Rust, it's done surprisingly well: https://old.reddit.com/r/rust/comments/18ul125/writing_a_game_in_rust_the_gnorp_apologue/?rdt=53506 https://old.reddit.com/r/rust/comments/18ul125/writing_a_gam...
  - pjmlp 2y ago
    From the trailer, it looks like something I would have played on an Amiga 500 or PC MS-DOS VGA with a Soundblaster/Adlib, so hardly a selling example for modern game development, even if it happens to be quite enjoyable.
    - johnnyanmac 2y ago
      you could say the same of Balartro on first blush. It really comes down to if we are approaching an engine's viability from a lens of a techie who wants to push the limits of the industry, or as a entrepreneur who wants a tool that fits their workflow. I'm a bit in the former, but those latter games do help get funding for projects so the engine can push further.
      - pjmlp 2y ago
        Yes, a famous game done in Love2D, providing that it is the gameplay and not the programming language that sells a game. However it isn't on the same league as the studios that care about shipping games in C, C++ and Assembly as main development tools. Right now, other than Bevy existing efforts, and absent of regulations that force those studios to adopt Rust, there aren't many reasons on the market for those studios to change their tooling. As small history lesson, it was the success of games like Quake that finally settled using C and C++ for game development, after they started to enjoy some love in the demoscene. C on game consoles, followed by C++, only started to be a thing after the PlayStation, the first games console to ship a C SDK instead of having only Assembly based tooling. Also Yaroze only had C support. C++ joined the party via the PlayStation 2 SDK. C# was used for the first time successfuly on Arena Wars[0] back in 2004, with the studio doing their own OpenGL bindings. It took Managed DirectX, followed by XNA and XBox Creative Arcade, MonoGame, Unity adopting MonoGame for their crossplatform rewrite (they were originally Mac OS only), lots of money to bring it to game consoles, for .NET based tooling for finally starting to be relevant as well. Before Unity took over, it was already being used as alternative to create game tooling based on C++ and MFC. Java never had much luck, because Sun understood game development even worse than desktop development, so the JavaGamming initiative went nowhere, even though there were nice engines like jMonkeyEngine, JOGL and LWGL. There was LibGDX for a while, but the RoboVM acquisition from Xamarin, only to be shortly acquired by Microsoft thereafter, kind of killed what it had going for it. Still, it is unavoidable on Minecraft, where Bedrock version isn't nowhere the mod community size as the Java one, and Android casual games. Also Android non-casual games do require some level of Java/Kotlin code, given that only rendering and audio is exposed on the NDK. Note that despite all the Rust adoption talk by Android team, there are no plans for official Rust support on the Android NDK, and Kotlin Native might even get there first, still looking forward when this might change. [0] - https://en.wikipedia.org/wiki/Arena_Wars https://en.wikipedia.org/wiki/Arena_Wars
        johnnyanmac 2y ago
        I don't disagree at all with any of your insight. It took Unity and Epic well over a decade each of support and proven games to even get their foot in the door with some studios. And to this day quite a few prolific studios will still use custom tech. Assembly has obvious dev strain that helped with c/++ adoption, while Rust isn't trying to claim it will relieve such strain in C/++, outside of bugs and safety. But I've seen enough game code bases to know thats a very distant, low priority in the modern gaming scene. For those that do care: Rust for those studios won't be adopted as abruptly "we're using Bevy now!". Studios will probably start slowly tooling parts of Rust in more critical parts of the engine, or using frameworks made over the coming years. Most engineers not dedicated to that work may ever even know there's Rust under the hood. ----- I guess my main reservation comes from me looking from a different lens. It won't be Naughty Dog nor IDTech that will make the "Quake" of Rust, it'll definitely a small, lean team closer to that of Croteam, or at least a yet unknown studio with that kind of discipline for optimization built into their culture. And with the current landscape it's not going to be trying to fight with AAA games to achieve that milestone. But it'll build it's own community around it and overall rise all ships from that. How high it goes from there, I can't say. ---- P.s. I do appreciate the history lesson. Also reminds me how I'm a bit sad that Microsoft killed so much of the potential C# scene last decade. C# always felt like a good middle ground between the nwas that was Java for Game Development while still staying in a safer space for those who don't need blazing fast C++ support. At least they still supported C# itself to a point where we almost have all the tools needed to work a basically unmanaged environment when needed.
- pjmlp 2y ago
  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 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.
  - fire_lake 2y ago
    The promise is to write the whole game in Rust, rather than having a split between C++ and a scripting language. The most common example of this is Unity with C++/C#. Having one language makes certain debugging tasks easier and can lead to faster execution. Using only one language is difficult in C++ due to the lack of garbage collection. What the Rust community is finding out is that it is also difficult in Rust due to compile times and the rigid borrow checker rules.
    - pjmlp 2y ago
      Doing whole games in C++ has been a thing for decades, granted with plenty Assembly in the mix, since Watcom C++ days in MS-DOS, or PlayStation being the first console with a C and C++ SDK. There was no garbage collection in all those 8 and 16 bit home computers and game consoles programmed in straight Assembly. If Rust can't top this, then its value for game development community isn't as great as many think it is.
      - spease 2y ago
        I added the Lua scripting layer to FS2Open. It’s very useful for not-quite-coders. There are a lot of projects where the founders end up doing everything because the other contributors don’t stick around permanently.
- exDM69 2y ago
  > 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 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.
  - indy 2y ago
    There's nothing wrong with writing your own game engine rather than going for Unreal or Unity, in fact that's one way of creating a truly unique game. My comment about "half baked" referred to the crates that people release instead of actual games. The Rust game dev community might be wise to steer away from the "we gave up on developing our game, but hey Rustaceans, here are some crates you might find useful!" approach
    - deleted 2y ago
      [deleted]
    - johnnyanmac 2y ago
      despite being in the same industry, engine programmers =/= game designers. You may as well be comparing a network engineer to a front end web dev. As for "actual games": indie dev with mature tools is hard enough as is to properly ship. and many don't make money. Making the kind of game that would attract attention requires funding that these communities often lack.
- atombender 2y ago
  Does anyone know what engine it uses? Bevy, or maybe a proprietary engine?
  - raincole 2y ago
    Bevy, but interestingly it doesn't seem to use wgpu but a custom made rendering solution.
- astrobe_ 2y ago
  Veloren [1] is also an actual game. [1] https://veloren.net/ https://veloren.net/
  - n8henrie 2y ago
    My son (9) loves Veloren!
- sylware 2y ago
  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.
  - pjmlp 2y ago
    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.
- johnnyanmac 2y ago
  like most market before The Big Thing (tm) releases. It's just part of the iterations. Unity was IOS only for a few years, and ofc Epic was an in-house engine for a decade. mature, battle tested engines don't pop up overnight.
- adamrezich 2y ago
  Tiny Glade is not a game—it is a toy. 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.
yodsanklai 2y ago
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 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. That being said, C++ is hard and complex and it's refreshing to be able to use a more modern language. Assuming you're certain you can't live with the performance overhead of a GC, Rust fills a gap, but it doesn't seem it's the end of the story. I even wonder if it's necessarily a better choice than modern C++ for someone starting a new project.
- hypeatei 2y ago
  > necessarily a better choice than modern C++ for someone starting a new project. 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.
  - pjmlp 2y ago
    While not cargo level, vcpkg and conan + cmake help a lot, with much better compilation times, due to support for native libraries. Still looking forward to the day cargo offers similar capabilities, without having to follow something like the whole Bevy setup.
- orf 2y ago
  > 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.
galleywest200 2y ago
Surprised not to see Godot mentioned in the article which has support for several languages, including Rust, via GDExtension. https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/what_is_gdextension.html https://docs.godotengine.org/en/stable/tutorials/scripting/g... C++ is official, with community support for D, Go, Haxe, Rust, and Swift.
purple-leafy 2y ago
I'm keen to try re-making my little 2.5D Ray-caster engine [0][1] in Rust. Current implementation/s are both in C, only ~500 lines of poor code. I tried a refactor and broke my ray-caster lol, C has been a blast but so many footguns man. Heres the repo/s [0] - https://github.com/con-dog/sdl-test/blob/main/README.md https://github.com/con-dog/sdl-test/blob/main/README.md [1] - https://github.com/con-dog/sdl-textured/blob/main/README.md https://github.com/con-dog/sdl-textured/blob/main/README.md

indy 2y ago

Tiny Glade (https://store.steampowered.com/app/2198150/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

dwattttt 2y ago
I was surprised to find out The Gnorp Apologue was written in Rust, it's done surprisingly well: https://old.reddit.com/r/rust/comments/18ul125/writing_a_game_in_rust_the_gnorp_apologue/?rdt=53506 https://old.reddit.com/r/rust/comments/18ul125/writing_a_gam...
- pjmlp 2y ago
  From the trailer, it looks like something I would have played on an Amiga 500 or PC MS-DOS VGA with a Soundblaster/Adlib, so hardly a selling example for modern game development, even if it happens to be quite enjoyable.
  - johnnyanmac 2y ago
    you could say the same of Balartro on first blush. It really comes down to if we are approaching an engine's viability from a lens of a techie who wants to push the limits of the industry, or as a entrepreneur who wants a tool that fits their workflow. I'm a bit in the former, but those latter games do help get funding for projects so the engine can push further.
    - pjmlp 2y ago
      Yes, a famous game done in Love2D, providing that it is the gameplay and not the programming language that sells a game. However it isn't on the same league as the studios that care about shipping games in C, C++ and Assembly as main development tools. Right now, other than Bevy existing efforts, and absent of regulations that force those studios to adopt Rust, there aren't many reasons on the market for those studios to change their tooling. As small history lesson, it was the success of games like Quake that finally settled using C and C++ for game development, after they started to enjoy some love in the demoscene. C on game consoles, followed by C++, only started to be a thing after the PlayStation, the first games console to ship a C SDK instead of having only Assembly based tooling. Also Yaroze only had C support. C++ joined the party via the PlayStation 2 SDK. C# was used for the first time successfuly on Arena Wars[0] back in 2004, with the studio doing their own OpenGL bindings. It took Managed DirectX, followed by XNA and XBox Creative Arcade, MonoGame, Unity adopting MonoGame for their crossplatform rewrite (they were originally Mac OS only), lots of money to bring it to game consoles, for .NET based tooling for finally starting to be relevant as well. Before Unity took over, it was already being used as alternative to create game tooling based on C++ and MFC. Java never had much luck, because Sun understood game development even worse than desktop development, so the JavaGamming initiative went nowhere, even though there were nice engines like jMonkeyEngine, JOGL and LWGL. There was LibGDX for a while, but the RoboVM acquisition from Xamarin, only to be shortly acquired by Microsoft thereafter, kind of killed what it had going for it. Still, it is unavoidable on Minecraft, where Bedrock version isn't nowhere the mod community size as the Java one, and Android casual games. Also Android non-casual games do require some level of Java/Kotlin code, given that only rendering and audio is exposed on the NDK. Note that despite all the Rust adoption talk by Android team, there are no plans for official Rust support on the Android NDK, and Kotlin Native might even get there first, still looking forward when this might change. [0] - https://en.wikipedia.org/wiki/Arena_Wars https://en.wikipedia.org/wiki/Arena_Wars
      - johnnyanmac 2y ago
        I don't disagree at all with any of your insight. It took Unity and Epic well over a decade each of support and proven games to even get their foot in the door with some studios. And to this day quite a few prolific studios will still use custom tech. Assembly has obvious dev strain that helped with c/++ adoption, while Rust isn't trying to claim it will relieve such strain in C/++, outside of bugs and safety. But I've seen enough game code bases to know thats a very distant, low priority in the modern gaming scene. For those that do care: Rust for those studios won't be adopted as abruptly "we're using Bevy now!". Studios will probably start slowly tooling parts of Rust in more critical parts of the engine, or using frameworks made over the coming years. Most engineers not dedicated to that work may ever even know there's Rust under the hood. ----- I guess my main reservation comes from me looking from a different lens. It won't be Naughty Dog nor IDTech that will make the "Quake" of Rust, it'll definitely a small, lean team closer to that of Croteam, or at least a yet unknown studio with that kind of discipline for optimization built into their culture. And with the current landscape it's not going to be trying to fight with AAA games to achieve that milestone. But it'll build it's own community around it and overall rise all ships from that. How high it goes from there, I can't say. ---- P.s. I do appreciate the history lesson. Also reminds me how I'm a bit sad that Microsoft killed so much of the potential C# scene last decade. C# always felt like a good middle ground between the nwas that was Java for Game Development while still staying in a safer space for those who don't need blazing fast C++ support. At least they still supported C# itself to a point where we almost have all the tools needed to work a basically unmanaged environment when needed.
pjmlp 2y ago
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 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.
- fire_lake 2y ago
  The promise is to write the whole game in Rust, rather than having a split between C++ and a scripting language. The most common example of this is Unity with C++/C#. Having one language makes certain debugging tasks easier and can lead to faster execution. Using only one language is difficult in C++ due to the lack of garbage collection. What the Rust community is finding out is that it is also difficult in Rust due to compile times and the rigid borrow checker rules.
  - pjmlp 2y ago
    Doing whole games in C++ has been a thing for decades, granted with plenty Assembly in the mix, since Watcom C++ days in MS-DOS, or PlayStation being the first console with a C and C++ SDK. There was no garbage collection in all those 8 and 16 bit home computers and game consoles programmed in straight Assembly. If Rust can't top this, then its value for game development community isn't as great as many think it is.
    - spease 2y ago
      I added the Lua scripting layer to FS2Open. It’s very useful for not-quite-coders. There are a lot of projects where the founders end up doing everything because the other contributors don’t stick around permanently.
exDM69 2y ago
> 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 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.
- indy 2y ago
  There's nothing wrong with writing your own game engine rather than going for Unreal or Unity, in fact that's one way of creating a truly unique game. My comment about "half baked" referred to the crates that people release instead of actual games. The Rust game dev community might be wise to steer away from the "we gave up on developing our game, but hey Rustaceans, here are some crates you might find useful!" approach
  - deleted 2y ago
    [deleted]
  - johnnyanmac 2y ago
    despite being in the same industry, engine programmers =/= game designers. You may as well be comparing a network engineer to a front end web dev. As for "actual games": indie dev with mature tools is hard enough as is to properly ship. and many don't make money. Making the kind of game that would attract attention requires funding that these communities often lack.
atombender 2y ago
Does anyone know what engine it uses? Bevy, or maybe a proprietary engine?
- raincole 2y ago
  Bevy, but interestingly it doesn't seem to use wgpu but a custom made rendering solution.
astrobe_ 2y ago
Veloren [1] is also an actual game. [1] https://veloren.net/ https://veloren.net/
- n8henrie 2y ago
  My son (9) loves Veloren!
sylware 2y ago
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.
- pjmlp 2y ago
  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.
johnnyanmac 2y ago
like most market before The Big Thing (tm) releases. It's just part of the iterations. Unity was IOS only for a few years, and ofc Epic was an in-house engine for a decade. mature, battle tested engines don't pop up overnight.
adamrezich 2y ago
Tiny Glade is not a game—it is a toy. 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.

yodsanklai 2y ago

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 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. That being said, C++ is hard and complex and it's refreshing to be able to use a more modern language. Assuming you're certain you can't live with the performance overhead of a GC, Rust fills a gap, but it doesn't seem it's the end of the story. I even wonder if it's necessarily a better choice than modern C++ for someone starting a new project.

hypeatei 2y ago
> necessarily a better choice than modern C++ for someone starting a new project. 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.
- pjmlp 2y ago
  While not cargo level, vcpkg and conan + cmake help a lot, with much better compilation times, due to support for native libraries. Still looking forward to the day cargo offers similar capabilities, without having to follow something like the whole Bevy setup.
orf 2y ago
> 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.

galleywest200 2y ago

Surprised not to see Godot mentioned in the article which has support for several languages, including Rust, via GDExtension. https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/what_is_gdextension.html https://docs.godotengine.org/en/stable/tutorials/scripting/g... C++ is official, with community support for D, Go, Haxe, Rust, and Swift.

purple-leafy 2y ago

I'm keen to try re-making my little 2.5D Ray-caster engine [0][1] in Rust. Current implementation/s are both in C, only ~500 lines of poor code. I tried a refactor and broke my ray-caster lol, C has been a blast but so many footguns man. Heres the repo/s [0] - https://github.com/con-dog/sdl-test/blob/main/README.md https://github.com/con-dog/sdl-test/blob/main/README.md [1] - https://github.com/con-dog/sdl-textured/blob/main/README.md https://github.com/con-dog/sdl-textured/blob/main/README.md