[pjmlp]

Which follows the pattern of only partially using the ecosystem and doing the relevant parts themselves.

Bevy is the most advanced Rust engine, and it doesn't work well if games that succeeded commercially, did so by not using most of the ecosystem to start with.

Game development, what could be more unsafe than Assembly coding and taking advantage of hardware tricks pushing the hardware to the limits, aren't going to rush in grooves to Rust due to safety.

Rather what can an engine, written in Rust, offer that they aren't having already wiht existing engines, also noting that the safety aspect is already taken care by Java/C#/Verse/Blueprints/Lua/Python/JS scritping.

[littlestymaar]

> Bevy is the most advanced Rust engine, and it doesn't work well if games that succeeded commercially, did so by not using most of the ecosystem to start with.

Tinyglade uses Bevy though. Granted it doesn't use all of Bevy but given who made it and how advanced the tiny glade renderer is, no commercial engine would have offered out of the box the rendering features the devs wanted for their project anyway.

> Game development, what could be more unsafe than Assembly coding and taking advantage of hardware tricks pushing the hardware to the limits

This vision is outdated by at least 20 years. A significant fraction of games today is actually written in C# (Unity) and most games don't need to push the hardware at all. It's mostly AAA title that do, and a significant fraction of that effort is made so that aging consoles can run the games. Unreal engine itself is more used because it is packed with features while being relatively fast, not because it's as fast as hardware can get.

> aren't going to rush in grooves to Rust due to safety.

In the context of gamedev, safety mostly doesn't mean security vulnerabilities, but fewer intractable multithreading bugs or UB. It affects velocity and that's why there's a tradeoff between Unity and Unreal: Unity being much faster to code with, but can very quickly become slow and you need to spend time optimizing your hot loops (gratuitous allocations being a #1 concern), code written in C++ for Unreal being much faster by default but also much more prone to bugs.

In theory Rust offers the best of both worlds, but the ecosystem is still years behind so no wonder why game studios don't rush using it.

"Can Rust catch-up?" Is an open question, and the first 5 years of gamedev in Rust (2015-2019) went pretty badly in that regard, but since then Bevy occurred and now there's legitimate hope that some day Rust may be a viable choice for most studios.

[pjmlp]

While Unity is used a lot, it isn't as much as us managed languages fans would like, and the engine most folks are running for instead is Godot, written in C++, where GDScript is really taking getting used, instead of C# or non C++ extensions.

As big C# fan it saddens me, but things are as they are.

As you can see even by famous 2024 releases, multithreanding bugs or UB, aren't something most studios care about, there is always the next DLC.

And this an industry that was used to burn what used to be the golden copy of the game, before moving to the next game, there were no patches or upgrades.

[littlestymaar]

> As you can see even by famous 2024 releases, multithreanding bugs or UB, aren't something most studios care about, there is always the next DLC.

Do not confuse the fact that they don't spend enough in testing with the idea that they don't care about it: even if they release the game with the bug, it's going to cost them money later on to fix it when players complain about it, and slow down the development of other projects.

[pjmlp]

As former IGDA member and GDCE attendee, still catching up on GDC Vault and Digital Dragons, regular EDGE, MCV Develop and RetroGammer, I kind of well aware of how things are, and not confused at all.

[dismalaf]

> A significant fraction of games today is actually written in C# (Unity) and most games don't need to push the hardware at all.

??? Unity is a C++ engine, C# is just used for scripting...

[pjmlp]

Since Burst compiler was introduced for HPC# subset, that C# is used for engine internals as well.

Unity is like doing AI with PyTorch, or CuPy, yep there is a low level C++ layer for the GPGPU code, that hardly anyone touches directly.

By the way, CAPCOM goes even further, they have their own .NET Core fork, and games like Devil May Cry for PlayStation 5 were made with it.

[johnnyanmac]

>Since Burst compiler was introduced for HPC# subset,

depends a lot on how far DOTS has come. I'm a few years out of date, but DOTS (and by extension, Burst) was more or less a very separate codepath you needed to opt into. Any game using it today needed to make the consious effort to grab the Burst package an integrate those optimizations themselves.

I have heard plans to try and more or less integrate DOTS into the core engine and have gameobjects powered by entries under the hood, but I have no clue how much progress was actually made.

[pjmlp]

That is already much improved on Unity 6, and Unity 7 roadmap has more unification as plan.

https://unity.com/blog/unity-6-features-announcement

https://gamefromscratch.com/unity-7-development-roadmap/

[littlestymaar]

> just used for scripting...

AKA writing games. Many people writing games with Unity go far beyond what anyone reasonable would call “scripting”, writing code that consume a significant part of the performance budget.

[dismalaf]

Not sure why you have scripting in quotations or are implying that it's somehow bad. You're not modifying the engine code or writing a renderer from scratch when programming a game in Unity so yeah, it's scripting by every definition.

[littlestymaar]

> or are implying that it's somehow bad.

You're actually the one implying that, you said “it's just for scripting”

> You're not modifying the engine code or writing a renderer from scratch

You're not modifying the kernel or writing a GPU driver from scratch when you're building a game engine, yet you don't consider that to be scripting, why the difference?

[dismalaf]

> You're actually the one implying that, you said “it's just for scripting”

I'm describing how the engine is actually made... It's mostly written in C++ and C# is the application scripting layer.

If the whole thing was C# top to bottom I'd call it a C# engine.

[johnnyanmac]

it's a philisophical line, I suppose. at what point is "scripting" simply programming the gameplay with a tight interface? Unity can definitely blur that line at times.

[dismalaf]

Is it really philosophical?

Scripting means telling an already built piece of software what to do. In this case, the game engine code doesn't change, the programmer uses the existing functions and interface to tell it what to do. Even Unreal programming is mostly scripting... Yes you're writing C++ but you're only telling the engine what to do, not rewriting it (well, unless you are).

It's why scripting languages are called such... The interpreter is already built and remains unchanged, and runs the code without rebuilding anything.

Python doesn't suddenly become a non-scripting language just because your program reaches a certain size or scope.

It's weird that someone would take offence to calling scripting scripting... Like, it's nice that things are prebuilt and make programming easier... I reach for Ruby first whenever I have a problem I need solved.

[pornel]

TinyGlade's (co)developer said he's very satisfied with Rust and the crate ecosystem. They've used Bevy's ECS:

https://youtu.be/jusWW2pPnA0?t=3275

Using individual components instead of the whole big framework isn't necessarily a failure. The components are designed to be usable independently.

TinyGlade project started a few years ago, when Bevy's rendering was even more basic. The art style is central to TinyGlade's appeal, so it's not surprising they've built a custom renderer.

[fire_lake]

The promise is to write the whole game in Rust, rather than having a split between C++ and a scripting language. The most common example of this is Unity with C++/C#.

Having one language makes certain debugging tasks easier and can lead to faster execution.

Using only one language is difficult in C++ due to the lack of garbage collection.

What the Rust community is finding out is that it is also difficult in Rust due to compile times and the rigid borrow checker rules.

[pjmlp]

Doing whole games in C++ has been a thing for decades, granted with plenty Assembly in the mix, since Watcom C++ days in MS-DOS, or PlayStation being the first console with a C and C++ SDK.

There was no garbage collection in all those 8 and 16 bit home computers and game consoles programmed in straight Assembly.

If Rust can't top this, then its value for game development community isn't as great as many think it is.

[fire_lake]

Of course it can be and has been done, but it takes much more developer time than writing less efficient code in a managed language.

[pjmlp]

Now take in consideration that when using a single language, doing in Rust takes much longer than C++, even without taking into consideration the existing middleware engines, and support for hot code reloading.

Also that stuff like SDL and SFML are pretty much the go tool for DYI folks, and Khronos standards are all based in C and C++.

Additionally, if a managed language is good enough, and does support compilation to native code via AOT, and the middleware tooling, it makes Rust's selling point even weaker.

Which is what you see in how Unity/HPC#/NativeAOT, FNA/clang, Swift, Java/Kotlin (on Android see XR), already offer today.

[fire_lake]

I think we are agreeing :)

[pjmlp]

In a way yes, although seeing something like Unreal in Rust, with the same tooling polish, would be quite interesting.

Bevy might eventually get there.

[spease]

I added the Lua scripting layer to FS2Open. It’s very useful for not-quite-coders. There are a lot of projects where the founders end up doing everything because the other contributors don’t stick around permanently.

[pjmlp]

That is how Lua got famous in first place, scripting language for games.

[miohtama]

Rust does not suit for scripting. The goal of scripting is to write code more easily without worry of system programming concepts like memory management.

[johnnyanmac]

> also noting that the safety aspect is already taken care by Java/C#/Verse/Blueprints/Lua/Python/JS scritping.

it sure isn't safe enough. and "safe" in this context isn't just "my game will almost never crash" (plenty of Unity games crash, even non-il2cpp ones). But if that's good enough, then tha's understandable.

Very very few games (even AAA) are doing those old school assembly hacks to eek out power, so it's basically a non-factor.

[raincole]

The weird thing is that there are already working interpreters of other scripting languages written in Rust, e.g. Boa (Javascript), mlua (Lua). But all Rust game engines seem to insist on one single language approach.

[siknad]

Bevy has support for dynamically described components and systems. Their main use-case is scripting language support. Can't agree that they insist on single language approach.

[xqt40]

I'm afraid, you would sooner see safe code in assembler with the help of ai than in rust. You can argue that ai can be used to enhance rust, but at this point why bother if ai will be writing code by your instructions.

[pjmlp]

Some people haven't yet understood that the transition into AI is similar to how optimising compilers mostly replaced Assembly programming.

While not yet there, eventually AI based code generation will be good enough to generate native code directly, without going through existing languages code generation.

So while we might get the equivalent of a -S compiler switch, to dump the AI compiler decisions and fine tune the prompts, that isn't something everyday dev will be bothering with.

[xqt40]

Like I mentioned - belief in Rust is a religion and I got a proof in those negative votes.

I don't think that people like you understand what are appliances for AI - it is not about writing or optimizing code, but writing language from the scrap if needed. And my remark was that Rust will hit the wall where it will need to go fully AI, because developers simply can't fullfill the promise of safe code by default as it would require inhuman testing to even get near that promised result. Also Rust is meant for humans - which loses any edge if switch is happening towards descriptive and not even programming language that developers will use. Rust here simply has no edge at all as any programming language can be improved with memory safety in mind.