Round Phases
The Three-Phase Round Cycle
Phase Architecture
Every round consists of exactly three phases:
| Phase | Duration | Purpose |
|---|---|---|
| MOVEMENT | 3/10/30 seconds | Make predictions via positioning |
| LOCKED | 3/10/30 seconds | Watch price movement |
| SETTLEMENT | ~100ms instant | Process results |
How it works: Server maintains authoritative round phase timer synced to UTC. All clients receive round phase transitions simultaneously via WebSocket broadcast. No client-side round phase control - server is single source of truth.
Technical impact: Network latency affects when you see round phase changes. High ping players see transitions slightly delayed but server timestamps all actions. Actions sent after round phase transition are rejected server-side.
MOVEMENT Phase
Allowed Actions
During MOVEMENT you can:
| Action | Description |
|---|---|
| Move | Adjacent platforms (4 directions) |
| Purchase | Chips with earned GP |
| Activate | One chip per round |
| View | All player positions |
| Monitor | Heat map percentages |
Cannot do:
| Restriction | Reason |
|---|---|
| Diagonal moves | Not implemented yet |
| Change chip | Locked after selection |
| Pass through players | Platforms occupied |
| Undo movements | Actions are final |
How it works: Client sends movement commands to server. Server validates adjacency, occupancy, and platform selectability. Successful moves update spatial system immediately. Position broadcast to all clients. Last position when round phase ends = your prediction.
Technical impact: Movement commands queued if sent rapidly. Only last valid position matters. Server rejects movements received after round phase transition timestamp. No grace period - timing is absolute.
Prediction Mechanism
Your platform position IS your prediction:
| Platform Type | Prediction |
|---|---|
| GREEN | Predicting UP |
| RED | Predicting DOWN |
| SAFE | No prediction |
| GOLD/BURNED | No prediction |
How it works: No separate prediction command needed. Server captures player position at exact moment MOVEMENT ends. Platform type at that position determines prediction. Cannot change after round phase transition.
Technical impact: Position sampling happens at round phase boundary. Movement command in-flight during transition is rejected. Safe zones allow tactical non-prediction. GOLD/BURNED platforms force you to move for predictions.
LOCKED Phase
State During LOCKED
What happens:
| Element | Status |
|---|---|
| Positions | Frozen completely |
| Price feed | Continues updating |
| Visual feedback | Shows price movement |
| Player actions | None possible |
| Anticipation | Maximum |
How it works: Server stops accepting all movement and chip commands. Price updates continue streaming to clients. Opening price captured at round phase start, closing price at round phase end. Clients can only observe.
Technical impact: Zero player input processed. Server still broadcasting price updates at normal rate. Round phase duration exactly matches MOVEMENT phase. Price capture timestamps are authoritative for settlement.
Price Capture Points
Critical timestamps:
| Capture Point | Timing | Source |
|---|---|---|
| Opening Price | Exact moment LOCKED begins | Latest trade |
| Closing Price | Exact moment LOCKED ends | Latest trade |
| Price Source | From market feed | Executed trades only |
| Precision | Millisecond accuracy | Server timestamp |
How it works: Server captures price from market feed at round phase boundaries. Uses latest completed trade, not bid/ask. Timestamps recorded for blockchain verification. Price comparison determines round outcome.
Technical impact: Network delays don't affect price capture - server timestamps are authoritative. Price feed interruption triggers SYNC mode. All players see same opening/closing prices. No client-side price determination.
SETTLEMENT Phase
Resolution Order
Strict processing sequence:
| Step | Process | Type |
|---|---|---|
| 1 | Evaluate all predictions | Simultaneous |
| 2 | Calculate chip effects | GUARD - ATTACK - RESTORE |
| 3 | Apply platform transformations | Atomic |
| 4 | Award GP and bonuses | Calculated |
| 5 | Update lives and eliminations | State changes |
| 6 | Broadcast results | Single update |
How it works: Server processes all players atomically. No race conditions - order is deterministic. Database transaction ensures consistency. Results broadcast as single state update. Typically completes in under 100ms.
Technical impact: All settlement server-side - no client validation. Players can't affect settlement once started. Atomic processing prevents partial updates. Failed settlement rolls back entire round.
Life Loss Calculation
When lives are lost:
| Condition | Life Change | Notes |
|---|---|---|
| Wrong prediction | -1 life | Active players only |
| No prediction | -1 life | Active players only |
| Inactive/eliminated | No change | Already out |
| DELAY chip | No change | Future feature |
How it works: Server checks each active player's prediction result. Life counter decremented atomically. Players reaching 0 lives marked ELIMINATED. State change broadcast immediately.
Technical impact: Life loss irreversible once processed. No client-side life tracking. Server validates lives before all actions. Elimination is permanent for that run.
Player State Machine
State Definitions
Players exist in one of three states:
| State | Description | Capabilities |
|---|---|---|
| SYNCING | Joining game | Waiting for round boundary |
| ACTIVE | Playing normally | Can make predictions |
| ELIMINATED | No lives left | Spectator mode only |
How it works: New players start SYNCING until next round starts. SYNCING to ACTIVE at round boundary. ACTIVE to ELIMINATED when lives reach 0. State persists until player leaves game.
Technical impact: State determines allowed actions. SYNCING players can't predict or lose lives. ELIMINATED players can spectate but not interact. State changes only at specific triggers.
State Transitions
Valid transitions:
| From - To | Trigger | Result |
|---|---|---|
| - SYNCING | Join game | Wait state |
| SYNCING - ACTIVE | Round starts | Can play |
| ACTIVE - ELIMINATED | Lives = 0 | Spectator |
| Any - Previous | Reconnect | State preserved |
How it works: Server enforces state machine rules. Invalid transitions rejected. State stored in database for persistence. Reconnection restores exact state.
Technical impact: No direct state manipulation. State changes trigger event broadcasts. Client UI updates based on state. Spectator mode automatic for ELIMINATED.
Phase Timing Precision
UTC Synchronization
All timing UTC-based:
| Aspect | Implementation |
|---|---|
| Round starts | Exact seconds |
| Phase transitions | Precise intervals |
| Timezone handling | UTC only |
| Global sync | All players aligned |
How it works: Server clock synced to NTP time servers. Round phase timers use high-resolution timestamps. All events logged with UTC timestamps. Client clocks not trusted.
Technical impact: ~50ms drift maximum from true UTC. Round phase lengths exact to millisecond. Action timestamps compared to round phase boundaries. Historical verification possible.
Network Latency Handling
How latency affects gameplay:
- Actions timestamped at server receipt
- Round phase boundaries absolute, not adjusted
- Visual delays possible for high-ping players
- Server authority always wins
How it works: Each action includes client timestamp. Server compares to round phase boundaries. Late actions rejected with error response. No rollback or compensation.
Technical impact: Players with <100ms ping unaffected. 100-200ms ping may see occasional rejections. >200ms ping requires predictive movement. Server-side validation prevents exploitation.
Inactivity Penalties
What Constitutes Inactivity
Counted as inactive if:
| Condition | Result | Applies To |
|---|---|---|
| On SAFE platform | -1 life | ACTIVE players |
| On GOLD/BURNED | -1 life | ACTIVE players |
| No movement | -1 life | ACTIVE players |
| SYNCING/ELIMINATED | No penalty | Not active |
How it works: Server checks final position at MOVEMENT end. Platform type determines if prediction made. No prediction for ACTIVE player = inactivity penalty. One life lost, no GP earned.
Technical impact: Cannot avoid predictions by staying safe. Forces engagement with game mechanics. AFK players eliminated naturally. Strategic non-prediction not possible.
Grace Periods
No grace periods exist:
| Aspect | Policy |
|---|---|
| Phase transitions | Instant |
| Warning system | None |
| Misclick forgiveness | None |
| Disconnection recovery | No phase extension |
How it works: Strict timing enforces fair play. All players face same constraints. Server rejects late actions universally. Reconnection doesn't extend phases.
Technical impact: Requires constant attention during MOVEMENT. Cannot rely on last-second actions. Network issues are player's responsibility. Encourages stable connections.
Database Atomicity
Round Settlement Transaction
Single atomic operation:
| Component | Handling |
|---|---|
| Player rounds | Written together |
| GP transactions | Same commit |
| Platform updates | Synchronized |
| Failure mode | Complete rollback |
How it works: PostgreSQL transaction wraps entire settlement. Any failure triggers complete rollback. No orphaned records possible. Consistency guaranteed.
Technical impact: Settlement either fully succeeds or fully fails. No corrupted game state possible. Database locks prevent race conditions. Recovery automatic on transient failures.
Remember: The round phase system is the heartbeat of the game. Understanding exact timing windows, state transitions, and resolution order explains why certain strategies work. Server authority is absolute - no client-side prediction or compensation exists.
Precision. Authority. Fairness.