[randartie]

I believe Bevy (rust game engine) does leverage multi-threading for running game code (most 'data oriented' frameworks do). The most popular older engines like Unity do not (unless using the experimental DOTS framework).

So, the phrase "a tremendous amount of game code doesn't benefit from multithreading" is actually true since most game code is in unreal/unity, but it's not a hard constraint for all game engines.

[andrewmcwatters]

I think there is without a doubt a space for it. Multithreading in today's game engines should be commonplace, I think. And that's outside of the obvious threads like main and audio.

The problem is that most naive "game engines" which provide nothing more than bindings to OpenGL/bgfx, OpenAL, Box2D, etc. and are really just "game libraries," don't even provide things like out-of-the-box multiplayer or level loading, so the idea that they're going to make the leap from providing basically nothing to providing mechanisms for multithreaded game logic, which requires some sort of gamerules/gamemode abstraction first is not something I think you'll see in practice.

Most game libraries or game frameworks like these only provide things like load, update, draw callbacks with some nice bindings.