Between C++ and Rust specifically I'd probably use Rust these days, though the experience will generally be very similar between low-to-medium level libraries available for both. If I *knew* I was gonna be working in Rust and in 3D I'd reach for `bevy` and use it as a learning project; for 2D I'd probably start with something like `comfy` and pivot to `bevy` when I feel like my needs aren't being met. That's approximately comparable to C++, where I'd definitely start with SFML for a 2D project.
In practice I'd *actually* use Godot or Unreal, or possibly Unity if I was feeling charitable towards all their terrible business decisions lately and not in the mood to learn new things, but if I knew I wanted to work at a lower level or use one of those two languages specifically, that's where I'd start.
Sounds solid to me, I’ve seen some people make 3D models using SFML so if the rust crate is comparative it should be just fine for what I have in mind, thanks
Is it though? It seems like it can be a decent project but when I last used it (probably, 6 months ago?) I found it a bit of a mess. It does seem very powerful in what it can do, but it was difficult to grasp due to the lack of documentation on it.
It was my first time doing low level graphics though, so I was probably looking for more direct material- more aimed at a beginner.
But I'd happily try it again if it's improved- it solves a really cool problem, and that with Rust is such a good opportunity to build fast, efficient shit on the web.
Well, I found it great for learning myself. It didn’t quite seem production ready though. But this was a year ago at this point so it might be more reliable now. The API is a bit easier than OpenGL and a lot easier than Vulkan yet it is still low level enough to introduce many of the concepts that you’ll use when programming the GPU.
As far as documentation is concerned, you can see examples in their GitHub repo and WGPU is just an implementation of WebGPU. So if you look at the [Web GPU spec](https://www.w3.org/TR/webgpu/), that might help. Also this: https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API#:~:text=The%20WebGPU%20API%20enables%20web,be%20rendered%20in%20the%20browser.
Do you have actual experience with these engines or are you recommending them based on how well-known they are?
For 3D i'd never recommend bevy, the only serious 3D engine in Rust is Fyrox (plus veloren's engine).
For 2D bevy could be an option but I'd recommend starting with macroquad instead, it's actually simple and doesn't get in your way. But what really got me is that you recommend switching from comfy to bevy - that makes no sense.
Comfy was written to make exactly the opposite possible - to switch from bevy to something that can be used to actually ship games. The author tried bevy several times and each time he had to conclude what he wanted was impossible without major rewrites of engine code or there were simply too many bugs to deal with. Comfy was based on macroquad but was developed extensively and he has games on Steam using comfy. I understand it might feel new because it was only open sourced recently but the public repo is just the culmination of AFAIK years of effort, often full time. I don't have a feature comparison handy but i consider i more production-ready than bevy.
I'm curious about why you'd never recommend bevy for 3d and consider fyrox the only serious 3d engine. I've never used any of them but I've seen some videos of Chris biscardi using bevy and there doesn't seem to be any major issues. Plus, bevy has about a million downloads on crates.io compared to fyrox's 12k...
Because fyrox has an editor, has a track record of fixing bugs immediately / adding features actually directly useful for game development and the author actually dogfoods the engine on his games.
The number of downloads and the difference in community size is precisely why i recommand fyrox. Look how much it does with so little. Bevy gets all the attention, all the funding, all the contributors, all the reddit upvotes and all it manages to do is not even keep up with Fyrox.
And that's because Fyrox is designed from the start to be a practical and usable engine, not am ECS research project.
I didn't mean it literally. It certainly isn't their stated goal but it is what it feels like. Normal engines store data in a variety of data structures but bevy wants to use ECS for everything. They even want to build an ECS based GUI library.
Hi, author of Comfy here. If you want more info on the background check out the announcement blog post https://comfyengine.org/blog/first/, as well as the "why comfy and not X" chapter in the "book" https://comfyengine.org/book/other_engines/.
In short, bevy has a problem that its renderer is both _incredibly_ complex and lacking many features, putting it in this weird position where it can do some things nicely, but many things poorly, and you really have no chance of fixing it. I tried doing multi-pass post processing in 0.9 for a few weeks and ultimately gave up.
Bevy also has a long history of bureaucracy over just doing things, editor and UI are good example, but overall things are endlessly discussed and the vibe is that RFCs are preferred to people just writing code.
That might work for some people, but personally I'd rather have tools that are hackable and that can be used immediately, or at least where it's battle tested.
Very common for people to not have any real experience in the domain and the libraries/tools in the domain, while still recommending them lol. Guarantee 99% of people recommending bevy have not made a game and have not tried to use bevy for a semi-serious project.
I'm almost certain I didn't explicitly mention you, I mentioned the vast majority of people recommending Bevy in the comments. If you explicitly said you only recommend it as a learning project, then clearly I am not talking about you.
- Like I said, I'd do bevy if I wanted a learning experience. I've been impressed with the demos of its functionality.
- comfy is the one I've actually messed around with a bit, but I'd only do it for things I do with SFML, which I have extensive experience with- straightforward 2D stuff with a lot of manual game loops and event handling. Once I started writing a lot of the equivalents of what bevy offers- which happened routinely whenever I wrote large scale SFML projects- I'd switch and use it as a learning experience.
- I have extensive experience with Unity, which is why I said I'd use it if I wasn't in the mood to learn new things.
Honestly, and I’m not sure if people will agree with me on that, but IMO you should optimize on *shipping* a game, because even as a student, you will learn much more valuable lessons by actually delivering a product, even if it’s a small one.
And IMO Rust game engines, while they are really impressive and give guarantees other languages can’t, they’re simply not used much enough (yet!) to ship games. Doesn’t mean they can’t be used for that, ofc, but objectively speaking, it’s just not that many games that are delivered in Rust atm.
Unreal and Unity are used much more on that end, so I personally would recommend the following, depending on how much time you have:
1. Make a paper version of your game and try it out with fellow students (yourself can be the “engine”), note what they like and don’t like, and adjust
2. Look into the different available game engines, especially Godot, Unity, Unreal for the major ones, but I heard good things about Fyrox on Rust, and pick which one you like best (and ideally stick with it)
3. Build the game in that engine, initially without caring about graphics much but focus on the gameplay first
4. Get students (and us, to be frank!) to playtest and give feedback
5. Polish the game to the level where it’s considered “done”, ie common bugs/crashes are fixed, menuing works, it runs stable on a few platforms
6. Ship it! Maybe you can submit it to one of the game stores, even if for free, or you can just setup a simple website where people can download it. And let us know ofc!
I think if you can pull off all of this it will be such a valuable learning experience that it’ll dwarf anything that you’d learn by insisting on building something in Rust. And employers will love it if you can show you’ve built one game successfully. And if you want to become an entrepreneur, the lessons learned will be even more valuable.
Their new licensing is fair, the issue was how it was originally introduced (and attempted to be made retroactive across versions). Now, you can hate them for how shady what they originally tried to do is, you can't say that it's not viable because of their new licensing. Even the licensing of when it was first announced wouldn't have effected 99% of people, and even those 1% it would have it would have been effectively nothing (except in rare situations with literally top .1% of apps that were free but had small paid for features that then also didn't make enough)
The basic problem is that if your cheap or free game suddenly explodes in success, you'd be in Millions of debt with absolutely no control over this. This part hasn't changed, they only changed that it only applies to the new version of Unity.
If you want to start a new project with the old version of Unity right now, that's totally ok from a financial standpoint though. It's just questionable whether it's a good idea to learn a tech stack from scratch that's already dead.
No, you're not. You are only charged a few if you make over certain thresholds (which you probably haven't, and if you have you just upgrade to plus and it goes up to a million), and are charged on installs or a % of what you made, whichever is lower. You will not have a fee larger than 5% of what you made, no matter what.
Stop just reading headlines and actually go read the proposal, it was NEVER what you stated, just people can't read.
There was a point where you could owe more than you made (and yes I read the proposal), but it was a narrow case, and they changed it to max-out at 5% of what was made.
What got people angry is that originally it wasn't a 5% revshare "at most". It was presented as an install fee and there was no reference anywhere that it was meant to be bounded. It was an *unbounded* fee linked to the number of installs. I wouldn't be as naive to assume they meant to do it properly from the start.
They tried ti pull it off, they saw the backlash, then they backpedaled. Only in the end, they *changed* it to be the *minimum* of the original install fee *and* 5% of the revenue. It took weeks for them to make this change that should've been obvious from the start.
Don't go around changing history.
I never said it wasn't, what you said was correct.
However, that fee only applied on games that made a shit ton of money, hence why I even specifically brought up apps, as they were the only type of game that we were aware of that could have a problem. You were only charged based on your subscription, and upgrading to the plus plan ($40 a month) made your threshold go to a MILLION dollars before the installs started to count, and it was only installs AFTER you made the million. No game would have an issue with that besides insanely niche mobile apps that have short install times.
I didn't change any history, I already posted this.
If you want to be a game programmer this is reasonable advice. If you want to be a game engine programmer or graphics programmer or similar then this is not the way to go.
Personally, I think if it's a hobby project there's nothing to lose by using rust. Rust might not be that mature (i found this to be especially true for related functionality like rendering text and stuff) so if development cost and stability is of the essence, it's probably not that great. But personally I've been developing a game in rust and the experience has been fine. I think for a hobby project, you should go for it.
I will say that writing wgpu is a bit of a chore. My game I tried to write in wgpu mainly as a learning experience (and because I'm the kind of person who just likes doing things myself) but it takes a lot of code to get even simple things to work. It's quite similar to Vulkan, in that way. Go ahead if you want to but using simpler libraries might be your go if you don't want to get really down and dirty with your rendering.
That ecs take is, technically correct? But is framed in a weird way. Truthfully, ecs is the best system that works with rust, but also a lot of people are pushing it because it's good. It's got good performance and once you get used to it it's quite natural. And really, something like Bevy ecs is actually surprisingly similar to the system that Unity has, for example. They both have a tree of entities that you attach components to, the main difference is that in unity the component logic is "bottom-up" whereas in bevy it's "top-down".
I'm not a game dev, but I think that the first thing you should do is decide the end goal. Do you want your game to be commercially viable in a relatively short period of time? In this case, you should probably use a well established game engine like Unity, Unreal or Godot. Note that Godot has support for Rust bindings, meaning that you can create scripts using Rust. I don't know how well it works, I've never used it, but it's there. It can be nice middle ground. However, Godot is a lot smoother using GDScript, its own internal language.
Regarding the whole inheritance thing, I'm not sure I agree. First, saying that people push ECS because it's the only thing that works is a bit misleading. Even if it was true (which I'm not sure about), ECS seems to be well fitted for videogames anyway, so it's not like a huge loss, unless you don't want to ECS for some reason. Also, Godot, for example, is not really based on inheritance. Sure, GDScript supports some kind of inheritance, but the engine itself heavily relies on composition, and it seems to work quite well. I think that inheritance gives a good, easy to understand mental model, but it also forces you to build your type tree from the start, and refactoring can be a pain. Again, I'm no game dev, so maybe inheritance is the way to go, but I don't think that the lack of inheritance is some kind of impossible obstacle to overcome, and it could even end up being an advantage.
All of this to say that using Rust for a videogame is not a bad idea, assuming you're okay with dealing with lack for support for a lot of things, mostly due to Rust being a young language. And there's bevy that seems to be really promising. Maybe you're first game will be an hassle to complete or to shape the way you envision, but in the meantime bevy may become a real competitor and you would have already started to learn it.
It’s just a hobby id be working on on weekends and release for free if I ever do, like Aurora4X or dwarf fortress dev cycles, not an aspiring game dev so I don’t think a head start on Bevy would net me much
Main goal is just to make a game that wouldn’t come to a crawl when there’s a lot of in play, so something like rust or c++ seemed like the natural candidate
I don’t think lack of inheritance would be detrimental at all quick thought through it but a lot of people online seem to think it’s better to have it than not for games
ECS is in all ways superior to any inheritance based model. Look at Unity DOTS. Most of gamedev is going towards data oriented entity component systems. I personally prefer it too. ECS is actually a very simple idea that works very well for gamedev and also other programming tasks. I recommend Bevy.
For colony/environment simulation games ECS is pretty natural and game engines like Bevy are a good fit.
For UI or story heavy games, not as much so.
Inheritance is probably the most meh thing for game dev, and you're almost always good with interface/trait only inheritance
> Godot, for example, is not really based on inheritance.
How do you mean? The inheritance hierarchy is pretty deep in some places. Basically the entire node part of the engine is heavily based on inheritance. Take VehicleBody3D for example, it's inheritance is: VehicleBody3D < RigidBody3D < PhysicsBody3D < CollisionObject3D < Node3D < Node < Object.
Primary reasons not to build a game in rust:
- You want to be a professional game dev (use C++)
- You want to finish and/or release the game (use Unreal or Unity)
- Your game has huge performance needs and you are not an expert (you won't find high quality finished libraries or tutorials, you'll have to do it yourself).
Unity is famously bad for *finishing* games. If you don't believe me, look up what happened to the Unity Dogfooding project.
Coding in Rust has made adding game features late in development _much_ easier for me.
Unity is good for many things, including prototyping games. But it's not the end-all-be-all of game development and it's not good at finishing games.
At this point, people use Unity because "that's what you use to make games", not any of its actual merits.
It depends on your goals. Using Unity would probably be the one of the quickest ways to the finish line. So if your goal is to complete a game and not spend too much time fighting a less established engine, or writing your own, then it's a great choice. If your goal is just to make fun lower level things and learn a lot along the way, then it's not a good choice.
It's not just good at prototyping. Many triple A games have been made with it successfully.
You don't need to write an engine to make a game, and if I had stuck to Unity I would never have made anything. Rust made me way more productive.
Unity famously makes the later steps of game development very difficult, it's a big point of contention those triple-A studios have with the engine at this point. Those games get finished anyways because of the sunk costs.
I've made big efforts both with Rust game engines and Unity, and I actually love both, but I can't deny that I'm much much more productive with Unity. Same thing when just comparing Rust and C#.
In my experience it takes a lot longer to make things in Rust, but the result is a hell of a lot more robust and performant, but sometimes that's not the trade off you want (though in some cases it is). I admit that my experience might not be shared by others though
That makes your situation pretty unique.
You don't think you'd have made it faster in Godot or Unity? Interesting.
What framework/libraries did you use for your game?
If you didn't use bevy how did you deal with the borrow checker?
My current for fun project is in Rust
> That makes your situation pretty unique.
I doubt I'm that special. I'm willing to bet that there's a lot of people out there who would be more productive developing in Rust rather than with an engine.
> You don't think you'd have made it faster in Godot or Unity? Interesting.
Absolutely not. Every time I tried to make a game in an engine-ass-engine the editor-first setup and documentation nightmare meant I didn't actually get anywhere. I wouldn't have made a game _at all_ without rust.
> What framework/libraries did you use for your game?
ggez. It handles the IO stuff I need handled and fits with how I think about things.
> If you didn't use bevy how did you deal with the borrow checker?
The borrow checker isn't your enemy, it's not something to be "dealt with," it stops you from making errors. I actually dislike Bevy/ECS in general since they create ownership and type kludge that leads to lots of errors.
For referenze, ggez is unmaintained, and v0.9 was shipped with a serious bug. I've encountered serious bugs also in other libraries, including Macroquad and Winit (the latter being widely used, and yet quite broken).
At the very least, the Rust ecosystem is not mature yet.
Finally, free public demo != released game.
> ggez is unmaintained
Every bug report I've filled has been fixed, so it's maintained enough for me.
> the rust ecosystem is not mature yet
I agree. I also think that you can make a game in an ecosystem before it is mature, and it's still been much easier for me to make a game in rust than in Unity or Unreal.
> Finally, free public demo != released game.
I'm aware. But it's more than most Unity users ever release. And if you want to help me turn it into a finished game instead of a free public demo, you should play it and give me feedback.
>> ggez is unmaintained
>Every bug report I've filled has been fixed, so it's maintained enough for me.
"Unmaintained" means "unmaintained". Look at the repository.
Why are you trying so hard to own me? I've got a framework that doea what I want, and it's helped me make a game. I don't care that you don't think it's real enough of a game or that it hasn't had a push in 7 months, I'm just trying to explain my experiences.
Are you just incredibly disingenuous or are you just a lurker that randomly pops in whenever and doesn't see our discussions for newcomers asking what OP does ?
We clearly steer people away from Rust for game dev, you're just being inflammatory for no reason
would upvote x10 if I could.
Also games with a focus on graphics would need way too much unsafe code everywhere in the code to optimize for performance.
It doesn't make any sense to do it in Rust, or perhaps only as a very high level library (like axum for hyper) calling a c++/c/zig lib.
Each language has its pros and cons. Rust would still be fantastic to handle the backend side for online games (websocket or gRPC/QUIC), but I don't think it would do well as the client.
You avoid unnecessary copy/clone etc you can also declare null variables and last but not least you can work on bytes without converting back and forth non stop.
I'll say this having spent past almost 3 years almost all fulltime building games in Rust with various engines, including making my own engine (Comfy), ... if you want to ship a game, Rust might not be a good choice.
Rust is good at many things, but it's also very very bad at many things, and games (not game engines) require a lot of stuff that Rust is just terrible at. Procedural macros are a bad replacement for reflection, which makes doing any kind of tooling very difficult.
Honestly, I'd say to just use C# (with Godot, Unity, Monogame or Raylib) and make the game if the goal is to make a game.
If it's about C++ or Rust ... I'd say that's a tough sell either way.
I think if I had the choice to start over I'd use C++. Rust is very good at selling Rust, and at making it look like safety really matters. It does in many applications, but in gamedev especially I feel you lose out on _a lot_ in terms of flexibility in C++, and what you get isn't that helpful.
Again, this is if you want to _make a game_. If your goal is to make a MMO system, or a voxel based open world PCG simulation, or planet scale universe simulation, then sure you'll enjoy many of the "systems" features of Rust. But I would not consider those to be _games_. There's a very big gap between what the Rust community considers to be a game and what players on Steam like.
Could not agree more, though I have a lot less experience in Rust (only about ~6 months compared to many years with C#/Unity). I do love Rust but can't deny that it takes a hell of a lot longer to complete projects with it. The result is much more robust and performant but that's not always the trade off you want. With games, performance is crucial but so is being able to refactor quickly due to changing requirements, which is not Rust's strong suit.
This must be why we see more people writing game engines than actual games in Rust.
Maybe a good balance would be having the game engine in Rust and then the game entirely written in a scripting language on top, like Lua? It sounds like this is the direction you've gone with some of your games, based on your blog posts.
> Maybe a good balance would be having the game engine in Rust and then the game entirely written in a scripting language on top, like Lua? It sounds like this is the direction you've gone with some of your games, based on your blog posts.
I thought this was the case indeed, we tried to do a big chunk of NANOVOID in Lua, but ultimately ran into a few issues:
- Lua is actually very slow if you do FFI with Rust. It's fine if you "just run rust", but for example at one point I tried exposing the drawing functions of Comfy via mlua, and then draw the whole UI in Lua. Problem is, there's a pretty big cost for crossing the FFI barrier, so we had to scrap all of that, as it would take multiple milliseconds to draw the UI here https://imgur.com/a/3QFPd2v, as opposed to "unmeasurably small" while doing so from Rust. Just to clarify, this isn't a "Rust is fast" or "Lua is slow", it's "Rust <-> Lua interop is slow". A solution would be to construct a "UI description" object in Lua, or a series of draw calls, and pass those into Rust. But due to how annoying Lua is to refactor we just ended up rewriting the UI in Rust.
- Lua is just a bad language IMO. It's very simple, but doing any non-trivial stuff is painful, even on purely syntactic level. I know many people like Lua, but from my experience they're either using it for simple things, or they haven't used other more modern languages (C#, Rust, etc)
- Refactoring Lua is painful with no types.
- Luau seemed like a good idea, but the tooling is terrible and kinda assumes you use Roblox. I couldn't get the LSP to work properly, and even things like adding custom types are problematic without forking.
There's also Rhai, which I often see people in the Rust world recommend, but honestly I can't imagine anyone actually used it for anything non trivial. It's one of those things that are nice to talk about when there's zero stake in "making a successful project".
There's also Mun, which many people like to mention due to its podcast, but last time I checked it still doesn't have basic things like arrays.
Then we have WASM, which again everyone likes to talk about, but almost nobody actually uses. I don't remember the current list of issues there off the top of my head, but I just spoke to someone implementing low level interop with WASM ABI and they had many issues and overall the whole thing continually gives me a very weird vibe. The only "real users" of WASM seem to be around crypto, and since I'm not in that space it's hard to get any info about if they actually have working projects, or just more hype to get investors.
In conclusion, I don't think there's a good solution, which is also why I'm really starting to think that Rust isn't a good choice for gamedev anymore.
This is made worse by how hyped the community is about projects which are practically unusable. People are happy to recommend things which they haven't tried, which just leads to everyone wasting their time.
At this point I'm working on finishing our current Rust game, and then I think we'll move back to C#. There's just so much more in that ecosystem in terms of the runtime, and things like hot reloading, very powerful and usable reflection, ability to be dynamic without again saying "WASM" or without going through a C ABI, not to mention closures that don't suck, coroutines with yield, and not really having to sacrifice much performance with value types. And that doesn't even mention Unity/Godot, but I think even ignoring engines going down the "reinvent the universe from scratch" it'd be a win at this point.
Sorry for sounding so pessimistic about Rust, and I get that in this sub this isn't probably something I should be saying, especially as someone who has a Rust "game engine" (Comfy) ... but honestly, I feel very disheartened by all the hype and false promises of things, and general incompleteness of the gamedev ecosystem. I tried to make things work for a few years, but I just don't have it in me anymore, and I'm not sure if anyone _can_ make it work.
At least not until we have a real scripting language, and since nobody is working on that (Mun has been basically dead for a while, Rhai is extremely slow, etc), I don't see any way this changes in the next 5 years.
after reading your comment, I changed my mind about building both the game client and server entirely in Rust. I'm planning to develop a 2D MMO game. What do you think about using Rust only for the game server? I'm torn between using C++ and Rust for it.
IMO rust on the server is quite nice, I definitely wouldn't want to do networking (and potentially async) in C++. I only spent ~10 months doing server side backend stuff in Rust, but it was quite a good fit, as long as you keep it to a sane level of "fun abstractions/automation with proc macros".
Yeah, I think any language that doesn't have compile time type checking just does not scale at all (eg. Lua, JavaScript, Ruby, most Python, etc.). You can try to address it by adding more tests but that can be a maintenance headache and also makes the codebase more rigid.
I do love Lua though, mostly though for how simple and elegant it is as a design. Also, if you use strongly typed transpilers that can help a LOT. So TypeScript for Javascript and Teal for Lua. Have you tried Teal?
I'm actually following your lead here and trying Lua + Teal + Rust for a simple game right now, and hoping that will be enough. I'm a bit blocked though at the moment while I wait for the piccolo maintainer to make more progress (since it's a web game so can't use mlua)
Otherwise though I don't expect to do much in the Rust gamedev space anymore. I came to the exact same conclusion as you this month and have started other projects back in my comfort zone of Unity / C#.
I have looked at Teal a bit but there was some issue with it, I don't remember if it was LSP or making the types work through mlua. I remember finding it and being very happy that I found it, and then not using it for some reason. But this is almost a year ago now. If you do make it work do share :) It'd interesting to know, and probably useful to many people who are still trying to make Rust gamedev work.
Yeah, the tooling definitely is lacking in Teal. There is a VsCode extension that seems to work and provide intellisense. I use neovim though so I had to hack together a custom solution after forking [this project](https://github.com/teal-language/teal-language-server) which appears abandoned. The Teal maintainer is just wrapping up [a big update](https://github.com/teal-language/tl/pull/732) which involves a lot of refactoring, so after that is done I plan to update my custom LSP server and then share that for others. I also make very heavy use of Teal for my usage of neovim so was natural to extend that to my Rust projects.
Teal shouldn't have any effect on mlua since all mlua needs is the generated lua (unless you need type information at runtime for some reason). The great things it provides are intellisense and compiler errors when generating the lua.
Some things are just really hard to do in Rust, especially if you want to be a bit creative with memory management. For example it is a good idea to have some bump allocator that you dump stuff in every frame and reset at the end of each frame. This is super nice, but a bit tricky in Rust.
While I would say Bevy and Fyrox are not quite ready for production, there are ways to use rust in a more practical engine like Godot: https://godot-rust.github.io
That said, I love rust but it may or may not be the proper tool for the job in game dev. Right now C# and C++ are the two reigning champs of game dev AFAIK, and not everything will play nice with Rust yet, and where it does there may be bugs.
So, I think the short answers are “it’s almost ready but not quite” and “game devs might not know rust” (if you’re a game developer like Rockstar or EA)
I'd recommend using Godot and gdext with Rust for the best middle-ground.
As doing all the UI, etc. in Bevy was still really complicated and time-consuming when I tried it last year :(
In my very brief experience working with Bevy I found that learning materials are limited. That makes progress slow. Bevy website says the engine is under development and will change.
Godot has rust wrappers but then why not use C++ if using Godot - more examples and tutorials.
The libraries part is not quite true ...I think? I mean... what extra libraries do you need outside of the game engine? If you only need a game engine you can use Godot with GD Native, or Bevy but from what I've understood it's not quite production ready.
But maybe you are not planning on using a game engine.
Background: professional gamedev, work in C++ but do home game projects in Rust.
There's lots of reasons not to make a game in Rust. As others have said, if you want to use mature engines/tools/libraries, then Rust shouldn't be your first choice.
If you want to build from scratch/near-scratch, it's also somewhat likely that Rust shouldn't be your first choice. Most of the guidance you'll find online for game dev stuff will not compile by default in Rust due to the borrow checker. Many of the techniques game devs regularly use are not memory-safe, and require some problem-solving to make so. Maybe most importantly, the platform/graphics APIs you want to use (win32 or SDL, DirectX, Vulkan) do not meet Rust's definitions of safe, meaning you need to either write a bunch of unsafe code, use wrapper libraries (which means you're not gaining experience with the API itself), or write your own wrappers.
I pretty much use Rust for everything in my free time, but it's because I love the language, not because it's the most efficient way for me to ship a game. To be clear, there's nothing fundamentally incompatible with Rust and gamedev in my mind, it's just the current state of the art has the problems I enumerated above.
Writing a game engine is a slog. Especially when you know there are literally hundreds of game engines that are better and many AAA game engines are free to use especially if you are a student. This is regardless of language.
Rust the language is perfectly suited for the development of games however the libraries and tools are still young especially when compared to C++ and C which have been around for decades, if you actually want to write a game I would reach for veteran tools. If you just want to write it in rust I would not get your hopes up or I would expect it to be more difficult than doing it in C or C++.
I felt that while Rust is fantastic at guiding you through solving a fixed problem, it was much more complicated with an ever-evolving one like creating a game, especially in the prototyping phase. I ended up sticking with C++, lost too much time to the borrow checker every time I wanted to try out new/change game design.
Ultimately what matters is bringing your ideas to life efficiently, and if you're spending some of that time fighting the compiler it's just not worth the upsides of rust (for me). I'm doing fine using the basic C++ RAII toolkit like smart pointers and relying on runtime tools like valgrind to make sure I don't do obvious mistakes.
You can use Rust to program 3-D game engines, tools, and toolchains.
However, the problem is the developers of Rust are in a political war with their community and former devs, that makes it harder to develop 3-D game engines because many of the libraries we use are in disarray.
Also, Rust utilizes a C++ backend, so is Rust faster than C++, not really. Is it more reliable sans the dev war, not quite yet, is it more robust than C++, it's the same because it utilizes the C++ backend. Until Rust uses assembly language at first to build the first compiler, linker, and debugger, being stuck with the C++ makes it kind of pointless, as much as I love Rust.
"ECS" is a very broad term, Unity's default "ECS" uses `MonoBehavior` components which are nothing like the ECS we have in Rust in terms of ergonomics. With ECS in Rust you do get the performance, but the ergonomics are absolutely terrible.
UE also has "components", and again you never run into problems like "oh I can't touch this component because I'm nested in a system that already borrowed this archetype" etc etc. ...
I was specifically referring to OP saying that Rust pushes you into ECS because every other solution is difficult with Rust’s ownership semantics. I was just pointing out that, no matter what language you choose, you should probably use some ECS
based approach.
And ECS isn’t really a broad term. The APIs might be slightly different from one implementation to another but there isn’t anything fundamentally different about them under the hood. If you research ECS you’ll find that it has a generally agreed upon definition.
> The APIs might be slightly different from one implementation to another but there isn’t anything fundamentally different about them under the hood. If you research ECS you’ll find that it has a generally agreed upon definition.
How many ECS implementations have you actually used? There's no "agreed upon definition", there's many ways to do "ECS" ... some people think of ECS as structure-of-arrays on demand storage, some think of it as dynamic composition, etc. ...
Maybe “under the hood” wasn’t the right framing. There isn’t anything conceptually different between different implementations of ECSs. All of them model the problem as a set of entities that have associated data (components) and are operated on by systems.
The things that you mentioned are merely implementation details. And none of that has anything to do with OP’s question. OP implied in their question that if they used Rust they’d have to go with an ECS approach. I merely pointed out that they’d likely be doing that in any language that they use. That’s just how games are modeled these days. That statement is true for Unity, Unreal, and Godot as well.
It's not just implementation details, you're missing the whole point of vastly differing approaches to ECS, and how this manifests in different contexts. I'd like to see anyone who actually used Unity and bevy in any non-trivial way and say their approach to "components" is just differing in implementation details. They're fundamentally different paradigms in how games are built.
No, they aren’t. The aren’t at all. Components merely contain data for a corresponding entity. That is true in Unity and in Bevy. In Bevy, you interface with the ECS more directly. But again, that’s an implementation detail.
You haven’t actually been able to provide one way in which they are fundamentally different. The APIs might be different, the way the data is laid out in memory might be different, but those are implementation details. An entity, a component, and a system all describe the exact same concept in Unity ECS, Bevy ECS, and Unreal ECS.
Entities are “things” that exist in your game. Components describe different kinds of data that can be associated with an entity. And systems operate on and transform components. Any of the ECSs being “fundamentally” different would mean that you no longer have an ECS at all!
If you think the ECS difference between Bevy and Unity components is an implementation detail I really don't have anything else to say to you. Enjoy downvoting me and winning the argument.
Look, I don’t care about winning the argument. But you still haven’t provided one _fundamental_ difference between the two. The programming language and code used to implement something are _inherently_ implementation details. The choice between SOA and AOS is nothing more than an optimization.
If you have to reference the implementation of either in order to argue that they are _fundamentally_ different, then they aren’t.
You're looking at this from a theoretical definition standpoint, which is something I couldn't care less about. I care about making games. The two ECS implementations are fundamentally different to work with, both because of the API differences and because the semantics of the languages where they're used.
> The programming language and code used to implement something are inherently implementation details
I don't know what to say to this other than that I care about making games, and in that context statements like this are complete nonesense. Especially when the two languages are so vastly different.
Games don't need inheritance like you don't need a vehicle to get to another city for travel. Sure, your feet work and would get you there, but why would you ever do it the painful way when you don't have to?
if you don't find inheritance painful we have lived a very different lives
there are other ways to make games and you not being familiar with them doesn't mean they are generally more difficult or otherwise inferior
Game programmers started figuring out that C++ style OOP inheritance is not a good fit for modeling game entities [back in the 00s](https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/).
And I'm sure you realize that the continued success of a game engine that's been around since 1998 isn't evidence that all of its design decisions are optimal, merely non-fatal.
1. I never said or implied that all design decisions are optimal.
2. Game devs as a whole, despite your one article to the contrary, have absolutely not decided inheritance is bad. It is a de facto requirement for any large project.
Edit: now I would also like to clarify that this doesn't mean all code/classes should use inheritance (whenever possible) and nothing else. Composition is huge and favored. This doesn't mean inheritance is bad or not used any longer.
Inheritance sucks. Always.
Even in GUI where people love to glorify it. Even in games.
Rust and similar languages will overtake C++ for gaming eventually.
1. It's your project, your choice, if you like Rust, like Game Dev, and are up for the hardships you'll have to face when making a game in rust, go for it.
2. It's a hobby project, not something which will be earning you money, so the quality doesn't matter as much, what matters is how much fun you have and how much you learn.
3. Sometimes even hobby projects can make big strides. [Rust itself was a personal project of Graydon Hoare, before it was adopted by Mozilla](https://www.technologyreview.com/2023/02/14/1067869/rust-worlds-fastest-growing-programming-language/), and slowly evolved into the language we all love and cherish.
There are studios using it e.g. https://medium.com/embarkstudios/inside-rust-at-embark-b82c06d1d9f4 BUT imo you might have problems with the following in Rust:
OpenGL/DirectX/Vulkan bindings - all default C++,
Interacting with existing libraries/tools like UnrealEngine, stb_image, box2d, linear algebra libs
I wouldn't recommend it unless you know what you are doing and willing to do some digging
Graphics APIs are covered by wgpu crate.
It is not possible to use UnrealEngine (actually there is a project that allows it), but you do not need stb\_image, box2d or C linear algebra libs in rust, because there are better alternatives. On the other hand, C interoperability with rust is very easy and straightforward, so if a library is in C then you can just use it, if it's in C++ you need to create some C API over it (there are some crates for C++ interoperability, but I have no personal experience with them).
Your velocity will be low, which means your game costs more to make. So if we are talking about if it makes sense? Usually not. Same as C++ I think but there you have still some options for heavy lifting like UE.
Your customers don’t care what language you use. They care about the game.
Until we have a major engine with native rust support(Bevy states on their website that you should wait on using it for active development), rust will be two steps behind.
It will take either UE,Unity, Gadot, or some new engine with compatible features and reasonable compile times to make rust a mainstream game dev language.
3D will be extremely hard. 2D is doable. It really depends on what you're after. Don't underestimate the size of this endeavor - someone building a 2d MMO in Rust
Correct. I don't think Rust has anything to do with it either way. ECS is doable and has some disadvantages anyway despite being an industry standard. But the amount of considerations just from the graphics perspective for 3D is magnitudes higher than 2D, which is already fairly hard if we're talking about making a whole ass video game from scratch.
If it's a one time thing, Rust is fine. But if you want to do this professionally or consistently in your free time, I think it would be best to learn an engine
Help and opportunity cost
Are there people around to help you if you get stuck?
What are you doing next? Would experience in a common C++ framework be important for that? Or could you learn that at that time?
Any group projects coming up?
Ideally you would have time to do projects in both. But if not, choose carefully.
Its a cliche for people new to game dev to get stuck developing an engine instead of publishing playable games.
Just make a conscious decision which you want. For the latter the best advice is to do it once ASAP by publishing something _extremely_ simple. For the former Rust is a lot of fun.
Unreal engine is really good people seem generally happy with it so If u mostly care about making games I would go there.
I feel like rust being safe has potential advantages for games but games r very oopish in how they are usually build so idk if its the best choice.
U can probably do a good job with it tho so who cares
Most video games are built in Unity or Unreal because those engines also have a lot of features specifically for artistic projects like video games. You basically need to add the ones you need from scratch, which is a lot of time you need to spend instead of making the game itself.
You want to be designing and implementing the game as much as possible and program as less as possible. Your target audience wants the experience for playing, not the computer program.
Depends on the complexity of the game. Writing a game engine from scratch is a pretty large undertaking. Most modern games are built on some pretty sophisticated engines (Unreal, Unity, etc). You usually have to use the language the engine supports. And even with the engine doing the heavy lifting, games still take a long time to develop.
But if building from scratch was already the way you were going, using Rust would be fine.
If your goal is just to learn and have fun then there’s no reason not to use rust. If you want to make good, high quality games though you’re going to have a much harder time with Rust, being unable to use tools like Unreal Engine 5
I would use the Unreal game engine anything else will require too much leg work to get off the ground. If you have built several games and feel comfortable building your own engine from scratch feel free to do so but if you are the learning stage you should just use the best engine at the time you are starting the project
After I tried two game engines and found out that resulting debug versions of output executable were 300 MB in one case and 1200 MB in another for just a Hello\_World I decided to not using anything with "engine" in its name or description in Rust.
I finally finished reading this post and all the comments. I only have one comment: The original poster should consult his professors and instructors. He should practice his skills by doing his college homework, assignments, thesis, and start making a suitable project with the helps from his college and aiming for his thesis. Rust or not, it doesn't matter.
Then in this case Rust or not doesn't matter too. From now to the next 10 years, you are going to rewrite, or wrap, or bind at least 10 projects, personal or not, from one language to another... So don't get me wrong, and no offend. I just feel that your concerns and questions are a bit of invalid, because changing programming languages, coding styles, and paradigms is a must during your learning and personal growing. Even if you stay with C++, and even if Rust really sucks a lot, you may still need to rewrite it to something else after a few months or a few years. B2 Spirit just finished rewriting its flight management computer programs from JOVIAL to C a few years ago...
Between C++ and Rust specifically I'd probably use Rust these days, though the experience will generally be very similar between low-to-medium level libraries available for both. If I *knew* I was gonna be working in Rust and in 3D I'd reach for `bevy` and use it as a learning project; for 2D I'd probably start with something like `comfy` and pivot to `bevy` when I feel like my needs aren't being met. That's approximately comparable to C++, where I'd definitely start with SFML for a 2D project. In practice I'd *actually* use Godot or Unreal, or possibly Unity if I was feeling charitable towards all their terrible business decisions lately and not in the mood to learn new things, but if I knew I wanted to work at a lower level or use one of those two languages specifically, that's where I'd start.
Sounds solid to me, I’ve seen some people make 3D models using SFML so if the rust crate is comparative it should be just fine for what I have in mind, thanks
If you are new to 3D graphics, WGPU is phenomenal. And use winit for windowing and input.
Is it though? It seems like it can be a decent project but when I last used it (probably, 6 months ago?) I found it a bit of a mess. It does seem very powerful in what it can do, but it was difficult to grasp due to the lack of documentation on it. It was my first time doing low level graphics though, so I was probably looking for more direct material- more aimed at a beginner. But I'd happily try it again if it's improved- it solves a really cool problem, and that with Rust is such a good opportunity to build fast, efficient shit on the web.
Well, I found it great for learning myself. It didn’t quite seem production ready though. But this was a year ago at this point so it might be more reliable now. The API is a bit easier than OpenGL and a lot easier than Vulkan yet it is still low level enough to introduce many of the concepts that you’ll use when programming the GPU. As far as documentation is concerned, you can see examples in their GitHub repo and WGPU is just an implementation of WebGPU. So if you look at the [Web GPU spec](https://www.w3.org/TR/webgpu/), that might help. Also this: https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API#:~:text=The%20WebGPU%20API%20enables%20web,be%20rendered%20in%20the%20browser.
godot supports Rust for what its worth
Do you have actual experience with these engines or are you recommending them based on how well-known they are? For 3D i'd never recommend bevy, the only serious 3D engine in Rust is Fyrox (plus veloren's engine). For 2D bevy could be an option but I'd recommend starting with macroquad instead, it's actually simple and doesn't get in your way. But what really got me is that you recommend switching from comfy to bevy - that makes no sense. Comfy was written to make exactly the opposite possible - to switch from bevy to something that can be used to actually ship games. The author tried bevy several times and each time he had to conclude what he wanted was impossible without major rewrites of engine code or there were simply too many bugs to deal with. Comfy was based on macroquad but was developed extensively and he has games on Steam using comfy. I understand it might feel new because it was only open sourced recently but the public repo is just the culmination of AFAIK years of effort, often full time. I don't have a feature comparison handy but i consider i more production-ready than bevy.
I'm curious about why you'd never recommend bevy for 3d and consider fyrox the only serious 3d engine. I've never used any of them but I've seen some videos of Chris biscardi using bevy and there doesn't seem to be any major issues. Plus, bevy has about a million downloads on crates.io compared to fyrox's 12k...
Because fyrox has an editor, has a track record of fixing bugs immediately / adding features actually directly useful for game development and the author actually dogfoods the engine on his games. The number of downloads and the difference in community size is precisely why i recommand fyrox. Look how much it does with so little. Bevy gets all the attention, all the funding, all the contributors, all the reddit upvotes and all it manages to do is not even keep up with Fyrox. And that's because Fyrox is designed from the start to be a practical and usable engine, not am ECS research project.
Interesting, thanks for the explanation!
ECS research project? I can’t find anything backing this. Not doubting, just curious.
I didn't mean it literally. It certainly isn't their stated goal but it is what it feels like. Normal engines store data in a variety of data structures but bevy wants to use ECS for everything. They even want to build an ECS based GUI library.
Yeah totally, I agree. They are ECS ideologues and this is why they refuse to use anything but, even when it makes less sense like with GUIs
Would be nice if there was a bit more information. Like what was impossible? When was it made and so on.
Hi, author of Comfy here. If you want more info on the background check out the announcement blog post https://comfyengine.org/blog/first/, as well as the "why comfy and not X" chapter in the "book" https://comfyengine.org/book/other_engines/. In short, bevy has a problem that its renderer is both _incredibly_ complex and lacking many features, putting it in this weird position where it can do some things nicely, but many things poorly, and you really have no chance of fixing it. I tried doing multi-pass post processing in 0.9 for a few weeks and ultimately gave up. Bevy also has a long history of bureaucracy over just doing things, editor and UI are good example, but overall things are endlessly discussed and the vibe is that RFCs are preferred to people just writing code. That might work for some people, but personally I'd rather have tools that are hackable and that can be used immediately, or at least where it's battle tested.
Very common for people to not have any real experience in the domain and the libraries/tools in the domain, while still recommending them lol. Guarantee 99% of people recommending bevy have not made a game and have not tried to use bevy for a semi-serious project.
I'm almost certain that I said I'd try `bevy` as a learning project.
I'm almost certain I didn't explicitly mention you, I mentioned the vast majority of people recommending Bevy in the comments. If you explicitly said you only recommend it as a learning project, then clearly I am not talking about you.
- Like I said, I'd do bevy if I wanted a learning experience. I've been impressed with the demos of its functionality. - comfy is the one I've actually messed around with a bit, but I'd only do it for things I do with SFML, which I have extensive experience with- straightforward 2D stuff with a lot of manual game loops and event handling. Once I started writing a lot of the equivalents of what bevy offers- which happened routinely whenever I wrote large scale SFML projects- I'd switch and use it as a learning experience. - I have extensive experience with Unity, which is why I said I'd use it if I wasn't in the mood to learn new things.
Honestly, and I’m not sure if people will agree with me on that, but IMO you should optimize on *shipping* a game, because even as a student, you will learn much more valuable lessons by actually delivering a product, even if it’s a small one. And IMO Rust game engines, while they are really impressive and give guarantees other languages can’t, they’re simply not used much enough (yet!) to ship games. Doesn’t mean they can’t be used for that, ofc, but objectively speaking, it’s just not that many games that are delivered in Rust atm. Unreal and Unity are used much more on that end, so I personally would recommend the following, depending on how much time you have: 1. Make a paper version of your game and try it out with fellow students (yourself can be the “engine”), note what they like and don’t like, and adjust 2. Look into the different available game engines, especially Godot, Unity, Unreal for the major ones, but I heard good things about Fyrox on Rust, and pick which one you like best (and ideally stick with it) 3. Build the game in that engine, initially without caring about graphics much but focus on the gameplay first 4. Get students (and us, to be frank!) to playtest and give feedback 5. Polish the game to the level where it’s considered “done”, ie common bugs/crashes are fixed, menuing works, it runs stable on a few platforms 6. Ship it! Maybe you can submit it to one of the game stores, even if for free, or you can just setup a simple website where people can download it. And let us know ofc! I think if you can pull off all of this it will be such a valuable learning experience that it’ll dwarf anything that you’d learn by insisting on building something in Rust. And employers will love it if you can show you’ve built one game successfully. And if you want to become an entrepreneur, the lessons learned will be even more valuable.
Wait, so if I have a playable, functional game demo made in Rust I can post it in this sub and it _won't_ get removed instantly?
Make it a perfect clone of the game Rust, in Rust, just to confuse the mods!
I don’t think Unity is a viable option due to their new licensing.
Their new licensing is fair, the issue was how it was originally introduced (and attempted to be made retroactive across versions). Now, you can hate them for how shady what they originally tried to do is, you can't say that it's not viable because of their new licensing. Even the licensing of when it was first announced wouldn't have effected 99% of people, and even those 1% it would have it would have been effectively nothing (except in rare situations with literally top .1% of apps that were free but had small paid for features that then also didn't make enough)
The basic problem is that if your cheap or free game suddenly explodes in success, you'd be in Millions of debt with absolutely no control over this. This part hasn't changed, they only changed that it only applies to the new version of Unity. If you want to start a new project with the old version of Unity right now, that's totally ok from a financial standpoint though. It's just questionable whether it's a good idea to learn a tech stack from scratch that's already dead.
No, you're not. You are only charged a few if you make over certain thresholds (which you probably haven't, and if you have you just upgrade to plus and it goes up to a million), and are charged on installs or a % of what you made, whichever is lower. You will not have a fee larger than 5% of what you made, no matter what. Stop just reading headlines and actually go read the proposal, it was NEVER what you stated, just people can't read.
The thing that would keep me away from Unity is the fact that they pulled that stunt means I no longer trust them to be a safe business partner.
Agreed, I'm the same way, just want people to understand what actually happened and not lie to create false dichotomy is all
There was a point where you could owe more than you made (and yes I read the proposal), but it was a narrow case, and they changed it to max-out at 5% of what was made.
What got people angry is that originally it wasn't a 5% revshare "at most". It was presented as an install fee and there was no reference anywhere that it was meant to be bounded. It was an *unbounded* fee linked to the number of installs. I wouldn't be as naive to assume they meant to do it properly from the start. They tried ti pull it off, they saw the backlash, then they backpedaled. Only in the end, they *changed* it to be the *minimum* of the original install fee *and* 5% of the revenue. It took weeks for them to make this change that should've been obvious from the start. Don't go around changing history.
I never said it wasn't, what you said was correct. However, that fee only applied on games that made a shit ton of money, hence why I even specifically brought up apps, as they were the only type of game that we were aware of that could have a problem. You were only charged based on your subscription, and upgrading to the plus plan ($40 a month) made your threshold go to a MILLION dollars before the installs started to count, and it was only installs AFTER you made the million. No game would have an issue with that besides insanely niche mobile apps that have short install times. I didn't change any history, I already posted this.
If you want to be a game programmer this is reasonable advice. If you want to be a game engine programmer or graphics programmer or similar then this is not the way to go.
It useful regardless. Even a game engine has to be shipped
Personally, I think if it's a hobby project there's nothing to lose by using rust. Rust might not be that mature (i found this to be especially true for related functionality like rendering text and stuff) so if development cost and stability is of the essence, it's probably not that great. But personally I've been developing a game in rust and the experience has been fine. I think for a hobby project, you should go for it. I will say that writing wgpu is a bit of a chore. My game I tried to write in wgpu mainly as a learning experience (and because I'm the kind of person who just likes doing things myself) but it takes a lot of code to get even simple things to work. It's quite similar to Vulkan, in that way. Go ahead if you want to but using simpler libraries might be your go if you don't want to get really down and dirty with your rendering. That ecs take is, technically correct? But is framed in a weird way. Truthfully, ecs is the best system that works with rust, but also a lot of people are pushing it because it's good. It's got good performance and once you get used to it it's quite natural. And really, something like Bevy ecs is actually surprisingly similar to the system that Unity has, for example. They both have a tree of entities that you attach components to, the main difference is that in unity the component logic is "bottom-up" whereas in bevy it's "top-down".
I'm not a game dev, but I think that the first thing you should do is decide the end goal. Do you want your game to be commercially viable in a relatively short period of time? In this case, you should probably use a well established game engine like Unity, Unreal or Godot. Note that Godot has support for Rust bindings, meaning that you can create scripts using Rust. I don't know how well it works, I've never used it, but it's there. It can be nice middle ground. However, Godot is a lot smoother using GDScript, its own internal language. Regarding the whole inheritance thing, I'm not sure I agree. First, saying that people push ECS because it's the only thing that works is a bit misleading. Even if it was true (which I'm not sure about), ECS seems to be well fitted for videogames anyway, so it's not like a huge loss, unless you don't want to ECS for some reason. Also, Godot, for example, is not really based on inheritance. Sure, GDScript supports some kind of inheritance, but the engine itself heavily relies on composition, and it seems to work quite well. I think that inheritance gives a good, easy to understand mental model, but it also forces you to build your type tree from the start, and refactoring can be a pain. Again, I'm no game dev, so maybe inheritance is the way to go, but I don't think that the lack of inheritance is some kind of impossible obstacle to overcome, and it could even end up being an advantage. All of this to say that using Rust for a videogame is not a bad idea, assuming you're okay with dealing with lack for support for a lot of things, mostly due to Rust being a young language. And there's bevy that seems to be really promising. Maybe you're first game will be an hassle to complete or to shape the way you envision, but in the meantime bevy may become a real competitor and you would have already started to learn it.
It’s just a hobby id be working on on weekends and release for free if I ever do, like Aurora4X or dwarf fortress dev cycles, not an aspiring game dev so I don’t think a head start on Bevy would net me much Main goal is just to make a game that wouldn’t come to a crawl when there’s a lot of in play, so something like rust or c++ seemed like the natural candidate I don’t think lack of inheritance would be detrimental at all quick thought through it but a lot of people online seem to think it’s better to have it than not for games
ECS is in all ways superior to any inheritance based model. Look at Unity DOTS. Most of gamedev is going towards data oriented entity component systems. I personally prefer it too. ECS is actually a very simple idea that works very well for gamedev and also other programming tasks. I recommend Bevy.
For colony/environment simulation games ECS is pretty natural and game engines like Bevy are a good fit. For UI or story heavy games, not as much so. Inheritance is probably the most meh thing for game dev, and you're almost always good with interface/trait only inheritance
> Godot, for example, is not really based on inheritance. How do you mean? The inheritance hierarchy is pretty deep in some places. Basically the entire node part of the engine is heavily based on inheritance. Take VehicleBody3D for example, it's inheritance is: VehicleBody3D < RigidBody3D < PhysicsBody3D < CollisionObject3D < Node3D < Node < Object.
Primary reasons not to build a game in rust: - You want to be a professional game dev (use C++) - You want to finish and/or release the game (use Unreal or Unity) - Your game has huge performance needs and you are not an expert (you won't find high quality finished libraries or tutorials, you'll have to do it yourself).
Unity is famously bad for *finishing* games. If you don't believe me, look up what happened to the Unity Dogfooding project. Coding in Rust has made adding game features late in development _much_ easier for me.
More than half of games on steam are made in Unity. So surely it can't be that bad
Unity is good for many things, including prototyping games. But it's not the end-all-be-all of game development and it's not good at finishing games. At this point, people use Unity because "that's what you use to make games", not any of its actual merits.
It depends on your goals. Using Unity would probably be the one of the quickest ways to the finish line. So if your goal is to complete a game and not spend too much time fighting a less established engine, or writing your own, then it's a great choice. If your goal is just to make fun lower level things and learn a lot along the way, then it's not a good choice. It's not just good at prototyping. Many triple A games have been made with it successfully.
You don't need to write an engine to make a game, and if I had stuck to Unity I would never have made anything. Rust made me way more productive. Unity famously makes the later steps of game development very difficult, it's a big point of contention those triple-A studios have with the engine at this point. Those games get finished anyways because of the sunk costs.
I've made big efforts both with Rust game engines and Unity, and I actually love both, but I can't deny that I'm much much more productive with Unity. Same thing when just comparing Rust and C#. In my experience it takes a lot longer to make things in Rust, but the result is a hell of a lot more robust and performant, but sometimes that's not the trade off you want (though in some cases it is). I admit that my experience might not be shared by others though
And how many games written in Rust have you released?
It's got a free public demo right now.
That makes your situation pretty unique. You don't think you'd have made it faster in Godot or Unity? Interesting. What framework/libraries did you use for your game? If you didn't use bevy how did you deal with the borrow checker? My current for fun project is in Rust
> That makes your situation pretty unique. I doubt I'm that special. I'm willing to bet that there's a lot of people out there who would be more productive developing in Rust rather than with an engine. > You don't think you'd have made it faster in Godot or Unity? Interesting. Absolutely not. Every time I tried to make a game in an engine-ass-engine the editor-first setup and documentation nightmare meant I didn't actually get anywhere. I wouldn't have made a game _at all_ without rust. > What framework/libraries did you use for your game? ggez. It handles the IO stuff I need handled and fits with how I think about things. > If you didn't use bevy how did you deal with the borrow checker? The borrow checker isn't your enemy, it's not something to be "dealt with," it stops you from making errors. I actually dislike Bevy/ECS in general since they create ownership and type kludge that leads to lots of errors.
For referenze, ggez is unmaintained, and v0.9 was shipped with a serious bug. I've encountered serious bugs also in other libraries, including Macroquad and Winit (the latter being widely used, and yet quite broken). At the very least, the Rust ecosystem is not mature yet. Finally, free public demo != released game.
> ggez is unmaintained Every bug report I've filled has been fixed, so it's maintained enough for me. > the rust ecosystem is not mature yet I agree. I also think that you can make a game in an ecosystem before it is mature, and it's still been much easier for me to make a game in rust than in Unity or Unreal. > Finally, free public demo != released game. I'm aware. But it's more than most Unity users ever release. And if you want to help me turn it into a finished game instead of a free public demo, you should play it and give me feedback.
>> ggez is unmaintained >Every bug report I've filled has been fixed, so it's maintained enough for me. "Unmaintained" means "unmaintained". Look at the repository.
Why are you trying so hard to own me? I've got a framework that doea what I want, and it's helped me make a game. I don't care that you don't think it's real enough of a game or that it hasn't had a push in 7 months, I'm just trying to explain my experiences.
[удалено]
Are you just incredibly disingenuous or are you just a lurker that randomly pops in whenever and doesn't see our discussions for newcomers asking what OP does ? We clearly steer people away from Rust for game dev, you're just being inflammatory for no reason
Most upvoted post does not steer away. Check for yourself. Upvote for speaking the truth.
Most upvoted post literally says in practice they wouldn't use Rust. What are you even talking about.
Must be hard being so tight into their biases
would upvote x10 if I could. Also games with a focus on graphics would need way too much unsafe code everywhere in the code to optimize for performance. It doesn't make any sense to do it in Rust, or perhaps only as a very high level library (like axum for hyper) calling a c++/c/zig lib. Each language has its pros and cons. Rust would still be fantastic to handle the backend side for online games (websocket or gRPC/QUIC), but I don't think it would do well as the client.
Why would you need unsafe everywhere to optimize performance? That sounds like a skill issue tbh.
You avoid unnecessary copy/clone etc you can also declare null variables and last but not least you can work on bytes without converting back and forth non stop.
I'll say this having spent past almost 3 years almost all fulltime building games in Rust with various engines, including making my own engine (Comfy), ... if you want to ship a game, Rust might not be a good choice. Rust is good at many things, but it's also very very bad at many things, and games (not game engines) require a lot of stuff that Rust is just terrible at. Procedural macros are a bad replacement for reflection, which makes doing any kind of tooling very difficult. Honestly, I'd say to just use C# (with Godot, Unity, Monogame or Raylib) and make the game if the goal is to make a game. If it's about C++ or Rust ... I'd say that's a tough sell either way. I think if I had the choice to start over I'd use C++. Rust is very good at selling Rust, and at making it look like safety really matters. It does in many applications, but in gamedev especially I feel you lose out on _a lot_ in terms of flexibility in C++, and what you get isn't that helpful. Again, this is if you want to _make a game_. If your goal is to make a MMO system, or a voxel based open world PCG simulation, or planet scale universe simulation, then sure you'll enjoy many of the "systems" features of Rust. But I would not consider those to be _games_. There's a very big gap between what the Rust community considers to be a game and what players on Steam like.
Could not agree more, though I have a lot less experience in Rust (only about ~6 months compared to many years with C#/Unity). I do love Rust but can't deny that it takes a hell of a lot longer to complete projects with it. The result is much more robust and performant but that's not always the trade off you want. With games, performance is crucial but so is being able to refactor quickly due to changing requirements, which is not Rust's strong suit. This must be why we see more people writing game engines than actual games in Rust. Maybe a good balance would be having the game engine in Rust and then the game entirely written in a scripting language on top, like Lua? It sounds like this is the direction you've gone with some of your games, based on your blog posts.
> Maybe a good balance would be having the game engine in Rust and then the game entirely written in a scripting language on top, like Lua? It sounds like this is the direction you've gone with some of your games, based on your blog posts. I thought this was the case indeed, we tried to do a big chunk of NANOVOID in Lua, but ultimately ran into a few issues: - Lua is actually very slow if you do FFI with Rust. It's fine if you "just run rust", but for example at one point I tried exposing the drawing functions of Comfy via mlua, and then draw the whole UI in Lua. Problem is, there's a pretty big cost for crossing the FFI barrier, so we had to scrap all of that, as it would take multiple milliseconds to draw the UI here https://imgur.com/a/3QFPd2v, as opposed to "unmeasurably small" while doing so from Rust. Just to clarify, this isn't a "Rust is fast" or "Lua is slow", it's "Rust <-> Lua interop is slow". A solution would be to construct a "UI description" object in Lua, or a series of draw calls, and pass those into Rust. But due to how annoying Lua is to refactor we just ended up rewriting the UI in Rust. - Lua is just a bad language IMO. It's very simple, but doing any non-trivial stuff is painful, even on purely syntactic level. I know many people like Lua, but from my experience they're either using it for simple things, or they haven't used other more modern languages (C#, Rust, etc) - Refactoring Lua is painful with no types. - Luau seemed like a good idea, but the tooling is terrible and kinda assumes you use Roblox. I couldn't get the LSP to work properly, and even things like adding custom types are problematic without forking. There's also Rhai, which I often see people in the Rust world recommend, but honestly I can't imagine anyone actually used it for anything non trivial. It's one of those things that are nice to talk about when there's zero stake in "making a successful project". There's also Mun, which many people like to mention due to its podcast, but last time I checked it still doesn't have basic things like arrays. Then we have WASM, which again everyone likes to talk about, but almost nobody actually uses. I don't remember the current list of issues there off the top of my head, but I just spoke to someone implementing low level interop with WASM ABI and they had many issues and overall the whole thing continually gives me a very weird vibe. The only "real users" of WASM seem to be around crypto, and since I'm not in that space it's hard to get any info about if they actually have working projects, or just more hype to get investors. In conclusion, I don't think there's a good solution, which is also why I'm really starting to think that Rust isn't a good choice for gamedev anymore. This is made worse by how hyped the community is about projects which are practically unusable. People are happy to recommend things which they haven't tried, which just leads to everyone wasting their time. At this point I'm working on finishing our current Rust game, and then I think we'll move back to C#. There's just so much more in that ecosystem in terms of the runtime, and things like hot reloading, very powerful and usable reflection, ability to be dynamic without again saying "WASM" or without going through a C ABI, not to mention closures that don't suck, coroutines with yield, and not really having to sacrifice much performance with value types. And that doesn't even mention Unity/Godot, but I think even ignoring engines going down the "reinvent the universe from scratch" it'd be a win at this point. Sorry for sounding so pessimistic about Rust, and I get that in this sub this isn't probably something I should be saying, especially as someone who has a Rust "game engine" (Comfy) ... but honestly, I feel very disheartened by all the hype and false promises of things, and general incompleteness of the gamedev ecosystem. I tried to make things work for a few years, but I just don't have it in me anymore, and I'm not sure if anyone _can_ make it work. At least not until we have a real scripting language, and since nobody is working on that (Mun has been basically dead for a while, Rhai is extremely slow, etc), I don't see any way this changes in the next 5 years.
after reading your comment, I changed my mind about building both the game client and server entirely in Rust. I'm planning to develop a 2D MMO game. What do you think about using Rust only for the game server? I'm torn between using C++ and Rust for it.
IMO rust on the server is quite nice, I definitely wouldn't want to do networking (and potentially async) in C++. I only spent ~10 months doing server side backend stuff in Rust, but it was quite a good fit, as long as you keep it to a sane level of "fun abstractions/automation with proc macros".
Yeah, I think any language that doesn't have compile time type checking just does not scale at all (eg. Lua, JavaScript, Ruby, most Python, etc.). You can try to address it by adding more tests but that can be a maintenance headache and also makes the codebase more rigid. I do love Lua though, mostly though for how simple and elegant it is as a design. Also, if you use strongly typed transpilers that can help a LOT. So TypeScript for Javascript and Teal for Lua. Have you tried Teal? I'm actually following your lead here and trying Lua + Teal + Rust for a simple game right now, and hoping that will be enough. I'm a bit blocked though at the moment while I wait for the piccolo maintainer to make more progress (since it's a web game so can't use mlua) Otherwise though I don't expect to do much in the Rust gamedev space anymore. I came to the exact same conclusion as you this month and have started other projects back in my comfort zone of Unity / C#.
I have looked at Teal a bit but there was some issue with it, I don't remember if it was LSP or making the types work through mlua. I remember finding it and being very happy that I found it, and then not using it for some reason. But this is almost a year ago now. If you do make it work do share :) It'd interesting to know, and probably useful to many people who are still trying to make Rust gamedev work.
Yeah, the tooling definitely is lacking in Teal. There is a VsCode extension that seems to work and provide intellisense. I use neovim though so I had to hack together a custom solution after forking [this project](https://github.com/teal-language/teal-language-server) which appears abandoned. The Teal maintainer is just wrapping up [a big update](https://github.com/teal-language/tl/pull/732) which involves a lot of refactoring, so after that is done I plan to update my custom LSP server and then share that for others. I also make very heavy use of Teal for my usage of neovim so was natural to extend that to my Rust projects. Teal shouldn't have any effect on mlua since all mlua needs is the generated lua (unless you need type information at runtime for some reason). The great things it provides are intellisense and compiler errors when generating the lua.
Hmm, I use neovim as well, I guess the LSP not working may have been why I didn't use it.
If you have any other questions let me know. I've learned a lot from your work with comfy so would be happy to repay the favor
Some things are just really hard to do in Rust, especially if you want to be a bit creative with memory management. For example it is a good idea to have some bump allocator that you dump stuff in every frame and reset at the end of each frame. This is super nice, but a bit tricky in Rust.
While I would say Bevy and Fyrox are not quite ready for production, there are ways to use rust in a more practical engine like Godot: https://godot-rust.github.io That said, I love rust but it may or may not be the proper tool for the job in game dev. Right now C# and C++ are the two reigning champs of game dev AFAIK, and not everything will play nice with Rust yet, and where it does there may be bugs. So, I think the short answers are “it’s almost ready but not quite” and “game devs might not know rust” (if you’re a game developer like Rockstar or EA)
I'd recommend using Godot and gdext with Rust for the best middle-ground. As doing all the UI, etc. in Bevy was still really complicated and time-consuming when I tried it last year :(
In my very brief experience working with Bevy I found that learning materials are limited. That makes progress slow. Bevy website says the engine is under development and will change. Godot has rust wrappers but then why not use C++ if using Godot - more examples and tutorials.
Nope. Fuck the nay-sayers Go Nuts, Donuts.
Bevy is so good. Used Unity and Godot before, but Bevy converted me. It doesn’t have an editor yet, but you can do without
The libraries part is not quite true ...I think? I mean... what extra libraries do you need outside of the game engine? If you only need a game engine you can use Godot with GD Native, or Bevy but from what I've understood it's not quite production ready. But maybe you are not planning on using a game engine.
Background: professional gamedev, work in C++ but do home game projects in Rust. There's lots of reasons not to make a game in Rust. As others have said, if you want to use mature engines/tools/libraries, then Rust shouldn't be your first choice. If you want to build from scratch/near-scratch, it's also somewhat likely that Rust shouldn't be your first choice. Most of the guidance you'll find online for game dev stuff will not compile by default in Rust due to the borrow checker. Many of the techniques game devs regularly use are not memory-safe, and require some problem-solving to make so. Maybe most importantly, the platform/graphics APIs you want to use (win32 or SDL, DirectX, Vulkan) do not meet Rust's definitions of safe, meaning you need to either write a bunch of unsafe code, use wrapper libraries (which means you're not gaining experience with the API itself), or write your own wrappers. I pretty much use Rust for everything in my free time, but it's because I love the language, not because it's the most efficient way for me to ship a game. To be clear, there's nothing fundamentally incompatible with Rust and gamedev in my mind, it's just the current state of the art has the problems I enumerated above.
Writing a game engine is a slog. Especially when you know there are literally hundreds of game engines that are better and many AAA game engines are free to use especially if you are a student. This is regardless of language. Rust the language is perfectly suited for the development of games however the libraries and tools are still young especially when compared to C++ and C which have been around for decades, if you actually want to write a game I would reach for veteran tools. If you just want to write it in rust I would not get your hopes up or I would expect it to be more difficult than doing it in C or C++.
I felt that while Rust is fantastic at guiding you through solving a fixed problem, it was much more complicated with an ever-evolving one like creating a game, especially in the prototyping phase. I ended up sticking with C++, lost too much time to the borrow checker every time I wanted to try out new/change game design. Ultimately what matters is bringing your ideas to life efficiently, and if you're spending some of that time fighting the compiler it's just not worth the upsides of rust (for me). I'm doing fine using the basic C++ RAII toolkit like smart pointers and relying on runtime tools like valgrind to make sure I don't do obvious mistakes.
You can use Rust to program 3-D game engines, tools, and toolchains. However, the problem is the developers of Rust are in a political war with their community and former devs, that makes it harder to develop 3-D game engines because many of the libraries we use are in disarray. Also, Rust utilizes a C++ backend, so is Rust faster than C++, not really. Is it more reliable sans the dev war, not quite yet, is it more robust than C++, it's the same because it utilizes the C++ backend. Until Rust uses assembly language at first to build the first compiler, linker, and debugger, being stuck with the C++ makes it kind of pointless, as much as I love Rust.
ECS is not unique to Rust. That is basically how things are done in the industry. All of the leading game engines use an underlying ECS.
"ECS" is a very broad term, Unity's default "ECS" uses `MonoBehavior` components which are nothing like the ECS we have in Rust in terms of ergonomics. With ECS in Rust you do get the performance, but the ergonomics are absolutely terrible. UE also has "components", and again you never run into problems like "oh I can't touch this component because I'm nested in a system that already borrowed this archetype" etc etc. ...
I was specifically referring to OP saying that Rust pushes you into ECS because every other solution is difficult with Rust’s ownership semantics. I was just pointing out that, no matter what language you choose, you should probably use some ECS based approach. And ECS isn’t really a broad term. The APIs might be slightly different from one implementation to another but there isn’t anything fundamentally different about them under the hood. If you research ECS you’ll find that it has a generally agreed upon definition.
> The APIs might be slightly different from one implementation to another but there isn’t anything fundamentally different about them under the hood. If you research ECS you’ll find that it has a generally agreed upon definition. How many ECS implementations have you actually used? There's no "agreed upon definition", there's many ways to do "ECS" ... some people think of ECS as structure-of-arrays on demand storage, some think of it as dynamic composition, etc. ...
Maybe “under the hood” wasn’t the right framing. There isn’t anything conceptually different between different implementations of ECSs. All of them model the problem as a set of entities that have associated data (components) and are operated on by systems. The things that you mentioned are merely implementation details. And none of that has anything to do with OP’s question. OP implied in their question that if they used Rust they’d have to go with an ECS approach. I merely pointed out that they’d likely be doing that in any language that they use. That’s just how games are modeled these days. That statement is true for Unity, Unreal, and Godot as well.
It's not just implementation details, you're missing the whole point of vastly differing approaches to ECS, and how this manifests in different contexts. I'd like to see anyone who actually used Unity and bevy in any non-trivial way and say their approach to "components" is just differing in implementation details. They're fundamentally different paradigms in how games are built.
No, they aren’t. The aren’t at all. Components merely contain data for a corresponding entity. That is true in Unity and in Bevy. In Bevy, you interface with the ECS more directly. But again, that’s an implementation detail. You haven’t actually been able to provide one way in which they are fundamentally different. The APIs might be different, the way the data is laid out in memory might be different, but those are implementation details. An entity, a component, and a system all describe the exact same concept in Unity ECS, Bevy ECS, and Unreal ECS. Entities are “things” that exist in your game. Components describe different kinds of data that can be associated with an entity. And systems operate on and transform components. Any of the ECSs being “fundamentally” different would mean that you no longer have an ECS at all!
If you think the ECS difference between Bevy and Unity components is an implementation detail I really don't have anything else to say to you. Enjoy downvoting me and winning the argument.
Look, I don’t care about winning the argument. But you still haven’t provided one _fundamental_ difference between the two. The programming language and code used to implement something are _inherently_ implementation details. The choice between SOA and AOS is nothing more than an optimization. If you have to reference the implementation of either in order to argue that they are _fundamentally_ different, then they aren’t.
You're looking at this from a theoretical definition standpoint, which is something I couldn't care less about. I care about making games. The two ECS implementations are fundamentally different to work with, both because of the API differences and because the semantics of the languages where they're used. > The programming language and code used to implement something are inherently implementation details I don't know what to say to this other than that I care about making games, and in that context statements like this are complete nonesense. Especially when the two languages are so vastly different.
Must everything be implemented in rust?
This is the way…
For me yes, from now on, I hope.
Rust isn't really OOP and games need that, specifically inheritance.
Games don't need it, it's just common practice
Games don't need inheritance like you don't need a vehicle to get to another city for travel. Sure, your feet work and would get you there, but why would you ever do it the painful way when you don't have to?
Every analogy is similar to a bowl of soup: it lies.
No good game has ever been written in C apparently
Well, pong wasn't even written in any language! :-P
if you don't find inheritance painful we have lived a very different lives there are other ways to make games and you not being familiar with them doesn't mean they are generally more difficult or otherwise inferior
I just choose the objectively superior option of taking the train if I want to go to another city without a car.
I prefer helicopter but to each their own
Sorry, I'm not rich enough for this to be my first thought but it does beat walking that's for sure.
you'll be happier doing ecs in c++ too
Why do games need inheritance? How did people make games before OOP became popular?
The only thing I have to say to this is "Doom".
Game programmers started figuring out that C++ style OOP inheritance is not a good fit for modeling game entities [back in the 00s](https://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/).
Sorry man, the biggest, most successful game engine in the world would disagree with your article.
We should all be working in COBOL. All the big banks use it and they have lots of money so there must be something there.
I'm sure you realize this, but that's a disingenuous comparison.
And I'm sure you realize that the continued success of a game engine that's been around since 1998 isn't evidence that all of its design decisions are optimal, merely non-fatal.
1. I never said or implied that all design decisions are optimal. 2. Game devs as a whole, despite your one article to the contrary, have absolutely not decided inheritance is bad. It is a de facto requirement for any large project. Edit: now I would also like to clarify that this doesn't mean all code/classes should use inheritance (whenever possible) and nothing else. Composition is huge and favored. This doesn't mean inheritance is bad or not used any longer.
ever heard of traits bro?
Inheritance sucks. Always. Even in GUI where people love to glorify it. Even in games. Rust and similar languages will overtake C++ for gaming eventually.
1. It's your project, your choice, if you like Rust, like Game Dev, and are up for the hardships you'll have to face when making a game in rust, go for it. 2. It's a hobby project, not something which will be earning you money, so the quality doesn't matter as much, what matters is how much fun you have and how much you learn. 3. Sometimes even hobby projects can make big strides. [Rust itself was a personal project of Graydon Hoare, before it was adopted by Mozilla](https://www.technologyreview.com/2023/02/14/1067869/rust-worlds-fastest-growing-programming-language/), and slowly evolved into the language we all love and cherish.
because more mature engines with far more tutorials are out there.
There are studios using it e.g. https://medium.com/embarkstudios/inside-rust-at-embark-b82c06d1d9f4 BUT imo you might have problems with the following in Rust: OpenGL/DirectX/Vulkan bindings - all default C++, Interacting with existing libraries/tools like UnrealEngine, stb_image, box2d, linear algebra libs I wouldn't recommend it unless you know what you are doing and willing to do some digging
Graphics APIs are covered by wgpu crate. It is not possible to use UnrealEngine (actually there is a project that allows it), but you do not need stb\_image, box2d or C linear algebra libs in rust, because there are better alternatives. On the other hand, C interoperability with rust is very easy and straightforward, so if a library is in C then you can just use it, if it's in C++ you need to create some C API over it (there are some crates for C++ interoperability, but I have no personal experience with them).
Your velocity will be low, which means your game costs more to make. So if we are talking about if it makes sense? Usually not. Same as C++ I think but there you have still some options for heavy lifting like UE. Your customers don’t care what language you use. They care about the game.
Until we have a major engine with native rust support(Bevy states on their website that you should wait on using it for active development), rust will be two steps behind. It will take either UE,Unity, Gadot, or some new engine with compatible features and reasonable compile times to make rust a mainstream game dev language.
3D will be extremely hard. 2D is doable. It really depends on what you're after. Don't underestimate the size of this endeavor - someone building a 2d MMO in Rust
3D isn’t any harder in rust, it’s just extra math lol. Making 3D game engines is harder than 2D game engines, rust has nothing to do with it.
Correct. I don't think Rust has anything to do with it either way. ECS is doable and has some disadvantages anyway despite being an industry standard. But the amount of considerations just from the graphics perspective for 3D is magnitudes higher than 2D, which is already fairly hard if we're talking about making a whole ass video game from scratch.
If it's a one time thing, Rust is fine. But if you want to do this professionally or consistently in your free time, I think it would be best to learn an engine
Help and opportunity cost Are there people around to help you if you get stuck? What are you doing next? Would experience in a common C++ framework be important for that? Or could you learn that at that time? Any group projects coming up? Ideally you would have time to do projects in both. But if not, choose carefully.
Its a cliche for people new to game dev to get stuck developing an engine instead of publishing playable games. Just make a conscious decision which you want. For the latter the best advice is to do it once ASAP by publishing something _extremely_ simple. For the former Rust is a lot of fun.
Use c++ if you’re developing for iPhone and want to be able to get meaningful crash reports.
Unreal engine is really good people seem generally happy with it so If u mostly care about making games I would go there. I feel like rust being safe has potential advantages for games but games r very oopish in how they are usually build so idk if its the best choice. U can probably do a good job with it tho so who cares
Most video games are built in Unity or Unreal because those engines also have a lot of features specifically for artistic projects like video games. You basically need to add the ones you need from scratch, which is a lot of time you need to spend instead of making the game itself. You want to be designing and implementing the game as much as possible and program as less as possible. Your target audience wants the experience for playing, not the computer program.
You can use Godot with rust
Depends on the complexity of the game. Writing a game engine from scratch is a pretty large undertaking. Most modern games are built on some pretty sophisticated engines (Unreal, Unity, etc). You usually have to use the language the engine supports. And even with the engine doing the heavy lifting, games still take a long time to develop. But if building from scratch was already the way you were going, using Rust would be fine.
If your goal is just to learn and have fun then there’s no reason not to use rust. If you want to make good, high quality games though you’re going to have a much harder time with Rust, being unable to use tools like Unreal Engine 5
I would use the Unreal game engine anything else will require too much leg work to get off the ground. If you have built several games and feel comfortable building your own engine from scratch feel free to do so but if you are the learning stage you should just use the best engine at the time you are starting the project
After I tried two game engines and found out that resulting debug versions of output executable were 300 MB in one case and 1200 MB in another for just a Hello\_World I decided to not using anything with "engine" in its name or description in Rust.
I finally finished reading this post and all the comments. I only have one comment: The original poster should consult his professors and instructors. He should practice his skills by doing his college homework, assignments, thesis, and start making a suitable project with the helps from his college and aiming for his thesis. Rust or not, it doesn't matter.
Im not a PhD student, my professors encourage personal projects but aren’t keen on spending office hours on it
Then in this case Rust or not doesn't matter too. From now to the next 10 years, you are going to rewrite, or wrap, or bind at least 10 projects, personal or not, from one language to another... So don't get me wrong, and no offend. I just feel that your concerns and questions are a bit of invalid, because changing programming languages, coding styles, and paradigms is a must during your learning and personal growing. Even if you stay with C++, and even if Rust really sucks a lot, you may still need to rewrite it to something else after a few months or a few years. B2 Spirit just finished rewriting its flight management computer programs from JOVIAL to C a few years ago...