5 ms·

> 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.

> 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 2y ago
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 2y ago
  > 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 2y ago
    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 2y ago
> 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 2y ago
  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 2y ago
    >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 2y ago
      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://unity.com/blog/unity-6-features-announcement https://gamefromscratch.com/unity-7-development-roadmap/ https://gamefromscratch.com/unity-7-development-roadmap/
- littlestymaar 2y ago
  > 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.

pjmlp 2y ago

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 2y ago
> 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 2y ago
  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 2y ago

> 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 2y ago
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 2y ago
  >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 2y ago
    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://unity.com/blog/unity-6-features-announcement https://gamefromscratch.com/unity-7-development-roadmap/ https://gamefromscratch.com/unity-7-development-roadmap/
littlestymaar 2y ago
> 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.