作者：Richard Rouse III

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

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

Design Documents(From Gscept.com)

——《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，控制以及关卡等内容。同时他也会始终确保游戏能够遵照设计文件而发展并始终牢记自己的最初创想。

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

原文发表于2004年11月1日，所涉事件和数据均以当时为准。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

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.(source:GAMASUTRA)