Comment by maccard
3 months ago
Disagree on both points. Anyone who has shipped a game in unity has dealt with object pooling, flipping to structs instead of classes, string interpolation, and replacing idiomatic APIs with out parameters of reused collections.
Similarly, anyone who has shipped a game in unreal will know that memory issues are absolutely rampant during development.
But, the cure rust presents to solve these for games is worse than the disease it seems. I don’t have a magic bullet either..
This is a mostly Unity-specific issue. Unity unfortunately has a potato for a GC. This is not even an exaggeration - it uses Boehm GC. Unity does not support Mono's better GC (SGen). .NET has an even better GC (and JIT) that Unity can't take advantage of because they are built on Mono still.
Other game engines exist which use C# with .NET or at least Mono's better GC. When using these engines a few allocations won't turn your game into a stuttery mess.
Just wanted to make it clear that C# is not the issue - just the engine most people use, including the topic of this thread, is the main issue.
I'm shocked that Beat Saber is written in C# & Unity. That's probably the most timing sensitive game in the world, and they've somehow pulled it off.
GC isn't something to be afraid of, it's a tool like any other tool. It can be used well or poorly. The defaults are just that - defaults. If I was going to write a rhythm game in Unity, I would use some of the options to control when GC happens [0], and play around with the idea of running a GC before and after a song but having it disabled during the actual interactive part (as an example).
[0] https://docs.unity3d.com/6000.0/Documentation/Manual/perform...
There's another highly sensitive to timing game - Osu!, which is written in C# too (on top of custom engine).
Devil May Cry for the Playstation 5 is written in C#, but not Unity.
Capcom has their own fork of .NET.
"RE:2023 C# 8.0 / .NET Support for Game Code, and the Future"
https://www.youtube.com/watch?v=tDUY90yIC7U