Yes, based on a few attempts chronicled in articles from different sources, Rust is a weak choice for game development, because it's too time-consuming to refactor.

▲

bakugo 5 days ago | parent | next [-]

There's also the fact that a lot of patterns that are commonly used in game development are fundamentally at odds with the borrow checker.

Relevant: https://youtu.be/4t1K66dMhWk?si=dZL2DoVD94WMl4fI

▲

simonask 5 days ago | parent [-]

Basically all of those problems originate with the tradition of conflating pointers and object identity, which is a problem in Rust as soon as you have ambiguous ownership or incongruent access patterns.

It's also very often not the best way to identify objects, for many reasons, including performance (spatial locality is a big deal).

These problems go away almost completely by simply using `EntityID` and going through `&mut World` for modifications, rather than passing around `EntityPtr`. This pattern gives you a lot of interesting things for free.

▲

bakugo 4 days ago | parent [-]

The video I linked to is long but goes through all of this.

Pretty much nobody writing games in C++ uses raw pointers in entities to hold references to other related entities, because entities can be destroyed at any time and there's no simple way for a referring entity to know when a referenced entity is destroyed.

Using some sort of entity ID or entity handle is very common in C++, the problem is that when implementing this sort of system in Rust, developers often end up having to effectively "work around" the borrow checker, and they end up not really gaining anything in terms of correctness over C++, ultimately defeating the purpose of using Rust in the first place, at least for that particular system.

	▲	simonask 4 days ago \| parent [-]
		Can you give an example of what problems need workarounds here? The benefits seem pretty massive, at least on the surface. For example, you can run any system that only takes `&World` (i.e., immutable access) in parallel without breaking a sweat.

▲

Defletter 5 days ago | parent | prev | next [-]

Yup, this one (https://news.ycombinator.com/item?id=43824640) comes to mind. The first comment says "Another failed game project in Rust", hinting that this is very common.

▲

ramon156 5 days ago | parent | prev [-]

We've only had 6-7 years of hame dev in rust. Bevy is coming along nicely and will hopefully remove these pain points

▲

flohofwoe 5 days ago | parent | next [-]

"Mit dem Angriff Steiner's wird das alles in Ordnung kommen" ;)

As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s. 6..7 years is a long time, and a single engine (especially when it's more or less just a runtime without editor and robust asset pipeline) won't change the bigger picture that Rust is a pretty poor choice for gamedev.

▲

eru 4 days ago | parent [-]

> As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s.

Did they? What's your evidence? Are you including consoles?

Btw, the alternatives in the 1990s were worse than they are now, so the bar to clear for eg C or C++ were lower.

▲

flohofwoe 4 days ago | parent [-]

I was there Gandalf... ;) Console SDKs offering C or C++ APIs doesn't really matter, because you can call C APIs from C++ just fine. So the language choice was a team and engine developer decision, not a platform owner decision (as it should be).

From what I've seen, around the late mid-90's, C++ usage was still rare, right before 2000 it was already common and most middleware didn't even offer C APIs anymore.

Of course a couple of years later Unity arrived and made the gamedev language choice more complicated again.

▲

pjmlp 4 days ago | parent | next [-]

As another Gandalf, Playstation 2 was the very first console to actually offer proper C++ tooling.

That would be 2000, until then Sega, Nintendo and Playstion only had C and Assembly SDKs, even the Playstation Yaroze for hobbists did get released only with C and Assembly support.

PC was naturally another matter, especialy with Watcom C/C++.

▲

eru 4 days ago | parent | prev [-]

> I was there Gandalf... ;)

You were at most in one place. My question was rather, which corners of the industry are you counting?

However you are right that one of the killer features of C++ was that it provided a pretty simple upgrade path from C to (bad) C++.

It's not just API calls. You can call C APIs from most languages just fine.

	▲	flohofwoe 4 days ago \| parent [-]
		My corner of the industry back then was mostly PC gamedev with occasional exploration of game consoles (but only starting with the OG Xbox. But that doesn't really matter much since it was obvious that the entire industry was very quickly moving to C++ (we had internet back then after all in my corner of the wood, as well as gamedev conferences to feel the general vibe). id Software was kinda famous for being the last big C holdout, having only switched to C++ with Doom 3, and development of Doom 3 started in late 2000.

▲

pizza234 2 days ago | parent | prev | next [-]

The articles describe how the problem is inherent in the language.

If we exclude AAA games, probably the vast majority of the games nowadays don't need manual memory management for the game core (C# was a popular choice, it seems). I guess that if one really needs manual memory management, languages with moderate memory safety would be a more appropriate choice (support libraries/frameworks being equal, which certainly aren't).

I've used Bevy, and ECS is not an appopriate choice for every game (I wouldn't actually advise it unless there is a specific need). It requires very careful design over the whole lifecycle (ECS-based games very easily tend to get a mess), which is exactly the opposite of one wants for rapid prototyping.

▲

account42 4 days ago | parent | prev [-]

And there are millions of game engines written in C++. Many of them have also been coming along nicely for years.

Making a nontrivial game with them is a wholly different story.