Multiplayer is a genuine step up, and most of the difficulty is not the networking — it's deciding who is allowed to be right about what.

1. The server is the authority

The rule that prevents every category of cheating: the server holds the real game state. Clients send intentions ("I pressed left"), never results ("my score is 4000"). The server decides what happened and tells everyone.

Break this rule and someone will edit the numbers, guaranteed, on any game anyone cares about.

2. Start with rooms

Before any gameplay, build the lobby: create a room, get a code, someone joins with it, both see each other, someone starts.

lobby-build.txt
Build a multiplayer lobby with WebSockets. Stack: <stack>.

- Create room returns a short, human-readable code (no ambiguous
  characters — people read these aloud).
- Join by code. Reject unknown, full, or already-started rooms with a
  clear message.
- Both players see the current member list live.
- Handle disconnects: remove the player, tell the other one, and clean
  up empty rooms rather than leaking them forever.
- Reconnect within a grace period rejoins the same room.

Server holds all room state. Clients only send intentions.

3. Turn-based first

If your game can be turn-based, make it turn-based. Real-time multiplayer needs interpolation, prediction and lag compensation — a genuinely hard set of problems. Turn-based needs none of it and is a completely valid design.

4. Design for the connection dropping

It will, constantly, on mobile. Every state needs an answer to "what if one player vanishes here?" Pause and wait, forfeit after a timer, or let an AI take over. Pick deliberately, because the default — the game hanging forever — is the worst option.

Test with your phone on mobile data, walking around, not with two tabs on your laptop. Local testing hides every problem that matters.