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 the same world state, addressed by room id.
• Authoritative server state: the server holds the source of truth for shared state (positions, scores, inventory). Clients render from that state and send intents.
• Sub-100ms latency under normal network conditions.
• No backend code to write. The realtime service is shared infrastructure; the agent writes game-side handlers against the SDK.
• Auth: realtime tokens are minted server-side per signed-in player. Anonymous players can be allowed or denied per game.

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:

• Realtime client connection on scene start.
• State sync for shared entities (positions, scores).
• Intent dispatch for player actions (movement, attacks, pickups).
• Lobby / room-code UI if you ask for one.

When multiplayer makes sense

The model — authoritative server, intent-based clients

This is critical to understand if you're going to direct the agent well.

• The server holds the authoritative state. A player's position on your screen is what the server says it is, not what the player's keyboard says.
• Clients send intents: "I'm pressing W", "I want to pick up coin 17", "I'm attacking". The server validates and applies them, then echoes the resulting state to everyone in the room.
• This prevents cheating (a malicious client can't teleport itself, can only ask), and keeps everyone in sync (one source of truth).

The trade-off: small input-to-render latency (50–150ms typical). For fast-twitch competitive games you can ask the agent for client-side prediction with server reconciliation; for casual or co-op games the default is fine.

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 — players queue, the system pairs them. Good for competitive 1v1 / 2v2.

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.

Anonymous vs signed-in

By default, multiplayer requires sign-in (each player needs an account- backed identity for the realtime service to mint a token).

For embedded / public games where you want anonymous play to work, ask:

Allow anonymous players. Each anonymous player gets a randomly-
generated display name like "Guest-1234".

The agent wires anonymous-friendly token minting on the server side.

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 (or your game allows anonymous). Also make sure they're using the published URL, not the editor URL — editor sessions are per-owner.
• "Players see each other for 5 seconds then desync." Usually means the game is also computing state locally (cheating prevention), so client and server diverge. Tell the agent: "Use server-authoritative state only — clients render from server updates, don't compute their own positions."
• "Voice / video chat?" Not built in. Players use a separate voice channel (Discord, etc).

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. They expire.
• 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