Can synchronization and an initial economy sustain a fun multiplayer match?
Synchronize lobby, resources, and construction at low latency before investing in the complete game economy.
CASE FILE. 03 / STRATEGY / GAME
Castle Wars
A multiplayer strategy game inspired by Tribal Wars 2. The prototype covers authentication, lobby, worlds, realtime, and the first resource-and-construction loop.
- React
- Node.js
- Socket.IO
- Firebase Auth
BRIEF. 01 / PROBLEM AND BOUNDARY
The product in one read.
A deliberate view of the current state. Metrics and the hypothesis remain editorial until public evidence can replace them.
- FLOW
- LOBBY → MATCH EDITORIAL LABEL
- LOOP
- RESOURCES + BUILD EDITORIAL LABEL
- CAPABILITIES
- 3 frontend / backend / realtime
- PUBLIC DOOR
- NO PRIVATE SURFACE
SYSTEM TRACE. 02 / PRIMARY FLOW
Boundaries before frameworks.
React client → Socket.IO gateway → Node.js world loop → Firebase authentication.
- 01CLIENT→
World client
React / commands and projections
- 02GATEWAY→
Realtime gateway
Socket.IO / rooms and presence
- 03LOOP→
World process
Resources, queue, and server clock
- 04STATE
Persistence boundary
Memory now / explicit roadmap
intent → policy → authoritative state → observable effectEXECUTION TRACE / ILLUSTRATIVE
One path. Every decision in view.
An editorial sequence for discussing contract, authority, and effect. It does not represent real production telemetry.
- CLIENT
Emits an intent with the known world version.
build.requested - GATEWAY
Authenticates presence, room, and event contract.
command.accepted - LOOP
Validates resources, queue, and clock on the authoritative server.
build.started | rejected - STATE
Advances the version and publishes the room projection.
world.version + 1
DECISION LOG. 03 / TRADE-OFFS
Every choice costs something.
Validate the realtime loop in memory and declare persistence as a gap instead of pretending the infrastructure is ready.
- 01 / PROTOTYPE
In-memory state for the first loop
- GAIN
- Validates synchronization and fun before operating larger infrastructure.
- COST
- A restart loses the world and deliberately limits long sessions.
- 02 / AUTHORITY
Command on client, decision on server
- GAIN
- Economy and construction queue preserve a single source of truth.
- COST
- The interface must account for latency, rejection, and reconciliation.
- 03 / PROTOCOL
Small events per room
- GAIN
- Updates stay focused on the world that actually changed.
- COST
- Versioning and re-entry must rebuild a coherent snapshot.
RELIABILITY. 04 / FAIL WITH CONTEXT
Failure mode. Signal back.
These are not published production metrics. They are risks the design must make observable and candidate signals for the next round.
- 01
A client returns after a disconnect with a projection older than the server.
- 02
Two simultaneous commands compete for the same resource or queue slot.
- 03
A process restart invalidates the world still held in memory.
- 01
Version difference between the client snapshot and authoritative state.
- 02
Commands rejected because of balance, clock, or queue conflict.
- 03
Reconnection rate that returns to the game without manual intervention.
INCIDENT DRILL. 05 / CONTAINMENT → RECOVERY → PROOF
When the hypothesis breaks.
Editorial resilience exercises, not real incidents or production runbooks. Each drill turns a failure mode into a response that can be discussed and tested.
DRILL-01A client returns after a disconnect with a projection older than the server.SIMULATION / NATIVE
Response to: A client returns after a disconnect with a projection older than the server.
- CONTAIN
- Block new commands until the local version is compared with the authoritative room version.
- RECOVER
- Deliver the current snapshot and event cursor, then reopen entry only after client acknowledgment.
- PROVE
- Confirm every player sees the same world and no command was applied to an obsolete version.
DRILL-02Two simultaneous commands compete for the same resource or queue slot.SIMULATION / NATIVE
Response to: Two simultaneous commands compete for the same resource or queue slot.
- CONTAIN
- Serialize the decision in the world process and reject the command that lost the version comparison.
- RECOVER
- Publish the new projection and a rejection reason that lets the client reconstruct intent without guessing.
- PROVE
- Run concurrent scenarios and demonstrate resource conservation, a valid queue, and monotonic versions.
DRILL-03A process restart invalidates the world still held in memory.SIMULATION / NATIVE
Response to: A process restart invalidates the world still held in memory.
- CONTAIN
- Close the room as a lab session instead of pretending ephemeral state remains available.
- RECOVER
- Create a new world and use the incident as a gate for checkpoints before persistent sessions.
- PROVE
- Ensure no client resumes a ghost world and the prototype limit remains visible in the lobby.
DESIGN EXERCISE / REVIEW AGAINST REAL TELEMETRY AND RUNBOOKS BEFORE OPERATING
EVIDENCE. 06 / WHAT CAN BE DEFENDED
Facts in view. Gaps too.
Persist world state, add reconciliation, and test simultaneous command conflicts.
- React + Node / Express + Socket.IO
- Firebase Auth
- Resources + first construction queue
- In-memory state; persistence on the roadmap
- Independent project, unaffiliated with the reference game
INTERVIEW MODE. 07 / DEEPEN THE CONVERSATION
Three points to open on the board.
Questions that connect the case to system design, product, and operations without turning a contextual decision into a universal rule.
- 01
How to migrate an in-memory prototype to persistence without blocking the loop.
↗ - 02
When to send an incremental event and when to rebuild a snapshot.
↗ - 03
How to test clocks, economy, and concurrent conflicts deterministically.
↗
CASE FILE / 03