第 12 章的核心问题可以用一句话概括：当一个 200 毫秒延迟的玩家和一个 20 毫秒延迟的玩家同时冲进据点，谁算「先进去」。这不是一个同步问题，而是一个公平性问题。团队占点给出的答案是时空回溯——服务端保存位置历史，按客户端时间戳把世界倒回去判定。这套做法是射击类游戏延迟补偿的标准解，也是本章最有技术含量的一段。此外本章还配了一篇 Elo 与 Glicko-2 的评分详解，把「匹配分从哪来」这个一直悬着的问题彻底讲透。
本章定位
- 难度梯度：高阶，全书实时对抗线的峰值章节之一。延迟补偿与占点判定的组合对正确性要求极高。
- 前置章节：第 1 章 聊天室（底座通讯）与 第 11 章 团队塔防（快照、回放与经济日志基建可复用）被标注为依赖。
- 能力跃迁：从「状态同步」跃迁到「时空一致性」。服务器不再只维护当前状态，还要维护可供回溯的历史窗口。
- 阅读时长：PRD 约 550 行加评分详解约 450 行，建议先读 PRD 的占点判定与回溯小节，再读评分详解补齐匹配侧。
核心验证目标
- 占点进出判定：以服务端为权威，对玩家位置历史做时空回溯（rewind 到 ts_client），判定其是否在控制半径内。
- 推进与回退逻辑：己方独占时按占领速率推进，敌方已占则先回退至零再推进，推进至阈值完成点权转移。
- 去抖与人数优势：进入与离开需连续两帧确认以抑制拥挤抖动，人数差达到阈值时引入优势系数。
- 客户端预测与服务器校正：本地移动即时反馈，服务端按 last_confirmed_input_seq 回滚并重放未确认输入。
- 房间生命周期闭环：创建、进行、加时、结算、销毁的完整状态机，加时条件为点位对峙或分差极小。
- 延迟公平性验收：200 毫秒延迟下进出点判定误差不影响胜负，容错不超过一帧。
- 评分与匹配：Elo 与 Glicko-2 的公式推导、评分更新、段位划分，以及团队玩法下如何从对局结果反推个人评分。
技术栈建议
- 语言：Go、Java、Rust 或 TypeScript，服务端以 Go 或 Java 为主。
- 协议栈：HTTP 承担匹配、战报与回放索引；WebSocket 承担状态与输入流；Cron 或 DelayQueue 承担加时与定时事件。
- 存储：位置历史以环形缓冲区驻留内存，录像与战报落持久化存储。
- 关键设计：容量目标为单房 8 至 16 人、128 房并发、服务器 p95 帧时延不超过 12 毫秒，逻辑帧 50 至 100 毫秒，这组数字决定了回溯窗口的长度上限。
本章文章
| 文章标题 | 核心内容 |
|---|---|
| 在线联机原型全集：第 12 章 团队占点 | 完整 PRD：据点形态与控制半径、占点判定与时空回溯、去抖与人数优势系数、加时规则、职业雏形与复活机制、验收口径 |
| 在线联机原型全集：第 12 章 Elo 与 Glicko-2 评分系统详解 | 评分体系详解：Elo 期望胜率与评分更新公式、Glicko-2 引入评分偏差与波动率的改进、两套体系在团队占点匹配中的实际效果对比 |
本章是全书第二个双篇章节，PRD 解决「对局内公平」，评分详解解决「对局间公平」，两者共同构成竞技闭环。
与相邻章节的关系
- 上一章：第 11 章 团队塔防 提供快照、回放与经济日志基建，本章在其上叠加延迟补偿。
- 下一章：第 13 章 小队生存系统 从实时对抗转向异步任务与世界持久化，开启「世界独立运行」这条新主线。