> 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.
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.
> 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.
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.
>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.
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.
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.
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?
The engine is in C++, but the game itself is written in C# (and this is the actual part you'd called out earlier in this thread), and no it's not “just scripting on top of the the engine”, no more than writing a game engine in C++ is “scripting on top of the OS” your definition of what is scripting and whatnot is just off.
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.
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.
Maybe "philosophical" is too strong a word, but I can't think of a better fitting term.
By those same definitions, we can Call any kind of middleware an API "scripting". You're not changing the underlying code so much as sending calls to some other code base to do the heavy lifting. But there's definitely some like between that and what popular game engines are structured by.
At the end of the day, the names are bikeshedding to me, what matters more is the output and experience of the tool more than the label applied to it. But names are communication, and communication is messy by nature.
> 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.
By this lose definition pretty much all of software engineering is scripting: you're always telling the underlying layer what to do without changing it: be it a web framework or the GPU driver.
I'd argue a lot of current programming definitely is.
How much foundational technology is actually being created? How many new OSes have there been in the last 30 years? Almost everything that's currently being built is built on top of many layers.
And why is this a bad thing?
When I was in university using R to solve economics problems I wasn't thinking to myself, "This is too easy, I'm just using a scripting language, I need to rewrite everything that's in CRAN myself". No, I was happy that so much foundational tech is already there to make our lives easy.
And when someone ships a game in Unreal or Unity they're probably happier to ship than regretting not writing their own engine.
Also, being in Canada, I can't legally call programming "software engineering" lol.
This response has nothing to do with the original point I made though, which has nothing to do with “foundational technology”, btw. When people write games in Unity the game is actually written in C#, sure the engine isn't, but that doesn't change the fact that the game is, and calling that “scripting” just because it's built on top of another layer makes no sense, because as you say, everything is built on top of another layer!
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.