Good point. Yeah I guess it wouldn't cut it for any fast-paced twitch shooter. Especially with a 120 update per second deadline. A non-deterministic GC pause could have disastorous effects, especially in a tense shootout. I don't know much about GC theory but the GC in BEAM is per process and heap-based? I'm not sure exactly what that entails, but can you not structure the main simulation process to take advantage of this fact?
I find myself interested in developing multi-player simulations with more flexible deadlines. My MMO runs at 10 ticks. And its not twitch-based. So the main simulation process can have pauses and it wouldn't have a big impact on gameplay. Though this has never occurred.
As long as: (tick process time) + (send update to clients) + (gc pause) < 100ms, everything is fine?. (My assumption).
Btw what does DOD mean? Is it Data on Demand? Since my game is persistent I can't reset arrays at some match end state. So I store things either in maps on the main server process or I store it in the dedicated client process state (can only be updated via server process).
I find myself interested in developing multi-player simulations with more flexible deadlines. My MMO runs at 10 ticks. And its not twitch-based. So the main simulation process can have pauses and it wouldn't have a big impact on gameplay. Though this has never occurred.
As long as: (tick process time) + (send update to clients) + (gc pause) < 100ms, everything is fine?. (My assumption).
Btw what does DOD mean? Is it Data on Demand? Since my game is persistent I can't reset arrays at some match end state. So I store things either in maps on the main server process or I store it in the dedicated client process state (can only be updated via server process).