Room Service is making the world's best multiplayer engine.

We're just at the start.

A high-performance multiplayer engine capable of supporting the most ambitious projects is just a hard thing to make. Here’s why.

Multiplayer is about beating the speed of light.

If your client confirms with a server on every single update, you’re adding an extra ~10-100ms latency to each request, just from the speed of light alone.

Instead, you can update optimistically. Send the message, assume success, don’t wait for confirmation, and get fantastic local-first, frontend performance.

But, that causes some issues.

Optimistic updating makes frontend performance a distributed systems problem.

If every client is sending requests without validation, then they’re acting in parallel, leading to a mess of unpredictable bugs.

For example, take a list like the following:

Anne updates index 2, and Zach deletes 0, both at the same time.

What happens? If Zach goes first, Anne updates something she probably wasn’t intending to.

But if Anne goes first, we get an entirely different result.

If Alice and Zach keep going, their lists will continue to diverge and will be unable to merge back up. One way or another, one of them is losing their work.

This problem isn't unique, multiplayer is filled with these issues.

CRDT & OT only go so far.

These problems are so common, that two strategies have developed: Conflict-Free Replicated Data Types (CRDTs) and Operational Transform (OT). To be frank, neither solution is very good.

Both are complex to implement correctly and most folks who try spend months or years building and end up with a buggy works-80%-of-the-time solution.

Room Service is making the 100% solution.