写好一份一流的游戏设计文档

成功的游戏设计文档的指路明灯。开动前不妨一读！

原文 Creating A Great Design Document ，作者为 Tzvi Freeman，于 1997 年九月 12 日发布于 Game Developer。

译者注：时隔二十多年，游戏开发，特别是独立游戏开发环境发生了巨大变化。然而，这些文字背后的思辨依然是一份成功的游戏设计文档所不可或缺的。我在策划自己团队的游戏企划时从这篇文章受益良多，因此选择了翻译出来以馈他人。特别的，协作办公不再那么依赖大量纸张，另外，文末所提到的作者简介我未经查证当前是否依然准确。

---

我必须推出产品。在惊慌和眩晕中，我的头撞在了 CRT 上，接着我发现赛博阿拉丁灯神从虚拟的青铜油灯里出现，并向我提供了三个愿望。我没有犹豫，回答说，“我需要……：

• 一支由才华横溢、技能娴熟、献身奉献的工程师和艺术家组成的强大团队（包括一位非常理解的妻子），并具有良好的人际交往能力；
• 足够的时间和金钱，以容忍一两次失败；
• 一份一流的设计文档；

很久以前，编写游戏只需要一个程序员（也许还有一位艺术家），预算十分随意，截止日期也很松散，因此文档并不需要那么严谨。你知道自己想要制作什么，然后就去做了。如果沿途有一些重大变化，唯一能抱怨的人就是你自己。如今，一份详尽而易读的文档可以成为预算无底洞之地狱的速降之旅与完美成品之天堂的易捷快车的关键区别。

游戏开发如何运转

大多数游戏经历三个开发阶段，从概念到设计到生产。可以称之为“灵光一现”、“落笔千言”和“百炼成钢”三个阶段。

在第一阶段中，概念文件既是给自己的一封信——清晰地阐述你的目标，以便你不会失去目标——同时也是将来向市场推销产品的销售工具。有时，这个阶段还会涉及一个能工作的迷你原型，来给你机会尝试和修改你的想法。

设计的中间阶段涉及与艺术家、动画师、音乐家和工程师的大量讨论——你需要尝试新事物，并找到组织和阐明你的想法的方式。

在最后的阶段，“磨合”阶段中，生产管理往往由一些擅长流转于组间灵活调度的专家负责。原始设计师可能是依然是团队的一个重要组成部分，但在许多情况下——特别是在大公司中——他最终反而变成了局外人。

毫无疑问，策划案是设计师对项目这个小婴儿的成长影响最大的地方。即使你，作为设计师，已经决定兼任项目经理，也不要自欺欺人地认为你掌握了所有的控制权。一个复杂的项目涉及许多有才华的人。熟练的程序员和艺术家往往有自己的想法。你可能打算创建一匹马，但艺术家可能正在构思一只独角兽，而程序员则可能正在构思一只高效的骆驼。一份好的策划案能确保你们都计划制作同样的东西。一份优秀的策划案能确保你们都对这个东西的内在灵魂有相同的感觉。把策划案想成是一个大型爵士乐队的乐谱：虽然依然给诸位表演者留下了大量改进空间，但它依然将所有人的灵感聚焦在了一起。

你的策划案就像是你的思想与现实世界之间的一种中介。它确保了你所想的东西是现实世界能够处理的，并且你最终得到的结果将是你最初所想的那样。

最后，记住任何有经验的游戏玩家都能证实的格言：“伟大的艺术在于细节。”精彩的细节自然而然地流露出来，就好像它们已经存在于最初的灵感中一样。但是，一旦你开始实施具体方案，就很容易失去这种火花。

挑战

自己制作项目的原型部分绝对是个好主意——尽可能地画出草图。但再次强调，正是那些细节至关重要。你的想象力所能包容的细节越多，你的作品就会变成更伟大的杰作。

从策划案开始工作也有另一面。开发一个激动人心的游戏本身就应该是令人兴奋的。许多项目最好的部分都是在最后一分钟的紧迫期限中发现的。的确，时间和成本预算的压力不允许概念不断重复，但你不能指望一款杀手级游戏从干燥、可预测的工作中产生。挑战在于用策划案让你的游戏能够容忍意外的改编，而不失去其最初的方向和范围。

表 1: 文档的三个阶段

	内容	目的
1. 策划案	类型;受众;简介;引人入胜的特点;市场信息;成本。	定义游戏的概念、范畴和存在的意义，向客户、发行商、员工和天使投资人宣发其灵感。
2. 设计稿	整个游戏项目的躯体和灵魂的详细描述，和每个游戏元素实现的具体方案。	确保所制作的是你所想制作的。
3. 制作文档	分时图（甘特图、PERT、等等等等）;任务表;财务表格;技术细节;质控记录。	在时间和成本的限制内完成设计稿所描述的。

十点写好设计文档的建议

躯体外阐释灵魂

如果游戏开发只是一个自动化的输入/输出问题——类似于编写代码并能够预测它将如何工作——你可以通过一份干燥的描述性文件进行开发。但实际情况是，开发是由人完成的，其中许多人是有创造力的人，他们有自己的想法;大多数人都希望在他们所做的每件事情上留下自己的烙印。

游戏开发是这样的：你给艺术家们提供设计并与他们讨论要做什么，然后你会联系程序员并和他们核对设计。两组人对你说的一切都认可并且表示可以完成。

那天晚上凌晨 2 点，就在 C++ 星座从西边升起的时候，程序员陷入了中年危机，并开始思考：“我要一辈子当极客程序员吗？这是我妈妈对我的期望吗？我也能像任何其他人一样设计游戏！”然后双手继续敲打代码。

大约在同一时间，艺术家刚刚在机器前醒来，他在等待一个复杂的 3D 渲染完成时陷入了深度昏睡。他不确定自己是在做梦还是真的在做这些工作而得到报酬。沉浸在那个狂热的艺术天才世界里，幻想和现实融为一体，荧光以前所未有的方式组合在一起——当然不是由你想象的。

到了第二天早上，你的马已经变成了一只有两个驼峰的独角兽。总之，对于有创意的人，单纯的指导是不够的。你需要激发他们的灵感。

在你的设计文档中，不要满足于详细描述每一个物品和细微差别。花些时间描述游戏应该具有的感觉，每个元素背后的目的，每个用户将有的体验，以及你可以想象和描述的游戏灵魂的任何其他方面。

例如，假设你正在设计一款射击游戏。你想要训练玩家在真正面对挑战之前应对某些挑战，因此你会在前面几步放置一些不那么致命的小挑战。你需要向开发团队中的每个人解释这一点，以便他们理解为什么某些事物在某个位置上以及为什么它们的运作方式是这样的。这样，即使（应该说是当）你的团队将你的想法加以扭曲和改变，你仍然可以抱有希望：最终结果会有相同或相似的整体效果。甚至比原来更好。

让设计文档可读

给每位制作者都准备好一份 10 点大小，无衬线字体，80 字符每行的设计稿，然后强令他们阅读。如果真有人服从命令会物理疼痛的话，那你可能还得给他们加上布洛芬。

我通常尽可能保持以下至少一部分的好的排版风格：

• 大片空白;
• 正文衬线字体;
• 标题加粗;
• 段落间留空行;
• 视觉动线指向重要元素;
• 用层级式的、“2D”式的结构组织（参见我在“设计文档工具”侧边栏里写的关于大纲的内容）;

很多例子都会提到表格或者图标。用，并且让它们感官上对读者有吸引。

点子也分清主次

现在你应该知道，你在与其他有意识的个体共同工作，你就应该会了解标记特定游戏元素对游戏的重要在制作中是多么紧急。当然，这样的标记不是保证，但只要你审慎使用，它就有可能得到尊重。但不要仅限于此。既然你已经在标记各种灵感了，你也不会介意同时划分好哪些是你认为必须做的，而哪些是你认为如果时间、成本、技能和技术条件允许可以做的。

这些之外，当然还有回收站：那些听起来很好，但最终还是因为其他更据理的原因废弃的点子。明确的记录，并且说明他们被废弃的原因。如果你不这么做，我向你保证肯定会有人把它们捡起来。你的标记可以如下分类：

• 绝不可弃
• 十分重要
• 如果可行
• 拒绝加入

你可能希望用视觉符号表示这些标记。不要依赖符号，因为文档不一定都是彩色打印的。

元素中深入细节

没有细节的文档是无用的。一般性的描述可以被任何人解释为他们喜欢的方式。对摩西来说，“不可杀人”是一种含义，而对西班牙征服者来说则是另一种含义。具体描述你不应该杀谁，在什么情况下杀人会更有帮助。对你的文档也同样适用：一旦你描述了一些实际的细节并给出了一些例子，你的想法就变得更加具体化，也更难被改变。

比如，不要只说“青铜鸟是无敌的”。要描述在它被攻击的每个可能情况下会发生什么，以及它在之后如何恢复。当然，如果动画师有任何自由和艺术尊严，你可以放心，他不会完全按照你的设计稿来。但至少他会有一个清晰的想法，知道你想要实现什么，他的修改也不会严重改变游戏的相关部分。

不要只是说：“在这个点，用户需要同时按跳跃键和箭头键来爬墙。”描述一下如果玩家尝试其他操作会发生什么。解释为什么你认为用户能够弄清楚你提供的组合。解释一下环境中什么表明可以爬这堵墙。

同样，你的艺术家可能会想出其他东西，甚至比你最初构思的更合适。这是真正的成功：当你的开发人员的结果更接近你最初的构思，甚至比你在纸上描述的更接近。但这只有在你清晰地描述你的概念之后才会发生。

不要只说，“NPC A 比 NPC B 强，但 B 的反应速度更快。”使用表格和图表为角色的移动速度、角色可以承受多少攻击、角色攻击造成多少伤害、需要多少图像单元才能动画化攻击等分配实际值。这种表格在生产的 Q/A 和微调阶段非常宝贵。

不要只说，“大多数人会在几天内弄懂整个游戏。”制作一个表格，预测对于不同玩家的产品寿命，指示在哪些时间点上你期望不同的游戏特点被发现。用户测试随后将为设计你的下一个游戏提供宝贵的反馈。

细节处给予演示

有时候几张草图就足够了，但如果这个想法对于项目的概念非常重要，你可能需要自己制作一个简单的动画。当元素的行为变得过于复杂和模糊，难以在纸上描述时，你需要制作一个原型。制作原型的另一个好处是，这种做法通常会导向更简单、更优雅的解决方案。

即使提供了动画和原型，也要用文字来表述概念。确实，一份动画胜过千言万语，但是文字可以用一些动画不能表达的方式进行沟通。文字还可以清晰地说明在观看动画时可能会忽略的重要细微差别。

制作时阐明方法

在现实世界中，“怎么做”决定了“做什么”的结果。例如，假设你选择了黏土动画。详细规划动画制作流程并记录下来。背景应该用什么材料和颜色？应该使用什么相机，为什么？捕捉帧的处理步骤是什么？等等。如果你尝试过，你就会知道这些因素中的任何一个都可能对最终结果产生严重影响。

例如，假设你正在开发一款摩托车赛车游戏。你指出，摩托车必须通过它们各自的优缺点来平衡。你甚至提供了一张显示它们平衡性的图表。然后你指出需要进行微调。说明你计划如何进行微调-流程是什么？假设你的游戏主角是歌剧魅影。描述玩家键盘如何映射为管风琴。提供每个键的映射图。指定将提供多少个声道。与你的程序员商讨并完善每一个细节的如何。然后记录下来。两种不同的“如何”可能意味着完全不同的结果。

确保有多重替代

项目经理总是花大量时间在甘特图和 PERT 上。个人来说，我真不觉得这些对游戏开发有什么帮助：原则上来说是因为有的变数太多了。你的游戏技术越激进前卫，你的开发流程就越难以预测。最佳的保证团队按日程规划达成里程碑的方法就是多留后路。

返回键盘和管风琴的例子。你的工程师给你描述了一个终极优秀、效果完美、体验身临其境的方案——需要 50 个工时来实现。和其他讨论过的东西一样：你把这些都记载下来。

但是你不能在这里停止。你还得问，“如果我只想要一个削减过的、八声道的管风琴需要多少（工时）？只达成最基本的需要多少？如果有一点协助呢？”然后你把得到的答案都记下来。等到游戏发售日，FedEx 的车来人搬走你的游戏发售的时候，你能简单的用一句话找回面子：“好，立马用方案 C。”

我做产品设计询问工程师的时候最大的错误，是问：“这个需求能实现吗？”除非你问的是一流程序员，否则这个问题就完全没有意义。更具体一点的，回复通常会落入以下三个类型：

• （低端程序员）“当然没问题。”
• （中档程序员）“不行，做不到。”
• （一流程序员）“可以做，大约得两周。或者我稍微改一下形式，像这样，只需要五个小时。”

总是要多问至少一个替代，预估一下每种大约要花多长时间。然后表达你的意见：如果我们有时间，就做这个。没有的话，就那个。

放灵感以其生路

我已经警告过你不要扼杀灵感和随着看到想法在你手中变成有生命的物体而带来的兴奋和创造力。你必须允许你的文件容忍变化——无论是你还是（希望是聪明的）他人所做的变化。

我在英属哥伦比亚大学学习音乐创作时，首次了解到这个教训。我费尽心思写了一首新文艺复兴风格的铜管五重奏曲，自认为非常自豪。我的教授也很喜欢。然而，当我们把它带到学院最出色的铜管五重奏排练时，在短短十秒内，我经历了几个阶段的恐慌、怀疑、愤怒和临床抑郁。五重奏开始演奏，然后在大号手的指示下停下来。那个家伙拿出铅笔改了几个音符，然后大家继续演奏。这种情况发生了不止一次。

我的教授看到我突然变得虚弱无力，转身对我说：“不要担心，他们也对莫扎特这样做过。而且他们通常是对的。”

事实上，无论东西在纸上看起来有多好，最伟大的专家在它进入客观感知的具体世界时仍然会修改它。然而，你不想见证你的设计和梦想被无情地摧残。相反，你希望它们能够有机地生长——创意自然地从你种下的种子中生长出来，而不需要移植外来的肢体和身体。

以下是创建可以容忍变化而不破坏原始想法或破坏开发过程的文件的一些提示：

• 确保将那些对游戏概念非常重要，不能更改的方面固定下来;
• 确保每个人都理解游戏应该具有的感觉以及每个细节的目的;
• 如果信息有重复，必须进行交叉引用。否则，如果有更改，有人可能会得到互相矛盾的指示;

以下是实际实施阶段的一些提示：

• 当有人提出更改时，回到设计文档中检查它是否与你的游戏“灵魂”一致。
• 检查这是否只是一个孤立的变化，还是具有重大的全局生态影响（参见“改进的生态学”）。如果是后者，就把它留到下一个项目中。
• 更新设计文档并包括更改的原因。如果你拒绝进行更改，请说明并解释为什么被拒绝。
• 更改、删除和被拒绝的想法应该保存在主文档中，以避免重复讨论同一件事情。
• 每个人必须使用相同的版本。过去的版本应该被销毁。
• 最关键的、最重要的：设计文档必须仅由一个人监督维护。

制作结果应有源

我见到过有的设计稿连页码都不标记，而其作者还总是抱怨其他人不遵从指示。任何好的文字处理软件都会自动给页面标页码，在页眉页脚标日期和标题。有些还允许你在章节改变时改变页眉。用粗体让重要信息能吸引人注意力。在文档中不同地方按你喜欢的频率重复它，只要你交叉引用的够好能够一次性一起改变。完完整整的做一份目录。

你也许还希望用 HTML 写文档，利用超链接。有些先进的文字处理器不用 HTML 也能提供超链接功能。但要记住，很多时候人们还是喜欢参照打印件。（至少电脑坏了修的时候不至于什么都没得看。）

干净排版后发布

这些工作都做完之后，你就需要动员起一切你能做的去让所有人都真的去读并且运用设计稿。一堆纸不会有人在意——看起来不够重要。只有上了硬封皮的才看起来很重要。

整理一个应该有设计稿的人的列表。把列表保存好。整份设计稿都打印出来，每页页眉都带好日期，打好孔上到活页本里。本脊和本封上做标记。一旦有更新，给每个人分发更新过的页面。到了一定程度，你可能需要给每个人提供一本新的。

总结一下……

电影制片人使用电影剧本，建筑师使用蓝图，音乐家使用乐谱。根据古代传说的证据，甚至连宇宙创造者也创建了一份设计文档——后来他让一些先知们窥视了一眼——在原始的“要有光！”之前。因此，开发者同好们，遵从着这些榜样们的行迹，自然也可以做同样的事情。做好它，后面的工作就会一帆风顺。

---

Tzvi Freeman 在加拿大温哥华的 Digipen School of Computer Gaming 教授游戏设计。他设计了多款商业游戏，同时为其他许多提供了咨询。可以通过电子邮箱 TzviF@aol.com 联系到他。