[a_t48]

The server can establish an ordering for the collapse events, and send back to the client that ordering.

Edit: depending on how complex the world is, the server could probably just send out the world changes itself, rather than relying on each client to correctly (deterministically) apply the changes. It needs to do so anyhow for late joiners.

[namibj]

Just keep some buffer of generated tiles around the players, and either use a server to asynchronously decide on when which player moved to cause which tile to be generated. You can also use something distributed if you go for peer-to-peer communication. fix the seed and ensure everyone aggrees on the order in which they tell the generatoe that a certain chunk needs yo be fixed or should be freed from memory. Consider just aggreeing on added/deleted blocks inside fixed intervals, and then process the list in e.g. coordinate order. Consider Raft for peer-to-peer aggreement of the exact diff for the most recent period. Consider chunks of like 0.5 seconds per diff. Don't apply the diff tk the generator until a moment later. You can interleave the cknsensus process of successive blocks a bit.

[a_t48]

Peer to peer greatly complicated multiplayer architecture- you _can_ build it like that, but it will be 10 times more difficult.

[atq2119]

You kind of have to have the server doing the collapse anyway, or clients can cheat by biasing the collapse towards tiles that are beneficial to them in some way.

You can partially work around this by requiring the client to use a server-provided PRNG seed, although even then a kind of aim bot could help the player decide which path to explore to get favourable tiles.

So your best bet to avoid cheating is to do the collapse on the server using a hidden RNG.