Project Overview

Battle Arena is a web-based real-time combat experiment focused on exploring real-time communication, state synchronization, and server authoritative models in web environments.

Live Demo: https://battle-arena.happyfu.dev/

Rather than pursuing complex game mechanics or visual polish, this project concentrates on core questions:

  • How to design multi-player real-time state synchronization
  • How servers drive the game loop
  • Practical performance of WebSocket in real-time systems
  • Building a complete working system with controlled complexity

Design Goals (MVP)

In the initial phase, Battle Arena focuses on a minimal playable loop:

  • ✅ Multiple concurrent clients
  • ✅ Basic movement and item collection for scoring
  • ✅ Server authoritative decision-making
  • ✅ Room mechanics with Ready-to-start flow
  • ✅ Fixed-duration matches with scoring

Explicitly excluded:

  • ❌ Complex physics systems
  • ❌ Advanced prediction or rollback
  • ❌ Account system or persistent data storage
  • ❌ Complex graphics or effects

This is an engineering experiment, not a polished product.

System Architecture

The project uses a clearly separated service structure:

Web Client   → Input collection / State rendering / Canvas drawing
API Server   → Authentication / Token distribution / Room listing
Game Server  → WebSocket / Game loop / State broadcast
Redis        → Session and room state storage

Core Flow

  1. Connection Establishment Clients obtain a token from the API Server, then connect to the Game Server’s WebSocket using that token

  2. Room Matching After entering a room, players send Ready signals. The game starts when all players are ready

  3. Game Loop The Game Server runs the main loop at a fixed tick rate (e.g., 60Hz):

    • Receive client inputs
    • Update game state (positions, collisions, scores)
    • Broadcast state snapshots to all clients

  4. Client Rendering Clients receive state snapshots, interpolate for smooth display

Technical Highlights

1. Server Authoritative Model

All game logic runs on the server. Clients only:

  • Send input commands (up/down/left/right)
  • Receive and render server state

This prevents cheating but is sensitive to latency.

2. State Synchronization Strategy

Uses periodic snapshot broadcasting:

  • Send complete game state each tick
  • Clients perform simple interpolation for smoothness
  • No prediction/rollback (MVP phase)

Example data structure:

{
  "type": "gameState",
  "tick": 12345,
  "players": [
    { "id": "p1", "x": 100, "y": 200, "score": 5 },
    { "id": "p2", "x": 300, "y": 150, "score": 3 }
  ],
  "items": [
    { "id": "i1", "x": 250, "y": 300, "type": "coin" }
  ]
}

3. WebSocket Communication

WebSocket chosen over HTTP polling because:

  • Bidirectional real-time communication
  • Low latency (vs short polling)
  • Persistent connection reduces handshake overhead

4. Room Isolation

Each room is an independent game instance:

  • Independent game loop
  • Independent state storage
  • Automatic resource cleanup on room destruction

Challenges Encountered

1. State Sync Latency

Simple snapshot synchronization causes stuttering during network jitter.

Future Solutions:

  • Client-side interpolation smoothing
  • Add client-side prediction
  • Use delta compression to reduce bandwidth

2. Clock Synchronization

Client/server clock mismatch causes countdown display inconsistencies.

Current Approach:

  • Server broadcasts remaining time
  • Clients use server time as source of truth

3. Disconnect Handling

How to handle player disconnections?

Current Implementation:

  • Preserve player state for short period (e.g., 30s)
  • Remove player after timeout
  • No reconnection implemented yet

Tech Stack

  • Frontend: Vanilla JavaScript / Canvas API
  • Backend: Go / WebSocket
  • Storage: Redis (session and room state)
  • Deployment: Docker / Cloud Server

Future Roadmap

This is an evolving experiment with potential optimization directions:

  • Introduce client prediction with server reconciliation
  • Implement disconnect/reconnect mechanism
  • Optimize network transmission (Protocol Buffers / Delta compression)
  • Add gameplay features (skills / items / maps)
  • Performance and stress testing

The core goal remains: keep it simple, understandable, and extensible.

Summary

Battle Arena is an engineering experiment focused on real-time system design. Rather than pursuing perfect gameplay, it explores through minimal implementation:

  • How server authoritative models work
  • Basic strategies for real-time state synchronization
  • Practical application of WebSocket in real scenarios

If you’re interested in real-time systems, try it at https://battle-arena.happyfu.dev/ or check the source code (to be open-sourced).

Keywords: Real-time systems, WebSocket, game server, state synchronization, server authoritative