篇目1，游戏设计文档为何不再具有可行性？

作者：James Sweatman

在过去数年中，游戏设计文件有多个称谓——GDD、设计宝典、游戏概要文件等。无论是哪个名称，它们描述的都是同一件事情：电子游戏的即时设计文档。GDD已有数十年时间被视为设计方向的支柱，为无论开发者和美术人员提供了游戏的愿景。这听起来很棒吧？谁不想在同个地方存储了解一款游戏所需的一切内容呢？

我就不想。

我在2008年进入游戏行业，当时刚刚大学毕业并且胸怀抱负。我进入了一家颇具知名度的独立工作室，准备开始施展抱负。我在大学的三年时光教会我撰写最佳文档并与不同团队成员进行有效沟通，这意味着我当然会成为一名出色的游戏设计师！

我们的设计团队与EA紧密合作，后者当时需要的是严谨的设计文档，该精简的地方就精简，需要文档的地方就不能省略。太完美了！我能够驾驶这种设计方法。在一年左右的时间里，我们的方法也的确管用。我们推出了过硬而富有规划性的游戏，这达到了我们所有的要求并且没有遇到什么麻烦。但在2010年我们着手一系列新颖而更具创意的项目时，一切都变了。

我所重视和信任的旧方法开始支离破碎。为一款实际上并不存在的游戏撰写大篇幅的文字这种感觉太疯狂了，居然会让这么多未经测试的理念像纸牌一样层层叠加起来。你只需要一点点怀疑就可以将其推翻并否决整个项目。

在2010年早期，我所就职的工作室取消了一款游戏，并不完全是因为设计很糟糕，但这也的确是其中一个因素。我们开始意识到编写庞大的文档，寄希望于创意美术人员和开发者去阅读并快乐地执行，真是一个致命的错误。

为何GDD不再可行了？

1.它们有太多假设

设计文件的一个前提就是文档。它并非一个游戏零件，它无法保证某个理念很棒，它仅仅是个理念而已。这种在微软Word文档中进行的简单理念探索导致我们无法真正去证实这些理念。在这个过程中会开始出现许多假设，你的产品却要以这种相当不稳定的东西为基础。

2.它们总是容易过时

假设我们编写了很棒的文档，并且有名开发者按照要求进行执行。我们现在发现有一系列功能需要更改。此时我们不但要向开发者提供引导内容，还得扯断文档以便日后更新。

你每在游戏中做一个调整，你就得更新一次文档。这是一个无止尽的编辑和更正循环。而这些时间原本却可用于编码、创造资产或平衡内容等一切有利于团队和产品的有意义之事。我敢说如果你现在看看自己的设计文档，肯定就会发现它至少有一个地方已经过时了。

3.没人会去看GDD

经常有人告诉我们管理层需要GDD，因为这些文档可以证明我们已经吃透和仔细调查了游戏理念，并且我们在开发之前已经做足了准备。

很好，但他们究竟有几次真正看过这些文档？一直都有看吗？还是一半时候有看？也许“从来没有”看过吧。虽然它可能是上级的要求，但管理层、制作人等之类的领导几乎都没有时间去看你长达5万字的设计文档，可能也并不想（或者需要）看。

但开发者们呢？美术人员呢？他们会逐字逐句去看吗？不会。你团队的多数人都有一个很好并且想制作的游戏理念，他们并不需要你在文档中填入所有的细节。他们只想知道与自己的工作有关的要点，这就够了。他们花在看文件和重新查看说明的时间越多，就越不可能制作出有趣的游戏。

4.它们太刻板了

设计文档从定义上看并不开放，它们并非烟盒背面任人解读的涂鸦，它们是关于一个理念的详细图表和蓝图，人们必须按照这个文档的指示来执行操作，否则游戏设计就会失败。这种刻板性会扼杀团队的创意，只有设计师才能独揽创意权，排除他人的见解，会在理念和执行之间隔起一道墙。

5.它们不允许失败

以文档形式完整设计一款游戏意味着在你编写一行代码之前就必须敲定许多元素。而等到发现其中的错误或问题时，整个产品已经围绕这个愿景基本成型了，这意味着理念的任何重要调整都可能产生巨大成本。

有什么替代方法？

这里并没有什么可以替代文档的方法。你还是得将某些东西落实到纸上，否则你就只能瞎摸着开发游戏，但这并不意味着我们在执行游戏开发之前需要阅读一整本的指南。我们所需要的只是一些引导，一些给我们指路的标志而已。所以将来你撰写文档时请先考虑以下要点：

1.在早期时尽量保持简洁性

在得到证实之前，理念只不过是理念而已。最好将文档控制在最小篇幅内。这里我指的是一句话的概括。要确定你的需求，以便证实理念并令其生效。我发现一个有用的方法就是“用户故事”。用一个简单的故事来解释你的想法，以及它为何有趣或者好玩。要从玩家角度来考虑这一点，“作为玩家我可以用Y来做X，以便感受到Z”。

2.保持敏捷性

在少量或没有文档的情况下开发游戏，意味着你无需等待设计师完成其洪篇巨制的文档就可以测试理念了。直接进入纸质或简单的数字版原型，你就可以尽早从失败中汲取经验。没有什么设计文件能够一次性全部更正好。所以在数周甚至数月的文档编写和预制作阶段后才发现某个理念并不可行，这对你的项目或工作室来说可并不是件好事。

3.保持合作性

不要闭门造车地自己编写文件。应该把这种“独行侠”式的游戏开发风格抛进历史。无论你在哪个游戏团队就职，最好都要让团队中的其他人也像你一样对游戏和设计满怀激情。

不要用冗长的文档来控制游戏设计，而要和团队一起发现和解决问题。你的团队越是深入地参与设计过程，他们与产品就会越亲近，产品也会越棒。

4.调查和记录

当你制作更大的文档集时，最好是从两种形式中择一而行：调查或记录。针对特定样本的文档调查，如果足够简洁，可以成为帮助团队制定决定和引导产品更广泛设计的优质资源。记录是游戏设计的真正定义，也是设计交流或创建决定产品方向的原型的结果。这些是你在对游戏设计的一些决策上犹豫不决时可以参考的文档。

5.不要用Word写文档

如果你必须写一些设计文档时，不要用Word进行编辑。不要误解我的意思，Word是个好工具，但却并非编写游戏文档的好帮手。它刻板、封闭性的特点，以及不支持高级排版和图像功能，所以不适用于设计文件。要让你的文档具有开放性、连网、合作性，最重要的是，要视觉形象化。Wiki’s、 Prezis和Google Docs等其他在线文档更有利于制作快速、形象化的文档。

总结

虽然我的确很想给传统GDD判个死刑，但也有一些时候我们真的需要GDD。例如在外包项目、第三方或多家工作室合作开发的时候，就总会需要一些形式的中心设计文档作为参照。

寄希望于人人都能参与到合作性、无文档的开发氛围中可能有点不现实，但总有办法克服这种现状。可以尝试新的文档撰写方式，摆脱Word的桎梏，为濒临死亡的GDD理念引进新方法。

篇目2，阐述用白板设计替代游戏设计文件的方法

作者：Andy Moore

我讨厌设计文件。我在编撰设计文件时碰到的最大问题是，最终可能会花费许多时间来编辑设计文件。

在我看来，游戏核心机制应当在1天的时间内构建完成。原型的润色只能耗费1周时间。如果你将整个周末的时间花费在编写设计文件上，而我将整个周末的时间花在制作机制上，谁的成果更好呢？你获得的是几张写满有趣理论的纸，而我拥有的是真正的趣味内容。

假设，我拥有个小团队，我将大量的内容存在自己的脑中。我用一些工具将数据记录下来，比如白板和制定待办事项列表。有人可能会辩解称，我所做的这种数据收集便是一得特殊的“设计文件”。或许，这种想法是对的。

有时候，你必须编写设计文件，因为其他人（游戏邦注：比如发行商或投资者）需要它。有时候，你需要用设计文件来换取政府扶助金。如果是这样，我很遗憾你需要将大把时间耗在编写文件上。有时，你拥有庞大的团队，所以你必须通过设计文件确保所有人达成共识。我认为这正是大型工作室开发游戏更耗时间的原因之一，因为大团队成员之间的交流效率较低。

我有时会使用白板，这种方法最接近于我心目中的“设计文件”。

图片说明

以我的文字游戏为例，它刚刚设计完成，内容还留在我的白板上。我从1月22日开始进行这款游戏的制作。

白板位于我桌子的左边，面对着我。在我开启代码IDE前，我拿起笔开始勾勒游戏主体架构。在大约10分钟的时间里，经过为数不多的修改，我得到了以下内容：

在游戏开发过程中，我或许修改过写在左下角的部分细节内容，但这块白板从游戏设计之日起从未更换过。

以下是对我们现在所看到的这幅图片的注解：

1、可以将其视为游戏想法的思维地图，我尝试将游戏的关键元素从脑中剥离，记录在白板上。我发现这样做确实很有好处，因为有时我会遗忘曾经想到过的某些关键元素。这也是我总是在随身带本笔记本的原因。

2、白板左半部分是游戏屏幕草图。这款游戏的目标很简单，你可以看到我在白板右边对游戏暂停等内容提出质疑。我发现，快速构建UI能够帮助我在脑中组件数据结构，帮助我正确地组织想法。如果我可以在白板上将“游戏玩法”划归为单个功能，我知道自己已经获得了易于构建的系统。

3、我草拟了游戏的基本玩法机制，就是右下方的文字内容。当我在脑中思考游戏玩法时，它绝不只是张图片。分解游戏玩法以得出这些组成部分是件麻烦事，相当于将机制分解成赤裸裸的元素。

4、白板右上方红色文字是我认为必须回答的关键问题，这样我才能获得可运行的原型，比如“格子应当设计成多大？”和“如果你的剩余字母无法发挥作用会怎样？”

我的方法与编撰标准设计文件的方法有如下不同之处：

1、制作这些内容最多只耗费30分钟时间。

2、我可以将白板放在桌旁，面对着我，在制作游戏过程中可以随时查看。

3、我从未更换白板，即便游戏玩法发生显著的改变。

更改核心机制

游戏玩法类似于《超级拼字》，但仍有所不同。你的角色将在格子上移动，而且你只能从角色当前站立点开始拼字。

看下我的最后两条游戏玩法元素，就是上图中右下角的绿色文字部分，你会注意到这两条描述了这种游戏玩法中的危险元素：

1、无有效移动 生命-1

2、移动到某些格子 生命+1

也就是说，假如你移动到角落而且无法找到新的拼写路径，那么你就会失去1个生命值。游戏将使用标准的模型，你总共有3个生命值，看看能够坚持多长时间。这样的机制看起来很不错，不是吗？

事实情况表明，即便设计了较小的棋盘，玩家也几乎不会遇到拼词障碍。玩家在游戏中总是可以找到合适的词汇。再加上偶尔会走到生命+1的格子，每个人最终都能够获得99个生命值，游戏永远无法结束。

事实证明，英语词汇是相当灵活的，我的游戏机制根本行不通。于是，我不得不转向使用基于计时的系统，移除生命值元素，添加计时器。最终，这种措施导致我在游戏中设置的许多机制和平衡机制发生改变。

这就是为何原型如此重要的原因所在，从设计文件上你看不出机制是否有效。你必须将其制作出来，而且必须尽快制作出来。

我本来可能会再花一周的时间来细化设计所有能够让玩家生命值+1的不同方法，并规划死亡动画，从音乐师处预定死亡音乐。但如果这样的话，投入的这些精力将完全浪费。

我将原始想法留在白板上，可以时刻提醒我游戏的核心简单性，提醒我游戏最原始的想法，提醒我游戏可以多么直观。如果我开始更改白板上的内容，很快就会陷入功能蔓延的困境。此外，将错误留在身边还能不断鞭策自己提升游戏设计技能。如果我将这些内容擦除，下次或许还会犯下同样的错误。

保持视觉风格稳定性

我在设计界面时，不只是绘制些许占位符逻辑盒。我在界面中花上了小企鹅，将部分UI元素添加到我认为合适的位置上，并设计富有特色的地图。以下便是游戏最终的界面：

看看这个界面，格子布局、企鹅主题甚至暂停键和计时器几乎与原先的规划相同。

保持风格一致性对我制作的游戏相当重要，有助于保持开发的一致性，使设计的背景显得更有意义。

我觉得编撰设计文件并非适合我使用的方法，以上便是我所用的替代方法。

篇目3，解析各种糟糕的设计文件类型以及解决方法

作者：Richard Rouse III

本篇文章是摘自Richard Rouse III的著作《游戏设计：原理与实践》的修订版。这本书覆盖了所有游戏设计的相关内容，包括想出一个可靠的理念，执行游戏玩法，以及测试最终版本的游戏。在设计师真正开始进行游戏编码前，他们必须先将游戏设计呈现在设计文件上。而就像Rouse在书中所提到的，并非所有设计文件的创造都是相同的。

“省略不必要的内容。确保表达的简洁。句子中不应该包含任何没有意义的单词，而段落中也不该包含任何没有意义的句子，就像绘画中不应该包含没有意义的线条而机器中不应该包含没有意义的组件一样。但是这并不是说作者们应该尽可能确保句子的简短或者不能阐述所有细节，而是说他们最好尽可能直接简洁地传达所要传达的内容便可。”

——《The Elements of Style》William Strunk

就像我之前提到的，如果我们能够获得一些较专业的游戏设计文件，我们便能够更好地明确游戏产业所要求的规格。然而你也必须谨慎地处理这一过程，因为有可能你所获得的设计文件并不能为你带来多大的帮助。很多有经验的专业人士所撰写的并且是用于一些已发行游戏上的设计文件其实都非常糟糕。而为了教会你们如何避免这些糟糕的文件，我将在此列举出一些不同类型的糟糕设计文件，并阐述它们为何会遭遇这样的失败。

极薄或充满省略符号的特殊文件

有一些不超过30页的设计文件却因为充斥着各种没有意义的内容而让经验丰富的游戏设计师感到无语。这些设计文件总是使用一些如“游戏玩法非常有趣”或者“反应非常强烈”如此乏味的内容进行描述。并且这些文件中的比较也总是平平淡淡，如“这玩起来就像《超级马里奥64》”或者“游戏的控制机制类似于《Quake》。”尽管有时候看来这种比较也会带来一些帮助，但是撰写出这些极薄设计文件的作者却未能详细解释《超级马里奥64》或《Quake》中的控制机制，使得读者对于这些游戏中的机制还是充满疑惑。

通常情况下这些文件总是会以较大的篇幅（也许是半页内容）去阐述背景故事。但是往往地这些背景故事对于游戏的开发其实没有多大的帮助。这种极薄的文件也总是会花大量时间在解释菜单的使用。并且这并不是指游戏内部的菜单而是系统菜单——也就是用户可以在此选择他们想要玩的游戏内容，并做出选择等等。虽然这些文件也设置了许多模型和选择，但是它们却未能详细描写这些选择对于游戏发展的影响。当设计师明确了哪些选择更重要或者玩家将选择哪些不同的游戏玩法时，他们就需要明确游戏中的菜单系统；但是这既不是游戏中最复杂的一步也不是设计师需要最先敲定的最重要系统。

这种极薄的文件一般都是出自于管理人员之手——他们总是认为自己就是游戏设计师。而这类型文件之所以也被称为充满省略符号的特殊文件是因为文件中总是布满各种省略符号。例如，全世界玩家在游戏中的遭遇都将被描写为：“丛林世界是一个炎热潮湿的地方，Garguflax猴将在此四处游动并纠缠玩家……”这应该是任何文件在向全世界玩家阐述内容的共同表达方式吧，即以省略号结尾，就好像在说“在这里插入游戏设计”似的。如此我们并不清楚这些文件的作者是否会在之后还会回到文件中填补这些省略，或者他们只是认为没有必要花时间解释游戏的具体运行吧。也许他们只是以此假设别人会来填充这些省略并创造出更棒的内容。

另外一个关于省略符号文件的例子是：“玩家将能从一些很厉害的武器中做出选择。例如比起玩家的其它武器‘Gargantuan Kaboom’拥有双倍的破坏力以及特殊的影响力。而‘Barboon Harpoon’则带有很好的摄像机效果让玩家能够在远处杀死敌人。而其它武器也都拥有各种有趣且强大的功能……”这一省略符号文件的作者未能详细描写游戏每个关卡所出现的武器，并且也只罗列出两种武器，从而让读者不得不自行想象其它武器。虽然文件告知了玩家其它武器也是“非常有趣且强大”，但是省略符号文件的作者却错误地认为开发一款游戏并不需要完整的描述。

极薄或充满省略符号的特殊文件的唯一优点便是它能帮助设计师快速有效地接管整个开发项目并将其变成自己的项目。我之所以说这是优点是因为管理者涵括在极薄文件中的内容通常都是荒谬的，或者不可能帮助设计师创造出真正可行的游戏玩法。但是我们还是必须对这种文件报以警觉。特别是当六个月后管理者开始抱怨“这与我所写的内容完全不一样”时，问题就严重了。

背景故事册

与撰写省略符号文件的作者不同的是，撰写背景故事册的作者会花大量的时间于文件编写中。这些书册（说是文件也不合适）经常会延伸至上百页——就像300，400或500页都不成问题。而关于这种大篇幅文件也存在着许多问题。

这类型文件所存在的第一个问题便是所有内容都以一种糟糕的表格形式呈现出来，且未提供任何明确的索引。在文件设计中，如果你的信息排列井然有序或者游戏设置非常合理，那不用设置索引也没关系了。但是如果同时忽视了这两点，你便会遇上大麻烦。而如果你的设计文件像《战争与和平》那样长篇大幅时，问题就会变得更加复杂。游戏设计文件的存在价值是让团队成员能够快速找到他们所面对的游戏内容的相关信息。就像如果程序员想要知道一个特殊敌人的AI是如何运行的，他便需要在此快速找到相关信息。而如果程序员不能在此找到这些信息，他便可能会将事情搞的一团糟。同样地，当美工人员想要明确游戏中特定领域需要何种纹理时，他便希望自己能够快速找到关于该领域的相关描述。设计文件并不是小说，没有人会老老实实从头看到尾。从根本上来看，设计文件更应该说是一种参考资料，而如果团队成员不能在此找到自己所需要的内容，他们便会放弃这些文件。

但是通常情况下当我们开始在这些背景故事册中找寻内容时，我们会发现很难在这里找到有关游戏玩法的相关信息。洋洋洒洒的500大页都是关于背景故事，而不是能够用于电子游戏中的内容（游戏邦注：即详细描写了游戏中的所有角色的背景，这些角色的好友，以及这些角色的亲戚和兄弟姐妹等！）尽管这些内容看起来非常有趣，但是读者在阅读了全部内容后会发现他们根本不可能在此找到有关于游戏如何运行的信息。通常情况下，这些文件的作者都是一些挫败的小说家或者是来自于非互动媒体的作家，他们根本就不了解游戏的开发。许多游戏都将故事阐述作为游戏的核心内容，而故事在游戏创作中也是非常重要的元素。所以在这种情况下，在设计文件包含游戏故事是言之有理的。但是不管怎么说，在设计文件中包含游戏设计比涵括故事更加重要。所以任何作者在撰写设计文件时都需要考虑的一个问题是“玩家能够在此做些什么？”尽管这些书册拥有一定的重量，并且也具有相当的风险，但是程序员在设计游戏过程中需要始终参考着这些文件，将其作为自己前进的向导。

过度的文件

有些设计师认为他们能够在设计文件中描写游戏的每个方面。当然了，就像我们之前所说的充满省略符号的特殊文件那样，许多设计文件都缺少了一些有用的细节内容，但是相反地也有许多设计文件阐述了过多的内容，这不仅是浪费设计师的时间，同时也会迫使读者们不得不仔细浏览这些多余的信息（从而找到真正对自己有帮助的内容）。此外，过度的文件也会让设计师陷入一个错觉中，即以为自己创造了一份完整周密的文件，但是孰不知他们只是过度强调某些对象的细节而忽视了其它该侧重的领域。

举个例子来说吧，假设一款游戏中设有若干角色，并且他们将在游戏世界中执行一定的行动。也就是游戏世界中住着一些市民，他们可以在此四处走动，坐下，站起来，与别人交谈或睡觉。所以设计文件应该基于AI描写这些行为。较为周密的文件会将这些内容分解为几个动画：起身，坐下，懒洋洋地坐着，懒洋洋地站着，行走，摆动着肢体语言等。因为一般情况下优秀的动画师和美工人员都比设计师擅于分解这些内容，所以在设计文件中描述这些内容通常都是多余的。但是就是有些设计师愿意浪费时间去一个个罗列出这些动画框架。太可笑了！在编写设计文件阶段我们根本不可能知道一个特定的动画中需要多少动画帧，因为这些内容也只有在游戏制作过程中才能逐渐明朗化。更不用说在设计文件中列出动画框架将会对动画师造成伤害了——他们会因为这种束缚的微观管理而倍感泄气。此外，设计文件还应该始终重视对于游戏玩法的描述，不应该轻易转向图像或其它图像文件领域。

另外一个例子便是我所说的“平衡数据”。这是一些关于游戏中的武器，道具和角色的真实统计。而设计文件则应该罗列出武器和角色所拥有的不同属性，例如一种武器拥有准确的射击率和极快的发射速度。除此之外设计文件也有可能会描写一种特定武器的特性，如“Double Barreled Shotgun虽然射程较短且不够精确，但是在较大范围内它却能够造成巨大的破坏力。”但是事实上，罗列出武器的这些属性对于设计文件来说并没有多大用处。就像是“Shotgun的精确度为2”这一描述并不存在任何特殊目的，因为在这里数字“2”并没有任何可供参考的环境，所以不具备任何意义。只有在游戏真正开始运转，也就是设计师能够根据玩家使用武器的情况平衡武器，并通过在不同设置中进行实验而达到预期效果时，这些价值标准才会真正实现。所以在我们真正能够测试信息之前创造大量的信息便只能说是一种浪费时间的表现。将内容以表格的形式表达出来虽然能够帮助设计师更好地阐述一些未经加工的想法，但是这种表格却只能呈现出最初形式，在游戏真正发行之前设计师还需要对此做出多次调整。

与动画细节和精确的平衡数据一样，资源代码也不适合出现在设计文件中。如果设计师甚至开始在自己的设计文件上编写代码，那就太夸张了！（游戏邦注：但是如果设计师也是游戏的程序员，那就无所谓了）设计文件不应该包含任何代码，甚至是伪代码。在设计文件中添加代码只能是增加文件的负担，或者将导致设计师忽略了那些本该阐述的内容。在这里，如果使用简单的如果则否则类的逻辑解释将会非常有帮助。因为这种解释能够在设计师撰写代码时告知他们所有的意外事件，以此帮助设计师在撰写文件时尽可能考虑到任何与游戏相关的情况和结果。但是如果你开始在文件中编写像C++语言这样的代码，那就只能说你做得太过火了。

如果说过度文件中也存在一些真正有用的信息，那也只能说设计师将这些信息隐藏在大量无意义的数据中并导致团队成员不敢去寻找它们。作者们总是认为自己能够预先规划好一切，并且自己也比团队中的其他成员更优秀。

尽管过度关注细节内容总比作者连自己在做些什么都不懂来得好，但是过度的设计文件却终究只会激怒那些依赖于文件的开发成员们。

空头支票式文件

这类型的设计文件总是拥有崇高的目标和高尚的想法，希望能够创造出真正优秀的游戏玩法。但是让人感到悲哀的是，这些作者一般都不了解电脑真正的功能或者一个拥有20个人的团队在一年半时间里真正能够创造出什么。

所以最终他们所创造的文件便只是基于一些幻想的理念而毫不考虑现实和可行性，并最终激怒了整个开发团队。

这种空头支票式文件可能包含“复制整个曼哈顿作为玩家的主要游戏世界，并伴随着代表城市中7百万居民的实时AI代理。”这种空头支票式文件的作者并不想费心去整理所有细节内容，如现有的电脑系统并不能在合理的时间框架（更别说实时了）下模拟7百万个居民。设计文件中提出的另外一个功能是“在游戏中设置自然语言解析器而允许用户能够打出完整且复杂的英语句子，而角色们也将以自己动态生成的对话做出回应。”这些设计师们并不想了解的事实是，研究机构花了数十年时间于研究自然语言解析器，但却只能生成一些简短的句子。当你发现自己正面对一份空头支票式文件时，你首先需要做的便是召开一个现状核实会议，并邀请主要程序员和美工人员以及设计文件的管理人员共同参与。当所有的人员都汇聚在一起时，你们便可以通过一张白纸或黑板快速简要地指出游戏中不切合实际的内容，而如果管理层仍然拒绝接受现状，你便可以考虑换份工作了。空头支票式文件中总是包含了一些省略号式特殊文件，即设计师只是罗列出一大堆不切实际的项目甚至还懒得去阐述它们的细节，而最终创造出一份极端糟糕的设计文件。

老化的文件

上述所提到的任何有缺陷的设计文件都可以说是老化的文件。的确，设计文件应该避免上述的任何问题，而如果设计师不能即时保持文件的更新，他的文件便只会沦落成老化的文件。我所知道的所有创造性游戏的设计在整个开发过程中都会不断发生改变，而如果设计发生改变了但是设计文件却不变，那便只能说你的文件开始走上老化道路了。

让我们假设开发团队中的程序员在老化的文件中找寻一些内容，却发现自己找到的都是一些过时的信息，随后她便会开始执行这些过时且冗长的功能。而这时候，那些知道设计变化的设计师或制作人便会注意到程序员正在创造一个不再合适的系统，所以他们也将阻止程序员的行动。而这一结果都将给双方带去巨大的负面影响，更别说会浪费程序员的时间了。除此之外，如果今后程序员还想了解一些有关设计的内容时他们肯定也不会再选择设计文件了——相反地他们可能会直接向设计师或者制作人寻求帮助以找寻最合适的系统。如此看来设计文件便失去了自己的功效，即设计师不能够将相关系统有效地传达给程序员。也许在这之后设计师会吸取教训而添加新系统，但是程序员可能永远都不会愿意再接近这一老化文件了。也就是说当设计发生改变时设计师如果未能即时更新设计文件，那么整份文件也将失去意义。今后将不再有人会相信你的文件也不再有人会愿意花时间去阅读你的文件。

维基系统能够帮助设计师更好地保持文件的更新。拥有了维基系统，开发团队中的所有成员便能够通过自己的网页浏览器去更新文件的某部分内容，而全版本控制和历史记录便能够阻止偶然的数据丢失情况的发生。举个例子来说吧，一个正在执行某一特定功能的程序员将能够修改设计文件的文本以适应功能的最终运行结果，并且他也能够添加更多信息或链接到这个新创造的技术型设计文件上。特别是在一些大型项目中，确保设计文件的即时更新更是设计师必须予以重视的任务。

分量较大的文件

很多人经常开玩笑地说他们不读设计文件是因为这些文件都太过有分量了。而不管是设计文件拥有难以忽视的分量还是开发成员们缺少阅读文件的兴趣都不是什么让人惊讶的事。并且这也总是我们难以避免的事实。我曾经听过一个来自某一游戏发行公司的前制作人阐述她的设计文件经验以及项目批准过程。她说道，“决策制作人”总是会选择更大规模的内容。例如当他们遇到两个具有同等价值的项目时，他们会为两个项目明确设计文件，并基于规模做出选择（也就是他们会选择更有分量的那一项目）。我们总是需要面对的惨痛现实是，如果你处于一个商业化游戏产业中，并且需要为了赚钱而努力时，你便需要尽可能确保设计文件拥有较大的分量。你需要让你的文件足够吸引人，能让读者一眼就找到它——虽然大多数读者都不会认真阅读这种设计文件，甚至有些人只会阅读文件开始的综述和目录。但是至少你能够让他们愿意选中你的文件，并对其拥有深刻的印象。

当然了，许多像这种厚重的文件其实也包含了大量对项目开发没有任何帮助的信息；就像是之前所提到的一些失败的文件类型，如背景故事册或过度的文件。作为设计师你所需要面对的挑战便是通过只在文件中提供一些有用的信息而让你的文件更具有实践性，并赋予其更大的分量而给读者留下深刻的印象。也有人想要在文件中包含大量的内容导览流程图或概念草图，或者选择一些更大的字体进行描述（但同时也避免太过明显）。当然了，我们也看过一些非常优秀的游戏的设计文件只有短短的10页。这时候人们便会好奇到底有多少优秀的游戏是因为发行商布满设计文件的分量而被彻底埋没？

谢天谢地的是，在过去几年时间里许多发行商和开发者开始意识到大规模设计文件的笨拙与繁琐。设计咨询顾问Mark Cerny便表示，开发者在一开始最好只接触那些简单的“宏观”设计文件（大约10页左右），并在今后的开发过程中再逐步扩展。就像我之前说到的，现在很多人都开始使用维基去组织并连接小规模文件中的设计信息。并且随着原型和图像解说式文件的兴起，现在越来越少的发行商会选择那些书本般厚重的设计文件了。所以往设计文件中塞更多内容的时代即将结束。

吸引别人阅读你的文件

一旦你完成了设计文件的编写后，你所面临的一大挑战便是让开发团队中的成员去阅读这一文件。通常情况下，许多程序员，美工人员甚至是设计师都不愿意花时间去细读你的文件。而其他成员可能已经在之前经历过糟糕的设计文件，所以自然也将你的文件判定为糟糕的文件。这时候你只有保持文件的即时更新，只在其中设置一些有用的信息，在列表中提供详细的内容，并只突出那些实用且可实现的游戏元素才能帮助你更好地吸引读者的注意。同时在文件每个部分之前设置一些简短且较高层次的总结内容也能够帮助团队成员进一步了解那些自己不曾关注的重要信息。除此之外，这些总结也能够帮助读者在深入挖掘文件细节内容前对它有一个宏观的了解。如果你的团队成员在尝试文件时发现了它的实用性，他们便会在真正执行特定系统或致力于特殊的图像内容时将其作为参考对象。与任何书面文件一样，如果你希望读者能够阅读你的文件你就必须先赢得他们的信任。

吸引别人阅读你的设计文件的另外一种方法便是确保读者能够轻松地找到它并进行阅读。你可以将设计文件置于团队中用于资产管理的同一个资源控制系统中。你肯定希望团队成员能够轻松地获得设计文件的最新版本，就像他们能够轻松地获得最新的游戏架构一样。因为你将不断地完善并更新你的文件以确保它与项目保持同步更新（并阻止它变成老化的文件），所以资源控制也将帮助你更好地追踪之前的文件修订版本。除此之外，维基系统还能够通过检查整个公司的内部网络而更好地向团队传达文件内容，也就是开发者便能够通过自己的网络浏览器随时阅读到最新版本的文件内容了。

当你完善了最新版本的文件时，记得向每位团队成员发送一封电子邮件告知它们文件的更新并解释改变的内容。如此，成员们便能够轻松地浏览那些更新内容。如果成员们发现改变中有与自己的任务相关的内容，他们便会通过网络而获得最新版本的文件，并仔细阅读相关的更新。如果读者们根本就不知道你做出了改变或者他们仍然只看得到旧版本的文件，那么你的更新便一点意义都没有。这时候版本编号便非常有帮助，如1.3版或2.7版之类的。你应该将这种版本编号以及更新日期明确地标注在文件的每个页码上。通常情况下人们只是会将设计文件打印出来，但却意识不到它是否已经过时了；而如果你能够提供给他们这些日期和版本号码，他们便能够快速意识到自己手上的版本是否是最新版本。

文件还只是开始

有些设计师或者是充满抱负的设计师总是认为完整的设计文件能够帮助他们创造出一款真正的游戏。的确，很多公司甚至拥有专属的设计师在编写这些文件，而当一个单独的团队开始执行他们的设计师这些设计师便会转移到其它项目中继续撰写新的设计文件。其实，设计文件更像是一种粗略提纲，是对于游戏创造的相关建议，在游戏真正进入最终测试版本之前设计师都不应该将其参和进游戏创造中，并且也不能将其当成是设计游戏的唯一武器。设计师总是希望自己在整个项目中拥有绝对的存在感，所以他会在必要时刻对设计做出任何修改以确保游戏拥有最大的吸引力，而与此同时他们也将相对应地更新设计文件（确保设计文件的内容也将不断改变并完善着）。

真正优秀的游戏设计师总是会不断平衡游戏中的武器，AI，控制以及关卡等内容。同时他也会始终确保游戏能够遵照设计文件而发展并始终牢记自己的最初创想。

当设计师撰写了一份设计文件后他会将其传达给团队中的其他成员落实行动，而这些成员们们便会基于自己的观点和游戏风格等对设计做出适当调整。所以设计文件将成为开发人员的创造行动的跳板——而不是设计师的跳板。虽然设计文件是游戏创造中的重要组成部分，但是它却不是游戏创造中的必要部分。为了成为一个项目中的重要贡献者，设计师就必须全身心投入于设计文件的创造中。可以说在某种程度上，撰写设计文件是电子游戏中相对简单的过程，而将文件应用于游戏中并创造出真正吸引人的游戏体验则是非常困难的过程。

篇目4，设计教程：如何撰写游戏的特征概要

作者：Ethan Levy

游戏开发的一个明显的事实是：完工的游戏永远不会完全符合你当初的想像。即使在游戏开发过程中严格执行，也会与最初的设想存在5%-10%的偏差。想法是廉价的，执行是昂贵的，更别说游戏必须发布。例如，我们的游戏《Enhanced Wars》大获成功，但在发布后的三年，我们仍在改进它，所以它永远不可能完全符合我们当初的想象。

在过去很长一段时里里，当我开始设计游戏时，我会先写一份很长的文件，详细地说明游戏的各个方面。最终，我发现这些文件基本上是白废功夫。没有人有耐心看完75-100页的文件，并且大部分初始概念在执行时都会面目全非。现在，当制作游戏时，我会通过一个方法管理好所有灵活的小功能的设计过程。

这个方法主要是撰写我称之为概要的简短文件。在本教程中，我将向大家介绍撰写一个特征概要的过程。

第一步：填写特征

在撰写特征概要以前，你应该把所有被提议的想法罗列成表。团队中的所有成员都可以并应该对游戏提交自己的创意。

(案例：《Enhanced Wars》的特征概要)

我严重建议使用谷歌电子表格来制作以上表格。你可以设计你自己的格式，但我建议你每一个功能都应该包含名称、KPI、执行难度、描述（一般是三句话）和评论这几项。写完概要后，各个功能的名称要超链接到相应的文件。当选择在游戏中添加什么功能时，应该优先制作这个列表，以便确定设计意图的关键方向和开发成本。

KPI是关键绩效指标。在上述例子中，这一栏是团队关注的特定指标。标准的KPI是留存率（游戏邦注：指在一段时间内留在游戏中玩家比率）、沉浸感（每天游戏的持续时间）、病毒性（由老玩家带来的新玩家的数量），赢利（如果是免费游戏，玩家在游戏中花的金钱数量）和品质（能提高游戏的得分/用户评价，但对衡量指标没有直接影响）。取决于你的游戏和商业模式，你的团队可以决定加入哪一项KPI。

第二步：撰写高概念

即使你的开发过程不强调文件，你也应该意识到，人们通常尽量少阅读。因此，我建议你的特征概要以简短的高概念为开头，这样其他人就能迅速理解这个特征。

以下是《Enhanced Wars》的高概念描述：

1.1.高概念

尽管《Enhanced Wars》是一款多人游戏，它也需要一些单人模式的内容，用来教新玩家熟悉游戏或给老玩家作为回合间的消遣。单人挑战关卡是一系列遭遇战，玩家可以在这种关卡中学习游戏和打发时间。这个概念类似于新闻上刊登的象棋迷题。

1.2.KPI

留存率：挑战关卡的主要设计目的是，提供一个安全的环境，让新玩家学习游戏，从而吸引更多新玩家并把他们转化为长期玩家。

正如你所见，以上信息只是将概要列表中的特征稍微拓展了一下。

第三步：形象化特征

当开始撰写详细的特征执行办法时，你必须详尽地解释UI和流程。但在早期阶段，我建议制作简单的实体模型，以便视觉化设计，使团队更加清楚方向。

(案例：《Enhanced Wars》中的单人挑战关卡对话的实体模型)

特征概要应该包括至少一张图片。可以是特征需要的界面模拟图，也可以是显示玩家在游戏中如何使用特征的故事板或其他视觉化表现形式。

在一张图片中，用清楚的图象表现玩家将看到的特征。

第四步：充实细节

最后，你应该列出特征的所有主要方面，写一到两段话来描述各个方面。再者，这些不是完整的执行步骤；它们只是把你头脑中想到的功能固定在纸上，以便你的团队评估它。

以下是《Enhanced Wars》的挑战关卡的详细进程系统描述：

2.2.进度

各个情节都体现玩家距离完成还有多少进度。一旦玩家完成该情节的所有挑战，对话框中将出现一个奖励的图标。

情节中的关卡一开始都是没有解锁的，可以按顺序玩到。一旦完成关卡，下一个关卡的星星图标就会亮起来。

这个阶段的关键词是简洁。如果你发现你的特征概要已经超过2到3页了，那么意味着你可能得把你的概念分解成多个功能了。你的目标是，你写出的信息足以让你的团队理解你的设计意图。

过程的目的

特征概要可以很快写出来。然而，详述《Enhanced Wars》的各个细节可能要花整整两周。给我几天时间，我写出的概要就可以开发上两年了。但顺着这个过程，你可以把头脑中的想法固定在纸面上，让你们的团队评估它的可执行性。有了概要以后，你便可以决定哪些功能可以开发，然后进一步说明如何执行它们。

篇目1，篇目2，篇目3，篇目4（本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao）

Death of the game design document

By Jagex’s James Sweatman

Jagex’s James Sweatman on why central design documents don’t always work, and the alternatives available

It has been called many things over the years – GDD, Design Bible, Game Overview Document. Regardless of title, they all describe one thing; the living design document for a video game. The GDD has been a pillar of design direction for decades, providing countless developers and artists a singular vision for a game. Sounds great right? Who wouldn’t want one place to store everything there is to know about a game?

I wouldn’t.

I joined the game industry in 2008, fresh out of university and with big dreams. Going into a well-regarded independent studio, I was ready to set the world alight. My three years at university taught me how to write the best documentation and effectively communicate with different team members, which meant I was sure to be a great game designer!

To start with I was right: Our design team worked closely with EA, who at the time wanted rigid design documentation, with briefs upon briefs and documents on documents. Perfect! I can nail this design malarkey. And for a year or so it worked. We shipped solid, formulaic games, meeting all the requirements set of us and didn’t rock the boat. That began to change as we rolled into a couple of new, more creative projects for 2010.

The old ways I’d held so dear and believed in so much had started to crumble away. The idea of writing thousands of words about a game that didn’t exist started to feel maddening, with so many untested concepts sitting on top of one another like a wobbly house of cards. It would only take a small gust of uncertainly to topple them and bring down the whole project.

In the early months of 2010 the studio I worked for had a game cancelled, not 100 per cent due to poor design, but we knew it was a factor. That hit home. It really began to sink in how our method of writing huge documents, expecting creative artists and developers to read them and happily implement our ideas, was fatally flawed.

So why don’t GDDs work?

1. They make too many assumptions

The premise of a design document is it is exactly that – a document. It isn’t a game fragment, it isn’t proof that an idea is great, it is only the idea. This simple exploration of ideas in Microsoft Word prevents them from ever being truly proven. Along the way many assumptions will begin to be made and your product is now based on some fairly shaky foundations.

2. They are always out of date

Let’s say that we’ve written our wonderful document and a developer has implemented it. We now find that a collection of features need to change. At this point not only do we have to provide guidance to our developer but also begin pulling apart our document in order to update it for future reference.

Every time you make a change in the game you have to update your documentation. An unending circle of edits and corrections. All time that could be spent helping with code, creating assets or balancing. Useful things to help the team and the product. I can guarantee that if you look at your design document right now it will be out of date in at least one major place.

3. No one reads them

We are always told that management need a GDD. They are proof that the game idea is thought out and well researched, and that there is evidence of all the preparation before development (preparation that we usually have to rewrite).

Great, but how many times are they actually read? All the time? 50 per cent of the time? Probably ‘never’ is the answer. While it may be a requirement, executives, producers, or leads of any kind almost certainly don’t have the time to read your 50,000 word document and probably don’t want (or need) to.

But what about the developers? The artists? They read every word right? Nope. Most of your team have a good idea of the game you’re all trying to make and won’t need all of the detail you’ve stuffed into your document. They want the points that are important to their work and that is all. Time spent reading and rereading is time not spent on making a fun game.

4. They are too rigid

Design documents by definition aren’t open to interpretation. They aren’t doodles on the back of a cigarette packet for someone to interpret. They are detailed diagrams and blueprints for an idea that have to be implemented by the numbers otherwise that design falls apart. This rigidity kills creativity in the team, saves it all for the designer, removes by-in, and builds a wall between the ideas and implementation.

5. It doesn’t allow for failure

Fully designing a game in document form means so many elements have to be decided before you have even written a single line of code. By the time development begins to reveal errors or problems an entire production has formed around this singular vision, meaning a huge cost for any core changes to the concept.

What’s the alternative?

There is no escaping documentation in some form. You have to get something on paper otherwise you’re developing in the dark, but that doesn’t mean we need a bible to guide us before we start on our path to game development glory. All we need is some guidance, a few signs to help us on our way. So when putting finger to keyboard think about these points for your future documentation.

1. Keep it light early on

An idea is still an idea until it is proven. Keep documentation to an absolute minimum. By minimum I’m talking a single sentence. Define what you need in order to prove the idea and make it happen. A way I find useful is the ‘user story’. A simple story that explains your idea and why it’ll be fun or interesting. Keep it in the guise of a player. “As a player I can do x with y in order to feel z”.

2. Keep it agile

Working with little or no documentation means you aren’t waiting for your designer to finish their epic tome before you can test out the idea. Jump into paper or simple digital prototyping so you can fail early and fail often. No design document has ever been correct first time. So waiting to find out an idea doesn’t work after weeks or months of documentation and preproduction isn’t good for your project or your studio.

3. Keep it collaborative

Don’t sit in a corner for weeks writing your finest works. This kind of “lone creative” style of game development should be and hopefully will be consigned to the history books. If you work in any kind of team in the game industry then anyone in that team should and will be as passionate about games and design as you are.

Instead of controlling the design with sprawling documents, work to discover and solve issues together. The deeper your team’s involvement in the design process the closer they’ll feel to the product and the better that product will be.

4. Research and record

Once you do produce larger sets of documentation they should come in one of two forms: research or recordings. Documenting research on a particular subject, if kept light enough, can be a great resource for aiding decisions as a group and guide the wider design of the product. Recordings are the real definitions of the game’s design, and are the results of design conversations or prototyping that fully define the direction of your product. These are documents you can refer to when being questioned on decisions made around the design of the game.

5. Don’t do it in Word

If you must write a design document of some kind, do not craft it in Word. Don’t get me wrong, Word is a good tool (I’m using it right now) but it isn’t a tool for documenting a game. Its rigidity, closed nature and poor support of advanced layouts and imagery makes it unsuitable for design documentation. Keep your documents open, online, collaborate and most importantly – visual. Wiki’s, Prezis, Google Docs and other great forms of live documents are far better for rapid, visual documentation for all to see.

There is no design utopia

While I’d love to really put the nail in the coffin of the traditional GDD for good, there will be occasions where something like it may still be required. Outsourcing, third-party or multi-studio development will always need some form of central design documentation for reference.

Expecting everyone to join the collaborative, document free commune may not be realistic but there are always ways to challenge the status-quo. Try new ways of documenting, break free of the shackles of Word and bring a fresh approach to the dying concept of the GDD.

篇目2，Design Docs: Barf

Andy Moore

I hate design docs.

I’ve been co-hosting a radio show recently on GameDevRadio.net, where we talk about game develoment topics on a weekly basis. A few weeks back we discussed design docs, and I think I did a good job of denoting when a design doc is good or useful, and when it is bad and just a detriment to your team. Go take a listen! I’ll sit here and wait patiently, but you don’t have to listen if you don’t want to. After all, I have it.

Summarized:

My biggest problem with design docs is that you can end up spending more time editing the design doc than anything else.

In my little world of game development, a core mechanic should be built in a day. A polished prototype should take you a weekend. If you spent all weekend working on a design doc, and I spent all weekend actually making mechanics, who’s in a better spot? You have a bunch of papers with theories on what is fun, and I have hard evidence.

That said, I have a small team (of one, usually!), and I hold a lot of things in my head. I use a few tools to hold data externally, like white boards and to-do lists, and one could argue that the collection of those things is a strange type of “design doc” I am referring to as I work. Fair enough! You might be right there.

Sometimes you have to make a design doc, because some suit somewhere (publisher maybe? investors?) demand it. Sometimes you need one for government grants. If that is the path game dev is taking you, I am sorry for your lots. But sometimes you just have a large team, and you have to make sure everyone is on the same page. Cool! I get it, and I also think that right there (the inability to effectively communicate across your large team) is one of the reasons why bigger studios take so long to make games in the first place. But I digress.

I mentioned I sometimes use a whiteboard. It’s the closest I come to “design doc” in my mind, and I wanted to share it with you!

Again, with pictures!

So let’s take a look at my word game as an example; it’s fresh and still sitting on my whiteboard. Back on the Sunday that was January 22nd, I started working on the game. I got up relatively early that morning, and while my head was still mostly in the clouds, I went to my desk.

Just to the left of my desk, facing me, is a whiteboard. Before I opened the code IDE, I picked up a marker and started sketching. In about ten minutes, with only minor amounts of erasing, this is what I came up with:

I might have tweaked some of the written details in the bottom left corner throughout the day, but this whiteboard has not changed since day one of my game design journey.

Here’s my notes on the image as I am seeing it now:

This is mostly a mind-map of ideas, trying to get the key elements of the game out of my head and down on a hardcopy somewhere. I find it really helps to do this, as often some keystone element I once thought of is lost to the mists of my memory. This is also why I always carry around a moleskine everywhere I go.
The left half of the board is a simple flow chart of the game screens. One of the goals of this game was to be very, very simple and uncomplex; you can see me questioning things like the pause screen (“need this?”) right on the document. I find doodling the UI really quickly definitely helps me form data structures in my head, and helps me properly organize my thoughts. If I can compartmentalize “gameplay” to a single function on the whiteboard, I know I have a system that’s easy to build.

I sketched out what I thought the basic gameplay mechanic was going to be, in text on the bottom right. When I thought of the gameplay in my head, it was more of an image; breaking it down into these component pieces was an exercise in trying to boil the mechanic down to its bare elements.

The top right I sketched – in red – the key questions I’d have to answer before I could have a working prototype. Questions like “how big should the grid be?” and “what if your leftover letters suck?” Identifying where your problem areas might be early keeps your mind constantly checking for these cropping up (and searching for solutions). Sometimes it’s good to put a problem on a slow boil in the back of your mind.

Here’s where this might deviate from a standard design doc:

I spent a maximum of 30 minutes creating this.

I always kept it next to my desk, staring me in the face, every time I worked on the game.

I never altered it, even when gameplay significantly shifted.

Alteration of the Core Mechanic

The entire premise of the gameplay was that you were playing Boggle, but sort of in a first-person fashion. Your character would move around on the tiles, and you could only start spelling from where you were currently standing.

If you take a look at my last two gameplay elements – in green in the bottom right of the above image – you’ll notice two entries that describe the danger element of this gameplay:

No valid move -1 life

Certain tiles give +1 life

That is to say, if you walk into a corner and can’t spell your way out, you lose a life – and the game would use a standard “three lives, how long can you last” model. Sounds good on paper, right?

Well, it turns out that – even with tiny board sizes – the player almost never got stuck. There was always some obscure word to spell. With the occasional 1up laying around, everyone could eventual get 99 lives an the game would never end.

It turns out that English is entirely too flexible and my game mechanic broke. Very early on I had to switch to a timer based system – remove the lives, add a countdown clock, have it work that way. This in turn shifted many of the mechanics and balance mechanisms I had in the game.

And this is why prototyping is so important: you can’t know from a document what will work, and what won’t. You have to make it. And you have to make it as soon as possible.

I could have spent another week detailing all the different ways you could get 1ups, and sketching out death animations, and ordering death-music-samples from musicians – and wasted all of that effort on something that could never work.

I left the original idea on the board though – to remind me of the core simplicity of the game. To remind me what it was at first, to remind me how straightforward the game could be. If I start altering my whiteboard, I quickly get into feature-creep territory. Besides, keeping my errors up there, constantly glaring at me – keeps my game design skills humbled. If I just erase it, will I learn the lesson for next time?

Visual style remained solid

When I doodled out the interfaces, it wasn’t just drawing some placeholder logic boxes. I drew little penguin doodles in there, placed some UI elements in positions I thought would be good, and had a distinctive “style map” in place. Here’s how the game ended up looking:

Check it out. Same tile layout, same penguin theme, even the pause button and timers still in their original positions. About the only thing that changed here is the level of talent doing the doodling (Thanks, Sven!)

Having a consistent driving style is important to the games I make. It helps focus development down the same path, and sometimes things just “make sense” in the context given.

I didn’t have to beg Sven to keep penguins as part of the game. He looked at my initial sketches and just ran with it.

Anyway,

I think design docs suck for my purposes. This is how I do it instead. How do you keep yourself organized?

篇目3，Game Design: Theory & Practice Second Edition: ‘Not All Game Design Documents Are Created Equal’

by Richard Rouse III

The following excerpt comes from Richard Rouse III’s book Game Design: Theory & Practice, which has just been released in a revised and expanded second edition. The book covers all aspects of game design, from coming up with a solid idea, through implementing the gameplay, to playtesting the final game. Along the way, before coding begins, a game’s design typically takes the form of the infamous design document. But, as Rouse discusses in this excerpt from ‘Chapter 19: The Design Document’, not all game design documents were created equal.

“Omit needless words. Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word should tell.”

- William Strunk in his book The Elements of Style

Inauspicious Design Documents

As I previously recommended, it may be useful to try to get your hands on some professional game design documents in order to give you an idea of what the industry expects in such specifications.

However, you must be careful. It is likely that the document you obtain will not be any good. Many of the documents that have been used for published games and that were written by experienced professionals are truly terrible. By way of example, and in order to best teach you what to avoid, I will explore a few of the different types of horrible design documents, and why they fail so miserably at what they are supposed to accomplish.

The Wafer-Thin or Ellipsis Special Document

These thin little volumes, certainly none longer than thirty pages, startle and amaze the experienced game designer with their total and complete lack of any useful content whatsoever. They use meaningless descriptions like “gameplay will be fun” and “responsiveness will be sharp.” In these documents, many comparisons to other games are made: “This plays like Super Mario 64” or “The game has a control scheme similar to Quake.” While such comparisons can be slightly useful, as I have discussed, the writer of the Wafer-Thin Document almost always fails to explain the control scheme of Super Mario 64 or Quake in any detail, let alone the scheme to be used by the game in question.

Often these documents spend a lot of time, maybe half their pages, talking about back-story. Usually this back-story is very weak and poorly developed and is only tangentially related to the game being developed. The Wafer-Thin Document also spends a lot of time talking about how the menus will work. Not the in-game menus, but the system menus where users select what type of game they want to play, set their options, and so forth. Many mock-ups are made and options are carefully listed. What exactly the options will affect in the game is seldom described in any detail, since the game itself is barely defined. Figuring out the menu system is something best pursued once the game is working, when the designer knows what sort of options might be important and what different gameplay choices players will have; it is certainly far from the most difficult part of game design, nor the most important system to nail down first.

Wafer-Thin Documents are often constructed by managers who like to think they are game designers. The reason these can also be called Ellipsis Special Documents is that they are often littered with ellipses. For example, the worlds players will encounter in the game will be described in the following manner: “Jungle World is a very hot and sticky place where the Garguflax Monkeys swing around and torment the player…” And that will be all the document provides in way of description for the world, ending at an ellipsis, as if to say “insert game design here.” It is unclear whether the writers of these documents plan to come back and fill in at the ellipsis later or that perhaps they do not deem it worthy of their valuable time to actually explain how their game works. They just assume someone somewhere will fill it in and make them look good.

Another example of the content found in Ellipsis Special Documents might be: “Players will be given an option of many cool weapons. For example, the Gargantuan Kaboom does twice the damage of the players’ other weapons and has a special effect. The Barboon Harpoon will allow users to kill enemies at a distance with a nice camera effect. Other weapons will be just as fun and cool…” Here the writer of the Ellipsis Special fails to describe the weapons the game will have to any useful level of detail, and then, having listed two weapons, decides to leave the rest up to the imagination of the reader. Of course, readers are very usefully told that the other weapons will be “fun and cool.” The writers of the Ellipsis Special mistakenly think that is all the description necessary to develop a game.

The only upside to the Wafer-Thin or Ellipsis Special Document is that it allows whoever gets to implement the design to pretty much take over the project and turn it into her own. I say this is an advantage, since usually the ideas the manager included in the Wafer-Thin Document are beyond ridiculous and do not make for viable gameplay. But one must be wary. Problems arise when the manager shows up six months later and complains: “But that’s not what I wrote!”

The Back-Story Tome

Unlike writers of Ellipsis Special Documents, the designer who writes the Back-Story Tome spends a lot of time working on her document. These books (it is hard to call them merely documents) usually stretch into the hundreds of pages — 300-, 400-, even 500-page documents are not out of the question. There’s a lot of information in there.

The first mistake these documents make is usually a poor table of contents and the lack of an index. In a design document, well-ordered information and a good table of contents can replace an index, but the absence of both is a huge error. The problems are compounded when the document is as long as War and Peace. The primary reason for the existence of game design documents is to allow team members to quickly look up information about a section of the game they are working on. If a programmer wants to know how the AI for a particular enemy is going to work, she needs to find that information quickly and easily. If she cannot find it, she may just make something up. Similarly, when an artist wants an idea of the textures that will be needed for a given area in the game, she wants to be able to find where that area is described as quickly as possible. Design documents are not read like novels. No one starts at the beginning and comes out at the end. Primarily, design documents are reference materials, and if team members cannot easily retrieve the data they are seeking, they are liable to give up.

However, once one starts hunting through one of these Back-Story Tomes, one is startled to find that, indeed, there is no information about the gameplay in there. It is all back-story. And at 500 pages, it is far more back-story than most computer games will ever use. The history of all the characters in the game, the friends of those characters, and all the relevant parents and siblings are all described in minute detail. It may be very interesting stuff (though usually it is a disorganized mess), but in the end the reader is left with very little idea of how the game is supposed to function. These documents are often the sign of the frustrated novelist or a writer from a non-interactive medium who does not truly understand game development. A lot of games make storytelling one of their central concerns, and a story bible can be quite useful to game creation. In such a case, it makes sense to discuss the game’s story in the design document to some extent. But first and foremost, a design document is supposed to contain the game’s design, which is very different from a game’s story. Remember, your most important consideration when writing a design document must be, “what can the player do?” Though these tomes are very significant in terms of weight and will probably impress the venture capitalists, the programmer who has to work with such a document as her only guidance is going to end up designing the game herself.

The Overkill Document

Some designers think they can describe every last aspect of a game in the design document. It is certainly true that many design documents lack the necessary detail to be useful, as we found in the Ellipsis Special Document discussed above, but at the same time, going to an excessive level of detail can be a waste of the designer’s time as well as that of the person who has to sift through all of that excess information. Furthermore, excessive documentation can lead to the illusion that the designer has created a complete, thorough document, when in fact she has gone into far too much detail about certain subjects while skipping other areas that need to be addressed.

For example, suppose that the game being documented has a number of characters that perform certain actions in the game-world. Say the game has townspeople, and they need to walk around, sit down and stand up, talk to each other, and sleep. The document should describe these behaviors in the AI section. A truly thorough document might break this down into separate animations: stand from sitting, sit from standing, idle sitting, idle standing, walk, converse with hand gestures, and so on. Probably this is not necessary, since good animators and artists will be able to break this down better than a designer can. But some designers may go overboard and actually sketch or list the individual animation frames. This is absurd. There is no way to know in the design document stage how many animation frames will be required for a given animation. This sort of decision can only be made and adjusted during the game’s production. Not to mention that listing animation frames is insulting to the animator who will only feel demoralized by this degree of micro-management. Furthermore, the design document should stick to gameplay design, and not veer into the territory of the art bible or other art documentation.

Another example might be what I call “balancing data.” These are the actual statistics for the weapons, items, and characters found in the game. The design document should probably list what different attributes weapons and characters will have. For instance, a weapon might have a range, accuracy, number of shots, and rate of fire. Furthermore, the design document might want to describe the qualities of a given weapon: “The Double Barreled Shotgun has a short range and a low accuracy, but does a large amount of damage in a large area.” However, actually listing the values for a weapon’s attributes is not very useful in the design document. Saying “Shotgun Accuracy: 2” does not really serve any purpose since the number “2” does not have any context and therefore no meaning. These values are best determined when the game is actually functioning, when a designer can balance the weapons as they will be used by the players and thus the designer can experiment with different settings to achieve the desired effects. Creating large tables full of data before this information is actually testable is by and large a waste of time. Filling in a chart quickly may be a way to convey some raw ideas that were hard to describe through words alone, but at best such a table is a first pass that will no doubt change many times before the game
ships.

As with animation minutia and precise balancing data, source code also does not belong in the document. Designers who start writing out algorithms in their design documents are going too far. It does not matter if the designer is also a programmer. There should be no code, not even pseudocode, in the design document. Including code will only serve to bloat the document and distract from omitted information that needs to be covered. Some simple if-then-else type logical explanations may be useful and are completely appropriate. Such examples may help communicate all the contingencies to the person actually writing the code, and if nothing else force the designer writing the document to consider all the possible cases and outcomes that the game will need to support. But by the time the examples start looking like compilable C++ code, you know your document is overdoing it.

If there is any useful information in the Overkill Document, it is so hidden in the river of useless data that team members will be too intimidated to look for it. The author thinks that she can preplan everything, and that she is far more talented than any member of her team. While such excessive attention to detail can be impressive to those who do not really know what they are doing, a design document that goes too far will only infuriate the team that has to work with it.

The Pie-in-the-Sky Document

These design documents often have noble intentions with grand ideas for truly magnificent gameplay. Sadly, the writers of them typically lack any technical grasp of what the computer is capable of or what a team of twenty people is likely to accomplish in a year and a half. As a result, these overly ambitious documents put forth fancy ideas with no basis in reality or feasibility and end up frustrating and infuriating the teams assigned to “make them happen.”

Pie-in-the-Sky Documents include ideas such as “a fully modeled replica of Manhattan will be the players’ primary game-world, complete with AI agents representing all of the city’s seven million inhabitants in real-time.” The authors of Pie-in-the-Sky Documents do not want to be bothered with messy details such as the reality that no existing computer system can simulate seven million humans in any sort of reasonable time frame (let alone real-time). Another feature suggested might be “a natural language parser will be included that allows users to type in full, complex English sentences, which the characters will respond to with their own dynamically generated dialog.” The guilty designer does not want to hear that research institutions have been working for decades on natural language processors that still have trouble with short, simple sentences. When confronted with a Pie-in-the-Sky Document that you must work with, the first thing to do is call a reality check meeting involving key programmers and artists as well as the management who want this document implemented. With them all in the same room, some simple and quick calculations on a piece of paper or white board will often reveal how fundamentally impractical the game proposed is, and if the management still refuses to accept the reality of the situation, it might be time to start looking for a new job. Pie-in-the-Sky Documents are often combined with Ellipsis Specials to create truly wretched design documents, where the guilty designer outlines a completely impractical project without bothering to go into much detail about it.

The Fossilized Document

Any of the above flawed design documents can also be a Fossilized Document. Indeed, a design document that does not necessarily suffer from any of the above problems and was once a fine reference tool will become a Fossilized Document over the course of a project if the designer is not diligent in her efforts to keep the document up to date. I know of no original game project whose design has not changed significantly during the course of its development, and when the design changes but the design document does not, that document starts to become fossilized.

Suppose a programmer on the development team looks something up in the Fossilized Document and the information she finds is out of date. She may start implementing the old, long-since-modified functionality. At some point, a designer or producer who is aware of the changes that have taken place in the design will notice that the programmer is creating a system that is no longer appropriate, and will chastise the programmer for doing so. This creates frustration for both parties, not to mention wasting the programmer’s time. Furthermore, whenever the programmer needs to know something about the design in the future, she will not trust the design document, and instead will go hunt down a designer or producer to find out how a given system is supposed to function.

Of course, this defeats the purpose of the document, as the designer must stop whatever she is working on to explain the system to the programmer. This new system may be described correctly in the document, but the programmer is not going to get burned again by using the Fossilized Document. When the designer fails to update the document when design changes occur, the entire document becomes useless. No one can trust it, and as a result no one will bother to read it.

Wiki systems can be great for more easily keeping a document or collection of documents up to date. With Wiki, any member of the team can update a section of the document through their web browser, and full version control and history is supported to prevent the accidental loss of data. So, for example, the programmer who is implementing a particular feature can slightly modify the text of the design document to match how the feature actually ended up working, to add more information, or to link to the newly created technical design document for that particular feature. On a large enough project, keeping the design document completely up to date can be a full-time job.

A Matter of Weight

It is often joked that design documents are not read, they are weighed. This is not surprising given the heft of many design documents and the lack of desire among team members to read them.

Shockingly, this statement is often true. I once heard an ex-producer from a major gaming publisher talk about her experience with design documents and the project approval process. She said that the “decision–makers” would bring a scale to their “green-light” meetings. When it came down to two similar projects that were both relatively worthy of funding, they would take the design document for each project and place it on the scale. Whichever one weighed more would get accepted, the other rejected. Much as it pains me to tell you, if you are in the commercial gaming business and groveling for dollars at publishers, you need to make your document hefty. You need it to be impressive to pick up and flip through. Many will never read it at all. Others will read only the Overview and Table of Contents at the beginning. But everyone will pick it up and remark on its weight.

Of course, many of these super-thick documents contain a lot of information of negligible value toward the actual development of the project. They may be stellar examples of one of the failed types of documents I discussed earlier, such as a Back-Story Tome or an Overkill Document. It is your challenge as the game designer to make the document as practical as possible by providing only useful information in the document, while making it hefty enough to impress the suits. One might want to include a large number of flowcharts or concept sketches or choose to use a bigger font, all while not being too obvious. Indeed, a great game (though a simplistic one) can have a perfect design document only ten pages long. One wonders how many great, simple games have been cast aside by publishers who were unimpressed with the mass of their design documents.

Thankfully, over the last few years many publishers and developers seem to be wising up to the unwieldiness of massive design documents. Design consultant Mark Cerny has been preaching the concept of starting development with only a simple “macro” design document of perhaps ten pages in length that can be expanded on as needed over the course of development. As I have discussed, others are starting to use Wiki as a means of organizing and interlinking a lot of design information contained in many smaller documents. And fewer and fewer publishers are funding development based on a phone book-like design document alone, with prototypes and high-level, graphical pitch documents becoming increasingly important. The days of padding out the design document just for the sake of it seem to be thankfully drawing to a close.

Getting It Read

Once your design document is written, one of your biggest challenges may be getting anyone on the development team to read it. Often, many programmers, artists, or even other designers will not want to put the time into a careful reading of your document. Others may have been burned by bad design documents in the past and will jump to the conclusion that yours is of similarly poor quality. Keeping your document up to date, including only useful information, providing a detailed table of contents, and limiting yourself to practical, accomplishable gameplay elements will help.

Including numerous short, high-level summaries before each section of the document can also help team members get high-level information for aspects of the game they don’t need to know so much about. At the same time, such summaries can give readers a big-picture vision before they dive into the gritty details of the document. If your team members sample your document and find it to be of superior quality, they are more likely to return to it for reference when they are actually implementing a given system or working on a particular piece of art. As with any written document, you need to earn the trust of your readers if you hope to keep them reading.

Another key method of getting your design document read is to make it easily available to anyone who wants to read it. Keep it in the same source-control system that your team uses for asset management. You want your team members to be able to get the latest version of the design document as easily as they get the latest build of the game. Since you will be constantly revising and updating your document to keep it up to date with the project (and to prevent it from becoming a Fossilized Document), source control will be a valuable tool for keeping track of the previous revisions. Not to beat a dead horse, but a Wiki system run over a company intranet can also be great for distributing the document to the team, with developers at any time being able to easily read the very latest version of the document through their web browsers.

When you check in the latest version of the document, send your team an e-mail telling them that it is available and explaining what has changed. That way, people can easily skim over the changes.

If one of the changes is relevant to their work, then they can get the latest version of the document off the network and read over the relevant updates. Updating your document does not do any good if no one knows you have updated it or if people are still reading old revisions. It is probably a good idea to use a version number with your document, such as 1.3 or 2.7. Include this version number, along with the date, in a header on every page. Often people will print out a design document and not realize how old or fossilized it is. If they can quickly compare a date and a version number, they will know which version of the document they have and whether they need to get a new one.

Documentation Is Only the Beginning

Some designers or aspiring designers seem to think that a thorough design document is, by itself, enough to build a game. Indeed, some companies have had designers write design documents, only to then have those designers move on to write other design documents while a separate team actually executes their design. At its best, a design document is a rough outline, more the suggestion of a game than anything else, and without being involved in a game’s creation until it goes gold master, one cannot truly be considered to have designed the game. A designer who takes any pride in her work will want to be there throughout the project, ready to change the design as necessary to make it the most compelling game possible and updating the document as the design is changed and revised (and rest assured it will be continuously changed and revised). A committed game designer will want to be there to balance the weapons, the AI, the controls, and certainly the levels. She will want to make sure the game follows the focus through and that the initial vision is realized.

If a designer writes a design document and then passes it on to others to actually build, the people who do the actual creation will change the design to match their own interests and artistic drives. The design document will be a springboard for their own acts of creation, not the original designer’s. The design document is an integral part of the game’s creation, perhaps, but a design document is not all that is required. To claim any sort of meaningful authorship on the project, a designer needs to be involved for the duration. In a way, writing the design document is the easy part of computer game design. Actually taking the document and creating a compelling gaming experience is much, much harder.

篇目4，Design tutorial – how to write a feature brief

by Ethan Levy

The simple truth of game development is that a finished game will never be all that you imagine it to be. Even the best managed game development processes result in a game that represents 5 to 10 percent of the initial ambition. Ideas are cheap, implementation is expensive and at a certain point games must be shipped. For instance, even if my team’s current game Enhanced Wars is a runaway success and we continuously improve it for the 3 years after launching, it will never be all that we want it to be.

Once upon a time, when I set out to design a game I would start by writing a lengthy document detailing every aspect of the game. Eventually I learned that these documents are largely a waste of effort. No one else would ever read a 75 to 100 page document and most of the initial concepts get changed dramatically in implementation. Nowadays when working on a game, I prescribe a method of managing the design process for all these features that is lightweight and flexible.

The process revolves around writing out short documents called feature briefs. In this tutorial, I will walk you through the process of writing a brief. You can access a downloadable template of a feature brief at this link.

Step 1 – fill your backlog

Before writing a single brief, you should start by setting up and populating a backlog of proposed features. This will be a place where every member of the team can and should submit ideas to add to the game.

A screenshot of the feature backlog for Enhanced Wars

I highly suggest using a Google spreadsheet for this backlog. Your format will be your own, but I suggest each feature have a name, KPI, estimated implementation effort, 3 sentence description and comments section. As briefs are written, the name of each feature is turned into a hyperlink to the document. This list can then be prioritized by the team and sorted on the key axis of design intention and development effort when choosing which features to add to the game.

KPI stands for key performance indicator. In the instance of a live game, this correlates to specific metrics that the game team wishes to focus on. The standard KPIs are Retention (keeping players in the game over a series of days), Engagement (length of play time per day), Virality (number of new players an existing player attracts to a game), Monetization (if free to play, the amount of money spent in game) and Quality (will improve the game’s critical rating/user reviews but will not have a direct impact on measured metrics). Depending on your game and business model, your team will determine the appropriate KPIs to obsess over.

Step 2 – write the high concept

Even if your process focuses on minimal documentation, it is important to recognize that people will generally read as little as necessary. Therefore, I recommend starting feature briefs with a short, high concept section that another person can quickly digest to understand the feature.

High concept section from an Enhanced Wars feature brief

As you can see, this information is just a slight expansion on what was found in the backlog.

Step 3 – visualize your feature

Once it is time to write a detailed feature treatment for implementation, you will need to spec out the user interface and flow fully. But at this early stage, I recommend making a single mock up of the feature to help solidify the design and make it clearer for more visually oriented team members.

Mock up of the Single Player challenge levels dialog box for Enhanced Wars

A feature brief should include at least one image. This can be a mock of the interface the feature will require, a storyboard to show how the player will use the feature in the game or some other form of visualization.

In a single image, paint a clear picture of how the feature will manifest for the player.

Step 4 – flesh out details

Finally, you should list out all the major sections of the feature and write a one to two paragraph description of each. Again these are not full implementation details; they are just enough information to get the feature out of your head and onto paper in a way that you can evaluate with your team.

Detailing the progression system for Enhanced Wars’ challenge levels

Brevity is key at this stage. If you find that your feature brief is going beyond 2 or 3 pages, it is probably an indicator that you should split your concept into multiple features. Your goal is to write just enough information to communicate the design intentions to your team.

The purpose of process

Feature briefs are quick to write. Instead of spending two full weeks speccing out every detail of Enhanced Wars, I can populate a backlog and write briefs for two years worth of development work in a few days. By following this process, you can get ideas out of your mind and onto paper in a format that your team evaluate it for implementation. Now that you have the briefs, you can decide which features will be developed and write more detailed treatments as they are required.