Async Multiplayer Without a Server: 5 Patterns That Work

Asynchronous multiplayer needs shared storage, not a live game server — and grasping that distinction is what lets a solo developer ship a multiplayer game at all. Five patterns cover most of what small games actually need: pass-and-play on one device, turn-based moves exchanged as cloud documents, async queues and mailboxes, a client-side idle economy that syncs, and ghost races against recorded runs. None of them asks you to run, patch, or watch a server.

A disclosure up front: this blog belongs to Egmatic, a no-code 2D editor in pre-alpha built around the layer a game needs between Build and Launch. The patterns below are engine-agnostic and vendor-neutral — they work whatever you build in.

The short answer#

If your players never need to act in the same second, you do not need a game server. You need one shared place both devices can read and write, and a rule for whose write wins:

One honest asterisk: "without a server" means without a server of yours. A managed store such as Firestore still runs on servers — Google's. What disappears is the operational job: no process to keep alive, no security patches, no 3 a.m. pages. For a solo developer that distinction is the whole game.

What asynchronous multiplayer actually means#

Two players are in the same match but not in the same moment. One acts now, the other acts tonight, and the game stays correct in between. Words With Friends ran on this shape from its launch in July 2009 — moves pushed between phones over hours and days — and became the canonical proof that a casual audience never needed shared simultaneity. Correspondence chess ran the same idea for a century before that, one letter at a time.

The design question that separates async from real-time is simply: how long may the gap between moves be? If the honest answer for your game is "seconds," stop reading — you need netcode. If it is "minutes to days," every pattern below is available to you, and each one trades latency tolerance for radically simpler infrastructure.

Pattern 1: Pass-and-play on one device#

The oldest async pattern: the device is the shared state. Player one takes a turn, hands the device over, player two responds. Nothing travels anywhere — no accounts, no networking, no cloud bill.

It is easy to dismiss as a party-game relic, but for a first multiplayer feature it is unbeatable: a weekend of work, zero failure modes outside your own bugs, and it teaches you turn serialization — writing a turn as data the next player consumes — which is exactly the skill the cloud patterns build on. Every match that works pass-and-play is one refactor away from working over the internet.

Pattern 2: Turn-based moves as cloud documents#

The workhorse. Represent the match as a single document — board state, whose turn, a numbered journal of moves — and store it in a managed document database such as Firestore or Supabase. A player's move appends to the journal and flips the turn field. The opponent's client reads the document, validates the move against the rules locally, and renders the result.

Three pieces do the heavy lifting:

• Security rules on the store decide who may write — "player A may append only when turn == A" is a rule, not a server.
• Push notifications tell the opponent a move is waiting. On Firebase, Cloud Messaging costs nothing.
• The free tier is real capacity. Firestore's no-cost quotas — 1 GiB stored, 50,000 reads and 20,000 writes per day — cover a correspondence game with hundreds of active players, because each move is one small write and one read.

The move journal matters more than any cleverness: a numbered, append-only list of moves is a source of truth any client can replay, verify, and resume from. If you are already wiring saves this way, the mechanics are close cousins of the ones in how to add cloud saves without a backend.

Pattern 3: Async queues and mailboxes#

Not every interaction is a match. Gifts, trades, challenges, and asynchronous inbox-style play are all the same structure: a queue of small documents that players claim and consume. A gift sits in your mailbox until you accept it; accepting marks the document consumed so it cannot be accepted twice.

The engineering care goes into claim semantics. "Claim once" must be atomic from the client's view — append a claim record, and treat the claim record, not the gift, as the source of truth. Done this way, a mailbox is forgiving: duplicated pushes, rereads, and offline periods degrade into "you already accepted this," not into duplicated currency.

Mailboxes also force the identity question — the gift must find the player on any device — which lands you on platform accounts and cloud identity. The cross-device mechanics are covered in how cloud saves work across Steam and mobile.

Pattern 4: A client-side idle economy, synced#

In the developer communities we read, this exact shape keeps recurring: a solo dev builds an idle 4X game, players log in at different times, and the question becomes where the shared economy lives. The no-server answer: on the client, simulated from timestamps.

An idle economy is a function, not a simulation loop. Given state_at_last_sync and now, the client computes what the player earned — offline or on, identically. Syncing becomes exchanging claims: "here is my last sync point, grant me the window." The server-side piece you skip is per-tick simulation; nothing needs to run while nobody plays.

Be clear-eyed about the trade: this trusts the client, and a client that can be edited will be edited. Timestamp-derived computation plus sanity clamps — maximum plausible earnings per window, bounded multipliers — keeps honest players honest and makes absurd claims visible. The competitive version of this economy, with trading or ranked stakes, is one of the signals in the boundary section below.

Pattern 5: Ghosts and time-shifted races#

Multiplayer feeling without simultaneous play: record a run, store it as data, and let another player race the recording. Rally games have shipped ghost rallies for decades; word and puzzle games do the same with puzzle-of-the-day seeds. The "opponent" is a replay, so there is no latency to tolerate and no session to keep alive — the pattern reduces to storing scores and replays, which is a leaderboard problem with well-mapped no-backend answers, from store services to lightweight game backends. Adding leaderboards without a backend covers that layer in detail.

Choosing between them#

A useful reading: the column that decides your architecture is the first one. Pick the loosest latency tolerance your design survives — every step looser deletes a category of infrastructure.

Resolving conflicts when nobody referees#

Two writes will eventually collide, so decide the winner before launch, not during an incident. The tools are few and sufficient:

• Version fields. Every document carries a version; a write must name the version it read. A write naming a stale version is rejected — the client re-reads and retries.
• Monotonic turn numbers. In the journal pattern, move 14 cannot land before move 13. The number itself is the ordering.
• Last-write-wins for cosmetics only. Let the newest write win for display name and settings; never for currency, inventory, or move state, where "newest" means "whoever's packet arrived last."

That last rule is where the no-server approach meets its philosophical limit. Someone — something — must order writes that both players care about. In these patterns the ordering authority is the document store's rules engine plus the turn structure of the game itself. When the writes are simultaneous and the stakes are real, you need a genuine single authority, which is the argument of does my game need a database in full.

The honest boundary: when async stops being enough#

Three signals say you have crossed out of no-server territory:

1. Players act on the same state in the same moment. Real-time co-op, twitch combat, shared physics — document exchange cannot carry a live simulation.
2. Outcomes carry stakes worth defending. Ranked seasons, trading economies, prize pools — client-trusted numbers will be forged, and forgiveness stops being a strategy.
3. Strangers must meet at scale. Matchmaking, lobbies, and presence among thousands of concurrent players is a live-systems problem.

Crossing the boundary does not mean writing a server. It means renting the problem as a product: managed game backends like PlayFab (usage-based, with a free tier), Epic Online Services (free), or Nakama — open source under the Apache-2 license, self-hosted on any cloud with a Postgres-compatible database beside it, with turn-based and realtime multiplayer built in, or managed as Heroic Cloud. Engine APIs follow the same current: Godot's high-level multiplayer and Construct's Multiplayer plugin still assume one machine acts as the authoritative host. At that point you are not eliminating the server; you are choosing whose server, and paying attention instead of babysitting.

Where Egmatic fits#

Egmatic exists because the gap these patterns live in — the ship layer between a finished build and a published game — is exactly where solo developers stall. The editor is no-code and ai-native: you direct, it executes, you own the result, including the save, sync, and async structures your game ships with. It is honestly pre-alpha; features arrive when they hold up, and we say so.

If the multiplayer plan above is the kind of decision you are making right now, the waitlist at egmatic.com is where you weigh in on what the ship layer handles for you — saves, leaderboards, async match structures — so the answer is built into the layer instead of bolted on after.

Common mistakes#

• Designing real-time when async would fit. Ask whether the game survives a one-minute gap between moves. Most cooperative and casual competitive designs do — and the async version ships in half the time.
• Polling instead of pushing. A client that re-reads the match every three seconds burns the free read quota and the battery. Push notifications are free on Firebase; use them to say "a move is waiting."
• Storing snapshots instead of a move journal. A board snapshot per turn cannot be replayed or arbitrated; a numbered move list can. The journal is the pattern that makes conflicts tractable.
• Trusting client numbers without clamps. If the client reports earnings, bound them. Impossible claims should be visible at a glance, not discovered in a forum thread.
• Last-write-wins on anything with a price. Newest-wins is a fine rule for display names and a catastrophic one for currency, inventory, and moves.

The takeaway#

Asynchronous multiplayer is not a compromise version of real-time — it is a different design space with almost no infrastructure, and most small games live comfortably inside it. Start from the loosest latency your game tolerates, represent every exchange as data with explicit ordering, and treat the move to a real backend as a graduation triggered by evidence: simultaneity, stakes, or scale. Ship the async version first. If the game earns a server, you will know exactly why.