I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until the turn of the millenium, in the wake of Quake 3 (buoyed by the new features of C++98).

Why? Those kinds of game engines are enormous amounts of code, and there's little incentive to rewrite.

I do strongly disagree that we aren't ever going to see large-scale game development in Rust; it just takes time. Whether games adopt an engine is largely about that engine's maturity rather than anything about the language. Bevy is quite young; 0.13 doesn't even have support for animation blending yet (I landed that for 0.14).

100% this. As I say elsewhere in these threads: Rust is the language that Tokio ate. It isn't even just async viral-chain-effect, it's that on the whole crates for one async runtime are not even compatible with those of another, and so it's all really just about tokio.

Which sucks, if you're doing, y'know, systems programming or embedded (or games). Because tokio has no business in those domains.

Even there it's very problematic at scale unless you know what you're doing. async/await isn't zero cost, regardless of what people will tell you.

The main reason is that you can't ship that Rust code on PS5 in a sensible manner. People have tried, got useless toys to compile, but in the end even Embark gave up. I remember seeing something from them that they had moved Rust to server-only.

Argh I have the same issue. Sure if you write JS or Python you probably need async. My current Java back end that has like 5 concurrent users does not need async everything making 10x the complexity.

"AAA" titles are huge and/or high dev budgets. Even if a game is "starting from scratch" the engine development team are still likely taking code from previous projects to get started. Of course there are other factors. It could be a BIG RISK to move to another programming language when the team, despite frustrations, are already familiar with something else... like the perks C++ brings (you learn from trial-and-error)

Could you imagine learning Rust as-you-go... building a AAA title... and fighting the compiler? To me it is a huge risk!

That is my opinion.. but I am sure others will disagree. If there is anyone on (or did) a AAA title with Rust... I would be happy to hear more about it.

I am not saying it will never happen. Maybe a AAA title is currently in development in Rust. I honestly dont know. However, game developers... if they are looking into Rust... are also looking at Odin, Jai, or Zig. For gaming, I think they are better alternatives than Rust but (again) that is my opinion.

Now for smaller, indie games - the possibility of moving to Rust (or another language) is more likely. Likely a fair percentage have moved away from C++ now.

At one point the studio behind the Finals was writing game server code in Rust with an Unreal engine client. Not sure if that's true still

Can you please elaborate on this? I see a lot of similar concerns in other contexts too. Linux kernel's scheduler for example. Is it a throughput/latency tradeoff?

But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios that are researching and prototyping are working on.

C++ is not a popular language to implement the actual game in for all the reasons you list. It is too slow to compile and too rigid. The people who actually build the games, make them tick, are all working in visual scripting languages.

Rust is pretty good for writing PL interpreters (and similar tooling) too, actually.

There are a few game engines[0] for CL, but most of them seem to be catered specifically to 2D games.

[0] https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil...

That's the kind of code for which Rust-like languages shine. Rich type systems make it easy to change your mind about things and make large changes to your code with confidence.

(Whether Rust tooling is actually at a level to take advantage of that is another question)

Not a game developer, but each time I tried to make one not using ECS(or something at least similar in spirit) I quickly found myself not being able to proceed due to the sheer mess in the codebase.

How does one normally avoid that?

I'd love to see a language built around ECS. I wonder how nice it can be in a language syntax where ECS is the easiest thing you can do.

I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on...

  // 2024-02-01
  $ curl https://www.taleworlds.com/en/News/552 | grep "Fixed a crash that" | wc -l
  29

  // 2023-12-21
  $ curl https://www.taleworlds.com/en/News/549 | grep "Fixed a crash that" | wc -l
  6

  // 2023-12-14
  $ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a crash that" | wc -l
  101

Edit: Lol guys calm down with the down-vote party. I was counting crashes, not bugs:

  $ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a bug that" | wc -l
  308

Memory safety may or may not be important in games, but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal. Job queuing systems have been popular in gamedev for a very long time, and Rust's insistence on explicit declaration of mutability is a big part of the reason that "just works" in Bevy.

I adore Rust because it does all the things I remember being told to do in C, but without me remembering to do them: Error codes from all functions, Ownership models, etc. But those are not good reasons for me to use it for anything I wouldn't use C for.

The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that writing Rust is as fast as writing Go. Anyone having done more than a toy program in Rust and Go knows how wrong this statement is. The reasons are given in the article.

I'm not sure whether or not that's even useful in game development. I've never done any form of game development beyond some Chess game I programmed in my first year of CS 30 years ago. But I'm actually really curious as to why you've struggled with variable ownership, because I'd frankly like to improve our on-boarding processes even more for new hires.

> my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust

Rust has a cult and it's best not to pay too much attention to it. Don't get me wrong, we're seeing great benefit in not just using Rust over C/C++ but also replacing more and more of our C# and Python services with it, but it's a very immature language and like any other programming language it's still just a tool. If it works for you, use it, if not... Well, use something that does.

* name intentionally made to make people angry

Perhaps learn another language like Haskell, Swift, or Kotlin before Rust.

Get cargo-bloat, cargo-cache, and cargo-outdated.

Setup a memcache server and use sccache to accelerate Rust, C, and C++ compilations. It's not 100% but it's pretty awesome for things compiled at a stable build location.

Just like any platform, avoid dependencies wherever possible and use minimal crate features. Some Rust crates have an npm-like problem of dragging in zillions of dependencies.

So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?

Yeah, Rust definitely is not the only solution, or perhaps not even a good solution to this problem in the context of game development. But let's not pretend the problem itself doesn't exist?

Rust is not a good language for actually writing games, and the fact that it is being sold as such is really detrimental to it in my opinion, because it is holding the ecosystem back. Rust is being pushed as a language for game logic, so people try out and realize it isn't very good at that, and so they just give up on Rust in the game development industry at all and leave, understandably! If Rust were more strategically positioned, it could get a lot farther. Where it should be focusing in the games industry is on game engines, where flexibility and quick iteration and easy prototyping and being able to just reach out and directly touch and control things isn't as important, but where concerns like the clarity and maintainability of the code base, stability of the software, resource ownership and management, and eeking out every ounce of performance all become important, and so the type system and static analysis guarantees of Rust are actually useful.

This is where, I'm disappointed to say, I think things like Bevy and Amethyst have severely hurt the Rust game development ecosystem. They aren't really game engines in the traditional sense, they are more like game frameworks like Love2D except written in Rust: they force you to statically link your game code to the engine code, and write your game logic in the same language your engine is written in. This means that game developers who just want to quickly prototype game mechanics and want to be able to iterate on them in order to refine them are forced to use a language that is far too focused on correctness, safety, static verifiability, and concerns like that to actually be usable as a programming language, and worse, it forces them to compile their game logic and the entire engine together and link them together in order to build their actual game and test it, massively increasing the weight of the process and basically ruling out hot reloading or making your game independent of any specific version of the engine, or its license. It puts them between a rock and a hard place, between using some other ecosystem, or using a language that simply unsuitable for a game development.

I think the far better solution (one which I plan to very slowly feel out with my embryo engine project, which is born out of my frustration of looking at the existing rust game engines and feeling like they are all kind of lying about what they are) would be to stop with the vaporware and the hype with Bevy and Amethyst and such, and actually build a proper game engine, like they are promising to be but are not, that is its own separate pre-compiled executable that game developers don't even need to mess with at all, that picks up game assets and game code written in a more flexible, dynamic, language that's better for prototyping, and runs them, something like what Unity or Godot or even Gamebryo do. Only then will the rust game development ecosystem take off, because it will no longer be forcing a language that just isn't good for that on to people.

Ah... Starcraft. It's 200 supply per player (hero units take 0 supply, zerglings are 0.5, and the supply cost goes up to 8 for battlecruisers for example). The limit is enforced when building a unit from a building. Map triggers can grant units and you can exceed the 200 supply limit.

The technical unit limit for the map was 1700, and was later in fact extended to 3400 by Blizzard. The EUD emulator (part of the official SC Remastered) allows for online custom games to be played without any third party tools on the player's part. Certain limits like sprites can be bypassed with this tool (for map makers) https://github.com/phu54321/euddraft/blob/master/plugins/unl...

EUD started out as a buffer overflow exploit which allowed custom maps to patch the game client's code. It was later fixed by blizzard but re-implemented as an emulator (with some restrictions).

These are definitely things that enhance gameplay for custom scenarios. https://youtu.be/HEv_U9WV4PA?t=1541 (yes, that is a battlecruiser shooting nukes)

I've tried to write several different types of games using it (with Bevy) in the past three years, and it just feels like shoe-horning something in.

But the biggest complaint I have with Bevy is that with all the refactoring that's been needed with the Bevy version upgrades: getting the code to compile again after the version upgrades has normally been fairly easy - but it then often didn't work correctly, and I'd have to spend time debugging the ECS system to work out what was wrong.

i.e. the "if it compiles, it'll almost certainly work" bonus of generic Rust code totally seems to fall down within Bevy.

I obviously understand that it's an in-development framework, in its early days, so some of that's on me for choosing it, but still, it's been a very painful experience, and I feel I've wasted a fairly significant amount of time over the past few years attempting it.

That small scale was exactly why the game ends up being so much about micro, and while that may make it more competitive or interesting for spectators it makes it a lot less fun to play IMO. Total Annihilation and successors were a lot more fun, and a big part of that was not having arbitrary unit caps in a way that affected gameplay; expanding the limit from 500 to 1500 did genuinely make the game more fun.

What many overlook is that using Rust has very high costs, but the edge over alternative languages is often only marginally - depending on the use case of course.

Those costs of Rust get in the way of developing the actual product. You loose speed, efficiency, but potentially gain no benefit to the users of your product.

In my opinion this is a result of big mobs having poor performance. When players get to choose they seem to like having more mobs thrown at them.

This can also be limiting for interactable objects.

Does anyone knowledgeable here have a sense for whether there are any insurmountable roadblocks to bringing hot reload to Godot?

Even for database engines specifically, modern C++ is essentially as safe as Rust and significantly more ergonomic. Rust's safety features can't reason about the case when all of your runtime objects live in explicitly paged memory with indefinite lifetimes and no fixed memory address, which is the norm in database kernels. You have to write the same code to make handling these objects safe and correct in Rust that you have to write in C++. You can't use normal pointers and allocators for this even if you wanted to.

Rust's safety is designed more for normal dynamic memory applications.

  > I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns. Basically a better version of C such as a selective subset of C++ or a Golang without garbage collection.

There is a sweet spot : non-GC, with pointers (but bounded), inference, basic OOP + tacking, and all the comforts of scripts. All in a good looking syntax without semi-colons.

So you can program fast and get a fast program.

But to go back to our subject: Rust is a great language and that’s all you need. I wish I could use it with unity.

It's not though. There's only one thing Rust is opinionated about.

> that wants everybody to program in a specific way that emphasizes memory safety above everything.

Well yes, that is literally the core proposition and purpose of the language. That's like saying java is opinionated because it wants to manage the memory.

> I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games

As soon as games are networked it starts being a problem, and these days non-networked games are pretty rare.

Sounds like Common Lisp or OCaml would work well. With Ocaml I find myself being able to iterate extremely quickly because of the inferred types and extremely fast compilation times. You also have the ability to tweak the GC to your needs and the assembly is easy to read.

Lisp is well… built for interactive development

Prototyping is certainly necessary but it shouldn't be at the cost of runtime performance – at least not too much –, because it will typically be very difficult to improve performance after the fact, which web development frameworks, and in particular shitty "web" applications like MS Teams are a testament to.

As always, it's about balance.

It should be but current state of web will show you that it is often not.

To clarify, Rust isn't against state at all. Rust bends over backwards to make mutation possible, when it would have been far easier (and slower, and less usable) to have a fully-immutable language. What Rust is against is global mutable state, and an aversion to global mutable state isn't a religious position, it's a pragmatic position, because global mutable state makes concurrency (and reasoning about your code in general) completely intractable.

I think FP is a great way to program actions and agency but OOP is a great way to model the world. I like Rust's trait system because the polymorphism is based on what you want an object to do not what it is. But when you're creating models of the world it's usually really convenient and even accurate to use nested inheritance models. Maybe the original system for this is the flora/fauna taxonomy but it applies to a lot of things; like GUI elements or game models.

If this is correct, it might explain why the discourse is so polarized. Whether OOP is a blessing or a curse probably depends on whether you're using a programming language as a modelling language or as a logic/execution language.

And now, the most popular generally available game engines right now are: Unity - C++ in the engine, C# for game code Godot - C++ in the engine code, GDScript or C# for game code Unreal - C++ in the engine code, somewhat mangled C++ for game code BUT with also one of the most capable and widely used visual programming setups I have ever seen

I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.