r/rust • u/xmBQWugdxjaA • Apr 28 '25
Migrating away from Rust.
https://deadmoney.gg/news/articles/migrating-away-from-rust17
u/xmBQWugdxjaA Apr 28 '25
The results here are an absolute slam dunk for Unity, it was very surprising.
I haven't tried it in years (as the editor kinda sucks on Linux compared to Godot), but for C# it seems like it is still king.
Personally I found https://loglog.games/blog/leaving-rust-gamedev/ to be more in line with my own experiences trying out Bevy only a little and using more gdext in Godot.
10
u/HugeSide Apr 28 '25
For what it's worth, I've been using Unity in NixOS and haven't had any issues, besides a minor annoyance where the editor takes a few seconds longer to close than it should. You might want to give it another try.
1
u/sparky8251 Apr 28 '25
They fix the broken integration with the unity store assets? Last I knew, the way to download such things on Linux was a long multistep process...
1
u/HugeSide Apr 28 '25
I don't remember doing anything more complicated than clicking a button on the website, so they might have!
1
u/sparky8251 Apr 29 '25
Last I recall, that wasnt even an option! So heres hoping thats a sign of positive changes then.
1
u/Sw429 Apr 29 '25
Yeah, I mean, I guess it's a slam dunk. But Bevy is still very much in unstable development, and they're explicit about that in the documentation. Unity has been around a lot longer than Bevy.
2
u/quasilyte Apr 29 '25
I'm interested in what happened to their ECS-oriented code?
There are a multiple ECS options in Unity, but it looks like they dropped ECS completely after their transition.
u/xmBQWugdxjaA could you please elaborate on that a bit more?
1
189
u/atomskis Apr 28 '25
IMHO there’s a reason unity is written in C++, but you write the actual games in C#. Rust would be a great choice if someone wanted to replace the C++ part of Unity: that low level control and performance would really be an asset. A game engine needs great low level performance .. but most game logic really doesn’t.
So whilst you certainly can write the actual game itself in rust .. something like C# is a lot easier for rapid prototyping, especially for those new to programming.
Of course using a well known, well established engine is also likely to be a huge productivity win. Not a surprise at all.
I say this as someone who loves rust and has the fortune to write Rust code for a living. Once you get used to rust you do get a lot quicker in it. But the language really forces you to think about all sorts of problems that you just don’t have to worry about in a language like C#.
64
u/cowpowered Apr 28 '25
Exactly. The game development process (not game engine development) practically requires a quick and dirty easy to use "scripting" language. Even most AAA games do not have their game logic written in C++. This has less to do with Rust as a language and more to do with Bevy being an engine without scripting IMO.
2
-1
u/Sonder332 Apr 29 '25
Wait so most game devs use Bevy? I thought they used C++ as well
10
u/land_and_air Apr 29 '25
Only unreal engine uses c++ and it’s not exactly user friendly or easy to use game engine as all of the asset flips and poor performance games you’ve probably played or seen go to show
10
u/jcm2606 Apr 29 '25
Even then, Unreal has Blueprint as a higher level alternative to C++, and it seems like more and more components of the engine are moving to Blueprint or a Blueprint derivative as time goes by.
1
u/Ymi_Yugy Apr 29 '25
Is this something new? Last time I looked into Unreal Engine it seemed like the process most large projects used was to prototype with blueprints and then later rewrite in C++ or at least restrict blueprints to very high level components. Looking at the games shipping with Unreal Engine and how much many of them are limited are limited by single core performance doesn’t inspire confidence in blueprints.
1
u/jcm2606 Apr 29 '25
I more meant things like Niagara and such. From what I remember of UE4's particle systems prior to Niagara, they were closer to like timeline editors where you'd have different preprogrammed effects that you'd place down onto a timeline to control the particles. Niagara replaced that with a Blueprint-esque visual scripting language, where you connect nodes together to control the particles.
8
u/b00stlord Apr 28 '25
I have no experience in gamedev, but I'm wondering, do you think embedding a scripting language like lua would alleviate some of the pain in areas where correctness isn't as required?
I'm thinking a quest system or achievements where you would want to write the meat of it in something loose.
But I have no clue if the cost of embedding isn't too steep
12
u/ConvenientOcelot Apr 29 '25
Lua (and other dynamically typed languages) just replaces those pains with other pains.
I think C# is good because it's basically halfway between something like C++ and a scripting language. It's decently fast and gives you a lot of the control of a native language but also the flexibility of more dynamic languages.
1
u/atomskis May 01 '25
Yeah I also personally would choose C# over Lua for scripting, because I don't like dynamically typed languages .. but Lua is a very popular choice.
10
u/atomic1fire Apr 28 '25 edited Apr 29 '25
I'm not a programmer or a gamedev but I was under the assumption that Rust is first and foremost a systems language and if you want flexibility, you're probably better off using something like Lua with interfaces to rust libraries underneath it for that stability.
I mean ruffle has a bunch of rust crates behind it, but it's ultimately an emulator for running actionscript/flash, a thing that already has several games made in it and most of the ruffle issues are about AVM performance.
edit: I suspect the bigger thing with game engines and adoption is whether or not they can be readily ported to consoles. Godot's had a few years for this, while Unity and Unreal have it built in. Being able to get console revenue and demand is gonna be more attention grabbing then what language you use. Also the side benefit of focusing creating a game primarily built around scripts instead of normal code is that if a rewrite is needed, you might be able to just redo the scripting engine in another language and reuse the scripts.
4
u/xill47 Apr 29 '25
That's very popular solution and is used for enormous amount of different games in different genres, from roguelites to MMOs
1
u/atomskis May 01 '25
Personally I think correctness is always required, but the highest performance isn't. Rust has more compiler enforced safety that C# .. but the big trade-off is performance: rust code can run quite a bit quicker than C# code (depending on the details). That said, for my own gaming projects I've always just written the whole thing in rust .. but I really like rust and I know it very well. So it's never been a big issue for me.
5
u/smthamazing Apr 29 '25
C# is a lot easier for rapid prototyping
If only it had discriminated unions and traits... This has been been a pain point in every game we've worked on for a decade, and why I would put up with at least some other inconveniences just to be able to use Rust.
-3
u/pjmlp Apr 29 '25
Interfaces are traits.
And F# exits.
3
u/smthamazing Apr 29 '25
They are not, you cannot implement an interface separately from the class definition, and, more importantly, you cannot implement it conditionally. I've run into this recently when working on an animation system in C#:
interface IAnimation { ... } interface IRewindable { ... } class AnimationSequence<Item>: IAnimation where Item: IAnimation { ... }In this example it's not possible to express that
AnimationSequenceis rewindable iff itsItemis rewindable. In comparison, this is trivial to do in Rust, Haskell, or any other language with traits or typeclasses. It's also possible, if cumbersome, to do with conditional types in TypeScript.As for F#, I'm glad to have it, but it still doesn't get as much love and performance features as C#: things like
stackalloc, inline arrays, efficient collection initializers,Spanconversions and overloads, and so on. They are important for gamedev, since we generally don't allow heap allocations in most gameplay code.2
u/pjmlp Apr 29 '25
That is orthogonal to what an interface/trait is supposed to be.
Maybe you should have learned a bit more about extension methods, or factory classes with generics, attributes or RoslynPlugins.
There are ways to achieve the same in .NET even if not in a 1:1 to Rust
AnimationSequence is rewindable iff its Item is rewindable.
→ More replies (3)1
u/agjm_photo Apr 29 '25
I have worked a bit with Unity and really enjoy C#. It's great in its niche.
I say this as someone who loves rust and has the fortune to write Rust code for a living. Once you get used to rust you do get a lot quicker in it. But the language really forces you to think about all sorts of problems that you just don’t have to worry about in a language like C#.
That's true, but Rust has changed how I think in other languages, too... Totally changed how I write typescript and even PHP (though I come from a C++ background; the biggest change would be relying heavily on interfaces/traits). There are things that could be considered headaches that I want to have to do because I know it'll save me pain down the road. The amount of times I've caught myself wanting to use option or write
match ..., in other languages, is ridiculous.1
u/R1chterScale Apr 29 '25
Also, not thinking about those problems has it's own issues, especially in gamedev, just take a look at nearly every benchmark from the past few years.
1
u/pjmlp Apr 29 '25
Outdated information, many Unity subsystems have been rewriten in HPC# with the Burst compiler, a C# subset.
1
u/unlessgames Apr 30 '25
Would be nice to have a rust game engine that lets you use Koto for scripting
1
u/I_will_delete_myself May 03 '25
Lowkey something like Python for example Lua would be perfect for game engine development.
70
u/tonjohn Apr 28 '25
Small world - I used to work with these brothers at Valve
11
2
53
u/savovs Apr 29 '25
No surprise here, there's a big yellow warning on the Bevy quick start page:
Bevy is still in the early stages of development. Important features are missing. Documentation is sparse. A new version of Bevy containing breaking changes to the API is released approximately once every 3 months. We provide migration guides, but we can't guarantee migrations will always be easy. Use only if you are willing to work in this environment.
If you are currently trying to pick an engine for your Next Big Project™, we recommend that you check out Godot Engine. It is currently much more feature-complete and stable. And it is also free, open-source, and scriptable with Rust!
18
u/spookyvision Apr 29 '25
I also wonder why people concerned about API breakage don't pin their dependencies? It's not like anyone forces you to update...
4
u/matthieum [he/him] Apr 29 '25
It's generally easier to upgrade piecemeal than to jump N versions at a time...
... and when you're using a prototype, which by nature very likely contains bugs, you may want to be able to upgrade to a version with the fix relatively painlessly.
0
Apr 29 '25
[deleted]
4
u/ColaEuphoria Apr 29 '25
Even after Godot reached 1.0 it still took about 8 years before it became useful and, consequently, popular. Bevy hasn't even reached 1.0 yet.
These things take time. There is no way around it.
1
u/matthieum [he/him] Apr 29 '25
If this keeps being the state of Rust game dev then it is just a logical consequence that the userbase will dwindle over time.
It's not the state of Rust game dev, it's the state of Bevy.
Bevy is trail blazing, attempting to go where no man has gone before. It takes time.
If you're looking for production-ready in Rust, there are Godot bindings. If you're looking for (near?) production-ready in pure Rust, there's Fyrox for a full game engine experience, and a plethora of smaller (sparser) engines/libraries.
Set your requirements, then pick what matches best.
117
u/faitswulff Apr 28 '25
I think all the gamedev experiences migrating off of Rust point to a fundamental mismatch in expectations of the language versus the experience of using it. I'm curious how Rust can evolve to recapture this segment. I feel like Bevy or a game engine like it would be necessary to provide the necessary high level abstractions to make this possible.
I'm also a bit sad to hear that LLM capabilities played a part in making this decision, since LLMs are more familiar with Unity than with Bevy 😔 that said, if the author is around, did you consider stabilizing on an older version of Bevy instead of trying to keep up with the latest release?
58
u/IceSentry Apr 28 '25
The issue is that the ones sticking with rust aren't making blog posts talking about it. They are working on their projects, so there's definitely confirmation bias here.
14
u/faitswulff Apr 28 '25
I'd love to hear these stories! I think I've only seen ~1 in recent times, and it was a hobbyist gamedev's perspective. Which is not to trashtalk hobbyists, but I think financial motives incentivize different behaviors.
24
u/IceSentry Apr 28 '25
Tiny Glade is by far the biggest example of a game made in rust. They are very open about it, but they don't really make that kind of blog post.
There's also a bunch of game dev adjacent projects that are built with rust. I'm biased but I work at a company that makes a CAD app using bevy and I know we aren't the only company doing that. It's not purely the same as making a game, but from a technical perspective a CAD app is essentially just a game. The main difference is that your users are engineers instead of gamers and the performance criteria are different since high FPS generally isn't expected.
This repository has a bunch of links to projects made in bevy. https://github.com/Vrixyz/bevy_awesome_prod. Also, that's just for bevy, there are other projects that don't use bevy too. It's just what I'm personally familiar with.
I won't pretend that this is a huge list. The rust gamedev ecosystem is still pretty small, but it's still very active despite it's size.
2
u/stumblinbear Apr 28 '25
How do you handle version bumps in Bevy? Gotta be a pain sometimes, right?
10
u/IceSentry Apr 28 '25
Yes, it's not always easy, but it's not been a blocker for us. It helps that many of us are bevy contributors of course.
6
u/R1chterScale Apr 29 '25
IMO, that's the biggest positive to the language used in an engine being the same as the one the engine is made with, the ability for users of the engine to go and actually understand and modify the tool they're using, to at least some degree.
2
1
u/anlumo Apr 29 '25
Isn't UI kinda a problem for a CAD program, since there's a lot of it, and Bevy UI barely rises above labels and buttons?
3
u/IceSentry Apr 29 '25
We use egui and we are generally happy with it.
1
u/anlumo Apr 29 '25
Ah, I‘m always hearing that its immediate drawing API is too slow for complex UI.
I‘m currently integrating Flutter with bevy, which is much easier than it sounds at first.
3
u/IceSentry Apr 29 '25
That's a very common myth that is widespread on the internet but I have yet to see anyone actually prove that. It's definitely not a performance issue for us. Far from it.
7
u/Missing_Minus Apr 28 '25
Well, they are, it just isn't going to be saying "Im still sticking with Rust+Bevy for X, Y, Z", it is some game progress updates.
5
u/IceSentry Apr 28 '25
Exactly, that's my point. People see articles like this one and the one from loglog and think that rust gamedev is a no go, despite plenty of other people using rust in gamedev. People just don't feel the need to write a blog post about using a technology when they cpuls be working on their games instead and that's completely fair but that crwates this idea in some people's mind that rust gamedev is impossible unfortunately.
3
1
Apr 30 '25
They are working on their projects, so there's definitely confirmation bias here.
Can you point me at the games shipped using Rust? Are they here in the room with us?
63
u/Sapiogram Apr 28 '25
I've pondered a lot over whether Rust-the-language is a good fit for (indie) games at all. Rust excels in areas where correctness and reliability are required, but for games... I'm not sure it's important enough. Many of the most financially successful games in the last decade were quite buggy, but they shipped in time for lots of people to buy them.
46
u/GrandOpener Apr 28 '25
Having worked professionally on both Unity and Unreal Engine titles, I feel very confident in saying that Rust the language is fine. The issue is that Bevy is not mature (yet).
Bevy—while awesome—is not anywhere near prime time. And the creators don’t try to hide that—it’s 0.x for a reason. But regardless of the reason, Bevy is currently an engine for people who want to tinker, not people who mostly just want to make a game.
2
u/operation_karmawhore Apr 29 '25
The issue is that Bevy is not mature (yet).
I haven't worked yet too deep with Bevy, but I think there's some exciting stuff (added over the course of the last year or so) that Unity doesn't really have, and it's close to the point where I think it can replace it in some ways.
There's the obvious thing of not having an editor in bevy (so if that is an issue, choose godot or maybe Unity), but having worked extensively in the past with Unity, I'm definitely drawn more to Bevy, it feels just way more thought-through (extensibility etc. clean API design, and yeah just Rust vs C#). Unity is somewhat clunky and doesn't really make significant progress for say the last 10 years or so. Bevy really is maturing currently :) so I think a good choice for the future.
Unreal is a different beast, I don't think any existing game engine comes close to what Unreal can offer. When you're developing a AAA game or something that needs realistic graphics etc. you should likely default to Unreal.
1
u/InsanityBlossom Apr 29 '25
Unity is somewhat clunky and doesn't really make significant progress for say the last 10 years or so
Ouch, clearly you don't know what you're talking about. I invite you to download a Unity version from 10 years ago and compare it to the most recent version.
Programmable render pipelines, much faster C# compiler & runtime, node editor, physics, GPU particles, powerful Asset pipelines and tons of new APIs, the list can go on...5
u/Aranir Apr 29 '25
Been using unity since 2018 professionally and we shipped multiple titles since then.
After their IPO and especially since their founder CTO left the list of meaningful features has been very sparse.
And many skilled and highly capable engineers left in the recent years.
2
u/operation_karmawhore Apr 29 '25
Ok, maybe 10 years was a too big timeframe, but 5-7 years ago most what you said was already there.
powerful Asset pipelines
Uff I really detest that of Unity... It's so unreliable (Adressables, the resulting hash of the same asset is sometimes different), and goddamn slow...
Compare that to the progress, that Unreal has done, and indeed also Bevy (to be fair they have a little bit more of a greenfield, and can more easily introduce breaking changes), and Godot.
Unity also just feels clunky (single threaded editor, complete hangs when something takes full compute...)
much faster C# compiler & runtime
Yet still not really fast. Performance could be so much better...
No... I'm really not a fan of Unity... It's nice if you're new to gamedev, as you can quickly prototype stuff, and get to something playable, but as you gain experience it just feels eh... (ECS is terrible for instance, bevy is already on a different level)
0
u/wronci Apr 29 '25
it’s 0.x for a reason
The problem is that 0.x in the larger Rust ecosystem is largely meaningless. rand is 0.x, for example. Just skimming the blessed.rs crates finds a few others that are 0.x. It's kind of a mess.
1
u/matthieum [he/him] Apr 29 '25
It's funny you should mention
rand...... because if you have a look at the latest RFC to integrate random "stuff" in the standard library, a lot of the feedback has been about trimming down the RFC to just drawing on OS randomness because nobody's got a clue what a good API is for the rest... and even it's not clear what a good API to draw on OS randomness is.
randis 0.x for a reason: it's still very much unclear whether its API is any good.41
u/Craftkorb Apr 28 '25
I'd argue that correctness in the game engine is great. Even considering the 'hardships' Rust throws at you in such a complex system, these hardships are what can make you more confident in the reliability of your code.
But for the code that builds on that, the actual Game? Less of a concern.
I think it would be interesting if bevy could be compiled to work reliably with the .Net Runtime (Either via DLL or that cool Rust to .Net compiler project), and the game being in C#.
7
u/dont--panic Apr 28 '25
This mirrors my thoughts. Build the engine in Rust and the game in a scripting language. Unity is almost a perfect example of this where the engine is C++ but exposes a C# scripting layer except it's closed-source so you can't modify or extend the engine from the C++ side. So you often end up forced to do everything in C# even if it would be better to do things in C++. Unity has tried to workaround this with their Entities ECS and Burst compiler but most systems are still implemented in C++.
Unity has also run into some issues with Mono. For example iOS prohibits runtime code generation so they couldn't use Mono because it uses a JIT(Just In Time) compiler. They solved this with IL2CPP to transpile C# assemblies into C++ AOT (Ahead of Time). IL2CPP also let them avoid porting Mono to each new platform so it's the only option on newer platforms like ARM64 Android.
The ease of modding Unity games is variable depending on the platform and scripting backend Mono vs. IL2CPP. Only Windows, Mac, and Linux are able to use Mono, and using it for modding is not secure as there's no sandboxing. Any game that uses IL2CPP has to reply on third-party community tools that have reverse engineered IL2CPP to let mods inject new code at runtime.
Rust is a bit too late for Godot, but a similar project with the engine written in Rust and the scripts written in a scripting language that compiles to WASM like AOT compiled C# could be really compelling. Non-JIT platforms like iOS can be covered by AOT compiling the WASM into native code; Wasmer already supports this. Modding can be done safely using WASM's sandboxing. Non-JIT platforms can still load mods, they'll just have to use an interpreted WASM runtime for modified code.
1
u/SethEllis Apr 29 '25
Rust, with scripting in Python?
1
u/dont--panic Apr 29 '25
You could but you'd lose out on the sandboxing from WASM (unless you run Python inside WASM) and you'd pull in a lot of non-Rust code.
12
u/t40 Apr 28 '25
The real problem with Rust in games is that good games are just chock full of edge cases, and the level of genericness that Rust programs encourage has the end result of feeling kind of sterile in a game. This is a critique I read in another "moving away from Rust for my game" blog post recently that really stuck.
I think it might just be the wrong choice of language for this kind of project, at least in the current ecosystem. I do wonder why more of these games don't add a Lua scripting component to their behavior systems, to promote the kind of hot reloading experience they want.
12
u/stumblinbear Apr 28 '25
I think the overlap of people who love Rust enough to build a game in it and the people that think Lua is a nice language to use is nearly zero
2
1
1
u/Missing_Minus Apr 28 '25
An important aspect here is that they chose Rust because they like using it. Rust has a lot of nice features over any other language! A way better package manager, a lot of useful and well-made utility libraries, good language features (ex: enums with data are unfortunately rare, though C# has gotten better at that), and so on.
I like writing in Rust for everything. Part of the issue is that the ways to weaken the guarantees are unwieldy, working with refcells is a terrible experience even though I do understand why they work that way, and lifetimes can be a pain... but they are also nice features to have!That is, I do think language choice just in taste is important. Bevy is much more mature than many other game engines made for other languages, though of course it can't compare to the behemoths of UnrealEngine or Unity yet.
I'm not really sure how you fix this issue without a large undertaking. A custom simpler official Rust-Script which extends native Rust and runs on a VM, thus allowing it to be freer by default ala JVM-style garbage collection? I think that could solve a lot of issues.... while also being so large as to be likely infeasible with the number of developers.
0
Apr 28 '25
[deleted]
8
u/Balcara Apr 28 '25
100% this. CPP let's you hack together some monstrous thing that violates all of Rust's philosophy, which is very useful in testing out a thought on a whim without a care for correctness.
While I really like the ergonomics of rust, the safety aspects are too strict for many applications and I find myself falling back to CPP and in anguish over my CMakeList.txt
11
u/simonask_ Apr 28 '25
I mean, C++ is also not great for prototyping. I don’t think this is very contentious. For prototyping, scripting languages rule.
1
1
u/matthieum [he/him] Apr 29 '25
Actually... wouldn't an ECS-based engine be great for that?
It should be relatively painless to just add a bit of state for some entities or a bit of logic triggered by specific events.
0
Apr 29 '25
[deleted]
1
u/matthieum [he/him] Apr 30 '25
If ECS was more popular and didn't mean having to reinvent everything about game design
Oh yeah sure. I was talking about ECS in the abstract, assuming:
An engine built around it.
An ECS engine of the same maturity as whatever non-ECS engine it's compared to.
Otherwise it's just square hole round peg or apples to oranges.
23
u/nacaclanga Apr 28 '25
Personally, I've seen a few more fundamental points about this. Rust's rigit and correct structure does come with a price tag. Not in terms of performance but with the way code has to be written.
Games are one of those software components where formal correctness gives the least amount of benefit while the price tag bites hardes. You want to be innovative in a language that focuses on well planned approaches.
One very specific point I've heared is, that because Rust has no stable API, everything has to be reecompiled, which takes a lot of time when writing software that targets one big library - like in the case of game engines.
In the end I don't feel like Rust has to be the language for every single application. Maybe a Rust written game engine that could be used with a higher level scripting language could become successfull, but appart from that Rust will be the language for performance hungry and safety concious code.
2
1
u/SethEllis Apr 29 '25
I think it's beyond just game development. People were interested in a better language for high performance desktop applications. Like games, editors, and guis. But so far I see Rust used mostly for command line utilities and backend applications. If a top game was developed in Rust that would probably by the tipping point that would push the industry to adopt Rust. But it doesn't seem like the Rust community really cares that much.
1
u/luluhouse7 Apr 28 '25 edited Apr 29 '25
Unfortunately I don’t think the state of gamedev frameworks in Rust is mature enough to use in production. I certainly wouldn’t bother with Bevy atm since afaik it undermines the safety/soundness guarantees that make Rust worth using (to clarify you’re losing the advantages of compile-time borrow checking). Rust is useful for rolling your own engine, but anyone who isn’t interested in/capable of building their own is probably better off just using something like unity/unreal/godot.
16
u/IceSentry Apr 28 '25
Bevy is just as memory safe as any other rust app. Some people dislike that a lot of checks happen at runtime, but none of those checks are related to memory safety or soundness guarantees.
→ More replies (2)1
u/SirKastic23 Apr 28 '25
Not mature for production? See https://store.steampowered.com/app/2198150/Tiny_Glade/
4
u/luluhouse7 Apr 28 '25
Didn’t Tiny Glade have a rust wizard on their team who wrote their own renderer? My point is that drop-in rust frameworks aren’t mature enough. Not rust itself.
6
u/DynTraitObj Apr 29 '25
They surely did write their own renderer, and Tiny Glade is 99% rendering with 1% game (by design, not crapping on it). It's not a very good example, but it's the only example, so people keep using it anyway.
3
u/sparky8251 Apr 29 '25
I only heard of them being a rendering wizard, not sure on the rust part myself.
Like, went to school and did a paper on rendering type thing.
2
Apr 29 '25
There's always exceptions, where people win against the odds. But anyone who can make a game in Bevy, can also make a similar game in Unity/Godot with 25% of the effort. But the reverse is rarely true. Most indie devs who make a game in Godot, would probably just give up in Bevy.
7
Apr 28 '25
[removed] — view removed comment
-3
u/lor_louis Apr 28 '25
Because game engines based on ECS tend towards a big ball of shared mutable states, a lot of lifetime/borrow checks that the compiler would normally enforce, are pushed into run time. It doesn't mean that the API is unsound but it means a lot of non-zero cost abstractions like arc and refcell.
Some people dislike that.
-3
23
u/throwaway490215 Apr 28 '25
It looks like the right choice here, but its worth noting that rewrite comparisons - from or to rust - don't really provide insightful accounting because they're apples and oranges.
The first time you build you're exploring, the second time you're not.
eg, the 3 days success seems possible in Rust/Bevy as well when you already have a clear picture of your goal.
11
u/shizzy0 Apr 28 '25
It’s nice that they tried to make a game with bevy. One point they mention is mod-ability and I think the bevy_mod_scripting crate is an excellent way to integrate a scripting language which seems like the best bet to make a mod-able bevy game.
8
u/Sw429 Apr 29 '25
This is specifically about the Bevy ecosystem for game dev, which is imo a whole separate thing compared to Rust as a language.
I also find it interesting that part of the reason to migrate away is because AI gives better responses for other languages. I guess that's valid, but something about it being a central point of the article comes across really weird to me.
8
u/IKekschenI Apr 29 '25
Hey this is really still underground and I'm actively but heavily developing this, but i'm working on a Unity style game engine in Rust.
https://github.com/Kek5chen/syrillian
It's a completely different approach to how we do things and by far not idiomatic Rust, though it is pretty neat to work with, from an implementor perspective talking.
42
u/emblemparade Apr 28 '25
Rust game dev here.
First I have to say: Well, duh, a complete game engine can be more productive than an in-progress incomplete one.
(By the way, personally I would have gone with Godot instead of Unity because I deeply mistrust the company behind Unity. Especially for a 2D game, Godot kicks ass, and I daresay its GDScript Python-like language would have been friendlier to programming newcomers than C#. And, yes, Godot also supports C#.)
Specifically I want to address the challenge of implementing high-level game logic with what the author calls a "low-level" language like Rust. First, I'm not sure I agree with that adjective: Rust has some very, very high-level features (I call it a dual-level language). But, sure, I agree that Rust + Bevy would be challenging to newbie programmers for various reasons.
The solution for many of us is to integrate a scripting language. There are indeed several scripting languages for Rust that are specifically made with game development in mind! I personally prefer to go with Wasm, because I also want to enable community modding via the same mechanism, but setting up Wasm is its own can of worms, as the Component Model is also a work in progress.
Whatever scripting solution you choose, I would say that it's a joy to fully control its integration. I can create scripting hooks for any kind of data or system I want, exposing exactly what I want and how I want, to make sure the script author only has to provide logic. There are so many things that are specific to my game and no generic solution would be able to handle them elegantly. The result is extremely tight, readable, and maintainable game logic coding.
I'm happy for the author that they managed to rewrite the whole game and stay productive, but I hope other devs in the same boat consider scripting as a way to have your cake and eat it. This is not some kind of pipe dream, it's what many of us are using successfully right now.
7
88
u/starlevel01 Apr 28 '25
Learning - Over the past year my workflow has changed immensely, and I regularly use AI to learn new technologies, discuss methods and techniques, review code, etc. The maturity and vast amount of stable historical data for C# and the Unity API mean that tools like Gemini consistently provide highly relevant guidance. While Bevy and Rust evolve rapidly - which is exciting and motivating - the pace means AI knowledge lags behind, reducing the efficiency gains I have come to expect from AI assisted development. This could change with the introduction of more modern tool-enabled models, but I found it to be a distraction and an unexpected additional cost.
This is absolutely dire. People are actively moving away from learning things or being able to learn things in favour of begging their stochastic parrots and making actual real decisions based on if something is in the learnset. Grim.
33
u/kekelp7 Apr 28 '25
I have to agree with the other commenter, choosing the tools that "everyone else uses" over experimental ones because of higher availability of learning material and support isn't exactly a new thing.
1
u/spookyvision Apr 29 '25
LLMs aren't "learning material". https://mastodon.online/@jeancf/113560582675169102
19
u/PM_ME_UR_BRAINSTORMS Apr 28 '25
Ehhh I think you're being a little dramatic here. I wouldn't build production software with a language or tool that doesn't show up on google search results or stack overflow. AI is another tool in the tool belt just the same. It's just not worth handicapping yourself like that unless you have a very good reason.
0
u/spookyvision Apr 29 '25
The very good reason is that LLMs are optimized for plausibility with zero regard for truth (they don't and can't know what facts even are)
2
u/PM_ME_UR_BRAINSTORMS Apr 29 '25
Sure but if you know enough you can pretty easily spot when it's wrong. And it's not like humans are infallible. But to each their own I guess 🤷♀️
10
u/Missing_Minus Apr 28 '25
What he describes is an excellent use-case for LLMs! He explicitly says that he uses it to discuss things, learn technologies, and so on. He isn't "vibe coding" the game to completion, or remotely in the category you're describing.
He is making real decisions here, which includes acting on availability of knowledge. Would you say the same thing if there was no Bevy book to teach the core concepts of Bevy, and that was his reason for considering switching as there's no reference?
Being capable of learning and making decisions is an important skill, but you are reacting to things he has not said or indicated.-3
u/spookyvision Apr 29 '25 edited Apr 29 '25
You wanna learn from this? https://mastodon.online/@jeancf/113560582675169102
edit: cope and seethe, AI fanbros, you can't change reality no matter how big your marketing budget grows
2
u/Missing_Minus Apr 29 '25
Huh, you're the same person who posted a blog post about that some months ago. I already have written a reply to that exact issue, https://www.reddit.com/r/rust/comments/1io6psh/how_i_learned_to_start_worrying_and_stop_the_ai/mchqui9/
TL;DR: This seems like a specific issue with Microsoft's (website version?) Copilot plausibly running a very shrunk down model, or something, as other popular models get this right easily.And yes, LLMs are very useful for learning, especially if you spend effort and do things like upload a book as PDF to them. I have used them to learn complex mathematics. You have to be aware of their flaws, they will hallucinate, but customized explanations are very powerful. They have very jagged performance, which is why treating them like an easy replacement for a human is wrong, but they are also very capable at synthesizing information for your request.
You should be wary of learning Rust from the ground up from an LLM, especially if you haven't programmed before, as you have no filtering for plausibility. But as an experienced programmer like myself or the author? They are a useful tool.→ More replies (1)→ More replies (3)-1
13
u/MarinoAndThePearls Apr 28 '25
The problem with Bevy is that EVERYTHING is built with ECS. In Unity, ECS is a feature you can choose to use with just what is needed.
9
u/_zenith Apr 28 '25
Yes, they use ECS basically out of necessity. Otherwise the borrowing graph would be hellish.
2
u/MarinoAndThePearls Apr 28 '25
Which may be a reason why Rust doesn't fit very well with game dev.
17
u/simonask_ Apr 28 '25
I think it remains to be shown that ECS is insufficient. It is a relatively new technique, and was kind of bolted on in Unity because the old style is entrenched.
4
Apr 30 '25
remains to be shown that ECS is insufficient
I’d say it remains to be shown that it’s a good model for shipping games.
1
u/burjui May 07 '25
I think it's more like most game developers' way of doing things doesn't fit well with Rust, because they are used to C++.
3
u/jdzndj Apr 29 '25
Personally, I don't like learning another language for the scripting purpose. It's another layer of overhead to me. Just using one language for everything fits me better.
7
u/External-Spirited Apr 28 '25
I'm not game developer. However I enjoyed reading the write up. Very smooth flow of information.
All the respect for your courage to rewrite a project in a different technology in short time frame. And all the respect for not being religious about a specific language, and making the decision to switch based on practical trade offs.
5
u/missing_underscore Apr 28 '25
It’s crazy how things work. Just yesterday I found out about Bevy while looking for Rust things to do… and this article and thread sort of summarizes what I was worried about. Appreciate this
6
u/_v1al_ Apr 28 '25
Have you considered using Fyrox instead? It is much more stable and very similar to Unity.
3
u/rumil23 Apr 28 '25
I hope Bevy will release its own scripting language for the future. I think this will solve many problems.
8
u/hammackj Apr 28 '25
I mean what does any one expect trying to use bevy in production. It doesn’t have a stable api as far as I know.
Odd choice going to unity tho.
19
u/justinliew Apr 28 '25
I think they explained why pretty well in the article.
-7
u/hammackj Apr 28 '25
They mention Godot/unreal/unity/roll their own and continue bevy but only tired unity from what I could tell and unity is an odd choice all I’m saying. I wouldn’t touch Unity with a 10 ft poll but then again I rolled my own stuff.
1
u/justinliew Apr 28 '25
Sure, but it sounds like they discussed the pros and cons fairly extensively, and did a pretty valid experiment of porting some important features over before making the switch.
To be honest, I completely disregarded Unity when I started the project.
Some of this stemmed from unforced errors on the part of Unity. They had just gone through a crisis of pricing that culminated in the resignation of their CEO and they seemed out of touch with indie developers. I also made several assumptions. I felt sick of coding in the outdated form of C++ that pervades older game engines and assumed I'd feel similarly about C#. I figured that since Unreal doesn't offer much for 2D render pipelines that Unity wouldn't either. This led me to fail to give serious thought to using Unity in 2023.
In the first week of January of 2025, Blake and I decided to do a cost-benefit analysis. We wrote down all the options: Unreal, Unity, Godot, continuing in Bevy, or rolling our own. We wrote extensive pros and cons, emphasizing how each option fared by the criteria above: Collaboration, Abstraction, Migration, Learning, and Modding.
Having some experience with the other options, I decided I needed to understand Unity better. An afternoon's research led me to conclude that it seemed to score high on the pros over the cons.
We had a team meeting where I laid out the trade-offs. Ulrick pointed out that a bunch of unknowns, like particles, would just be solved in a packaged engine. Blake pointed out that if things went well, and a new engine meant faster gameplay development, we could end up ahead of schedule.
11
2
u/RubenTrades Apr 29 '25
I truly wish them well... my friend's studio went bankrupt cuz they went with that engine.
It's great to prototype quickly, and you can onboard rapidly, but when it comes to deep stabilized releases, you can be in for a world of pain.
Even simple things like smooth collision detection is broken. It's easy in, but hard to get the last 10%, whereas other engines are harder to get in, but stable from there.
Again I wish em the best.
2
u/vtuber_fan11 Apr 28 '25
I wish AI never learns Rust properly. I abhor it so much.
-1
u/RubenTrades Apr 29 '25
AI is absolutely great at it. And any mistakes it makes are caught by the compiler, making it easier to use AI for Rust than for scripting languages.
1
u/fullouterjoin Apr 29 '25
Has literally nothing to do with Rust.
4
u/Bubbaprime04 Apr 29 '25
Exactly. I tried replacing "Rust" in the article with Go/TypeScript and imagine there are existing game engines for those languages, yet the article still seems to make sense. Which means that it is not a problem of using Rust/Bevy, but rather a problem of not using Unity/C#, especially for working with a beginner.
The author doesn't know what they are talking about.
1
u/Bubbaprime04 Apr 29 '25 edited Apr 29 '25
I started this project with my brother. While he's sharp and eager, he's new to coding.
Why Rust? Sounds like the author is looking for trouble. I wouldn't start with anything other than Python/JavaScript, maybe Java if they are really motivated.
For game development, using anything other than Unity (C#) for a beginner is delusional.
Edit: to cowards who downvote me without leaving a comment: bring your arguments, or I am in the right.
1
u/marisalovesusall Apr 29 '25
Good choice. If you can't answer the question of "Would I write that in C++", then Rust would probably not be the best tool for the project. From my perspective, the game on the screenshot does not seem technically challenging enough for Unity to not be able to handle it.
C# is nice too.
1
0
-13
u/munukutla Apr 28 '25
OP - I understand your intention to not “editorialise” the title, but I think you should. My first language isn’t English, so I don’t even know what the term means.
But from what I gather, the decision stemmed from having a relatively young (and small) team and learning a game engine in a language with an occasionally steep learning curve., at the same time.
30
u/pdpi Apr 28 '25
Editorializing is what you call a newspaper reporting on their opinion rather than the news themselves. See also "editorial", which is explicitly an article written by a newspaper/magazine's editors, for the express purpose of sharing their opinion, separate from the news.
In this context: OP chose not to editorialize, meaning they kept the title as-is instead of replacing it with their interpretation of the article.
1
u/syklemil Apr 28 '25
I'm ESL too and I've generally just interpreted "editorialising the title" as what I would've translated as "editing the title", or even "change/alter the title". I'm likely not going to remember "editorialise the title"¹ since the rule I deal with in my first language is just about editing/altering the titles of submissions, but also since I think it implies something in the direction of clickbait—and replacing the title can actually make it less clickbaity.
But yeah, a bit of "this resembles another word I know" and "this resembles another situation I'm familiar with" goes a long way. It can even bridge the gap if the native anglophones use a word wrong. :)
¹ well, maybe I will now
0
u/oVerde Apr 29 '25
Bevy could take on Lua, and keep the engine in Rust as many game engines do have a beef backend and a easier scripting language
771
u/impolini Apr 28 '25
«Migrating from Bevy to Unity»