赛事玩法（Bracket / 瑞士轮 / BO 系列）

赛制建模 · 种子分配 · 比分晋级 · 录像回放 · 观战低延迟推流 · 反作弊闭环——用一套赛制骨架把电竞级玩法配置化上线。

场景问题

普通匹配和赛事玩法看着都在"给玩家凑对手"，其实是两回事：

赛事玩法开发的核心不是"再写一遍匹配代码"，而是把赛制骨架做成配置化模板：赛制种类 + BO 层数 + 种子规则 + 观战档位 + 录像格式 + 反作弊策略 → 一次上线支持后续 N 种赛事。

实现方案

一：赛制模型对比

BO 系列（Best-of-N）是每场的层级，正交于赛制模型：

二：Bracket 数据模型

对局树 = 节点（Match）+ 胜/败方链接：

type Match struct {
    ID          uint64
    Round       int              // 轮次（1 = 首轮）
    Bracket     BracketSide      // WINNERS / LOSERS / FINAL
    P1, P2      *Player          // 双方；Bye 时其一为 nil
    BestOf      int              // BO1/3/5/7
    Score       [2]int           // 双方比分（局数）
    Status      MatchStatus      // PENDING / IN_PROGRESS / DONE / WALKOVER
    WinnerNext  *Match           // 胜者进入哪场
    LoserNext   *Match           // 败者进入哪场（双败才有）
    StartAt     time.Time
    ReplayIDs   []uint64         // 关联录像 ID 列表
}

Bye（轮空）处理：选手数不足 2^k 时，前几名种子直接进下一轮。Bye 的对手 nil → Status = WALKOVER，不计入胜负记录，但必须留 Bracket 位（否则种子编号会错）。

Tie-Breaker（并列名次决胜）：循环赛/瑞士轮的常见问题，按优先级依次比较：

1. 直接对局胜负（Head-to-Head）
2. 净胜局数（Game Win Ratio）
3. 总局分（Points）
4. 公共对手的强度（Buchholz / SOS，瑞士轮常用）
5. 抛硬币 / 表演赛（真正最后手段）

三：种子分配

种子（Seeding）= 让强者不在早期相遇。三种典型：

跨赛区队伍的时区与延迟约束：

• 队伍所在赛区 → 服务器选择要能双向可接受（不能让一方 RTT 200ms+，详见 net-lowlatency-fullstack）。
• 时区差大的场次（如中美对阵）要在双方都不深夜的窗口安排；不行就先协商中立时区。
• 涉及签证/隔离期的线下赛还要预留 D-14 排期。

四：录像回放

确定性回放依赖：同一随机种子 + 同一输入序列 + 同一版本代码/数据。三者缺一，回放就"跑不出一样"。

• 格式：种子 + 版本 hash + 输入序列（按帧压缩）+ 关键帧快照（每 N 秒一份）。
• 快照点：既是回放起点（跳转 / 倍速播放的基础），也是灾难恢复点——一局打到一半服务端崩了，从最近快照回放 + 重放输入即可恢复（与 stateful-recovery 的 checkpoint + WAL 同思路）。
• 跳转与倍速：从快照 A 直接跳到快照 B 之间的任意帧，靠回放引擎快进。倍速播放不改物理，只改渲染节奏。
• 隐私脱敏：观战版本要去掉聊天、语音、账号信息；比赛版本可保留但归档时脱敏。

五：观战低延迟推流

观战不是"直播 + 拉流"，是延迟档位与业务规则的交易：

推流节点就近调度：详见 net-lowlatency-fullstack 的 GeoDNS / Anycast + BGP 章节，本篇不复述。

六：反作弊闭环

赛事期的反作弊在常态基础上加强，四步闭环：

• 常态：详见 anti-cheat（服务端权威、遥测评分、封禁申诉闭环）。
• 加强：赛事期开启关键操作服务端二次校验（比如"击杀判定"服务端复算而不是采信客户端）、录像强留、人工导播实时监控。
• 申诉窗：封禁后 24/48 小时可申诉，走独立评审组，避免误杀退赛。
• 赛后重赛判定：如果作弊被赛后确认（比如通过录像人工审核发现的开镜），要按赛前公示的规则判负 + 名次顺延或重赛。

七：作为一种活动模板接入

赛事本质是条件-进度-奖励三段抽象的一种实例（详见 activity-framework）：

• Condition：报名条件（等级/段位/绑定要求）
• Progress：赛程进度（当前轮次 / 已完成场次 / 战绩）
• Reward：名次奖励、参与奖励、单场胜利奖励

复用活动框架的好处：幂等发奖、断线补发、防重复领取、多渠道对账这些通用能力不需要重写。

为什么这么做

• 为什么把赛制模型和 BO 层数拆成两层正交：真实赛事经常"小组瑞士 BO1、淘汰双败 BO5、决赛 BO7"多种组合叠加。拆开后配置化上线一次赛事只是配几个参数，不用重写代码。
• 为什么种子必须走 MMR/积分而不是随机：随机分配头部选手会导致 1 号种子第一轮就撞 2 号种子，头部相互伤害、观赏性崩盘。种子的意义就是用赛前信息把强者晚遇作为约束。
• 为什么录像必须确定性回放：赛后申诉需要"客观回放"这一板凳。若回放跑出不一样的结果，判定成黑箱，权威性崩塌。
• 为什么观战要主动延迟 10–30 秒：反作弊的边界就是"选手看不到实时对手信息"。观战延迟越短，作弊窗口越小；但官方直播主动加大延迟是最便宜的反作弊手段之一。
• 为什么赛事复用活动框架：报名、发奖、进度、公示、防重复——这些能力在活动侧已经沉淀过一遍，赛事再自造轮子只会踩同样的坑（重复发奖、少发奖、断线补发丢失）。

为什么别的选择不行

• 只用普通匹配代替赛制：匹配面向"池子里的散人"，赛事面向"已注册的固定队伍"。前者要"快"，后者要"公平 + 可观赏 + 可复现"，目标函数不一样。
• 单败淘汰做重要赛事：一败即出局，头部选手被冷门爆冷就整场赛事看点全无。双败给败者一次复活机会，是电竞主流决赛选择。
• BO1 做决赛：偶然性太大，观众和选手都不服。决赛用 BO5/BO7 拉长样本，降低方差。
• 观战延迟不加：作弊窗口太大，被利用一次就是重大公关事故。
• 录像用状态同步：文件大 10-100 倍、成本爆炸；且状态同步的"跨版本可回放"优势在赛期（版本冻结）用不上。
• 赛事期不加强反作弊：常态反作弊的评分阈值是"错杀 vs 漏杀"的平衡；赛期"漏杀"的代价是奖金，必须调高召回宁可增加人工复审。

沉淀结论

• 赛事骨架 = 赛制模型（Bracket / 瑞士 / 循环）× BO 系列，两层正交组合配置化上线。
• 种子分配让强者晚遇：Seed by rating、Snake seeding、Random within tier 三种选一，避免头部互伤。
• Tie-Breaker 优先级：直接对局 → 净胜局 → 总局分 → Buchholz → 表演赛，必须赛前公示。
• 录像：确定性回放（种子 + 版本 + 输入序列），赛事期锁版本用帧同步。
• 观战延迟是反作弊窗口：官方直播主动加 10–30s，导播台用无延迟，付费白名单用 WebRTC。
• 赛事反作弊在常态基础上：关键操作服务端复算 + 录像强留 + 人工监控 + 申诉/重赛闭环。
• 接入 activity-framework 复用报名/发奖/进度/公示能力，不自造轮子。

记忆口诀

赛制两层：模型（单败/双败/循环/瑞士/积分）× BO（1/3/5/7）——正交组合
Bracket 三要素：Match 节点 / 胜败方链接 / Bye + Walkover 保位
Tie-Breaker 五级：直接对局 → 净胜局 → 总局分 → Buchholz → 表演赛
种子三法：Seed by rating / Snake seeding / Random within tier
观战四档：50ms 导播 / 500ms WebRTC / 2s LL-HLS / 10s HLS
反作弊四步：加强遥测 → 服务端复算 → 人工复审 → 判负/重赛/申诉
赛前三公示：断线补赛边界 / Tie-Breaker 顺序 / 申诉窗与权限——不公示必撕逼
录像三要素：随机种子 + 输入序列 + 版本冻结——缺一回放不复现

内容来源

综合整理。参考方向：Riot Games / Valve / Blizzard 官方电竞赛制文档、Challonge / Toornament 等赛事平台的数据模型公开信息、瑞士轮 Buchholz 分数在国际象棋联合会（FIDE）的定义、直播协议 HLS / LL-HLS / WebRTC 的延迟规范，以及站内 matchmaking / anti-cheat / activity-framework / net-lowlatency-fullstack 的赛事场景应用视角。

自测：合上资料能说清楚吗？