格斗游戏
🏦 场景与客户
一家有格斗情怀的小团队，做一款二对二格斗游戏，目标平台主机与 PC，核心是在线对战与线下赛事。团队不到二十人，程序 4 人，其余是动作与特效美术。
格斗游戏的成败几乎全在帧数据上。项目初期，招式的起手、判定、收招帧靠策划在文档里手写，程序另抄一份到代码里，两份长期不同步；判定框与角色模型对不上，画面上明明打中了却判定落空。上线联机测试时，玩家反馈「明明先出手却被反打」，两边屏幕上的画面根本不是同一局。
📅 实施节奏
- 第 1–3 周：建立帧数据表，把每个招式的各阶段帧数、取消窗口、无敌帧统一到配置里
- 第 4–6 周：做判定盒可视化工具，可在编辑器里直接画出受击盒与攻击盒，并逐帧预览
- 第 7–10 周：对战同步改为确定性帧同步，输入带帧号上行，两端各自推进
- 第 11 周起：加入回滚与训练模式，把帧数据以可读形式展示给玩家
🗝️ 方案要点
- 帧数据唯一来源：招式数据只存在一处，程序与文档都从它生成，杜绝两份数据打架
- 判定与表现分离：命中与否只看判定盒与帧窗口，特效和受击动画跟着结果播
- 输入缓冲与容错：连段的衔接留若干帧宽容窗口，玩家的操作意图不会因为一两帧的误差被判失败
- 回滚式联网：本地输入立即生效，远端输入到达后重演修正，保证双方看到同一场比赛
⚖️ 选型与权衡
| 选择点 | 方案 | 权衡 |
|---|---|---|
| 同步方式 | 帧同步 + 回滚 | 延迟感最低、回放天然支持；代价是逻辑必须完全确定，一处浮点误差就会让双方画面分家 |
| 判定容错 | 留输入缓冲窗口 | 新手更容易打出连段；代价是硬核玩家会觉得「这也能接上」，削弱了操作的精确回报 |
| 帧率 | 逻辑固定帧率，画面不锁 | 判定稳定、手感一致；代价是画面需要插值，快速镜头下可能出现轻微抖动 |
| 训练模式 | 开放帧数据与判定盒显示 | 社区研究氛围好、寿命长；代价是数值被完全看透，后续调整的每一步都被放大审视 |
🚧 实施难点与排查
- 画面上打中却没伤害：判定盒位置取自模型骨骼，动画混合时骨骼偏移。改为判定盒与骨骼解耦，用独立数据驱动
- 连段在联机下接不上：两端帧号对不齐导致取消窗口错位。统一以帧号而非真实时间判断窗口后解决
- 回滚后画面跳变：重演改变了逻辑位置。做法是逻辑照常回滚，表现层用插值追平，不做瞬移
- 角色之间强度失衡：某一招因判定的有利帧过多而变成万能解。改由帧数据表统一审查，把「有利帧」作为显式指标管控
💵 成本与收益
- 成本：工具与同步重构约 3 人 × 10 周；联网对战带宽需求极低，服务器成本可控
- 收益：平衡性调整从「凭感觉改」变成「改表 + 回放验证」；社区对判定透明度的抱怨大幅减少
- 省钱的点：确定性模拟让 bug 可以用回放精确复现，省下大量靠人肉重打的测试成本
🛡️ 风险与保障
- 公平：服务端校验输入序列合法性，异常高频输入直接拒绝
- 反作弊：结算由服务端重演确认，客户端上报结果不作为唯一依据
- 断线：支持短暂断线后按输入补齐继续，不直接判负
- 可追溯：每局保留输入序列，赛事争议局可完整复盘
♾️ 可复用与演进
- 帧数据表与判定盒工具可以直接复用到动作、横版过关等品类
- 演进方向：基于回放数据统计各招式的使用率与胜率，让平衡调整有据可依
- 再进一步：把回放做成观战与集锦的素材来源，服务赛事与社区生态
