Hacker news

  • Top
  • New
  • Past
  • Ask
  • Show
  • Jobs

How We Synchronized Editing for Rec Room's Multiplayer Scripting System (https://www.tyleo.com)

29 points by tyleo about 15 hours ago | 15 comments | View on ycombinator

giovannibonetti about 14 hours ago |

I find it fascinating when different people independently arrive at the same architecture when working on a hard problem like this. In my company we built our offline-first apps with PowerSync, which has the same idea of optimistic local changes while waiting for the central server to acknowledge the definitive changes. In PowerSync's case, the sync engine reads Postgres replication logs directly.

wpietri about 14 hours ago |

For those interested in a keep-everything-hot approach like this, it's worth checking out the 25-year-old library Prevayler. Full ACID guarantees, and radically faster than a database. I happily used it for a project forever ago and was disappointed to see it so thoroughly ignored.

davidanekstein about 13 hours ago |

I’m surprised there was no mention of operational CRDT’s, or CRDT’s generally.

forrestthewoods about 12 hours ago |

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.