Online multiplayer

umicat ships a realtime service for online multiplayer. You ask the agent for the kind of multiplayer you want (co-op, competitive, room- based) and it wires the game using the realtime SDK — you don't write socket code yourself.

What you get

• Rooms — a group of players sharing state. Up to 16 per room (8 by default), addressed by an optional short room code.
• Two synced state surfaces: per-player data, which only that player can write, and room-wide shared data, which anyone in the room can write. Both are delta-synced to everyone, in milliseconds.
• A live player list — who is in the room, their display names.
• No backend code to write. The realtime service is shared infrastructure; the agent writes the game-side handlers.
• Sign-in required — see below.

Asking the agent

For a small co-op game:

Make this a 2-player co-op game. Both players control a wizard in the
same field. They share the coin counter — coins picked up by either
player count toward a shared total. Show both wizards live.

For a small competitive game:

Make this 2-4 player competitive. Each player has their own coin
counter. The first to 20 coins wins. Show all players' counters in
the HUD.

For a room-lobby flow:

Add a lobby screen: enter a room code to join an existing room, or
press "Create room" to make a new one. Show the player list in the
lobby. Start the game when the host clicks "Start".

The agent wires:

• The room connection on scene start, and the reconnect handling.
• Writes into your own player data, and reads of everyone else's.
• Shared room state for anything the whole table needs — the turn, the board, the score.
• Lobby and room-code UI if you ask for one.

When multiplayer makes sense

The model — synchronised state, not an authoritative server

This is the most important thing on this page, because it decides what you can safely build.

The realtime service synchronises state between clients. It does not run your game. It has no idea what your rules are, so it cannot enforce them. What it does guarantee:

• A player can only write their own player data. Nobody can write into somebody else's slot.
• Everyone sees the same room state, delta-synced, in order.

What it does not do:

• Validate a move against your game's rules.
• Stop a modified client from writing a room value it shouldn't.
• Compute anything on your behalf.

Typical latency is well under 100ms on a normal connection. For fast-twitch games you can ask for local prediction so input feels instant, with the synced state correcting it.

Rooms and matchmaking

By default, the agent wires one of these patterns:

• Single global room — every player joins the same room. Easiest; works for 2-8 player casual games.
• Room codes — host creates a room, gets a 4-character code, shares it. Friends-only multiplayer.
• Random matchmaking — not a platform feature, but the agent can build it on top of room codes (a shared "waiting" room that hands out codes). Say so explicitly if that's what you want.

Tell the agent which one you want:

Use room codes. When the host clicks "Create room" they see a 4-letter
code to share. Others enter the code to join.

Multiplayer requires sign-in

Every player in a room needs a umicat account. The realtime service only accepts a token minted for a signed-in player, and there is no anonymous mode you can switch on.

Design for it: a multiplayer game is asking every player to make an account before they can play with a friend. If you want the game to be playable by anyone with the link, give it a single-player mode that works without signing in — cloud saves fall back to local storage for anonymous players, so that half works fine.

What players see

• Sign in if needed — when the game opens, players are prompted to sign in if your game requires it.
• Lobby / room code UI if you asked for one.
• Live player list with display names + avatars (sourced from umicat profiles when available).
• The shared game world, with other players' avatars / sprites visible in real time.
• Disconnect / rejoin is handled automatically — if a player loses connection briefly, they're reseated into the same room when they reconnect. If they're gone for too long they're dropped.

Common gotchas

• "It works for me but not for friends." Make sure your friend is signed in — multiplayer has no anonymous mode. Also make sure they're using the published URL, not the editor URL — editor sessions are per-owner.
• "Players see each other, then they desync." Usually two clients are both writing the same shared value and overwriting each other. Tell the agent: "Only the player whose turn it is writes the shared state; everyone else renders from it."
• "Voice or video chat?" Not built in — players use Discord or similar. Voice input is a different feature: it turns what one player says into text for their own game, not audio for other players.

Cost

Realtime is included with your umicat account at reasonable usage. There's no per-player or per-room charge for normal game scale. If your published game gets a massive audience and uses heavy realtime, we'll reach out about scaling — not in your way, just to talk.

Privacy + security

• Tokens are minted per-player, per-game, per-session, and expire. A token for one game cannot join another game's room.
• Player identities in rooms are the umicat display name and avatar by default. You can ask the agent to use a different in-game name field.
• All realtime traffic is over secure WebSockets (wss://).

Next steps