What
观看 Masahiro Sakurai on Creating Games 的视频，了解优化过程中可能会出现奇怪问题这一现象！
内容
D10 - Unexpected Results
做过不少项目，但正式版里出现意料外的结果并不罕见，有时还会让成品“变味”。
案例 1：〈Meteos〉
- 末期做了性能优化 → 整体运行更快，而游戏内部许多逻辑直接依赖运行速度，结果难度曲线被抬高、玩家更快进入吃紧局面。这并非原意。
- 末期做了性能优化 → 整体运行更快，而游戏内部许多逻辑直接依赖运行速度，结果难度曲线被抬高、玩家更快进入吃紧局面。这并非原意。
案例 2：〈甲虫王者·虫王〉
- 一直用“自制大型开发基板”调平衡，与量产机存在速度差；正式版出现饥饿值下降过快等偏差
- 一直用“自制大型开发基板”调平衡，与量产机存在速度差；正式版出现饥饿值下降过快等偏差
案例 3：〈任天堂明星大乱斗 特别版〉
- 首发版本里，大家普遍感到CPU 强度偏高；疑似优化引发的“间接加强”，但具体原因查不清。
- 若全面回调难度，会牵动巨量回归测试，代价太高。转而采取侧向对策：把“挑战者”难度调早、给“灯火之星”新增“非常简单”等；幸好有线上更新可补救。
结论：和计算机打交道，意外一定会发生；并非所有风险都在清单里，很多项目其实都在“钢丝上行走”。
方法论（避免“优化把游戏玩坏”的实用清单）
一、技术层：把“速度”从“玩法”中解耦
- 固定时间步 / 逻辑帧独立：用固定
deltaTime进行物理、AI、计时器更新；渲染可变帧率，逻辑固定步长。 - 与帧率脱钩：所有与节奏相关的数值（冷却、Buff 时长、AI 决策周期、生成频率）禁止依赖真实帧间隔。
- 平台时钟一致性：统一时间源（避免不同硬件/地区时钟差、浮点精度差）以保持决定性/可复现性。
- 速度因子总开关：全局
GameSpeed/Timescale做最后保险，出现整体快/慢时一键回调。
二、AI 与平衡：可复现、可对比、可回退
- 黄金回放（golden recordings）：录制关键关卡/AI 对局输入流，优化前后重放，TTK、DPS、通过率自动比对，发现“被优化加强/削弱”。
- 固定随机种子：平衡测试走固定 seed，减少噪声，便于比较。
- 敏感度矩阵：列出受“速度/并发”影响最大的系统（投射物、抓取/投技、体力流失、刷怪、连招窗口），重点监控。
- 难度旋钮外露：把关键难度参数做成热更新/配置化，便于首发后快速微调；预留“极易/无障碍”档位当安全网。
三、性能优化的“闸门”与回归
- 两段式优化：
- Beta 前：只做安全优化（内存、加载、I/O、裁剪）。
- 内容冻结后：再做潜在影响玩法的优化（循环并行、合批、时序改写）。
- 优化清单→行为回归：每一项可能改变时序/频率的优化，都要绑定一组行为用例（AI 反应、投射物寿命、计时器精度）。
- 平台一致性检查：开发机≠量产机，尽早、频繁在目标硬件上做节奏/时序回归（掌机、低配、不同地区机型）。
四、流程与工具：尽量让“意外”被看见
- 度量基线：为关键体验设 KPI 阈值（如“平均第 X 分钟进入高压段”），做版本间对比曲线。
- 灰度/AB：上线后以灰度或 AB 测试验证难度体感，数据+口碑双信号触发回调。
- 紧急回退路径：发布流程内置“参数热修”与“快速补丁”路径，避免因全面回归阻塞救火。
- 问题登记为“类型库”：把这类“优化→节奏漂移”的事故沉淀为清单，新项目复用。
五、设计侧的预备方案（当根因难以迅速定位）
- 替代性缓冲：像视频里那样，用早期下调挑战入口、新增更低难度/辅助功能来止血。
- 节奏托底：在关键节点放资源/复活/护甲托底点，防整体变难后玩家卡死。
- 沟通与预期管理：补丁说明清楚告知“性能优化引起节奏变化已回调/在监测”，降低负面感知。
一句话收束
任何“加速”和“并行”都有机会偷偷改写你的游戏节奏。把逻辑从帧率里解放出来，用可复现的对比与可回退的参数化，配合“优化闸门+黄金回放”，就能把“意外结果”压到最低，并保留快速修正的余地。
