Network roadmap
This is the short, public version of the network plan (the full one has about 750 items and lives in the repository as docs/NETWORK-PLAN.md). It was written on 2026-11-05. It says what you can use today, what is being built, and what is blocked, without promising dates.
The idea in one paragraph
The server is the referee. It runs the same deterministic simulation as the game (aqua4-sim) at 30 steps per second; a client only sends orders and draws what the server says it may see. Nothing a client claims is believed without a check, a game can be recovered after a restart, and a player who drops can come back. See You can always come back and Fair play and privacy.
What works today
On the server and the website, built and tested (about 540 of the plan's items are done):
- Dedicated server on a 30 Hz simulation, over TCP with TLS, with guests and signed-in players, fog-aware snapshots, delta snapshots, a binary codec with interest rectangles and a byte budget, lobby, loading and post-game phases, and in-game chat. Host a dedicated server lists every flag.
- Online service and W4 ID: accounts, email confirmation and reset, the games list, global chat, history with replays, leaderboard, moderation routes. See Online service and the generated HTTP interface.
- Ranked queue and parties (1v1 to 4v4, Glicko-2 ratings, rules against farming): Ranked queue and parties.
- Tournaments with a seeded single-elimination bracket: Tournaments.
- Rejoin: a dropped client reconnects inside a grace window and gets a full snapshot; the website shows a Rejoin banner. You can always come back.
- Spectating in the browser and recorded games (replays) with checkpoint hashes so a replay can be checked.
- Fair play basics: order-rate limits, a flag for abnormal order floods, a soft signal for two seats behind one address, mutes read at login.
- Operations: metrics, structured logs, backups, rc services behind Caddy, a content security policy and security headers on the site, a bot client and a load test (Bot load test).
- Checked by hand on 2026-11-05: sign-up, sign-in, queue, party and tournament pages against a local service (
docs/SITE-QA.md).
What is coming next
- Lockstep research stays research. The server is authoritative (decision N39); lockstep is kept only as an experiment, and rollback netcode and peer-to-peer are not planned.
- QUIC / UDP as a second road to the server, next to TCP/TLS, to be measured on the real line before it becomes a default. See Network settings.
- Matchmaking polish: expected waits from real data, more of the leave and no-show rules.
- Observability and load: more counters, a rooms-per-box limit measured on the two-core server, and chaos tests (packet loss, restarts) that prove recovery.
- Replay viewer in the browser (the spectator gateway in replay mode) and a report button in the game.
- A script API for networking (designed, nothing built yet): Go map scripts reading lobby state and sending messages through the same channel as chat.
Blocked, and on what
| Waiting on | What it holds back |
|---|---|
| The engine's network client (prediction, interpolation, the join screen) | Playing a networked game from the W4 Engine itself. The server, the wire format (WIRE.md) and a bot client exist; the engine window does not yet connect. |
| The live server box | QUIC on the real line (a firewall rule for UDP), off-box backups, time sync, and the measured per-player budgets. |
| A real second machine and real players | Numbers for latency, bandwidth and rooms per box; today they are estimates from one PC. |
| A passkey device | The end-to-end check of passkey sign-in. |
How to follow it
The plan is split into lettered sections (foundations, determinism, codec, interest, transport, session, service, security, operations, website, replays and so on). Each item is marked done, partial or open, and a done item names its test or file. Pages like this one are updated when a section changes: if a page and this roadmap disagree, the page is right and the roadmap is out of date.