原文是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个月，问问自己（和你的程序员）什么有效，什么无效。