[dfox]

Major reason why many game engines used to have native core and then some kind of "scripting" language for game logic (think Unreal Engine before 3, but many engines are similar) is that then you can trivially serialize the simulation state (ie. save game) and even run the whole thing as either lock-step, forward predicted or fully distributed network game without much effort on the part of whoever is writing the "scripting language" part of the game code.

[Aardappel]

Agreed, those are nice benefits. But there are also huge downsides, in the sense that you're writing all the glue code in the wrong language :) The amount of speed of iteration you get from having your entire engine + game's structure in a friendlier language is impressive (in my experience).

Also doing savegames by just serializing the entire scripting VM may work in some cases, but can also be problematic, since you're mixing ephemeral data with gameplay state. Last U3 engine game I worked on had explicit savegame serialization :)

[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).

[erikpukinskis]

Also, you can never update your data structures without ruining all of your safrgames.

[Aardappel]

Good point. I actually made this with game serialization needs in mind originally: https://google.github.io/flatbuffers/