在线联机原型全集：第 15 章　微型赛车系统

微型赛车系统（Mini Racing System）

• 类别：实时同步 + 物理预测 + 状态回滚
• 目标：验证客户端预测 + 服务端回滚同步的稳定性、物理碰撞裁定与轨迹对齐机制；评估高频输入下的延迟、漂移与带宽控制策略。
• 原型代号：proto-015-mini-race-rollback
• 依赖模块：proto-007-snake-battle（实时同步框架）、proto-011-team-td（AOI/物理同步）、proto-002-rps（回合锁步框架）
• 推荐语言栈：Go（服务端）+ TypeScript（客户端，基于 WebGL/Three.js 或 Unity WebGL）
• 协议栈：UDP / WebSocket（可靠 + 低延迟模式） + Tick/StateFrame 同步模型

一、核心玩法与目标

1.1 游戏概要

• 类型：多人实时竞速（Micro Racing）

• 玩家数：2–8 人

• 目标：在微型赛道（椭圆/8字形/城市弯道等）中控制赛车前进，率先到达终点。

• 视角：上帝视角或第三人称俯视。

• 机制：

  • 精确控制转向与加速；
  • 动态碰撞与摩擦力影响；
  • 碰撞裁定与回滚；
  • 服务端与客户端共享物理模型。

1.2 技术验证目标

1. 预测机制（Client-side Prediction）：输入本地立即生效；
2. 状态回滚（Rollback）：当接收到服务端确认帧后进行校正；
3. 碰撞裁定（Collision Arbitration）：统一由服务端权威处理；
4. 漂移与延迟控制：模拟 50~200ms 网络延迟下的表现；
5. 状态压缩与增量同步：验证高帧率下（30Hz~60Hz）网络带宽可控性。

二、核心架构设计

2.1 模块分层

graph TD
  Client[客户端]
  Net[网络层 WS/UDP]
  Pred[预测控制器]
  Phys[物理模拟]
  Renderer[渲染器]
  Server[游戏服务器]
  Room[房间/状态同步模块]
  Arbiter[碰撞裁定]
  Replay[回放系统]
  
  Client --> Net
  Net --> Server
  Client --> Pred
  Pred --> Phys
  Phys --> Renderer
  Server --> Room
  Room --> Arbiter
  Room --> Replay

2.2 Tick-Based 时序结构

• 逻辑 Tick：服务器与客户端统一步长（如 33.33ms → 30fps）；
• 状态帧：每 Tick 生成一帧（包含位置、速度、朝向等）；
• 输入帧：客户端将当前 Tick 的控制输入发送到服务器；
• 服务端：延迟接收后，按时间顺序执行并广播 authoritative 状态帧。

2.3 Tick 示例

三、输入预测机制（Client Prediction）

3.1 基本原理

玩家的输入（例如油门、转向、刹车）会在本地立即生效，客户端将基于上一状态预测当前状态，从而避免操作延迟。

3.2 实现过程

1. 本地立即模拟：客户端收到按键后直接推进物理模拟；
2. 记录输入历史：保存每一帧的输入（tick_id + control）；
3. 等待服务器帧：当收到权威帧后，比较差异；
4. 校正/回滚：如有偏差，则回滚至服务端帧并重新模拟本地缓存的输入；
5. 平滑过渡：将修正后的状态与当前状态平滑插值。

3.3 示例伪代码

function onLocalInput(input, tick) {
  localInputs.push({ tick, input });
  applyInput(localCarState, input, deltaTime);
}

function onServerState(serverTick, state) {
  const localTick = currentTick();
  if (serverTick < localTick) {
    const savedState = localCarState;
    rollbackTo(serverTick, state);
    for (let t = serverTick + 1; t <= localTick; t++) {
      const input = findInput(t);
      applyInput(localCarState, input, deltaTime);
    }
    interpolateState(savedState, localCarState);
  }
}

四、状态回滚与同步

4.1 状态定义

type CarState struct {
    ID        int64
    Position  Vector2
    Velocity  Vector2
    Rotation  float32
    InputSeq  uint32
    Timestamp int64
}

4.2 回滚流程

1. 客户端接收到服务器帧 S(t-k)；
2. 对比当前 Tick C(t)；
3. 回滚到 S(t-k) 状态；
4. 重新按输入历史重放；
5. 输出校正状态 C'(t)；
6. 平滑插值到新状态。

4.3 时间补偿

为防止网络抖动造成的卡顿，可采用时间滑窗策略：

• 客户端始终比服务器滞后 3–5 Tick；
• 当延迟波动时，调整缓冲长度；
• 服务器只广播关键帧，每 3–5 Tick 一次。

五、碰撞裁定机制（Collision Arbitration）

5.1 原则

• 服务器权威（Authoritative Collision）：碰撞事件以服务器物理模拟为准；
• 客户端预测：提前检测并回滚修正；
• 容差机制：允许一定误差范围内的预测偏移。

5.2 碰撞检测类型

1. 圆形碰撞体（Circle Collider）：适合小车模型；
2. AABB（Axis-Aligned Bounding Box）：快速近似；
3. SAT（Separating Axis Theorem）：精确判断旋转物体。

5.3 碰撞响应

• 计算法线向量 n；
• 投影速度分量： v' = v - (1 + e)(v·n)n 其中 e 为恢复系数（0–1）；
• 若为边界碰撞：限制位置至边界内；
• 若为车-车碰撞：双方动量守恒，施加反向冲量。

5.4 服务端裁定逻辑

func HandleCollision(carA, carB *CarState) {
    if Distance(carA.Position, carB.Position) < radiusSum {
        n := Normalize(carA.Position.Sub(carB.Position))
        relVel := carA.Velocity.Sub(carB.Velocity)
        if Dot(relVel, n) < 0 {
            impulse := (-(1+e)*Dot(relVel, n)) / (1/mA + 1/mB)
            carA.Velocity = carA.Velocity.Add(n.Mul(impulse/mA))
            carB.Velocity = carB.Velocity.Sub(n.Mul(impulse/mB))
        }
    }
}

六、延迟与漂移控制

6.1 时间同步

• NTP-like Round Trip：客户端定期测量 RTT；
• Delta Adjustment：每 5 秒更新时差 δ；
• 滑动平均过滤：防止单次抖动造成回滚误判。

6.2 动态缓冲调整

客户端维持缓冲区 B：

• 若延迟上升 → 扩大 B；
• 若延迟下降 → 缩小 B；
• 保持 RTT ≈ 3 × TickDuration × B。

6.3 插值与外推

• 插值：对其他玩家使用线性插值（Lerp）；
• 外推：若丢包或延迟过大，预测下一个位置： p_next = p_curr + v * Δt；
• 纠正：若误差 > 阈值，则直接跳变 + 淡出动画。

七、网络同步协议

7.1 数据包格式

// 客户端输入帧
{
  "type": "input",
  "tick": 1023,
  "seq": 47,
  "uid": 1001,
  "input": {"throttle":1,"steer":-0.2,"brake":0}
}

// 服务端状态帧
{
  "type": "state",
  "tick": 1023,
  "cars": [
    {"id":1001,"pos":[12.3,8.2],"rot":0.91,"vel":[2.1,0.4]},
    {"id":1002,"pos":[9.1,7.9],"rot":1.33,"vel":[1.9,0.6]}
  ]
}

7.2 数据压缩

• 位置差量（Δx, Δy）压缩为 int16；
• 角度量化（rot × 1000 → uint16）；
• 每帧仅传递变化的对象；
• 可选 Zstandard 或 LZ4 压缩通道。

八、物理模型与参数化

8.1 力学更新公式

v(t+Δt) = v(t) + aΔt - μv(t)
p(t+Δt) = p(t) + v(t)Δt

其中 μ 为摩擦阻尼。

九、赛道与地形系统

9.1 数据结构

{
  "track_id": "mini01",
  "checkpoints": [[0,0],[10,5],[20,0]],
  "obstacles": [{"type":"barrier","pos":[5,2],"r":1.2}],
  "laps": 3
}

9.2 赛道逻辑

• 检查点验证：玩家必须依次通过；
• 圈计数：完成所有检查点计一圈；
• 反向检测：防止倒退刷圈；
• 出界检测：越界重置至上一个检查点；
• 摩擦差异：不同地面（草地、柏油）影响摩擦系数。

十、房间与状态管理

10.1 房间生命周期

Idle → Waiting → Countdown → Racing → Finish → Replay → Close

10.2 关键事件

• E_JOIN_ROOM
• E_READY
• E_COUNTDOWN
• E_TICK_UPDATE
• E_COLLISION
• E_FINISH
• E_REPLAY_START

10.3 房间状态表

十一、回放系统（Replay System）

11.1 设计思想

• 事件溯源（Event Sourcing）：仅记录输入与随机种子；
• 可重建性（Deterministic Physics）：物理计算需完全确定；
• 压缩重放流：记录输入差量 + 状态关键帧。

11.2 存储格式

{
  "seed": 312459,
  "ticks": 1800,
  "inputs": [
    {"uid":1001,"tick":1,"input":{"t":1,"s":0}},
    {"uid":1001,"tick":2,"input":{"t":1,"s":0.2}}
  ],
  "keyframes": [0,600,1200,1800]
}

11.3 回放机制

1. 初始化世界状态；
2. 使用记录输入流重建物理状态；
3. 在客户端播放；
4. 支持快进/慢放；
5. 可生成“幽灵车（Ghost Car）”对比跑法。

十二、作弊防御与安全

十三、性能与网络优化

13.1 传输层优化

• 使用 UDP + FEC 替代纯 WebSocket；
• 合帧打包：多个输入合并成单包；
• 延迟分层：关键帧优先发送。

13.2 物理性能

• 优化碰撞检测：四叉树（QuadTree）；
• 简化模型：近似圆形；
• Tick 计算与渲染分离（多线程）。

13.3 带宽估算

十四、指标与监控

14.1 监控可视化

• 客户端 FPS 与 RTT 曲线；
• 回滚误差分布图；
• 碰撞次数与严重度统计；
• 玩家平均速度热力图。

十五、测试场景与验证计划

15.1 单机确定性验证

• 在固定输入序列下，客户端与服务器状态应完全一致；
• 测试随机种子一致性。

15.2 延迟模拟

• 模拟 50–300ms RTT；
• 统计预测误差与修正频率；
• 记录回滚开销。

15.3 并发碰撞

• 多辆车同时进入弯道；
• 检测碰撞优先级一致性；
• 验证物理能量守恒。

15.4 网络丢包

• 模拟 10% 丢包率；
• 验证插值与重传机制。

十六、客户端交互与表现

16.1 HUD 元素

• 当前速度 / 圈数 / 排名；
• RTT / 预测偏差可视化；
• 碰撞提示与漂移特效。

16.2 操作控制

• 键盘：↑加速，↓刹车，←→转向；
• 手柄：模拟摇杆；
• 移动端：陀螺仪或虚拟方向盘。

16.3 动画与反馈

• 碰撞火花、烟雾；
• 漂移痕迹；
• 回滚时轻微闪烁特效；
• 胜利镜头、重播回放。

十七、系统迭代路线

• Minigame
• Race Rollback
• PRD