[SeasonalEnnui]

I could argue the opposite - GC makes it more viable for games. "GC is bad" misses too much nuance. It goes like this: developer very quickly and productively gets minimum viable game going using naive C# code. Management and investors are happy with speed of progress. Developers see frame rate stutters, they learn about hot path profiling, gen0/1/2/3 GC & how to keep GC extremely fast, stackalloc, array pooling, Span<T>, native alloc; progressively enhancing quickly until there are no problems. These advanced concepts are quick and low risk to use, and in the case of many of the advanced concepts; what you would be doing in other languages anyway.

[DeathArrow]

The only reason we might see FPS drop in games, is not because C# and its GC. It's mostly because the poor usage of the graphics pipeline and the lack of optimization. As a former game developer I had to do a lot of optimization so our games run nicely on mobile phones with modest hardware.

C# it's plenty fast for game programming.

[mycocola]

That entirely depends on the game. Recent example is Risk of Rain 2, which had frequent hitches caused by the C# garbage collector. Someone made a mod to fix this by delaying the garbage collection until the next load-screen — in other words, controlled memory leakage.

The developers of Risk of Rain 2 were undoubtedly aware of the hitches, but it interfered with their vision of the game, and affected users were left with a degraded experience.

It's worth mentioning that when game developers scope of the features of their game, available tech informs the feature-set. Faster languages thus enable a wider feature-set.

[munificent]

> It's worth mentioning that when game developers scope of the features of their game, available tech informs the feature-set. Faster languages thus enable a wider feature-set.

This is true, but developer productivity also informs the feature set.

A game could support all possible features if written carefully in bare metal C. But it would take two decades to finish and the company would go out of business.

Game developers are always navigating the complex boundary around "How quickly can I ship the features I want with acceptable performance?"

Given that hardware is getting faster and human brains are not, I expect that over time higher level languages become a better fit for games. I think C# (and other statically typed GC languages) are a good balance right now between good enough runtime performance and better developer velocity than C++.

[Const-me]

> frequent hitches caused by the C# garbage collector

They probably create too much garbage. It’s equally easy to slow down C++ code with too many malloc/free functions called by the standard library collections and smart pointers.

The solution is the same for both languages: allocate memory in large blocks, implement object pools and/or arena allocators on top of these blocks.

Neither C++ nor C# standard libraries have much support for that design pattern. In both languages, it’s something programmers have to implement themselves. I did things like that multiple time in both languages. I found that, when necessary, it’s not terribly hard to implement that in either C++ or C#.

[smaudet]

> In both languages, it’s something programmers have to implement themselves.

I think this is where the difference between these languages and rust shines - Rust seems to make these things explicit, C++/C# hides behind compiler warnings.

Some things you can't do as a result in Rust, but really if the rust community cares it could port those features (make an always stack type type, e.g.).

Code base velocity is important to consider in addition to dev velocity, if the code needs to be significantly altered to support a concept it swept under the rug e.g. object pools/memory arenas, then that feature is less likely to be used and harder to implement later on.

As you say, it's not hard to do or a difficult concept to grasp, once a dev knows about them, but making things explicit is why we use strongly typed languages in the first place...

[Rohansi]

The GC that Unity is using is extremely bad by today's standards. C# everywhere else has a significantly better GC.

In this game's case though they possibly didn't do much optimization to reduce GC by pooling, etc. Unity has very good profiling tools to track down allocations built in so they could have easily found significant sources of GC allocations and reduced them. I work on one of the larger Unity games and we always profile and try to pool everything to reduce GC hitches.

[n4r9]

Apparently that was released in 2019? Both C# and dotnet have had multiple major releases since then, with significant performance improvements.

[SeasonalEnnui]

A good datapoint, thanks. Extending my original point - C# got really good in the last 5 years with regards to performance & low-level features. There might be an entrenched opinion problem to overcome here.

[bluGill]

Anybody writing a game should be writing in a game engine. There are too many things you want in a game that just come "free" from an engine that you will spend years writing by hand.

GC can work or not when writing a game engine. However everybody who writes a significant graphical game engine in a GC language learns how to fight the garbage collector - at the very least delaying GC until between frames. Often they treat the game like safety critical: preallocate all buffers so that there is no garbage in the first place (or perhaps minimal garbage). Without garbage collection might technically use more CPU cycles, but in general they are spread out more over time and so more consistent.