How Do You Make Two Players See the Same World at the Same Time?
A single-player game is a closed system: the player presses, the engine responds, the state is true because there is only one copy of it. Add a second player on a different device and that guarantee evaporates. Now there are two copies, a wire between them with 80ms of latency each way, and a player who will notice the instant they are wrong. Real-time multiplayer is not a feature you bolt on; it is a redesign of what "true" means. Here is the part teams underestimate.
Q: Why is sync in a mini-game a full magnitude harder than single-player?
Because truth becomes a negotiation. In single-player the engine is the judge. In multiplayer, the judge is the network, and the network is slow, lossy, and sometimes lying. Every action now has a round-trip: your input leaves your device, reaches the other side, gets reconciled, and comes back as state — and during that round-trip the other player has moved. The mini-game constraint makes it worse: you are doing this on a phone over cellular, not a wired PC, so your latency budget is tighter and your dropout rate higher. Most teams budget for "we will add multiplayer later" and discover that later is a rewrite, not an append.
Q: Authority, lockstep, prediction — how do you actually choose?
Three architectures, three honesty trades. Server-authoritative means one machine owns the truth and clients are dumb terminals; it is the only model that stops cheating, but it adds a round-trip to everything and feels laggy unless you pair it with prediction. Lockstep runs every client on the same deterministic simulation and just exchanges inputs; it is cheap on bandwidth but one slow peer stalls the whole match, and any non-determinism desyncs everyone. Client prediction with server reconciliation lets the local player feel instant while the server quietly corrects them — the standard for shooters and racers, and the most code to get right. For a casual mini-game, the real question is whether you need real-time at all: turn-based or async removes 90% of this pain.
Q: Interpolation, rollback, compensation — how is latency actually hidden?
You do not remove latency; you lie about it convincingly. Interpolation renders other players a few frames in the past so their motion is smooth instead of teleporting between network updates — the cost is everyone looks slightly delayed, which players accept. Rollback, used in fighting games, instead assumes the other player's input arrived, simulates forward, and if it did not, rewinds and replays — feels instant, but demands fully deterministic, snapshot-able state. Network compensation like lag shielding fakes a dead player's last action so they do not freeze. The art is choosing which lie your genre can survive: smooth-and-late, or instant-and-rewind.
Q: How do you decide if your game should even be real-time?
Run the honesty test first. If your game is a puzzle, a card battle, or anything where a 200ms delay does not change the outcome, you almost certainly want async or turn-based and should spend your budget on matchmaking, not netcode. Real-time earns its cost only when simultaneity is the fun — racing, shooting, co-op dodging. And a shared runtime helps here more than teams expect: one consistent networking layer across every mini-game means you write the hard sync code once, not per title. The table is the gate most teams skip.
| If your genre is… | Sync model | Why | What it costs you |
|---|---|---|---|
| Puzzle / card / turn | Async or turn-based | Delay does not change the outcome | Almost no netcode work |
| Racer / shooter / co-op | Client prediction + server auth | Simultaneity is the fun | Prediction + reconciliation code |
| Deterministic strategy | Lockstep | Bandwidth-cheap, fair | One laggy peer stalls all |
| Casual, unsure | Start async, measure | Real-time may be a trap | Rework if you guess wrong |
Real-time multiplayer is a tax on every frame. Charge it only where the fun is simultaneity.
