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|1 year ago
C# it's plenty fast for game programming.
mycocola|1 year ago
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.
SeasonalEnnui|1 year ago
bluGill|1 year ago
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.