Cool post!

I don’t quite understand the “funnel” section. Users see some change local immediately (S1->S2). And all users send all commands to the host. The host then effectively chooses the sort order and broadcasts back.

So does the initial user effectively rewind and replay state? If action applied to S1 was actually from another player they rewind to S1 and apply the sequence?

How many state snapshots do they need to persist? There was no mention of invertible steps.

I feel like I’m missing a step.

Whether users see the action locally or not is decided on a per-action basis. For more visual actions like movement, we use a local imposter that gets overwritten on completion of the action (success or failure). These revert to the most recent “committed” state which already passed through the action funnel.

We have some actions which happen when saving config UI which don’t really need realtime sync when “save” is pressed and we treat them more like a normal POST request (e.g. we wait for full commit before rerendering). The form fields are kinds a built-in imposter.

For state snapshots we only do big ones. The “full save” that happens every 25 actions or so. These aren’t generally used for reverting people.

So it kinda works like:

1. Do I have an outstanding imposter? If so read from it.

2. Otherwise read from the committed state.