[dfox]

My point is that having scripting VM that is explicitly designed for game logic allows you to serialize only the relevant state. And if the whole system is designed correctly you can also do checkpointing and streaming replication essentially of the game state for free. This buys you things like rendering thread that is decoupled from the simulation (just draw the snapshot of state that was current on the start of rendering iteration), non-synchronized joins of multiplayer players (send serialized checkpoint and do stream the changes until the client catches up) and so on.

[Aardappel]

I agree, for that level of integration you want a "gameplay scripting system", whereas Lobster is more of a general purpose programming language that happens to be a nice starting point for simple games & engines. I don't think in its current form it is a great language for a large AAA team anyway, because of its heavy reliance on type inference and lack of separate compilation.

The language could of course be adopted to these use cases, it simply hasn't, so far.

Doing simulation on a separate thread from main/rendering is something it is already set up to do (multi-threading uses separate memory spaces so it is easy to ensure there's no data races between the two).