Chaos Arena
A browser game platform with server-managed multiplayer rooms, Redis-backed match history, SQLite leaderboards, and WebRTC voice signaling.
My focusFull-stack game development
The reviewed branch includes AI/TTS service code, but disables Gemini game-master calls and Sarvam commentary. These are not presented as active features.
- registered game modes
- 3
- configured players / room
- 8
- configured Grass Collect tick
- 60 Hz
Source-defined configuration, not a load-test result or a measured client frame rate. Numbers reflect the reviewed rit branch.
Overview
Chaos Arena is a multiplayer browser-game project built around a React client and a TypeScript backend. The engineering focus is shared game state, room lifecycles, persistent results, and communication between players.
The problem
Multiplayer games need players to see a consistent match while input, scoring, and communication arrive asynchronously. Match results also need to remain available after a room ends, without making the simulation depend on every storage operation succeeding.
Approach
Separate real-time gameplay from HTTP queries. Colyseus rooms own each game mode, while Express endpoints serve match history, leaderboard data, and player statistics. React connects to the game server, and a shared room-communication service relays chat and WebRTC signaling.
System design
React client → Colyseus WebSocket transport → game rooms. The server registers Grass Collect, Hot Dynamite, and Turf Soccer. Match results are written to Redis and SQLite; recent-match queries try Redis first and fall back to SQLite. Player statistics use parameterized SQLite statements and transactional updates.
Implementation
The source configures a maximum of 8 clients per room. Grass Collect schedules its simulation at 1000 / 60 milliseconds. REST routes expose health, recent matches, leaderboards, player statistics, and player-name updates. Voice offers, answers, and ICE candidates are relayed through the room communication layer.
Engineering tradeoffs
Real-time state and database persistence have different failure modes. The storage code catches Redis and SQLite failures so unavailable persistence does not automatically stop gameplay; the tradeoff is that results may not be stored. A full-mesh voice design is suitable for small rooms, but would need reassessment for substantially larger groups.
Results & evaluation
The reviewed source contains 3 registered game modes, an 8-player room limit, and a configured 60 Hz Grass Collect simulation. These establish implementation scope, not demonstrated concurrency, latency, uptime, or production load capacity.
What I learned
The project connects room-based state synchronization, HTTP APIs, caching, persistence, and browser communication in one system. The next engineering step would be repeatable multi-client load tests, persistence-failure tests, and reconnect scenarios—not unsupported performance claims.