Battle Arena：一个基于 Web 的实时对战实验项目

项目概述

Battle Arena 是一个基于 Web 的实时对战实验项目，目标是探索实时通信、状态同步与服务端权威模型在 Web 环境中的实现方式。

在线体验：https://battle-arena.happyfu.dev/

该项目并不追求复杂的游戏机制或美术表现，而是专注于以下核心问题：

多人实时状态同步如何设计
服务端如何驱动游戏主循环
WebSocket 在实时系统中的实际表现
如何在可控复杂度下构建完整可运行系统

设计目标（MVP）

在最初阶段，Battle Arena 只关注最小可玩闭环：

✅ 多客户端同时在线
✅ 基础移动与拾取得分
✅ 服务端统一判定（Server Authoritative）
✅ 房间机制与 Ready 开始流程
✅ 固定时长的对局与结算

明确不包含的内容：

❌ 复杂物理系统
❌ 高级预测或回滚
❌ 账号体系或长期数据存储
❌ 复杂美术或特效

这是一个工程实验项目，而非成熟产品。

系统架构

项目采用明确分离的服务结构：

Web Client   → 输入采集 / 状态渲染 / Canvas 绘制
API Server   → 鉴权 / Token 分发 / 房间列表
Game Server  → WebSocket / 游戏主循环 / 状态广播
Redis        → 会话与房间状态存储

核心流程

连接建立 客户端通过 API Server 获取 Token，再用 Token 连接 Game Server 的 WebSocket
房间匹配 进入房间后，玩家可以选择在线匹配，或者直接和机器人来一场激情对决
游戏主循环 Game Server 以固定帧率（如 60Hz）运行主循环：
- 接收客户端输入
- 更新游戏状态（位置、碰撞、得分）
- 广播状态快照给所有客户端
客户端渲染 客户端接收状态快照，插值渲染，保持流畅显示

技术要点

1. 服务端权威（Server Authoritative）

所有游戏逻辑运算在服务端进行，客户端只负责：

发送输入指令（上/下/左/右）
接收并渲染服务端状态

这样可以防止作弊，但代价是延迟敏感。

2. 状态同步策略

采用定时快照广播方式：

每帧发送完整游戏状态
客户端做简单插值平滑
未实现预测/回滚（MVP 阶段）

数据结构示例：

{
  "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 通信

选择 WebSocket 而非 HTTP 轮询的原因：

双向实时通信
低延迟（相比短轮询）
连接保持，减少握手开销

4. 房间隔离

每个房间是独立的游戏实例：

独立的 game loop
独立的状态存储
房间销毁后自动释放资源

遇到的挑战

1. 状态同步延迟

由于采用简单的快照同步，网络抖动会导致画面卡顿。

解决方案（未来优化）：

客户端插值平滑
增加客户端预测
使用 delta 压缩减少带宽

技术栈

前端：原生 JavaScript / Canvas API
后端：Go / WebSocket
存储：Redis（会话和房间状态）
部署：Docker / 云服务器

总结

Battle Arena 是一个聚焦于实时系统设计的工程实验项目。它不追求完美的游戏体验，而是通过最小化实现探索：

服务端权威模型如何运作
实时状态同步的基础策略
WebSocket 在实际场景中的应用

如果你对实时系统感兴趣，欢迎访问 https://battle-arena.happyfu.dev/ 体验。

关键词：实时系统、WebSocket、游戏服务器、状态同步、服务端权威