[karmadog]

First of all, I'm talking about game engines, not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting.

However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure.

It's certainly possible to work around GC pauses, but that effectively means you are manually managing your memory manager (instead of the memory), which can be surprisingly difficult.

It's also possible that whatever you do is so "small" that GC pauses never affect you. Enjoy your free lunch then.

[pandaman]

Even if there was entirely non-stop GC (e.g. through reference counting) it's still wouldn't be a good choice for games since a game is, essentially, just a neatly arranged data structure in memory. Compared to the amount of memory a game reads/writes every frame all other I/O channels are just noise. You actually want to manage your memory instead of trying to figure out how to force a foreign memory system to do what is best.

[TeMPOraL]

Some of the work done to work around GC feels similar to the work you'd do in C/C++ to work around memory fragmentation issues. Also, depending on the language/runtime, you might be able to influence the GC algorithm, or at least the frequency with which it runs. If you can e.g. run a GC every second for not longer than ~1 frame, then pauses won't be noticeable.

[karmadog]

A dropped frame is always noticable. What you can do is keep a budget for GC and then force-collect every frame.