开发周期中的平衡

平衡贯穿开发（p.397–398）

题记是贝尔实验室 Tom Cargill 的"九十九法则"：前 90% 的代码花掉前 90% 的时间，剩下 10% 的代码花掉另外 90% 的时间。几种平衡方法随时间此消彼长：早期观察几名试玩者价值极高，临近发售时把足够多人塞进观察室已不现实；数据分析正相反，早期数据不够统计显著，到预发布 beta 有几十万局数据时远比看几个人玩更有指导意义。

下面的时间线概括了各阶段的平衡重点：从"先好玩"到"建工具"，再到"批量产出并对齐基准"，最后"调感知最强的数字"和"用线上数据修模型"。

flowchart LR
  A["早期开发：先做好玩，只修阻碍测试的致命失衡"] --> B["首个可玩版本：小范围测试，关注宏观玩法风格平衡"]
  B --> C["Pre-Alpha：建电子表格模型，设计数据埋点"]
  C --> D["Alpha：功能完整，内容批量产出，对齐香草基准"]
  D --> E["Beta：内容完整，调玩家可感知的数字，大规模测试与数据分析"]
  E --> F["上线后：用线上数据修正模型，新内容与平衡补丁"]

早期开发（p.398–401）

机制剧烈变动，目标是好玩（或达成设计目标），先把反复出现的核心玩法做扎实——"先好玩，后平衡"。唯一例外：失衡严重到妨碍有意义的测试（例如发现一个绕过大部分机制直接获胜的退化策略），这时用粗暴手段削弱到可以继续测试即可，这类问题通常也很明显。

没有模型、测试和数据时，第一批数字从哪来？

• 先决定基调：要么一切都"超模"（只要超模程度一致，仍可平衡），要么什么都不超模。史诗感的游戏用夸张的大数字和强烈反差——吸收数百万伤害的护甲、需要科学计数法显示的叠加伤害、近乎瞬移的速度，向极端推，只在必要时收回；写实风格的数字集中在窄区间，大偏离就是会吸引玩家注意（和日后设计审视）的例外。最要避免的是大多数平平无奇、少数完全超模——只有少数东西重要，其余设计都成了垃圾。
• 再想每个对象的用途与角色：职业是输出、保护队伍还是增加掉落？射击游戏里的武器适合开阔地远程、狭窄隧道近战，还是打大而慢的载具？RPG 护甲防物理、防魔法、靠闪避，还是只加输出属性？塔防的塔对付集群、单体 Boss、重甲、快速敌人，还是增益友塔、减益敌人？敌人要让玩家觉得强大、聪明还是害怕？
• 然后找能实现它的数字："玻璃大炮"就把输出属性拉满、承伤属性压到最低。这不是最终数字，早期目的是定基调而非平衡。
• 只做最少的代表性内容：将来有 100+ 角色的 MOBA，早期只需 DPS、坦克、辅助三个代表；若一个"香草 (vanilla)"角色就能代表所有角色，就只做它作为基准。
• 记录每个对象的用途和设计旋钮：一句话到一段话写明它在游戏中的角色、哪些数字可改、哪些不可改、哪些约束不能违背其存在初衷。真正开始平衡时几乎总会发现差得很远，这些笔记能避免做出日后又要撤回的改动。即使"错"的数字也在培养系统设计直觉。

首个可玩版本（p.401–402）

有 bug、缺内容和关键系统，但能坐下来玩出某种体验。测试范围很小：商业项目可能尚未公布，只限团队或签了保密协议的亲友；桌游则是家人朋友或本地测试小组。仍不专门测平衡，而是看游戏是否吸引人、核心机制是否成立、脑中的愿景是否接近实际体验（答案大概率是"差得远"——这正是测试的意义）。唯一要留意的平衡问题是宏观层面：几个"香草"角色代表的玩法风格之间，是否因核心机制（而非数字）天然偏向某一种——例如远程相对近战太强，不必立刻修，但要记下并考虑调整机制。

对待测试者反馈：测试者的职责是发现问题而不是给出方案。

• "我不喜欢这个"——有用，提醒了问题，接着找原因并从根源解决；
• "我不喜欢这个，因为……"——更有用，替你做了一半工作；
• "我觉得你应该把它改成那样"——用处较小，工作量翻倍：先反推他想解决的（真实或想象的）问题，再找原因和改法，而你的改法通常不是他建议的那个。

玩家的批评通常归结为：他们脑中理想的游戏与正在玩的不同。设计师要先弄清他们想的是什么游戏，判断那是否就是你要做的游戏，再决定改呈现方式（让人看清你在做什么游戏）还是改游戏本身。

Pre-Alpha（p.402–403）

核心机制基本固化后开始建数学模型：用电子表格公式描述机制间的关系，作为日后的平衡工具，趁机制不再变动时把工作前置。初版模型必然是错的，越早开始越有时间发现，例如模型显示"毒"是最强法术、"火球"最弱——原来把持续伤害等同于即时爆发伤害了，对未来伤害打折后才合理（数学建模见 成本曲线与支撑数学）。

这一阶段还要设计数据埋点：需要采集和存储哪些数据才能支撑日后的平衡决策？要权衡程序员时间（不做游戏而做埋点）、带宽与存储（什么都记导致动作游戏掉帧就是问题），与程序团队商定优先级（数据分析流程见 数据分析与平衡）。重点仍是建平衡工具而不是平衡本身，除非测试中有阻碍进度的强烈抱怨。

Alpha（p.403–406）

没有行业统一定义，通常指功能完整 (feature complete)：机制都已在游戏中、引擎可用、所有系统可玩，但缺大量内容、bug 多得"像昆虫实验室"；核心设计基本锁定，此后新增功能要走正式的变更申请流程。

• 内容批量产出并对齐基准：怪物与物品表、角色阵容、对话树、关卡布局等在此阶段大量产出，用早期的"香草"资产作为基准。以《任天堂明星大乱斗》这类有上百角色的游戏为例：100 名角色、4 人对局（不许重复选）的组合接近 400 万种（$\binom{100}{4}=3{,}921{,}225$），不可能逐一测试；若已有几种相互平衡的原型角色 (archetype)，只需把每个角色与其原型对齐，即 100 组对比。基准角色甚至可能不进最终游戏，它们只是量尺。但这不保证全局平衡：某角色理论强度合理，却可能对多数角色有天然克制而在元游戏中失衡——所以这只是用最少时间进入"大致范围"的方法，尤其适合格斗、MOBA、TCG 这类无法穷举组合的游戏。
• 调数字的方法：早先的表格模型此时能以最少精力产出大致平衡的内容。不清楚数字该在哪时先走极端：取值 0–100 就先试 0、100、再试 50，形成直觉再微调；改动要大——没把握时翻倍或减半，有把握时也不少于 10%（再小大概察觉不到）。没有模型也得给新内容赋值，但后面要返工、要花更多测试时间。
• 测试：仍以团队和亲友为主，但可以开始请人专门测平衡、找漏洞，并首次检验模型是否准确：你认为更难的关卡、更强的武器，玩家是否同意？测试者集中使用某些看似有效、却与模型预测不符的策略时，正是修订模型的好时机。

六类测试者（Jaime Griesemer 的经典 GDC 演讲）：要关注反馈来自谁。

Beta（p.407–408）

老笑话："alpha 是古希腊语'软件坏了'，beta 是古希腊语'软件还是坏的'"。同样没有统一定义，通常指内容完整 (content complete) 且功能完整，可从头玩到尾。此后只剩修 bug：负责人定期开会做分诊 (triage)——哪些阻碍测试要立刻修、哪些发售前修、哪些可以等。程序部门忙着灭火，设计团队则回答"是否按设计工作"的问题，并大量做最后的数值平衡——调单个数字比改整个机制容易得多也便宜得多。此时可以抢先体验或封闭/公开 beta，大项目由此获得足够大的数据集做数据分析；若事先告诉社区平衡会经常调整，甚至能成为玩家的期待话题（《杀戮尖塔》设计师的 GDC 演讲讲的就是这种做法）。

指导原则：平衡关乎玩家感知，不亚于实际公平。时间永远不够，优先调影响最大、最显眼、玩家能直接感知的部分：

• 玩家难以感知随机范围——把武器的随机加成从"+0 到 +10"改成"−3 到 +15"，远不如改基础伤害明显，因为玩家只看到结果，要很多次才察觉变化（除非显式显示范围和掷骰）。
• 改平台跳跃的物理与改后台伤害公式相比，物理更直接、可感、本能，改动对体验的影响更明显。

上线后（p.408）

MMO、在线 TCG、F2P 手游等持续开发新内容乃至资料片。带全新机制的内容会按与原作类似但更短的阶段开发，且起点信息更多，平衡工作可集中在新机制与旧内容的关系上。线上玩家数据让你修正数学模型以贴近实际玩法，从而更容易平衡新内容；有时还可发布平衡补丁——加强一无是处的东西、削弱在元游戏中造成问题的东西。

为平衡而测试（p.409–410）

设计师要给测试者明确方向——对多数测试组只说"测一下平衡"只会换来茫然的眼神。小规模测试（桌游、纸面原型）的通用建议：

• 尊重时间：核心问题一有答案就提前结束（除非对方主动想继续）；娱乐时中途散局很失礼，测试时这样做反而是尊重。
• 带着目的测试：知道要回答什么问题（"好玩吗？""平衡吗？"），据此安排测试。
• 除非保密对结果有效性很重要，否则告诉测试者测试目的和方法。
• 确保要测的事情发生：想知道"这张牌早抽到是否超模"，就把它叠在牌堆顶；电子游戏要请程序加作弊码辅助测试——作弊码常被保留到正式版，因为玩家也喜欢；看一款游戏有哪些作弊码，大致就知道哪些功能对简化测试最重要。

测整体平衡时，让测试者为赢而玩（擅长者"像金子一样"，要好好对待）：

• 试退化策略：抓住一个超模的东西反复用——无构筑限制的 TCG 放 100 张同一张强卡、格斗游戏狂按一招、塔防只造一种塔。这种玩法自己无聊、对手（若奏效）极度受挫，正是要避免的"把乐趣优化掉"。
• 当个彻头彻尾的混蛋：背刺、做极不公平的举动、除非有足够物质好处否则拒绝合作，在不作弊的前提下为一点优势不择手段。若刻薄能在游戏中得到奖励，玩家就会刻薄，要测出来确保游戏不激励玩家恶待他人。
• 进一步可读 David Sirlin 的免费在线书《Playing to Win》——相当于竞技游戏/电竞语境下的《孙子兵法》，深入展示竞技心态。

延伸资源：Jaime Griesemer《Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3》（GDC 2010）；Anthony Giovannetti《Slay the Spire: Metrics Driven Design and Balance》（GDC 2019）；David Sirlin《Playing to Win》。

课后练习要点（p.411–414）

讨论题包括：过早或过晚开始平衡的后果；何时开始由设计师亲自观察的小规模测试；在机制可玩之前就建电子表格模型的风险；功能完整与内容完整的区别；封闭 beta 与公开 beta 中观察测试结果的差异；何时设计埋点、何时最依赖数据；自己最像六类测试者中的哪一类；银河恶魔城测试者建议"加大初始短程枪射程"时如何回应。

• 支线 15.1 作弊码：选一款有作弊码的游戏，列出全部作弊码，推测开发团队如何用它们测试。
• 支线 15.2 BattleBattle（Eric Zimmerman 为教平衡而设计的双人骰子游戏）：以 5 生命、3 个 +1 骰值标记的"Vanilla"为基准，把 28 个大多不平衡的角色逐一对 Vanilla 测试并做一两处修改（生命、标记数、特殊能力、骰面）；再让修改后的角色两两对战继续调整。终极挑战是自己设计角色，检查三点：是否有有意义的选择（反例 Dalek 毫无选择）；是否对 Vanilla 平衡且不易与其他角色形成极端克制（反例 Cat 用标记而非生命抵挡伤害，遇到额外伤害或干扰标记的角色会极强或极弱）；机制是否符合主题（反例 Sniper 没有任何狙击手的感觉）。随后随机分发角色举行比赛：个人按胜负排名，角色按终局剩余生命衡量平衡——1 血险胜说明接近，大比分碾压说明悬殊，平均剩余生命最低的角色最平衡。
• 法师主线第 6 部分（最终部分）：找人一起"打破"第 4 部分调整过的卡组或单卡（50 张、每张行动卡最多 3 份），发现过强的卡、组合或卡组就手动改费用，并回头检查成本曲线与支撑数学，找出其他需要修改的卡。

原书问题

数值核对：p.404 $\binom{100}{4}=3{,}921{,}225$，"接近 400 万"✓。

与其他书的对照