当玩家使用某个机制时所感受到的满足感来自于一个有序的五层层次结构：

1. 实现
2. 感觉
3. 掌握
4. 目的
5. 有意义的选择

每一层都建立在前一层的基础之上。如果一个机制没有完全实现，它就不会有好的感觉。如果一个机制感觉不好，那么掌握它将会很痛苦。如果没有目的，那么掌握它将毫无奖励。如果两个机制的目的重叠或目的不明确，那么你就无法做出有意义的选择。

实现

• 一个功能必须完全实现。
• 为此，必须合理地设定时间框架并进行相应的计划。
• 了解你的创意需要多少工作量。

无论你的机制多么有趣、深思熟虑或平衡，如果它不能正常运作，你不能指望有人会使用它。这不仅仅是程序员的责任——设计师也要承担责任。

设计师必须始终考虑他们的创意需要多少工作量，否则它们会毫不留情地从游戏中被砍掉；更糟的是，以半成品的状态发布。

当事情出错或进度落后时，很容易责怪他人。然而，设计师必须对实现失败负责。记住你的系统需要每个部门投入多少工作量，因为最终，我们处在责任的顶端，所有糟糕的创意都会影响到整个团队……

感觉

• 一个功能必须使用起来感觉良好。
• 这将比你想象的需要更多的时间。
• 不要过分依赖以往的经验，或假设每个功能都可以以完全相同的方式实现。
• 确保向他人展示它。

机制的感觉全在于你第一次使用它时的反应。当你开枪时低音炮的震撼感，或是你第一次用闪电击中敌人时他尖叫和颤抖的样子。它看起来如何，听起来如何，敌人对此的反应如何，使用起来有多难，按键是否合适？机制的感觉极难把握，但也极其重要。如果感觉不好，你不会坚持去掌握它。

如果你是一个特别分析型的设计师（像我一样），很难专注于某物的感觉。机制的感觉更多是关于直觉而非“科学”。我合作过的最佳设计师对这个过程阶段几乎有狂热的激情。在制作《战神》时，我会看到设计师加载一个小竞技场，只有奎托斯和一个单独的士兵。他会花接下来的几个小时用尽可能多的方法击打那个敌人。将士兵击飞到空中并按下轻攻击按钮，他会发现只有两次打击感觉不对，于是调整怪物的下落速度。这种改变不是基于任何量化的数值，而只是因为感觉不对。

那些老版《战神》敌人的按钮小游戏是最难掌握的部分之一。按钮出现的确切时间和持续时间都很棘手。这也是“科学”和“感觉”之间区别的一个很好的例子。

科学上，如果你想要一个有一定难度的按钮窗口，大约15帧（0.5秒）是合适的。这通过无数创建的小游戏得到了验证。它是量化且被验证的，是定律。

然而，有一个特定的敌人，设计师在实现时让我试试小游戏。我玩了几次，觉得有点难。他指出按钮在怪物发生某些酷炫效果时出现，所以我的目光被吸引到怪物上，错过了早期的帧。为了解决这个问题，设计师增加了按钮窗口的帧数，并调整了按钮出现的时间，结果感觉完美。即使科学告诉你它应该是某种方式，机制的感觉要求改变。

掌握

• 核心功能必须提供引人入胜的掌握曲线。
• 掌握带来兴奋感和长期享受。
• 确保有奖励时刻，否则玩家会放弃。
• 需要进行游戏测试以确保掌握曲线的正确性。
• 并非所有功能都需要长掌握曲线。

有些机制难以掌握，比如在FPS中用火箭弹瞄准目标，而有些则容易掌握。掌握带来的兴奋感在于有效使用机制时的快感，越难掌握越有满足感。挑战是好的，但要确保机制不会难到让玩家因沮丧而放弃（尤其是核心机制）；反之，太容易则不会有满足感。想象一下，如果狙击步枪自动瞄准敌人的头部，满足感会转瞬即逝。

掌握某物的过程不是线性的。刚开始学习时很难，但进步很快。随着时间推移，使用机制变得容易，但进步（技能提升）开始减慢。丹尼尔·平克在他的书《驱动力》中对掌握的描述非常精彩。他说：

掌握是一个渐近线。你可以接近它，可以瞄准它，可以非常非常接近它。但……你永远无法完全触及它。完全实现掌握是不可能的。乐趣在于追求而非实现。最终，掌握之所以吸引人，正是因为它难以实现。——丹尼尔·平克

你可以在许多成功的游戏中看到这一点，但我认为最好的例子之一是《魔兽世界：经典版》。在《魔兽世界》中，你不断掌握新事物，游戏以一种让你不会感到不知所措的速度将它们展示给玩家。在游戏的最初几个小时里，你会连续升级，帕夫洛夫设计的（杀敌->经验->升级）机制非常吸引人，因为你不断得到酷炫的奖励。到了50级时，你已经意识不到获得同样奖励需要几天时间。很多人（通常是那些没玩过的人）抱怨《魔兽世界》（以及MMO游戏）的西西弗斯性质。

这些抱怨……部分是正确的。在《魔兽世界》中，你确实推石头上山，但不是永远如此。刚开始时是一个很小的山丘，你最终会把石头推上去。你感觉很棒；你掌握了世界的一部分。然后游戏对你说，“嘿，伙计，看看那边更大的山丘。”于是你卷起袖子开始推。

很快你就把石头推过那个山丘，游戏狡黠地指出一个更大的山丘。这种情况不断重复。通过掌握->奖励->掌握的巧妙设计，游戏以一种让你永远不会感到不知所措的速度展示新事物，并将所有机制编织在一起，创造了一个整个游戏都遵循掌握渐近线的情景。难怪人们会如此上瘾。

目的

• 核心功能必须有明确传达的目的。
• 目的是人们追求掌握的关键原因。
• 次要和第三层功能和机制也应该有目的，但不需要如此明确传达。

有多少次你看着屏幕大喊：“这东西到底有什么用？”可能比你能数得清的次数还多。为你的机制定义一个目的至关重要。一个强有力的目的不仅有助于你克服掌握曲线的初始“陡峭”，还提供了有效使用它的额外满足感。设计师的工作不仅是确保机制有明确的目的，还要确保这个目的清晰传达给玩家。

想象一个游戏有两种敌人：人类和外星人。再想象玩家有两种手枪。这些手枪看起来相似，开火时发出的声音相似，敌人被击中时的反应也相似；然而，第一种手枪对人类造成额外伤害，第二种手枪对外星人造成额外伤害。在这个例子中，玩家完全不知道哪种手枪更有效。拿起第二种手枪后，他可能会开几枪，疑惑它的用途，然后回到已经使用（掌握）的手枪。

所有时间都花在了创建一个未使用的物品上，这只是问题的一部分。更糟糕的是，玩家会因为不理解第二种手枪的用途而感到愚蠢，而这显然不是他们的错。

有意义的选择

• 玩家必须有选择的权力，否则我们就不是游戏。
• 选择的权力必须在有目的的选项之间，否则就是无意义的选择。
• 通常有两种有意义的选择：战略性和战术性
  • 战略性：影响未来的选择
  • 战术性：影响当前的选择
• 不要给玩家太多选择，否则他们无法分析自己的选择。

体验层次结构中的最后也是最难的一层是有意义的选择。选择是将游戏与其他娱乐媒介区分开的因素，而选择背后的意义使游戏如此有趣。如果你曾玩过大富翁游戏，你很可能遇到过选择失去意义的时刻。

在大富翁中，总有一场游戏某个混蛋拥有大量财产和金钱，而你勉强维持着破烂的小道。当你处于劣势时，几乎不可能翻身。你可以选择掷骰子，或者你可能攒够了钱升级你破烂的房产，但那有什么用？所有玩家都知道游戏结束了，但游戏仍在继续。因为你的选择此时没有意义，游戏就不再有趣。

有意义的选择有两种：战略性和战术性。战略性选择是高层次的选择，涉及到未来的视角（我的法师应该专攻火系还是冰系）。战术性选择是低层次的选择，涉及到当前（这个怪物是火系的，所以我要用水系）。有些人倾向于专注于其中一种。我个人特别喜欢有战略性选择的系统。我会花几个小时决定“完美”的RPG职业构建，然后一旦搞定，就会转向其他东西。这并不是说我不喜欢没有战略性选择的游戏，只是我特别容易被有大量战略性选择的游戏吸引。

话虽如此，你必须小心不要给玩家太多选择。选择越多，玩家做出有意义选择的难度就越大，因为他们无法准确判断一个选择相对于另一个选择的价值。这有时被称为“选择悖论”，这是你必须时刻牢记的。你可能认为你的游戏很棒，因为它提供了各种现代突击步枪的变体，但作为玩家，我只会感到完全不知所措。在这种情况下，拥有这么多武器会导致用途的巨大重叠。作为玩家，我不仅会挣扎于选择哪种枪，当我最终做出选择时，我会对自己的选择感到不满意，因为我会不断怀疑是否有更好的选择。

原文是Damion Schubert在GDC的一次演讲稿件，这里进行了转换和翻译。

关于作者

我听到的声音

• “设计文档是浪费时间”
• “没有人阅读设计文档。”
• “我的程序员觉得审查设计文档完全是浪费时间。”

这可能是对您文档的评价，而不是对文档本身的真实证明。

严酷的真相

• 所有设计师都应该想要分享他们的想法
• 所有程序员（和其他团队成员）都应该想要知道他们正在构建什么。
• 另一方面，大多数设计文档并不是很好，而大多数文档流程忽视了寻找乐趣的迭代性质。

文章目录

• 设计文档的目标
• 为什么好的设计文档很少
• 撰写游戏设计文档的规则
• 给leader的提示 – 建立游戏设计文档流程

优秀文档的目标

• 捕捉设计共识
• 部门之间的主要愿景渠道
• 有助于排期
• 提供焦点
• 给予未来依赖关系和设计冲突的可见性

为什么好的设计文档如此稀缺？

• 大多数游戏的设计文档涉及复杂且相互关联的系统。
• 设计师往往过度设计。
– 系统的设计时间通常少于制作时间。
– “愚蠢的大书”
• 大多数设计文档没有拥抱迭代。
• 大多数文档在项目进展中很少保持更新。

良好设计文档的法则

其他开发者说：

1.了解你的目标受众

• 对设计文档感兴趣的人：
– 设计团队。为了达成设计共识。
– 程序开发团队。为了构建游戏。
– 制作人。为了排期和获取资金。
– QA。为了制定测试计划。
– 外部合作伙伴。为了满足烦人的需求配额。

2.保持简短

• 简短的文档：
– 更容易阅读
– 更容易撰写
– 更容易维护和保持更新
– 更容易处理政治问题
– 不太可能出现矛盾
– 更可能是简单的设计

• 干掉多余的内容
• 干掉空白部分
• 干掉“复制粘贴”的内容
• 干掉不言自明的文本

太长了：

• 公会邀请确认UI。玩家在创建公会时会收到一个确认UI，询问“您真的想加入这个公会吗？”并有一个“确定”按钮和一个“取消”按钮。
  • 确定按钮。确认UI有一个确定按钮，用于确认公会的邀请。
  • 取消。确认UI有一个取消按钮，防止公会的成立。
  • 关闭按钮。UI右上角有一个“X”按钮，其功能与点击取消按钮相同。
  • Esc。按下Esc键将取消交易，其功能与点击取消按钮相同。

更好：

• 公会邀请确认UI。玩家在被邀请加入公会时会收到一个确认对话框（见通用对话框.doc）。

谁在乎？

制作税。赫淮斯托斯，锻造之神，已将他的意志施加于雅典的工匠们，所有人都因他的伟大而感到谦卑。因此，任何希望制作物品的玩家必须向赫淮斯托斯的神庙支付税金，以赢得他的青睐，除非该玩家找到了像“众神之锤”这样的物品，允许玩家绕过这些税金。

更好：

• 制作税。玩家在制作物品时必须支付金币（向当地神庙的税金）。
• 绕过税金。某些工具允许玩家绕过税金。

• 记住：
– 程序员几乎总是想要一个简短的项目列表
– （他们喜欢在列表上勾选事项）

3.划分优先级

• 给功能设定优先级，将其分为不同阶段。
• 确保文档清楚地区分后期阶段的功能。

错误！

• 玩家可以在背包界面上装备物品。
• 装备的物品会改变玩家的战斗属性。
• 玩家装备在穿戴时可见。
• 玩家装备可以附加魔法效果。
• 玩家可以在其盾牌上绘制公会徽章。

仍然不够好

• （第1阶段）玩家可以在背包界面上装备物品。
• （第1阶段）装备的物品会改变玩家的战斗属性。
• （第2阶段）玩家装备在穿戴时可见。
• （第2阶段）玩家装备可以附加魔法效果。
• （第4阶段）玩家可以在其盾牌上绘制公会徽章。

更好

开发阶段的划分：

•第1阶段：原型功能
–（必要以验证或演示游戏）
•第2阶段：核心功能。
–（包含支撑内容创建的功能和工具）
•第3阶段：必须在发布产品中
–（包括依赖于第二优先级功能的功能）
•第4阶段：愿望清单，可能是扩展
•第5阶段：完结

• 优先级是跨项目的，而不是单一功能 。整个功能或文档可能充满第2、第3或第4阶段的功能。

4.举例

• 一图胜千言。
• 策略：
  – 其他游戏中类似功能的屏幕截图。
  – Visio图表
  – “示例”文本

例子

5. 不要告诉别人如何做他的工作

这有什么问题

• 图片越抽象，读者越容易投射自己的观点。
• 假设你有一个称职且薪水丰厚的UI艺术家，你希望给他们的想象力留出空间——不要试图做他们的工作！

更好，信不信由你

这不是你的问题！

“任务.doc”

• 任务变量将存储在角色对象的位向量链表中。

这是你的问题，让程序员来解决它。

“任务.doc”

• 任务变量的内存考虑。
• 游戏中将有大约2500个任务。
  • 玩家最多可以同时拥有20个进行中的任务。
  • 玩家在一个任务中可能有多达10个决策点，状态必须在任务完成之前存储。
  • 玩家可能会找到后续内容，这些内容由他们已经完成的任务解锁——任务的完成状态（和结果）必须被存储。

6.使用用户故事

• 独立 – 不与其他用户故事重叠
• 可协商 – 细节和实现不如最终用户满意度重要。
• 有价值 – 以最终用户为中心撰写。
• 可估算 – 详细到足以让程序员进行架构和排期
• 小 – 不超过一周。
• 可测试 – 设计和编程可以达成一致，确认何时完成。
以上是SCRUM对用户故事的规则。

• 玩家在升级时听到一个音效。（太小了）
• 玩家可以选举新的太空大使。（太宽泛了）
•当玩家升级时，他听到一个“叮”的音效，看到一个粒子效果，获得3个属性点，获得5个技能点，并在达到10级时获得一个声望职业。（太长了）

一个用户故事（包含子任务）相当于2-5个编程工作日的工作。

• 玩家在跨越经验值阈值时升级。
– 玩家听到一个“叮”的音效。
– 玩家看到一个粒子效果。
– 玩家获得5个属性点，可以用于他的属性。
– 玩家获得3个技能点，可以用于他的技能树。
– 如果玩家达到10级，他可以获得声望职业（见声望职业.doc）。
注意每一个都以玩家开头

7.代码和内容分开

可怕的列表

• 制作工具。一些制作技能将需要制作工具才能使用，否则玩家将收到错误消息，提示他无法使用该技能。
• 锻造。使用锻造技能需要铁匠锤和钳子。玩家可能最终会找到更高级的锤子和钳子，从而获得更多的制作选项。
  • 裁缝。成为裁缝需要一个织布机。
  • 炼金术。炼金术需要一个试管套件。玩家可能最终会找到更高级的试管，从而获得更多的制作选项。
  • 雕塑。雕塑需要一个锤子和凿子。

只有两个要求 – 简单！

• 制作工具。一些制作技能需要制作工具才能使用，否则玩家将收到错误消息，提示他无法使用该技能。
• 高级工具。一些制作技能允许玩家使用更强大的工具制作更强大的物品。

制作技能和工具
技能	工具	高级工具
锻造	锤子和钳子	是
裁缝	织布机
炼金术	试管套装	是
雕塑	锤子和凿子

• 不要让人们为他们想要的信息而苦苦寻找。
• 将内容分成附录或表格。

8.使用良好的格式

• 使用团队模板
• 更改字体
• 使用水平线
• 使用示例框
• 使用项目符号列表
• 但不要成为格式的奴隶

• 使用默认的幻灯片模板，效果不是很好，对吧？
• 花一点时间更改字体或添加水印可以对文档的专业感产生巨大影响

9.使用清晰的术语

不要假设你的读者知道什么！

• 这个法术有高DPS，但也有一个减少仇恨的成分，以减少在团队中的仇恨。
• 每个超级块最多只能有6个生成代理。

• 使用简单语句
• 避免奇怪的术语
• 避免公司特定的术语
• 一致地使用新术语
• 考虑使用术语表

10.消除冗余

重复是魔鬼，会导致混淆和更新错误。

跨模块的冗余！

在一个文档描写规则，其他文档引用它。

11.没有弱语言

不可以！

• 玩家可能能够吸引异性 NPC。
• 将来，我们可能会增加通过演奏感人的情歌来提高吸引女性的机会的功能。
• 如果实现了这一点，玩家可能可以创作自己的情歌。

更好！

浪漫 NPC                             （原型阶段）
• 玩家可以通过对话选项尝试吸引异性 NPC
• 玩家还可以通过吟唱他们学到的歌曲来尝试吸引异性 NPC。

高级浪漫                              （第四阶段）
• 玩家可以为浪漫系统创作自己的歌曲。

•使用强有力的、明确的语言
–不要使用“可能”、“可以”、“也许”
–甚至避免使用“可能”。
•不要模棱两可
•不要说“我们”
•选择一个方向
•将“可能”功能移到后期阶段。

12.记录你的推理

记录思考的过程，但要和正文分隔开

不可以！

• 玩家不能将物品放在地上。这是为了减少视觉杂乱，并确保玩家不会通过放置数百个物品而造成干扰。

更好！

• 玩家不能将物品放在地上。
…
常见问题解答：为什么玩家不能将物品放在地上？
这是为了帮助减少视觉杂乱，并确保玩家不会通过放置数百个物品而造成干扰。

• 记录你的推理对于较长的项目尤其有用，因为团队可能会忘记他们为什么选择了某一方。
• 记录你的推理，反过来，减少了有争议的问题被重新提出的次数。

给Leader的提示

1.拥抱迭代设计

•将下一个立即阶段设计得非常详细
•将远期阶段设计到人月级别
•不要让设计师对远期功能产生情感投
•随着设计的变化和迭代，重新审视文档

2.使其可搜索

• 设计文档只有在用户能够找到所需内容时才会被用作参考。
• 可能的方式：
–Wiki
–桌面搜索
–设计圣经

3.尽可能自动化

• 需要证据？
–Thottbot, Wowhead, Allakhazam

•文档自动化的优势：
–准确性，即使是事后
–可搜索
–易于添加审计和报告

4.设计文档是一个协作过程

5.始终从启动会议开始

• 设计师与主设计师会面，并回答以下三个问题：
  – 这个系统的目标是什么？
  – 这个文档应该回答哪些问题？
  – 这个系统的复杂性可以达到什么程度？

启动会议

“目标是什么？”
–证明系统的合理性
–帮助决定边界问题
•示例：以下两个目标是有价值的，但如果设计没有提前规划，它们是矛盾的。
–“制作是一个副业，可以填补空闲时间，并可以在现场进行。”
–“专注的工匠可以拥有自己的熔炉和铁匠铺，获得声望和财富，为其他玩家服务。”

“这个文档回答哪些问题？”
–由于所有系统最终都会相互影响，所以重要的是决定文档写到哪为止。
–允许领导安排文档编写过程。
–防止过早行动
–防止设计“抢占”
–突出第一阶段功能

“复杂性可以达到什么程度？”
–代币表示。我们只想要盒子上的要点
–竞争性。我们希望拥有市场领导者的功能，进行小幅调整，但不想冒太大风险。
–替代。没有太大的东西，但绝对不同于我们的竞争对手。
–创新。这个功能将击败对手，我们将听到她们的哀号。

6.有一个审批流程

•应该逐步进行
–主设计师首先批准
–设计团队随后批准
–高级领导/跨团队随后批准
•这种方法允许设计团队就完成的设计以统一的声音进行交流。
•启动通常很难，但一旦团队成员发现价值，通常会加速。

7.强制专家咨询

•强制你的设计师在任何文档上都不要在真空中工作。他们应该寻求相关专家的意见。
–团队中的其他设计师。
–构建该功能的工程师。
–具有独特专业知识的艺术家或程序员。
–使用工具的‘客户’。
–如果其他项目团队的见解特别有价值，也要咨询他们的成员。

8.建立一个可视化的进度跟踪方法

9.建立一个变更流程

•随着游戏的迭代，设计将会发生变化。需要一个流程来确保设计变更传达给团队的决策者。
•主设计师通常可以作为仲裁者，决定何时需要通知高级领导并/或批准重大变更。

10.不定期审核流程

•设计文档的流程必须为团队服务。如果团队认为文档流程是压迫性的，设计文档流程最终会被颠覆。
•永远不要失去对目标的关注：
–简短
–保持更新
–对程序员友好
•每4-6个月，问问自己（和你的程序员）什么有效，什么无效。

构建费用的基本目的是让游戏可以有许多玩法物件的乐趣。如果这些物件确实做到了各不相同，那有些必然会特别强力，也就意味着这些物件会更容易让你获得胜利。如果星际的虫族农民、机枪兵和航母战斗力一模一样那这游戏会相当无趣。但如果我们想要玩家也会用那些非强力物件，我们就需要为强力物件分配高一点的费用，为弱小物件分配低一些的费用。

精准的费用和良好的游戏平衡并非只是为了那些最老练的玩家。也是为了那些菜鸟玩家(这点也许更为重要)，以此保障他们的游戏体验。如果航母的费用太高，那就永远不应该建造它们。如果盗贼比别的职业弱，那选择这个职业的玩家(由于无知或由于个人口味)就“犯了个错”。别的玩家会让他们知道(自己做错了)，而这些玩家可能会对这个游戏失望。所以你得保证有一些基本的玩法选择是合理的，并非说它们要始终正确而是在于它们不能始终错误。

一个游戏有多少合理的选择很大程度上取决于游戏类型。在一款RTS中，你可能想要每个单位都是一个合理的选择，至少在某些情况下。想必你想要MMORPG中的每个职业都是可用的。但是当物件数量非常多之后——一整套万智牌的卡牌或MMORPG的道具——你可能不想它们全都是可用的，甚至即便你想你也没办法让它们都能用。

不想让这些物件都可用是因为比较它们的好坏正是游戏乐趣的一部分。升级你的牌组、军队或角色是人们玩游戏的一大原因。如果有些选择对新手来说简单直白(这么做才是对的)，就像“扔掉你那白色新手剑换上这把+2力量的闪亮新剑”，那么这些选择对老玩家来说更是显而易见。这没问题，只要保证游戏中有大量更难的选择让老玩家去克服就行了。

如果你可以做出一款游戏拥有成千上万的玩法物件并且它们能力相等，这也不一定是件好事。假设一个玩家策略是由20个物件(牌组中的卡牌、或角色拥有的道具)构成的子集，成千上万的物件都需要被考虑一遍，具有相同可行性的玩家策略有如此众多，没有哪个玩家(或设计者)能够搞明白。一个游戏有3到4种完全不同的方式去玩一个盗贼很酷很有趣。但一个有3到4千种方式的游戏则让人感到困惑和讨厌。

即使你有让全部选择都可用的想法也无法实现，这是因为你无法准确地平衡所有物件。如果你的游戏中有大量功能不同的物件，你怎样在效用上把它们做到完全一致呢？魔兽世界满级角色身上只有这么多个孔位，万智牌的牌组里只有这么多张牌，只有前100的物件有能力竞争这些位置。如果你降低费用让一个较弱的物件变得强大了，你也许是让它取代了前100里某个东西的位置。但是很可能最终你也没有改变可用物件的数量。所以使每个物件都可用的想法除了让你被误导外不会有什么卵用。

在任何情况下，让所有物件完美平衡的危险都不值得忧虑(没哪个游戏有这个问题)。重点是要弄清楚你想要可用的物件占总体的比例是多少。把它们调整平衡并接受其他物件要差一些这件事。从现在开始我会假设你已经确定了一组要平衡的物件并着手开展工作。

要平衡几组物件，你需要将费用分摊。要记住，费用可能会被玩家认作费用，也可能不会。在星际争霸中一个单位的费用主要是建造消耗的水晶和气，但你为了能够建造它所打通的科技树和建造时间也是费用。在万智牌中一张牌的费用主要是其所需的法术力，但这样想往往更有帮助：除此之外它还消耗了一张牌(即你用掉了一张手牌也是要算进去的，只有在那种每回合结束时自动补充手牌的游戏中才不存在这种费用)。这就是为什么0费的牌并不是真正免费的。魔兽世界中道具的黄金价值和它的费用几乎没什么关系。它的费用在某种意义上是为了得到它所花费的时间和克服的困难(怪物多久掉落一次)，但那太难量化了，因此用更容易处理的物品等级来代替。(下文有更多说明)

选自《故事》的前言，我觉得同样适用于游戏导演和游戏策划。这可以启发我们，学习和积累哪些东西是有利于设计的，而哪些东西是可以被打破和挑战的，又有哪些东西是需要及时改正的。

《故事》论述的是原理，而不是规则。

规则说：“你必须以这种方式做。”原理说：“这种方式有效……而且经过了时间的验证。”二者有着本质的区别。你的作品没有必要以一部“写得好”的剧本作为摹本去写；而是必须依循我们这门艺术赖以成形的原理去写好。急于求成、缺少经验的作家往往遵从规则；离经叛道、非科班的作家破除规则；艺术家则精通形式。

《故事》论述的是永恒、普遍的形式，而不是公式。

任何兜售商业成功范本和故事速成模式的说法，都纯属无稽之谈。尽管有各种潮流，有旧片重拍和好片续集等，但当我们将好莱坞电影作为一个整体来审视时，我们发现其故事设计之丰富多样确实令人叹为观止，而其中却没有一个范例。《顽固分子》所代表的好莱坞典型性绝不多于《门第》、《来自边缘的明信片》、《狮子王》、《重金属乐队纪实》、《命运的逆转》、《危险的关系》、《圣烛节》、《离开拉斯维加斯》以及属于从闹剧到悲剧的数十种类型和次类型的成千上万部优秀影片。

《故事》激励人创造能够令六大洲的观众兴奋不已而且历久不衰的作品。没有人需要另一本重炒好莱坞残羹剩炙的菜谱。我们需要重新发现我们这门艺术的潜在原则，那些解放才智的指导原理=无论电影在哪儿拍摄——好莱坞、巴黎抑或香港，只要它具有原型的特质，其愉悦性便会在全球引发永久性的连锁反应，从一家影院传到另一家影院，从一代观众传向下一代观众。

《故事》论述的是原型，而不是陈规俗套。

原型故事挖掘出一种普遍性的人生体验，然后以一种独一无二的、具有文化特性的表现手法对它进行装饰。平庸的俗套故事则将这一模式颠倒过来：其内容和形式都贫乏得可怜。它将内容囿于一种偏狭的、具有具体文化特性的体验之中，然后饰之以陈腐而无特色的庸常形式。

例如，根据过去的西班牙习俗，女儿出嫁必须以年龄长幼为序：在西班牙文化中，一部关于严父、弱母、嫁不出去的大姑娘和苦待闺中的小女儿的19世纪家庭的影片，也许能打动那些依稀记得这一习俗的观众；而在西班牙文化之外，观众却未必能够领会。作者唯恐故事感召力有限，便求助于过去的观众喜爱且熟悉的场景、人物和动作。结果呢·世人对这些陈词滥调更加兴味索然。

反之，如果艺术家切实下功夫去寻找一个原型，这种压抑的习俗则可能成为轰动世界的素材。原型故事能创造出世所罕见的场景和人物，令我们目不暇给地去观赏每一个细节；而其讲述手法又能揭示属于人性真谛的冲突，使之得以从一个文化到另一个文化不胫而走。

在劳拉·埃斯奎弗的《情迷巧克力》中，母女之间就依赖独立、永恒和变化、自我和他人之间对立的要求短兵相接——这些冲突都是每一个家庭感同身受的。然而，埃斯奎弗对家庭和社会、亲情和行为的观察和表现是那样地富于人所未见的细节，以致我们不可抵御地被其人物所吸引，沉湎于一个我们从来不曾知闻亦不可想象的领域。

陈规俗套的故事不会流传开来，而原型故事却会不胫而走。从查利·卓别林到英格玛·伯格曼，从萨蒂亚吉特‘雷伊到伍迪·艾伦，诸多电影故事高手为我们提供了我们渴求的双锋际遇。

首先，使我们发现了一个我们不知道的世界。无论是言情还是史诗，无论是当代还是历史，无论是现实具体还是方外幻想，一个出色艺术家的世界总是能使我们感受到一种异域之情、离奇之叹。就像一名劈路而行的林中探险者，我们瞠目结舌地步入一个未曾触及的社会，一个破除了陈规俗套的领域，在其间腐朽化为神奇，平常变成非凡。

其次，一旦进入了这个奇异的世界，我们又发现了我们自己。在这些人物及其冲突的深处，我们找到了我们自己的人性。我们去看电影，从而进人一个令人痴迷的新世界，去设身处地地体验初看起来似乎并不同于我们但其内心却和我们息息相通的另外一个人的生活，去生活在一个虚构的现实，从而照亮我们的日常现实。我们并不希望逃避生活，而是去发现生活，以一种焕然一新的试验性的方式去使用我们的头脑思想，去激荡我们的情感，去欣赏，去学习，去增加我们生活的深度：《故事》的写作宗旨即在于培育出具有原型魅力的电影，从而为世界带来这种双重愉悦。

《故事》论述的是全面彻底、始终如一，而不是捷径。

从灵感闪现到最后定稿，写一个剧本也许需要花费和写一部小说同样的时间。电影剧本和小说作者都是要创造同样的内容丰富、感情强烈的世界、人物和故事，但由于电影剧本的篇幅中有许多空白，我们常常误认为写电影剧本要比写小说更快更容易。但是，尽管粗制滥造者能够以其最快的打字速度迅速填满稿纸，电影剧作家却总是惜字如金，不断删改，力图以最少的文字表达最多的信息。帕斯卡尔曾经给朋友写过一封长而无当的书信，然后在信尾的又及中深表歉意，说他没有时间写一封短信。就像帕斯卡尔一样，剧作家明白简是关键：简明扼要需要花费时间，卓越超群来自于孜孜以求。

《故事》论述的是写作的现实，而不是写作的秘诀。

艺术的真谛并不是需要策划什么阴谋来保守的秘密。自从亚里士多德撰写《诗学》后，两千三百年来，故事的“秘密”就像街上的图书馆一样一直是公开的。讲故事这个行当里根本就没有什么难解的奥秘。事实上，乍看起来，在银幕上讲故事似乎是轻而易举之事。但是，当你一步一步地接近其中心，一个场景接着一个场景地努力着要把故事讲好时，这个任务就变得越来越艰难，因为我们意识到在银幕上绝对没有藏拙之地。

如果银幕剧作家未能以其纯粹戏剧化的场景打动我们，他不能像小说家那样利用作者的声音或者像戏剧作家那样利用独白来将其掩藏在自己的言语背后。他不能利用解释性或情感性的语言来抹平逻辑的裂缝、粉饰动机的模糊或情感的枯燥，不能仅仅是告诉我们该想什么或该如何感觉。

摄影镜头是可怕的x光机器，任何虚假的东西都逃不过它的透视。它将生活放大数倍，使每一个软弱无力或不近情理的故事转折暴露无遗，逼得我们困惑、失望到直想脱身而逃。不过，假以决心和研究，难题便会迎刃而解。银幕剧作充满了神奇，但并没有不可解读的奥秘。

《故事》论述的是如何精通这门艺术，而不是如何揣摩市场行情。

没有人能够教别人什么畅销，什么不畅销，什么能打响，什么将失败，因为没有人知道。好莱坞的哑炮在其制造过程中注入的商业心机与轰动作品是一样多的，而那些被钱场的智者打入另册的暗淡的剧情片——《普通人》、《偶然的旅游者》、《猜火车》——却默默地征服了国内外的票房。我们这个行当一切都没有保证。所以，多少人绞尽脑汁、搜索枯肠却始终不得其门而入。

当你满怀上述担忧，战战兢兢地涉足其中时，你就必须按照大都市的规矩，老老实实地去找一个经纪人，兜售你的作品。如果你的作品质量果然出类拔萃，那你便能看到它在银幕上得到忠实的体现，否则的话……如果你匆匆忙忙地炮制出了去年暑期档热门影片的翻版，那么你便加入了每年以成千上万的陈词滥调故事充斥好莱坞的那些三流作家的行列。与其痛思时运不济，不如起而磨砺自己，以臻卓越。如果你在经纪人面前拿得出饱蕴才思、富有独创的剧本，他们将会争先恐后地争当你的代理人。你所雇佣的经纪人将会在正闹故事饥荒的制片人中挑起一场夺标战，中标者将会付给你一大笔钱，数目之巨足以令他囊中羞涩。
而且，一旦投拍，你的完成剧本面临的干预会少得令人惊奇。没有人能保证不幸的人员组合不会毁掉一部好作品，但好莱坞最优秀的演艺和导演天才肯定深切地明白，他们的事业全靠优秀的剧本来支撑。然而，由于好莱坞对故事的需求太贪婪，剧本常常在尚未成熟之前就已选定，然后在拍摄现场被迫修改。沉稳的作家并不出卖初稿。他们会耐心地数易其稿，直到本子尽可能地符合导演和演员的工作要求。未完成的作品较容易遭到窜改，而多加润饰的成熟作品却可以保持其完整性。

《故事》论述的是对观众的尊重，而不是对观众的鄙薄。

天才作家写不出好作品不外乎两个原因：他们要么是被一个他们觉得非证明不可的观念所蒙蔽，要么是被一种他们必须表达的情感所驱策。天才作家写出好作品一般是因为这个原因：他们被一种要打动观众的欲望所感动。

在多年的演员和导演生涯中，夜复一夜，我总是怀着敬畏的心情面对观众，对其反应能力敬畏不已。他们就像中了魔术一样，面具全部脱落，赤诚的面孔全不设防，对一切感受兼收并蓄。电影观众不会防卫自己的情感，他们以一种连自己的爱人也不知晓的方式向故事人敞开心扉，迎接欢笑、眼泪、恐怖、暴怒、同情、激情、爱恋和仇恨——这场仪式常常令他们精疲力竭。

观众不仅令人惊叹地敏感，而且一旦他们在黑暗的影院坐定，其集体智商则能飞跃二十五点。当你去看电影时，你难道不是经常觉得自己比你所看到的内容更加聪明吗·人物还没开始行动，你就知道他们要做什么；影片离结尾还老远的时候，你就看出了结局。观众不仅聪明，而且是比大多数电影更聪明；当你置身于银幕的另一面时，这一事实也不会改变。作家所能做的一切就是，尽其所能，以求超越聚精会神的观众所表现出的敏锐的集体感知力。

一部电影如若不了解观众的反应和期待，必将行之不远。你必须以一种既能表达自己的想象，又能满足观众的欲望的方式来构建自己的故事形态。观众和其他诸多要素一样，是设计故事的决定力量，因为没有观众，这种创作行为便失去了意义。

《故事》论述的是独创，而不是复制。

独创性是内容和形式的融合——独具慧眼的主题选择加上独运匠心的故事形态。内容(场景、人物、思想)和形式(事件的选择和编排)相辅相成、相得益彰而且相互影响。一手把握内容，一手精于形式，作家便可以雕琢故事。当你反复推敲故事材质时，故事形态便会自行重塑。当你玩味故事形态时，心智和情感的精灵便会渐渐浮出。

一个故事不仅是你该讲什么，而且还包括怎么去讲。如果内容是陈词滥调，那么讲述手法也必定是陈规老套：但是，如果你的想象深远而新颖，你的故事设计必将独出心裁。反之，如果故事手法纯属老调重弹、司空见惯，也就需要用陈规俗套角色来演绎陈陈相因的行为。然而，如若故事设计新颖别致，那么背景、人物和思想也必定要同样令人耳目一新才能使其臻于完满：故事形态的构建是为了适应故事材质；故事材质的推敲是为了支持故事设计。

不过，切忌将猎奇误以为独创。为不同而不同就跟屈从于商业规矩一样，难免流于空洞。一个严肃的作家在经过经年累月的搜集整理、广征博采和冥思苦想，终于建立起了一个故事素材的宝库之后，决不会将自己的想象①[想象(vision)：指导演对其未来影片画面的想像力。——译者]囿于某一公式的藩篱或使之沦为标新立异的下品。“范本”公式可能会窒息故事的声音；而“艺术片”的含糊其辞则又会导致表达的口吃。就像小孩摔碎东西取乐或无理取闹以博大人关注一样，太多的电影制作者不惜采用婴幼儿的伎俩在银幕上大叫：“瞧瞧我的本事!”成熟的艺术家决不会故意引人注意，明智的艺术家决不会纯粹为了打破常规而行事。

霍顿·富特、罗伯特·奥尔特曼、约翰·卡萨维茨、普雷斯顿·斯图尔奇斯、弗朗索瓦·特吕弗和英格玛·伯格曼等大师的影片具有的个人特质有如DNA，使人只需读三页故事梗概便可以准确无误地判定作者是谁。伟大的银幕剧作家总是以其个人化的故事风格而独树一帜；这种风格不仅与其想象不可分割，而且从深层意义而言，这种风格即是想象象。他们的形式选择(主人公人数、故事进展的节奏、冲突的层面、时段的安排等)与实质内容的选择(背景、人物、思想)既相辅相成又相反相成，直至一切因素融合成一个独一无二的剧本。

更进一步，如果我们暂且将其影片的内容搁置一旁，只去研究其片中事件的纯粹形式，那么我们将会发现，即如一段没有歌词的旋律，就像一幅没有原物的剪影，其故事设计本身便重重地承担着含义。故事大师对事件的选择和安排即是其对社会现实中各个层面(个人的、政治的、环境的、精神的)之间的互相关联所作的精譬妙喻。剥开其人物塑造和场景设置的表层，故事结构便展示出作者个人的宇宙观，他对世间万物之所以如是的最深层的模式和动因的深刻见解——这是他为生活的隐藏秩序所描画的地图。

无论你的英雄是谁——伍迪·艾伦、大卫·马梅特、昆廷·塔伦蒂诺、鲁思·普罗尔·贾布瓦拉、奥利弗·斯通、威廉·戈德曼、张艺谋、诺拉-埃夫龙、斯派克·李、斯坦利·库布里克——你崇敬他们皆因他们是独一无二的。他们之所以出类拔萃是因为他们选择了别人没有选择的内容，设计了别人没有设计的形式，并将二者融合为一种不会被误认的、只能属于他自己的风格。我要求你们也要这样。

不过，我对你们的希望不止于能力和技巧。我渴望看到伟大的影片。过去二十年来，我确实看到过好电影，而且还有一些很好的电影，可是却很少很少有一部具有震慑人心的力和美的影片。也许原因在我；也许我看电影看腻了。可是，我并不这么认为。现在还不。我仍然相信，艺术能改造生活。不过，我知道，如果你不会弹奏故事交响乐中的所有乐器，那么无论你的想象中有多么美妙的音乐，你注定只能哼出那千篇一律的老调=《故事》的宗旨即是加强你对这门手艺的掌握，将你从束缚中解放出来，使你得以表达你对生活的新颖独特的看法，提高你的才能，使你超越陈规俗套，创造出具有独特材质、结构和风格的电影。

不少游戏有着庞大的物件数量，过段时间之后你希望在这类游戏中加入更多物件(收集式纸面游戏和MMORPG会比RTS更频繁)。这种时候管理物件生命周期就相当重要了。因为你添加了新物件，你想要让玩家觉得这是有趣的选择。这是一个我几乎不提及的大主题，但完全不提它我又觉得疏忽了什么。

你有3种方案来引入新物件：

a)它们和你当前的物件威力差不多
b)它们比当前的物件强得多
c)它们和之前的的物件差不多，但你把老东西废了(套牌轮换)

从短期来看，a方案和b方案是较为合理的选择。但是最终a方案会导致所有新物件在成千上万的现有物件面前毫无价值。大多数牌组(或部队、角色)都会选择使用老物件，老物件的池子更大更可能有好东西，即便新物件整体水平和老物件持平但它们看起来还是会比较搓。不过这方案对于物件池比较小的游戏(例如RTS的一两个扩展包)还算不错。

如果用b方案那新系列看起来很振奋人心，但随着这类物件越来越强力，游戏系统很可能会在这种负担下崩溃。若在你的游戏中更多强力物件意味着快速制胜，那你最终会迎来游戏会一回合收场的状态。如果强力防御在游戏里戏份很大，那也许有些策略会变得无人能挡，然后多数游戏局会陷入困境。理论上来说，游戏规模可以被无限放大(纯数字游戏的每个数都翻倍之后和之前本质上是一样的)，但实际上高度复杂的游戏总会在某种规模时崩溃。你也许觉得你的游戏永远不会到那一天，所以b方案或许是个好选择。由于技术原因，电脑游戏的寿命都不太长，所以超长期的考虑有时也没什么用处。

顺便插一句，要记得就算没加入任何新物件，你也能在RPG的升级过程中发现一种新东西越来越强的现象：你用30级的道具换掉了20级的道具，以此来保证你对新道具的渴望。但我在这里主要说的是游戏持续运营过程中加入的新内容。

如果你做长线考虑的话c方案是必然的选择。如果想让游戏持续10年，并想在这期间持续引入新的玩法物件，就必须抛弃某些老物件才能避免新东西越来越强。不过玩家会因为你拿走了他们的老物品而对你很生气。你有几种方法来缓解这种愤怒，然而你不可能完全消除它。一种就是让玩家有一个专门的模式来玩他们的老物品，这个模式不太受新加物品的影响，新玩家不太可能参与其中，只有老玩家才能玩好这个模式。另一种方法是利用“潘洛斯阶梯”的力量，让每次要加入的系列看上去都比之前的更强(这样玩家就会觉得新东西比老东西好)，但要做得好是一个微妙又艰巨的任务(理论上让两个系列按照剪刀石头布的关系排列就可以，一套里的物件可以克制另一套里的物件)。

无论你选择采用哪个方案，都要在测试新物件时记得将它们和老物件进行对比。人在测试时自然会趋向于使用新玩具。但这样很容易让所有新物件之间挺平衡，却没有和老物件平衡。

记住仍有一大堆问题是关于如何应对某些损害游戏体验的物件，你要决定是消除它、限制其使用还是修改它的功能。本文的重点是在游戏发布前调好平衡性。要当心，无论你之前多么仔细地平衡物件，有些问题物件还是会从你的眼皮底下逃过。当这些问题发生时处理起来相当痛苦(对你和你的用户来说都是)，任何使它们尽量不出现的努力都是值得的。当然这些问题太多的话你的游戏就不可挽回了。

从某种意义上看，这个部分才是这篇文章的重点。我会列举构建物件的费用和平衡的各种技巧，大致按重要程度来说。

一些警告：这些最多是一些经验法则，不是绝对律法，有大量的例外情况。尽管我挑选的问题都尽量普适通用，但根据你开发的游戏类型，有些问题影响会更大。

1.调整费用而不是效果

如果有物件对它的费用来说太强力了，人们会注意到它的效果并想将其调低一些。抑制住这种冲动，最好先调整它的费用，这样你才能指望保留这个物件的特色和原始设计意图。即使一个物件看上去不好玩，也要扪心自问：使用它的人觉得它不好玩？也许它的费用该少一些，使用者就能找到乐子了。对面玩家觉得它不好玩？也许它的费用该多一些，这样对面的人能少受它的蹂躏。

除了保留设计意图外，首先调整费用还有其他好处。如果你反复调整费用，那么你在几轮迭代中做的事情会很好理解。反之一个大的效果变更往往意味着你的测试工作将重新来过，因为现在你相当于有了一个新物件。而且，如果你发现一个物件对它的费用来说太强力了，然后你调高了它的费用，那么你会收获一个昂贵的大单位。这样的物件会比那些便宜弱小的物件带来更多乐趣。

有时候确实需要调整物件的效果，不管它费用多少都显得很没趣(尽量避免那些会被人抛弃的效果)。有时候一个效果很难在不伤害整个系统的前提下构建费用(详见“不可量化效果的危险”一段)。但是改变费用应该是你的第一个想法，常常也是你接下来的想法。

2.单点理论

在有些游戏中，物件伴随着很多与之相关的数字。你通常只想要一种数字来代表费用，这样便于调整。否则，构建费用问题会变得过于复杂。这不意味着你不会去调整其他参数，而是说你会以一种数字来进行考量。举个例子，如果你的RTS单位消耗黄金和木头，想出一个合理的转换率(不必很完美，你可以在之后调整它)然后用黄金为单位写下所有东西的费用。这样你就能知道单位A是不是比单位B更贵了，而且当你增减费用时也能一眼看出。如果没有现成的数字可用，你可能要生造一个——就像魔兽世界中的物品等级。你在构建一个被经济学家称作价值标准的东西(一种或许有些武断的单位，用来度量你所有的费用)，源自相同的理由。如果你稍微思考一下会发现规则1暗示了规则2。

3.色轮无处不在

在万智牌中，有5种颜色的卡牌，分别花费5种颜色的法术力。这看起来好像很特别，但其实我想说这其实很普通。

万智牌的色轮有什么用处？它是一种鼓励玩法多样化的方法。如果法术力没有颜色，我就只选最好的牌(在给定费用时)放进我的牌组。但在有色轮的情况下，如果我选了红色牌我就需要红色法术力，这会让我继续用红色牌变得更容易。现在(假设开发者已经搞定了平衡性)我也许构建了一套红色牌，或绿色牌，或蓝色牌……我有5倍的牌组类型。事实上我还有更多，因为还能构建双色牌。如果我搞了一套红绿牌组，有时我会挺难过的因为我的法术力是红色却想打一张绿色牌，但双色让我有更大的选择面(牌池)，对我很有帮助。玩全部5种颜色可能太多了，我会时常面临牌色对不上的情况，但根据法术力生效的具体细节我大概可以用1到3种颜色。(如果我始终可以轻松地用5个颜色，那色轮对我就没意义了。又回到了在给定费用时选最好的牌的情况)

为什么这是一个普通的现象？因为基本原理就是在玩法物件中强化关联性可以增加变数。大多数时候关联性是100%的：如果你是神族，那你只能建神族单位。如果你个是牧师，你只能施放牧师的法术。但有时候也并非如此：如果在RTS中你升级箭术建筑，你会制造更多弓箭手，但你仍会有一些近战单位。如果你采了很多气，你可以造一些花费气的单位，但你仍然可以造那些花费水晶的单位。

确定你游戏中的“色轮”以及在宽泛(使用多种颜色较容易)和狭窄(必须专注某种颜色)之间做平衡是开发良好系统的重要内容。考虑两个因素：

a)使用多种“颜色”有多难？强制你建造气矿或花钱升级箭术把你分别推向耗气单位或弓箭手。你必须选择一个职业，做牧师和盗贼截然不同。

b)每种“颜色”有多少独特的东西？如果只有红色法术能直接伤害对手，那你会想要向牌组中加入红色牌(即便使用多种颜色会困难一些)。若每种颜色都可独立做任何事，那你只会选一种颜色用——不会为此多费一丝力气。

像万智牌这样的系统较好平衡了以上两个因素，所以你可以混合搭配颜色或者使用单一颜色，玩得好的话都很吸引人，当然要玩好不容易。平衡职业制RPG(强制使用一种“颜色”)已经够难了，平衡纯粹的加点制RPG(可以把任何牌加入牌组中)更是难上加难，而且可能永远无法成功。这些系统看似有着不错的多样性，但实际上容易退化为只有一种角色模型可用。

值得注意的是如果很容易使用多个颜色，或各种颜色完全没特色，那么你的游戏其实不存在“色轮”。还要注意的是玩家和你团队中多数初级设计师会倾向于更容易使用多种颜色，以及让每个颜色都有别的颜色的“独占能力”，别对这种倾向屈服。

4.剪刀石头布

剪刀石头布是一套异常强大的设计工具。假设你的游戏有3种玩法单位A、B、C，你想要把它们的胜率平衡在50%左右。你肯定会出错然后发现B对A的胜率是53%同时对C的胜率是57%。于是每个人都会只玩B了，你的游戏就会变得很无聊。但如果你让A克制B克制C克制A(克制意味着60%的胜率)，那么除非极端情况，这三者都能保持可用(不是完全相等的比例，但已足够)。当然，让克制的胜率为100%更安全，但游戏可能就不太有趣了。

好游戏会把剪刀石头布体系用在各种地方。有时候很直白：骑兵打弓箭手时+2，弓箭手打步兵时+2，步兵打骑兵时+2(坦率地说我觉得没什么道理)。有时候很优雅：许多RTS游戏中，近战克远程，远程克空军，空军克近战。

有些例子则是特殊能力单位输给拥有克制该能力的单位，该克制单位又输给普通单位。所以如果一个单位使用foo攻击(造成25%额外伤害)，它就会输给具有foo防御的单位(只遭受一半foo攻击，但其余属性较低，比如血量少5%)，这种foo防御单位就打不过正常单位。 从防御角度来看一个类似的例子是装甲单位、穿甲单位、普通单位。

一个微妙的剪刀石头布适用于许多游戏，包括大多数集换式卡牌和RTS游戏，在这种游戏中越后期创建的单位越强大。如果在游戏后期出现的单位不是单纯强大，而会同样更昂贵的话，你会得到这样的动态关系：

1<2<3<…<n-1<n<1

稍微出现得晚一些但是更强大的部队能让你赢得游戏。但打算非常晚才出一个很牛的部队不是件好事……可能在部队准备好之前你就输了。(上面的动态关系在RTS中代表研究套件，在集换式卡牌中代表法术力费用)

注意，你必须仔细处理剪刀石头布影响的轻重。如果蓝色套牌始终战胜绿色套牌、或盗贼始终战胜牧师，你的整个游戏环境还是具有多样性的(如果你把其他的剪刀石头布处理好了的话)，但当个体玩家处于上述较量的被克制一方时他们会觉得没那么有趣了。

在游戏中使用剪刀石头布的技巧是尽量识别出该结构在哪，各个单位在其中扮演何种角色，然后确保每个单位都有所克制(它才有用)以及能被谁克制(才不会淘汰谁)。记住穿甲单位克制装甲单位很容易，但是记住普通单位克制穿甲单位要难一些。

5.别忽略白板曲线

大量的时间和注意力都会浪费在那些具有特殊功能的游戏物件上，为它们定费用是一件非常有挑战的事。但尤其在系统开发阶段，我们聚焦于白板曲线：那些只有基本属性的白板物件的费用。即便这看上去有些琐碎无聊，用费用正确地衡量该物件的能力，或属性A与属性B的价值换算，对于这个物件本身(多数游戏都有大量白板物件)和物件体系的地基是非常重要的。你会发现那些最善于“解构”特殊物件的开发者(从其中找到巧妙的组合)并不太擅长平衡白板物件。

当你调好了白板曲线后，你就能看看别的物件然后说：“好吧，这些属性值这么多，同时我们做了别的也有同样能力的物件，所以我们知道这种能力值多少了。”如果你知道如何在白板曲线(走运的话它会是线性的)里正确地添加能力的费用，就能为某个物件定费用了。如果你办不到这点，那每个物件都会需要进行玩测，你会早早耗尽测试资源。当创造出新物件时，你会想要尽量把测试精力放在新能力上而不是那些老能力的新组合上。一个坚实的白板曲线可以帮你实现这一点。

6.流程

我已在之前讨论了好几种组织设计和开发团队的方式，在这里不再赘述。

7.监视列表

让开发员多玩(开发中的)游戏是很有价值的，当东西做得越来越像样之后也要确保他们这样做。在开发的早期阶段，他们应该多关注游戏的乐趣性而少关注平衡性。之后当你聚焦于平衡问题时，在你团队中至少要有几名精英把时间花在解决那些破坏平衡性的东西上面。

所以说以良好的方式分割工作还是有意义的。我找到一个好办法是让所有的开发人员都到同一个房间里，列出所有被认为可能有问题的物件然后指派一些人去测试。当到了评估这个东西的时候，那个测试它的人很可能已变得喜欢它了，所以尤其要认真倾听作为对手人员的反馈意见。如果他们都认为这东西没问题，那很可能就真的没问题。如果测试者认为该物件挺平衡但别的人都讨厌它，这就是一个危险的信号。

8.辅助设计师的简单数据库

我们喜欢把所有卡牌的玩法数据放到一个简单的数据库里以便设计师和开发员使用。对于一个新游戏来说，至少部分设计师和开发员要能够直接修改这个数据库(例如添加新字段)，这点很重要。数据库里除了数据之外还有很多评论。

对于一些复杂的游戏来说，单点(见第2部分)在哪并不太明显。在数据库里用一些公式将能力转化为单一的费用就比较方便。在理想状况下，每条不同的玩法属性都会转化为一个费用，任何特殊能力都会转化为费用(独特的能力需要估算并手工录入)，一些合理的算法将它们联合表示为一个代表此道具效用的数字(尽可能准确)。于是这个道具在游戏中的成本就表示出来了。请注意这些数字不一定要都相等。一个有趣的游戏既需要好东西也需要烂东西。不过一个好的游戏开发员需要知道哪些是好那些是坏，且价值几何。

测试的价值远大于其成本。而评估公式或独能力的价值表面上不划算，但开发员还是大量用它们。

就这种部分自动化算费所需的工作量而言，不是所有游戏都值得这样去做。但那种持续运营的游戏(MMORPG或系列RTS游戏)能付得起这样的成本。拥有一个所有开发人员都可以写评论(而不是一个只有一个人会读的脚本文件)的数据库也总还是有价值的。

9.玩测vs理论分析

我在这儿写的大部分东西可能会给人一种我觉得理论分析比玩测更好的印象，或者精妙的公式会比实际玩游戏告诉你更多内容。实际上，我所认为的恰恰相反。理论分析经常犯错，目前为止玩测是最好的检验方式。但玩游戏的花费是很大的(尤其是测试概率性的东西)，况且不可能有足够时间测试所有东西，甚至是其中相当小的部分都不可能(一旦你又掺入了交互)。所以即使很多理论分析在之后的玩测中都变为了空话，但还是值得去做。我发现2小时的高效讨论由100分钟毫无意义的理论分析和20分钟足以节约一周工作的干货构成。

然而要记得，如果人们在一个理论上反复争论了很久而毫无进展，那么最好搁置讨论直接试一下(不过在大家都有一些实际数据后有时候还是会值得回来继续争论)。

好的理论对确定那种需要特殊测试的危险区域尤其有价值。如果你知道法力值快速恢复或摸牌会出问题就能更仔细地测试它们。

10.为多种环境做开发

你的游戏常常会以多种方式来玩，但是每次都会使用一些相同的玩法元素。在万智牌中竞赛选手和休闲玩家可能会用同样的牌，或者同为竞赛选手也有玩轮抽和构筑赛的。在魔兽世界中也有很多休闲玩家和硬核玩家，大多数硬核玩家会在raid公会里或者忙于PvP。在一个环境中平衡的东西不一定在另一个环境中也平衡。因此即使在理论上也不存在一套柏拉图式完美平衡的道具。

如果你接受了并非所有物件都需要在所有环境都可用的观点，那么这么做理论上就没多大问题：让这个物件在它最适用的环境里做到平衡，并接受它在其他环境里不那么好这个事实。实际上，你不会有资源去测试所有环境中的所有物件。你最好的办法可能是挑选最具平衡压力的那个环境(往往是最具竞技性的环境)来做测试。如果一个物件看起来在其他环境出奇地好，你可创建一个特例来测试。

当心那些在你最重要或最流行的环境中的测试陷阱。如果你认为万智牌的限制赛或魔兽世界的PvE是最重要的内容，那不意味着你要将平衡测试专注于此(当然，你应该玩玩它们看是否有趣)。你应该把万智牌的构筑赛或魔兽世界的PvP作为最有物件平衡压力的环境并拿它们做测试。如果物件在高压环境做到了平衡，一般来说在低压环境里也会不错，少数例外也能被识别出来。

11.黑莲花效应

在你游戏中有一个不平衡的物件会怎样？也许不是强到逆天(无论使用者还是对手的游戏体验都被其支配)但是每个人都想有一个？如果你被开发者/平衡者的心态包围，你也许会觉得踩灭这些东西就是你的工作。一般来说这是正确的，不过我也要承认这并非完全正确。如果它不是碾压性的，万智牌里的黑莲花(或是魔兽世界中的正义之手)也能制造很好的效果。每个人都想要它，每个人都为它而激动。只要不是太难获得，每个人都有机会获得一件极品，他们能因拥有一件真正的好东西而感觉良好，而不是只能获得它们买得起的东西。

很多东西看上去都很类似。但也许有那么一些让你的游戏收获大于损失。记住游戏还是损失了一些东西：如果游戏里有一件最好的靴子，没有谁比它更好了，那么当一个角色穿上它的时候就等于删除了角色的靴子孔。游戏中其他的所有靴子都没有意义了。不过也许有时候这种成本是可以接受的。它肯定能成为玩家之间的谈资。

如果这道具会弄得对手很不爽，或者是否拥有它直接决定了游戏结果，那可能就太过了。

12.不可量化效果的危险

大多数物件都是可量化的：它们增加你的属性或者造成一定量的伤害或者是具体身材的生物。但有些物件不是：一个摧毁敌对生物的法术(无论范围多大)，一个治疗友军所有伤害的法术(不论多贵)，或取消对手施法的一踢。这些物件可能会比较危险。它们通常能被定价(如果只用2费太划算了，那你愿意花8费使用它吗？)，但它们在度量上的缺陷会导致不好的效应。

在像万智牌或RTS这种由玩家支付费用的游戏中，这些道具会伤害到其他道具。如果你的摧毁任意敌对生物的法术要花4费，那你就很难使用超过4费太多的生物。也许5、6费你能接受但8费就不行了。一个杀死生物的法术很酷，但它值得让你不再使用所有昂贵的生物吗？你可以设计这样的物件，但它们会强烈影响其他物件，你要早做思考。虽然游戏系统开发一般聚焦于白板曲线，你仍然要尽早决定是否要设计这类非黑即白的法术并且在它们存在的同时平衡好白板曲线。从平衡角度来看，一个有“杀死生物”效果的游戏和没有它的游戏是有很大不同的；一个有“治疗你所有伤害”法术的游戏和没有它的游戏也是有很大区别的。

在MMORPG里这个问题常常以稍微不同的形式出现。角色升级后很多道具就该被淘汰了，但非量化道具很难被淘汰：治疗一个人的全部HP始终是很棒的，很难再有一个比它更好的治疗法术了。类似的还有获得一次额外攻击、阻止敌人的施法。一旦你给了玩家这样的好能力，如果它是非量化的，那你之后可能很难给他更好的了。

很难避免非量化道具，因为要摆脱它们常意味着把一些既简约又好玩的东西(获得一次额外攻击)变得不那么优雅(在40级以下获得一次额外的攻击)。但要小心这些道具会导致的潜在问题，决定它们是否值得。也许它们能被调整一下，也可能会成为你的“黑莲花”。

13.平衡出现较晚或稀少的强力效果

一个在卡牌游戏或RTS中出现得很晚的单位(往往由于其高费用或长科技树)是平衡上的棘手问题。人天生会对游戏里的这种东西进行评判。主要是它们出现得很晚或很少，甚至常常没机会出现。如果大多数牌是4费而巨龙是8费，那么许多盘游戏结束时它都会停留在你手牌里。它需要非常强大的能力作为弥补。如果你想让巨龙成为高端玩家在组牌时的可行选择，或者你想让大舰成为星际争霸中人族玩家的可行选择，那它或许应该比你第一眼时的感觉更强一些。如果你只要有办法放出一个超强的单位就能自动获得胜利那就太无趣了(而且就算它好玩，你也必然没法做出比它更贵的单位了)。因此大多数费用系统至少在可用单位中都有一个花费上限。

14.灵活性有时候没你想的那么有用

一般来说专注某一项的东西是最好的。单项很极品的物件好过多项表现平平的东西。所以一个四种属性+3的戒指应该比一个单一属性+12的戒指费用更低。一张允许你选择两种能力中的一种施放的牌并非是一张只能施放一种能力牌的两倍(实际上，我们的经验是先把这两种能力调得一样好，即它们的费用差小于1点法术力)。灵活性并非无用，但它往往没你想的那么有用。

15.错过目标的另一面

如果事实证明某个物件很难平衡，你通常想矫枉过正而不是一次次做小修改。如果盗贼太弱了就把他改强。如果毁灭之剑太强了就把它改弱。一旦两者你都错过了，那把它放到下次迭代中会容易一些。

这类平衡游戏物件的方法没法把一个无聊的游戏变得有趣。但它们可以使那些本来很有趣但有成千上万玩家在寻找系统漏洞的游戏免于崩溃。当下越来越多的玩家通过互联网分享他们的策略(要么通过攻略网站要么是直接在游戏里一起玩)，对游戏保持平衡的压力已是相当之大。游戏设计师和开发员需要用上浑身解数来做到这一点。

接下来让我们直接进入专业问题。游戏的设计过程可以分为两部分：设计游戏方案，对这个方案进行调整。对电脑游戏而言，两者并没有明确界限，统称“游戏设计”是合理的；但在威世智，它们有着明确的划分：前一部分称为“设计”，后一部分则是“开发”。很显然，下文提到的“开发”并不具备电脑游戏世界里的一般含义，它专指调整的过程。在电子游戏世界里，“开发”与“编写游戏程序”是某种程度上的同义词，有时还指代“从提出构思到完成作品的整个过程”。同理，“开发员”也并非一般意义上的程序员，而是调测游戏方案的专门人员。如果把游戏看成一幢建筑，设计师就相当于建筑师，而开发员就是工程师。建筑师做得不够好，最多是房子不讨好；工程师做得不好，房子就会倒塌。

从以往的经验当中，我们知道不同的人可能只擅长研发工作的其中一部分，威世智较早意识到这2个角色间的区别。以万智牌新系列的开发为例，研发团队的其中一组设计师设计出一套全新卡牌，另一组开发员则接手调整费用、异能和其他事项。设计师的工作多数依靠天马行空的个人创造，开发员则遵循一套成熟的技术展开团队协作，将前者的创意成果调整到合理状态。设计师们会有限度地试玩自己的创作，目的是体验新作品的实战感觉；而同样的事情对开发员来说则是家常便饭，解构——修正——再解构是他们的主要工作。

比起开发人员，适合担任设计师的人才更为稀有，也很难为它们提供行之有效的职业培训。设计构思更像一种艺术而不是科学，开发则正好相反(当然，两者都有两面性)。包含大量物件的游戏所需的开发人员远多于设计师，前者较易通过职业训练来培养因而就成了值得庆幸的事。一个研发团队可能只需1-2名设计师，但却要4-5名开发员一起工作，才能达到最好的效果。

构思和研发相互独立的开发模式在扩展系列的设计中运作良好；新游戏——尤其是拥有众多游戏物件的游戏，开发过程就显得较为繁琐，一般可以分为如下四个部分：

基础玩法设计(“系统设计”)
基础玩法的调测和修改(“系统开发”)
游戏物件的创造(“系列设计”)
物件效果的调整和费用确定(“系列开发”)

上面只是概念上的划分，在实际工作中，四个部分之间显然是互相关联的。更大的项目甚至会动用4个团队，每个团队专门负责其中一部分工作；即便是只需一个团队的小项目，保证成员之间分工明确也是很有必要的。

接下来，请允许我向大家介绍各部分的具体内容、为什么要这样划分，以及它们彼此之间如何有效地进行沟通。

游戏系统的初始设计是最困难的部分。这里没有一成不变的规则，没有一步登天的捷径，我也不会试图向大家讲解(个人甚至不确定它能不能被讲解)，但有几点可以明确：在这阶段，尽管设计师必须拿出足够数量的游戏物件来证实可玩性，设计过多的物件却很可能是个错误，进一步开展费用调整就更不用说了。

系统开发也许是最难讲解的部分，它包含游戏系统的基本调整和规则漏洞的填补两大单元；而最不显眼(却又同样重要)的环节则是费用系统的构造。没有合理的系统，游戏会面临严重的费用平衡问题。各位可以把费用系统想象成一套挂钩手柄（更形象的比喻是一系列带刻度盘的把手，这样你就可以调整它们），你将围绕它构建一套平衡过的游戏物件。每款游戏都有一定的物件(武器，咒语，人物职业，诸如此类)，这些物件却不一定有合适的费用。所谓“合适”，意思是既简单又可靠：“简单”以致玩家可以轻松地理解和应用，“可靠”确保它有效地覆盖所有物件，从而在可用物件有限的情况下维持游戏环境的多样性。举个例子，如果国际象棋可以自选棋子，规定“每位玩家必须选择16枚棋子”就能视为一个费用(每选择一枚棋子，就占用了起始棋位的1/16)；然而这系统并不可靠，因为在这样的规则下，人们可以用16枚皇后展开游戏。

系列设计阶段，研发团队将设计所有游戏物件。本阶段的重点是趣味性而不是物件间的平衡，所有物件费用都只是暂时性的。

进入系列开发阶段，物件将被赋予更准确的费用，其平衡性也会被反复的测试所验证。早期犯下的错误在本阶段会被发现和清除，但如果系统开发没有赋予足够的趣味性，本阶段对此将无计可施；如果系统开发没有创造出合理的费用系统，本阶段就无法对物件进行平衡。部分物件会被大幅修改甚至剔除，但总的来说，开发人员会尽可能保留每一个物件，而完善的费用系统对此很有帮助。

当然，这些阶段之间并不是、也不该是完全独立的。系统设计和系列开发显然应该分列首末，剩下两部分孰先孰后却有待商榷。不清楚物件细节的情况下设定规则细节显然毫无意义，没有既定系统的情况下凭空设计游戏物件同样并不可行——因此，这两者总希望自己被安排在对方之后开展。对此，安排两者同时进行，促进它们互相交流、互通有无，也许是最合理的解决办法。

对小型游戏的开发团队而言，小组之间有时会出现大量人员重叠，典型的工作安排甚至可以是这样的：一到两名设计师完成游戏系统的初始设计，交给系统开发员做测试，而其中一名设计师随即转入系列设计；系列设计完成后，负责系统开发的人员系列开发的工作。即使工作小组之间采取彼此独立的编制，人员重叠对保证设计工作的连贯性也非常重要，尤其在开发人员修改原始设计的时候，设计师的参与可以确保人们明确设计意图，从而找到两全其美的方法——至少也在知情的情况下改变设计意图，避免“意外”篡改的情况出现。允许小组成员扮演多个角色通常是件好事，团队领袖却不然，设计组的负责人应该始终坚持并代表团队的意念，受到质疑时必须站出来辩护而不是简单地解释和妥协。

综上，设计师的责任是游戏趣味性，开发员的责任是排查可能出现的问题——进入开发阶段的游戏却可能不怎么有趣，这可能因为游戏本身并不好玩，也可能是大量的修改扼杀了游戏乐趣。无论原因为何，解决问题的关键在于不让开发员们僭越到设计师的领域。经验老到的首席开发员可以敏锐地察觉到这种情形，也懂得提请上司将设计打回重做(是否由同一个设计团队重做则是后话)。

如果只看上面的描述，读者们会认为游戏设计无异于流水线式的自动生产，其出品也必定了无生气。实情并非如此。下面请允许我举例向大家说明，这样的拆分为什么有利于想象力自由发挥。

假设我们将为集换式卡牌游戏设计新的扩展系列。某人在研发初期提出一张新牌，这张牌看上去很有趣，但又有点非同寻常。年资较低的研发成员常认为“这张牌太破坏平衡，不能采用”；而所谓“破坏平衡”，意思是其效应以当前的费用来看太具破坏性(总体上超强)。如果把这张牌交给某位资深的开发员，他可能会这样评价：“哦，你看，这张牌现在是3费，所以有点过强……改成8费会不会好点？”得到的答案通常是“8费太高了，估计没人会用”，之后这张牌就被顺利收录了……一张新牌应该设计成3费、8费还是两者之间，这是开发阶段探讨的问题，但那并不等于“有了合适的费用，不管什么创意都会变得可行”，再怎么研究和修饰有时也不能让无趣的机制变得有趣。但如果设计团队愿意承担设计上的风险，专注于游戏的趣味性而把费用问题留给后续的研发工作，他们的意愿就更容易得到回报；哪怕两者由同一个团队完成，这条规律也同样适用。一旦知道费用问题可以留待将来解决，设计师们就不必过早为它担心了。

At this point we run smack into a terminology problem. The game design process can be split into two parts: designing the initial game, and tuning that design. Either of those things would be called “game design” in the computer world, and they wouldn’t necessarily be clearly distinguished. At Wizards, we distinguish them quite strongly, and we call the first one “design” and the second one “development”. So when I use the word “development” I mean this process of tuning an existing design. I won’t use the word “development” in the sense the computer world uses it: as a word meaning something like “coding” or “the general process of getting a game out, including everything from game design onwards”. And a “developer” is someone doing this job of tuning a game, not someone who is writing code. If you think of a game as a house, the designers are the architects and the developers are the engineers. If the architects are no good, no one will want to live in the house; if the engineers are no good, the house will fall down.

Relatively early on Wizards realized these two roles were different, largely because we found very different people were good at one or the other. If we produce a new Magic set, one group of people (the designers) will produce a set of cards. Another group (the developers) will then take that set of cards and adjust the costs, the details of how the cards work, and so on. The designers create new cards from scratch in various odd individualistic ways; the developers more often work in groups and apply fairly well-developed techniques to get the card file in decent shape.4 Designers playtest a fair amount to get a sense of how their design feels; developers playtest a lot, breaking the design, fixing it, and breaking it again.

Designers are rarer than developers, and it’s hard to give useful formal training in design. Design is probably more art than science, while development is more science than art (each has elements of both, though). A game with many complex gameplay objects will need more developers than designers, so it’s fortunate that developers are easier to train. We find 1 or 2 designers is often enough, whereas developers often work best in teams of 4 or 5.

This split between design and development applies pretty well to a new set of cards for an existing game. For a new game with lots of gameplay objects, it gets more complicated. There are four basic things going on:
1) design of the basic game (“game system design”)
2) tuning and modifying that design (“game system development”)
3) creation of the objects (“set design”)
4) tuning and costing of that collection of objects (“set development”)

Obviously all four of these things interact with each other, but we’ve found it very helpful conceptually to split them up. On large projects, we may even have four teams (with some overlapping personnel), one for each of these tasks. But even on a small project where it’s just one team for all four tasks, splitting them up mentally can help clarify what needs to get done.

Let me try to explain a little more what the pieces entail, and then why it makes sense to split them up and how to get the pieces to talk to each other effectively.

The initial game system design is the trickiest part. There are no hard and fast rules, and I won’t attempt to explain here how to do it (it’s not clear it can be explained). I will say that at this stage, enough sample gameplay objects are needed to try out the design and see if it’s fun, but designing a very large number of objects is probably a mistake, and tuning the costs in any concerted way certainly is.

Game system development is probably the hardest to explain. It includes basic tuning and filling in the holes in the rules. But probably the most subtle part of it is getting the costing system set up correctly. An otherwise solid design will often have serious problems in its costing system. Think of a costing system as a set of hooks and handles (or better yet, a collection of knobs and dials that you can adjust) around which you can build a large collection of balanced objects. The game design will want certain kinds of objects (weapons, or spells, or character classes). Do the right sorts of costs exist for those objects? By “right sorts” I mean something simple and elegant, so players can understand it, but still robust enough so that everything can be costed effectively — so that the variety of gameplay won’t collapse as players use just a small fraction of the choices available to them. “Everyone gets to bring 16 pieces to the table” is a costing system for choose-your-own-army chess (each piece you bring costs you 1 of your 16 slots) but it’s not robust, since players will choose nothing but queens.

Set design is where all the objects for the game are created. The focus should be on fun and not balance at this stage. Objects may have costs, but they are just guesses at this point.

In set development, the objects are given more accurate costs, and tested repeatedly for balance. Mistakes from earlier stages will become clearer here. If the game wasn’t fun before, set development won’t make it fun. If game system development didn’t create the right knobs, the set developers won’t be able to balance the set. Probably some objects will need to be tossed out or drastically altered, but the set developers should be making a good faith effort to include as many as possible, and a robust costing system will help.

Of course, these four phases can’t be completely separated, nor should they be. Step 1 pretty clearly comes first, and step 4 last, but steps 2 and 3 are problematic: each wants the other to come first. Designing the detailed rules for a digital object system without knowing what objects it needs to support is pointless, and designing objects without a system is impossible. Running them in parallel and having them talk to each other a lot is probably the best bet.

For smaller games, there may be a lot of overlap on the various teams. A typical setup might be a couple of people doing the system design, which they then hand off to a team of three or four developers. Those developers do system development while one of the designers designs the set, at which point the same developers develop the set.

Even if there are four separate teams, it’s important to have overlap among the team members for continuity. In particular, if developers need to change something in the design, it’s very important to have one of the designers right there who can say “well, this is the reason we designed it the way we did”. Then the developers can look for a change that preserves that original design intent, or at very least can override that intent knowingly rather than accidentally. In general, it’s best to have the overlapping team members not be the team leads. A team lead is more likely to be wedded to a particular choice and might well feel called upon to defend it rather than simply explain it.

In general, the designers are responsible for putting the fun in the game, and the developers for taking the problems out. But sometimes in development the game just doesn’t seem like fun: maybe the game simply wasn’t that fun to begin with, or maybe development had to make so many corrections to problems that the game suffocated under the weight of all the changes. At this point it’s key to resist the temptation of having a bunch of developers redesign a game. An experienced lead developer will spot this happening and go to his boss and ask that the game be kicked back to design (perhaps that same design team, perhaps a new one).

Looking back on what I’ve written, I realize this all may seem like an attempt to automate the production of games and thereby suck all the life out of it. I don’t think that’s true — let me give an example to try to explain why breaking things
into pieces like this can actually help free up people’s thinking.

Imagine a new set is being created for an existing trading card game. Relatively early on (in set design) someone proposes an interesting and rather unusual card. It often happens that a somewhat junior R&D member says “we can’t make that, that card’s broken!” Now often the card is “broken” (grossly overpowered) at whatever cost it currently has in the design file. A more senior developer may respond “well, it costs 3 now… would it be broken if it costs 8?” to which the answer will usually be “well, nobody would play it at 8, it would be terrible.” At this point hopefully it’s clear that in fact this card can go in the design file… it’s an issue for development as to whether it should cost 3, or 8, or something in between. That’s not to say any card is OK if you find the right cost; some game mechanics are just plain not fun. But if the design team worries about what’s fun and what isn’t, and leaves the costing for later, they are more likely to take the design risks that make for a fun card set. This applies even if the design team and the development team are one and the same. Knowing you will think carefully about costing later keeps you from worrying about it before you should.