Skip to main content

Guides

What multiplayer games teach about real-time systems

Real time is easy to promise and hard to keep. We learned what it takes from games: a trivia match where every player must see the same question at the same moment, a Mafia game where a vote has to land for everyone at once, and a floor game where the screen and the floor must agree on every step. This page is what those taught us, written for anyone building a live system, game or not.

It is our own judgement, from our own builds. It names no client, no figure and no price.

Last updated: 2026-10-28

01

What "real time" actually means

For people, real time does not mean zero delay; it means nobody notices one. A chat can arrive a beat late. A vote that lands for one player before another feels unfair at once. The first design decision is which events must feel instant and which only need to arrive.

02

One place decides

In a multiplayer game the server keeps the rules and every screen shows its decision. Arrab, our Mafia game in development, resolves the night, the timers and the votes on the server, so no phone can disagree about who was eliminated. The same rule holds for stock, bookings or bids: decide once, in one place, then tell everyone.

03

Dropping out is the normal case

People lose signal in lifts, switch apps and lock their phones. A live system has to treat a reconnect as routine: the person comes back to the current state, not to an error. We design that path first, because in a game it happens every round.

04

Where this applies beyond games

The same engineering fits any system where several people act on the same thing at once.

Live dashboards
Numbers that move as they happen, without a refresh button.
Queues and bookings
One slot, one winner, decided in one place.
Live events and activations
A screen, a crowd and a prize that must agree, as in Up The Beat.

Common questions

Common questions

It depends on how many events must be instant. Designing which ones truly need it is the biggest cost lever, and it is the first thing we look at.

Both have their place. We used Socket.IO rooms for Arrab and a managed backend for Nabsh; the choice follows who must decide and how much control the system needs.

Yes, and live text is where right to left breaks most often: names, numbers and mixed Arabic and English in one line. We test it with Arabic content from the first build.

Still deciding?

Tell us what you're building and we'll give you an honest read on scope and approach, including if we think someone else should build it.