> 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.
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
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.
I was thinking of the kinds of games mentioned in this thread: Tiny Glade and The Gnorp Apologue. Small indie games made by people who fill the role of both engine programmer and game designer.
On a larger, more professional scale someone like Jonathan Blow comes to mind
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.
so the retort is survivor's bias? Hollow knight was a game jam game, so my 2d autorunner definitely coulda made 8m dollars, right?
>I've abandoned rust because I don't find it useable to me with unneeded complexity to code.
I don't want to be too dismissive, but if you dont care about code safety, Rust is the absolute worst language to choose for game development. Yes, it's a lot more work upfront and iterative game development wants to break things quickly to figure out a good game loop.
I want to make a game myself in Rust one day and I know for certain that my scripting will definitely not be in Rust.
Dude, it is not safe programming if you put all your code under unsafe brackets.
You can write safe code in other languages but it really requires more advanced programmers than Rust programmers will ever be - the idea of Rust is to simply taking out responsibility from all programmers and puts it on Rust developers, so how much you care about code safety - that is not what you need to think when programming in Rust.
>>>I want to make a game myself in Rust one day and I know for certain that my scripting will definitely not be in Rust.
>it is not safe programming if you put all your code under unsafe brackets.
Put less code in unsafe brackets. I haven't seen how a proper renderer is made in Rust, but I'd be shocked if something on the scale of Bevy's still was just "Rust without rust" as a quick c++ port.
I'm sure there Wil inevitably be some low level hardware tricks that need unsafe blocks, but that's much less needed in most modern code than back in the day. And if we're being frank, those kinds of optimizations probably aren't top priority compares to, say, a proper front end scene graph to interact with.
>I mean - do I need to say more?
That every language has strengths and weaknesses? I'm all for any wisdom you wish to share. I won't pretend to be an expert in any language.
My design decision (or rather, suspicion) comes more from the fact that scripting needs different demands (rapid iteration) than the underlying foundation (rendering/physics/asset management that can create the nastiest kinds of bugs). Therss inevitable issue bridging languages, but I think overall it would give the best of both worlds.
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.
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.
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.
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.
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 to native code via AOT, and the middleware tooling, it makes Rust's selling point even weaker.
Which is what you see in how Unity/HPC#/NativeAOT, FNA/clang, Swift, Java/Kotlin (on Android see XR), already offer today.
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.
Rust does not suit for scripting. The goal of scripting is to write code more easily without worry of system programming concepts like memory management.
> also noting that the safety aspect is already taken care by Java/C#/Verse/Blueprints/Lua/Python/JS scritping.
it sure isn't safe enough. and "safe" in this context isn't just "my game will almost never crash" (plenty of Unity games crash, even non-il2cpp ones). But if that's good enough, then tha's understandable.
Very very few games (even AAA) are doing those old school assembly hacks to eek out power, so it's basically a non-factor.
> 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.
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.
> 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.
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.
>Since Burst compiler was introduced for HPC# subset,
depends a lot on how far DOTS has come. I'm a few years out of date, but DOTS (and by extension, Burst) was more or less a very separate codepath you needed to opt into. Any game using it today needed to make the consious effort to grab the Burst package an integrate those optimizations themselves.
I have heard plans to try and more or less integrate DOTS into the core engine and have gameobjects powered by entries under the hood, but I have no clue how much progress was actually made.
AKA writing games. Many people writing games with Unity go far beyond what anyone reasonable would call “scripting”, writing code that consume a significant part of the performance budget.
Not sure why you have scripting in quotations or are implying that it's somehow bad. You're not modifying the engine code or writing a renderer from scratch when programming a game in Unity so yeah, it's scripting by every definition.
it's a philisophical line, I suppose. at what point is "scripting" simply programming the gameplay with a tight interface? Unity can definitely blur that line at times.
Scripting means telling an already built piece of software what to do. In this case, the game engine code doesn't change, the programmer uses the existing functions and interface to tell it what to do. Even Unreal programming is mostly scripting... Yes you're writing C++ but you're only telling the engine what to do, not rewriting it (well, unless you are).
It's why scripting languages are called such... The interpreter is already built and remains unchanged, and runs the code without rebuilding anything.
Python doesn't suddenly become a non-scripting language just because your program reaches a certain size or scope.
It's weird that someone would take offence to calling scripting scripting... Like, it's nice that things are prebuilt and make programming easier... I reach for Ruby first whenever I have a problem I need solved.
Maybe "philosophical" is too strong a word, but I can't think of a better fitting term.
By those same definitions, we can Call any kind of middleware an API "scripting". You're not changing the underlying code so much as sending calls to some other code base to do the heavy lifting. But there's definitely some like between that and what popular game engines are structured by.
At the end of the day, the names are bikeshedding to me, what matters more is the output and experience of the tool more than the label applied to it. But names are communication, and communication is messy by nature.
> Scripting means telling an already built piece of software what to do. In this case, the game engine code doesn't change, the programmer uses the existing functions and interface to tell it what to do.
By this lose definition pretty much all of software engineering is scripting: you're always telling the underlying layer what to do without changing it: be it a web framework or the GPU driver.
I'd argue a lot of current programming definitely is.
How much foundational technology is actually being created? How many new OSes have there been in the last 30 years? Almost everything that's currently being built is built on top of many layers.
And why is this a bad thing?
When I was in university using R to solve economics problems I wasn't thinking to myself, "This is too easy, I'm just using a scripting language, I need to rewrite everything that's in CRAN myself". No, I was happy that so much foundational tech is already there to make our lives easy.
And when someone ships a game in Unreal or Unity they're probably happier to ship than regretting not writing their own engine.
Also, being in Canada, I can't legally call programming "software engineering" lol.
This response has nothing to do with the original point I made though, which has nothing to do with “foundational technology”, btw. When people write games in Unity the game is actually written in C#, sure the engine isn't, but that doesn't change the fact that the game is, and calling that “scripting” just because it's built on top of another layer makes no sense, because as you say, everything is built on top of another layer!
You're actually the one implying that, you said “it's just for scripting”
> You're not modifying the engine code or writing a renderer from scratch
You're not modifying the kernel or writing a GPU driver from scratch when you're building a game engine, yet you don't consider that to be scripting, why the difference?
The engine is in C++, but the game itself is written in C# (and this is the actual part you'd called out earlier in this thread), and no it's not “just scripting on top of the the engine”, no more than writing a game engine in C++ is “scripting on top of the OS” your definition of what is scripting and whatnot is just off.
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.
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.
Like I mentioned - belief in Rust is a religion and I got a proof in those negative votes.
I don't think that people like you understand what are appliances for AI - it is not about writing or optimizing code, but writing language from the scrap if needed. And my remark was that Rust will hit the wall where it will need to go fully AI, because developers simply can't fullfill the promise of safe code by default as it would require inhuman testing to even get near that promised result. Also Rust is meant for humans - which loses any edge if switch is happening towards descriptive and not even programming language that developers will use. Rust here simply has no edge at all as any programming language can be improved with memory safety in mind.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
>I even wonder if it's necessarily a better choice than modern C++ for someone starting a new project.
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).
> 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)
Apart from that exception, Rust game development seems more about releasing half baked crates than actual games
reply