Migrating away from Rust [gamedev]
Migrating away from Rust [gamedev]
Follow Up: Highlights from the comments on “Migrating away from Rust.” When I started building Architect of Ruin in Dec...
"we have been using Unity for the past three months."
Ew.
"I regularly use AI to learn new technologies, discuss methods and techniques, review code, etc. "
Ew!
Nah AI can be extremely useful for learning technologies. You just need to be careful to verify they aren't bullshitting you.
For example find an explanation of PPM compression that is concrete and simple. As far as I can tell it doesn't exist.
But I could ask ChatGPT and it told me how it works (probably) in just a few seconds. I haven't verified yet (at a BBQ) whether it is the correct algorithm but it's certainly a plausible one that would work.
It told me that you use a trie (typically) of symbol prefixes to record the probability of the following symbols, so for example you know that for the prefix "Th" the probability of "e" is 90%. Then you encode the symbol with arithmetic coding using the modelled probabilities. Apparently the typical max context length is 4-6.
That would have taken me hours to find by reading code and ancient papers but I can verify it a lot quicker.
This is luddite behavior. AI can be a very valuable tool for learning unless you're working with some truly exotic shit (in which case pray to RAG to save you)
This was a great blog post. I love Rust and Bevy, but I can definitely see why you made the switch.
The primary issue with your decision to use Rust/Bevy, for me, was that you were taking on the task of getting others to work in a difficult language for novice developers. I would never suggest Rust as someone's first language, coupling that with a regularly-changing library like Bevy.
I would love to know what the pros and cons were between Unity and Godot. If you were going to switch to C# anyway, Godot seems like the next logic choice to me, so I'm curious about what your team's evaluation was for that engine.
In our experience at $DAYJOB, Rust is actually not too bad, when it is one of the first languages that someone learns. It's definitely a lot more troubling for experienced devs who have certain patterns in mind, which they can't replicate in Rust. They tend to struggle a lot, whereas our students generally pick up and work with Rust like it's any other language.
But Rust + Bevy is probably more confusing. I actually started my journey into Rust with a (much less mature) game engine, too, which also used an ECS. And well, the ECS kind of bypasses Rust's memory management, which I didn't understand until much later. I didn't really learn Rust's memory management model until 5 months in, even though I was partially using it...
I'm really impressed with the management of this project. Using rust isn't more important than the game itself.
Not here to doubt their decision, they had good reasons to switch.
For the sake of discussion though, would it have been easier though if they had focused more on abstractions with their code architecture? I haven't done any serious projects in Rust, but those issues with low-level coding and API thrash seem like more of a code architecture problem. Like, that example of a function signature seems like they should have bundled up their paperdoll logic more into a single "PaperdollLoadout" struct and moved that into a separate game logic function separate from the view related code. It's more code to write, but that's the up-front cost of strict type checking.
Modding and learning definitely seem like a big barrier for Bevy overall though.
One decision i will question is picking Unity over Godot, though maybe they were still reeling from the learning issues on Bevy.
Quick google search points out this blog post for tips and tricks for prototyping stuff like game features in Rust: https://corrode.dev/blog/prototyping/
Definitely something that I'm going to try when I have to time to get back into Rust. Probably good advice for most people who are unhappy with Rust. Being attracted by Rust's unique optimization tools too early on seems like a big beginner trap.
Reads okay for the most part. But I like how we see the same point about AI as a feature in some more serious real-life projects. There, we frame it as "Rust makes it harder for a 'contributor' to sneak in LLM-generated crap".
In what situation are you accepting contributions that you haven't vetted thoroughly enough to detect crap code? I've seen a lot of crap from developers that's as bad or worse than LLM generated crap so there's no way I'll ever accept contributions to an important system without thoroughly vetting them unless they're from one of a very few number of people I trust implicitly.
Well, no matter how thoroughly you vet, it's always good to have a tool to back you up.
For example, we once got a pull request, which was purely AI-generated but I couldn't tell that right away. So, I skimmed it to make sure no malicious code is part of it, then I gave it to the CI runner. And that failed pretty much immediately during a compile check, which made it obvious that the pull request author had never tried to compile it.
In that moment, I could stop wasting my time with that pull request, rather than try to debug why it's not working or having to vet it more thoroughly...
if nothing else it should be easier with rust because:
a) That fucking syntax is probably more legible to an AI than a human (sue me, Rust absolutists)
b) The language has more safety barriers; making use of AI safer by association
Yeah, I feel like Bevy needs quite a bit more time in the oven, and I absolutely do not say that due to me thinking that it's bad. Unity, Unreal and Godot have rather just been in the oven for so long, that it takes a long while to catch up.
They are implemented in C++, which is similarly low-level as Rust. It's just the abstractions built on top that make these engines feel more high-level. Unity offering a C# API and Godot offering GDScript, those are also just abstractions. Similarly, Bevy could one day offer "BevyScript" or such, although I don't necessarily feel like the syntax needs a ton of abstractions.
Rather I think that it's the ecosystem that still needs to mature and grow a lot. But yeah, I do believe that in a decade or two, at least one of the major game engines will be implemented in Rust and it might as well be Bevy that takes that spot.
BevyScript
Or some existing language?
Yeah, sure. Both are possible.
Although, again, I don't necessarily feel like the syntax needs much abstraction. Rust is a comparatively modern language. So, while there's existing scripting languages that concern themselves less with low-level topics and therefore may be better suited for high-level development, it's been a while since a new, modern scripting language got popular, so in some ways, it would also be a downgrade to switch to one of those.
This reminds me a lot of LogLog Games doing the same thing this time last year. It also talks about similar issues and goes pretty deep into normal Rust responses.
I agree about the rust gui situation highlighted in a few of the comments here. It's tough to make it work in a truly native-feeling, rust-idiomatic way with the frameworks out there.
If you want a language with memory safety features, I can recommend D. GC pauses are negligible if you don't go above a certain memory size and 60Hz, otherwise you also can do manual memory management if you're experienced enough with that, especially if you're willing to learn an alternative runtime (might require you to write C bindings or your own libraries).
Limiting framerate to 60hz? In [current year]??
Because I absolutely NEED 144 Hz in my turn-based strategy game.
If you're writing a small indie game, or a quick prototype, then you could do much worse
YO; extremely rare D mention
I discovered digitalmars back in the very early days; it's been on my watchlist for over 15+ years now
Welcome GC pauses :) I wonder how do those manifests in real life.
Games might be an area where it isn't too bad since you can disable the GC while doing all your physics and graphics, and then just after you've dispatched a frame trigger a GC with a hard time limit.
I don't know if Unity works like that but it should.
There are plenty of games made with C# and Unity.
You surely played a few of them, let's be honest.
So, if you're asking this question, I guess the answer is: "you don't even realize it's happening"...
Rust marketing; since Rust has became popular, GC became a problem, out of no where, and segfaults became the most terrible bug a software can be afflicted with.
If C# and Unity are working well for them, good for them.
TBH I almost don't play games and I'm genuinely curious whether GC pauses are noticeable. And not only Rust, there is Swift as well.
C# uses ref counting, which has much less impact on that. I do however use D for my game engine, which some say is infamous for its GC pauses, but they only happen if you allocate with the GC itself, and otherwise if you work work the GC, you can get some performance gains compared to dumb manual memory management, but not so much if you actually can manage your own memory, or write your own automatic memory management system, like I did on top of numem. Otherwise the pauses are negligible for smaller projects, and some of the larger projects like The Art of Reflection uses GC only for loading assets, with my engine also going in that direction.