篇目1，Tim Ryan解构游戏设计文档的设定问题

作者：Tim Ryan

创造设计文件的目的是传达游戏创意，描述游戏内容，呈现执行计划。设计文件是制片人宣传目标，设计师倡导理念的权威材料，也是美术人员和程序员的任务指南。不幸的是， 有时候设计文件很容易被忽视，或者达不到制作人，设计师，美术人员以及程序员的预期。本文将通过展现撰写设计文件各部分内容的相关指导原则，助你根据项目和团队需求制 作文件。

在本系列文章的第一部分中，我将描述创造设计文件的目的，以及遵循这些原则的好处。本文包括编写设计文件的前两个步骤，即编写理念文件和游戏提案。而在第二部分，我将 进一步阐述撰写功能说明，技术规范以及关卡设计的相关原则。

撰写设计文件的目的

从广义上来说，撰写设计文件的目的便是详细阐述游戏观点从而让开发者更好地执行它。它能够避免程序员，设计师以及美术人员手足无措地向设计师、制作人询问自己的工作职 责这种无序状态。设计文件让他们不再局限于一个狭小空间编制程序或制作动画，而是让他们真正清楚该如何将自己的工作与其他人的工作有效地整合在一起。如此便大大减少了 不必要的投入并避免各种混乱。

对于团队中的不同角色来说，文件的含义也不同。对于制作人来说，设计文件是他“布道”的圣经；如果制作人不能认同设计文件或者不能让团队成员理念文件，那么它就失去了 原有的价值。对于设计师来说，文件是一种传达制作人理念的方法，能够告知他们更多关于游戏执行的细节内容。首席设计师可以说是所有文件的作者——除了技术说明，因为这 是高级程序员或技术总监所撰写的。而对于程序员和美术人员来说，设计文件则是他们的执行指令，也是他们表现自己设计，美工以及编码技能的重要方式。设计文件应该是团队 共同努力的结晶，因为几乎团队中的所有人都会玩游戏，并都将为游戏设计做出自己的贡献。

设计文件也不会取代设计会议或电子讨论会议。在撰写出文件之前让所有人聚集在会议室中进行讨论，或者根据每个人的观点做出总结性规划都是决定游戏内容的最快速方法。设 计文件只能够表达出一致意见，具体化各种观点并消除模糊性。但是它本身也只是讨论的一部分内容。尽管设计文件的宗旨是巩固想法和计划，但它们也并非板上钉钉的内容。应 该允许团队成员编辑文件内容或发表评论，让大家更好地交换彼此的意见。

明确文件设计大纲的益处

遵从明确的设计原则将能够让你的所有项目受益。因为这类大纲有助于开发者摆脱华而不实的内容，让所有成员更加明确自己的任务，并确保你的项目能够遵循一定的规程，从而 助你更加轻松地安排工作并执行测试计划。

减少华而不实的内容。大纲通过要求设计师确定游戏中的实质元素并减少那些不切合时机的白日梦，从而让他们能够投入那些更加切实可行的任务中。

清晰性和确定性。大纲能够进一步保证设计过程中的清晰性和确定性。它创造出了一种一致性，让读者能够更容易理解文件内容。并且也让作者从读者角度出发，撰写更加通俗易 懂的内容。

大纲可以确保特定的流程遵从设计文件的安排——这些安排包括市场研究，技术评估，深入探索以及观点传播的过程。

大纲有助于拟定安排和测试计划。遵循明确大纲的设计文件能够帮助你更快速地落实行动。文件中明确列出了美术人员和作曲人员所需要创作的图像和声音要求；帮助关卡设计师 有序地分解了故事中的不同关卡，并罗列出了要求数据输入和脚本撰写的游戏对象；确定了程序员所需负责的不同程序领域和规程；最后，它还明确了QA团队在测试计划中需要重 视的各种游戏元素，特征和功能等内容。

大纲会发生变化。基于项目的独特性，你有可能需要放弃一定的原则转而遵循其它内容。例如移植项目通常都比较简单，除了技术说明之外它们并不会要求额外的文件内容（除非 改变了原先的设计）。续集游戏（游戏邦注：如《银河飞将II》，《银河飞将III》等）以及其它非常有名的设计（如《大富翁》或扑克游戏）便不需要过多地解释相关机制内容， 而是应该提供给读者们关于现有游戏或设计的相关文件。只有一些具体的特殊执行项目需要提供明确的文件。

游戏理念大纲

游戏理念大纲能够传达游戏的核心理念。通常这只要1至2页的文件描述，因为简洁的表达才能够鼓励更多创造性理念的涌现。游戏理念文件的目标读者应该是那些你希望介绍游戏 的对象，特别是那些能够帮助你在接下来的正式游戏提案中出谋划策的人。

一般来说，所有的理念在传达给产品开发部之前都需要先给开发部主管（或执行制作人）过目。而该主管则需要判断这些理念是否具有价值，是否值得他们投入更多资源落实开发 。

开发主管或许会认可游戏理念，但是他们仍会要求做出一些改变。他们将会与一些设计人员和制作人，甚至整个部门或公司成员分享这些理念；如此汇聚了大量人才的想法和想象 力后，游戏理念必然会变得更具有吸引力。

游戏理念应该包含以下内容：

介绍

背景（非必要选项）

描述

主要功能

类型

平台

概念艺术（非必要选项）

介绍：游戏理念中的介绍包含了文件中一些最重要的关键字——能够帮助读者更好地理解文件内容。尝试着将游戏中一些重要内容以一个句子简要地表达出来，包括游戏名称，类 型，方向，设置，差异性，平台以及其它关键内容（差异性是指如何让你的游戏有别于同类型的其它游戏）例如：

“《Man or Machine》是一款PC平台上的第一人称射击游戏，游戏使用《Quake II》引擎将玩家带进了37世纪的高科技星际战争中，他们将在此扮演一个机器人太空战士的角色。 ”

用几个句子描写介绍能够更加清晰地向读者解说内容。但是你同时也需要记住，如果你介绍的内容越繁琐，读者便很容易觉得你的观点不具有说服力。

背景（非必要选项）：游戏理念的背景内容与你在介绍中所提到的产品，项目，授权或者其它属性相关。本质上来看，背景是独立于介绍内容，所以如果读者已经拥有了相关的背 景知识便可以轻易跳过它。不过对于那些授权游戏，续集游戏或者深受早前相同类型影响的游戏，背景尤为重要。如果你想要使用现有代码，工具或授权使用一个游戏引擎，你就 需要在背景中描写清楚这些内容以及它们的优势。

描述：通过使用几个段落或者一页的空间，将读者当成玩家对他们阐述你的游戏。你需要以第二人称的表达方法——“你”进行描述，并努力让这部分内容成为让玩家兴奋的叙述 体验。在此，你可以通过描写玩家该做些什么或者能够看到些什么而向他们传达核心游戏玩法；避免一些细节描述，如点击鼠标或击键，但是也不能太过含糊。你希望读者们都能 融入游戏角色中。同时你需要将细节关卡适当地安置在GUI互动上。你的表达方式应该像“查看你的战术雷达并捕捉更多靠近你的妖怪”，而不是“你应该点击战术雷达按钮，随后 会挑出一个窗口告知你有两个妖怪正在逼近你。”你必须利用描述内容有效且清晰地呈现出游戏内容和娱乐价值。

主要特色：游戏理念的主要特色就像是一个项目清单，能够帮助你的游戏区别于其它游戏，并为后来的文件明确方向。这是对于描述阶段所提到的功能的总结。而这些项目内容将 最终出现在游戏包装背面或促销单上，并且同时也将包含一些延伸内容。例如：

“高级人工智能（AI）：《Man or Machine》将使当年《半条命》中富有挑战性和真实感的AI实现更大的飞跃。”

判断该罗列出多少特色也需要仔细掂量。如果你面对的是比益智游戏更复杂的游戏，那么只罗列出1、2个主要特色便不是明确的决策；相反地，如果你的特色超过1页篇幅，玩家便 会感觉自己好像面临非常艰巨的任务，并因此感到胆怯。总之，罗列出过少特色便不能很好地传达你的理念，而滔滔不绝的内容也会冲淡游戏特色的价值。

要切记，不要列出那些众所周知的特色，如“炫目的图像”或“动人的音乐”等，除非你真的认为这些特色远远超越其它竞争对手。华丽的图像以及吸引人的音乐等都是人们对每 一个游戏项目的默认目标。但是，如果你的游戏真的拥有独特的图像或音乐并且能它脱颖而出，那你就应该明确地指出这一点。

类型：也就是定义游戏的类型。以来自杂志或者获奖游戏类别为向导。例如，你可以从如下游戏类型中做出选择：运动类，即时策略，第一人称射击，益智，赛车模拟，冒险，角 色扮演，飞行模拟，竞速射击，模拟上帝，策略，行动策略，回合制策略，卷轴射击，教育类或飞行射击游戏等。然后你可以根据这些名称或重新使用其它短语定义游戏，如现代 ，二战，现实交替，后启示录，未来主义，科幻，幻想，中世纪，古老，太空，网络朋克等。

平台：也就是列出目标平台。如果你认为游戏理念同时适合多个平台，你也应该明确那个属于优先平台。如果你希望创造的是在线多人游戏模式，你也需要注明。

概念艺术（非必要选项）：采用一定的美术元素能够帮助你更好地传达理念，并让读者以更加积极的心态感受你的游戏。使用美术去传达独特或复杂的理念。屏幕模型能够帮助你 有效地传达各种想法。但是因为游戏概念艺术超出了许多开发人员的能力范围，如此便可能导致他们所提交的创造理念大大减少；所以这是一种可选择的项目。如果你确定一个理 念具有价值，那就可以从其他技术资源中提取其美术元素。通常，来自于早前项目或者网上的美术内容都有助为文件增色。但要注意避免版权问题。

常见错误

以下是开发者在创造游戏理念时最常遇到的问题：

理念完全不符合公司当前的规划。如果你不想浪费时间去撰写一些矛盾的理念，你就需要好好寻找真正适合自己公司的理念，并学会判断哪些哪些想法才是真正有帮助的。

从资源上来看，文件中的某些要求总是背离现实。你需要尽可能将自己的理念保持在适度范围内；通过使用现有的工具或属性控制预算。确保你能够在特定时间以及合理预算范围 内实践想法。将你的实验技术限制在一个特定区域内；最好不要轻易尝试具有变革性的AI以及最先进的3D引擎。如果你正在创造自己的游戏理念，你就必须先明确时间安排和预期 预算。

文件缺少内容。就像是“《命令与征服》结合《机甲战士》，你命令自己的‘Mech加入战斗，’”但是这种表达却远远不够充分。你的描述必须解释清楚玩家应该执行何种行动， 从而让他们能够对此感兴趣。优秀的描述应该是：“你命令自己的Mech直接朝着Clan MadCat OmniMech暴露的躯壳射击。”这样的描述内容才能消除玩家对于核心游戏玩法的误解 。

游戏并不有趣。一个真正有效的方法便是分解所有玩家可能执行的动词（游戏邦注：包括射击，命令，奔跑，购买，构建以及观看等）并想象玩家是如何执行每个动词。随后，基 于每个动词询问自己这是否有趣；然后问自己目标玩家是否会觉得有趣。你必须确保自己足够客观地回答这些问题。如果你认为玩家所采取的行动不够有趣，你就应该立即为其设 定其它更加有趣的行动。

使用了拙劣的语言和语法表达。你应该仔细检查语法和拼写，避免出现一些不雅或具有诽谤性的言语。因为你并不知道谁最终将阅读你的文件，所以你很难判断某些特别表达的单 词是否会侵犯读者。不论是带有大男子主义，歪曲的政治立场，文化冲突等元素的表达，还是你在午餐时间所开的一个低俗笑话都不应该出现在文件中的。

设计师放弃表达理念。千万不要放弃提交更多创意理念，因为你永远不知道哪个理念才能真正创造出成功的游戏。相信我，坚持总是会有回报的。

游戏提案

游戏提案是用于明确游戏开发项目所需要的资金和资源的正式项目提案。你需要投入一定的时间（当然还有金钱）才能创造出合理的游戏提案，并且它却只针对于那些具有发展前 景的游戏理念。

游戏提案是游戏理念的延伸。撰写游戏提案也需要包含来自于其它部门的反馈和信息，特别是来自于市场营销部门（如果存在的话）的信息。你的市场营销部门必须能够针对于游 戏理念进行一定的市场研究和分析。而如果你的游戏是授权产品，那么财务和法律部门就需要出面审查许可证的可用性以及其中所需要的成本。

程序员，特别是高级程序员或技术总监，应该执行理念的最初技术评估。他们应该评估理念的技术可行性以及那些需要深入研究的程序编制领域。他们应该评估项目的风险以及主 要任务，并制定相关策略或找出替代选择。同时他们也需要粗略评估研究与开发所需要的时间和资源。

游戏提案中应该包含游戏理念的修订版本。关于理念文件的技术，市场营销以及财务反馈都将要求你适当压缩理念内容；但同时你也可能需要修改并添加其它功能。并且你需要确 保这种改变不会让任何人感到惊讶，因为这是理念首次接受批评与协作讨论的过程。在正式创造出游戏提案之前将相关反馈和分析副本提交给开发总监（或其他要求审查游戏提案 的人士）过目；这不仅能够让一些特定人士或部门给予理念相应的书面评价，同时也给予了总监否决，修改或主张其它提案的权利。

游戏提案包含以下内容：

修订后的游戏理念（前序要素）

市场分析

技术分析

法律分析（如果可行的话）

成本和收益预测

美术

市场分析：市场营销部门或者市场研究公司（如果你的公司支付得起这笔费用）应该编辑这些信息。而如果你是自己进行编辑，你就应该竭力避免乱猜数字的可能性。在网络上寻 找信息，并基于现有同类型游戏的点击数研究它们的市场表现。

目标市场：目标市场是基于游戏类型和平台进行定义，在理念文件中已经相应地处理了这些问题。你可以根据一些已经成功占领市场的特定游戏进一步分析这一定义。最成功的游 戏总是能够预测市场的发展潜能以及规模；并且你也能够因此了解到典型的用户年龄范围，性别以及其它重要的市场用户特征。而如果你的游戏包含有授权属性或者属于续集游戏 ，你就有必要描述原有市场情况。

表现最佳者：列出市场中的表现最佳的游戏。你应该指出它们的销量，获得突破的数据以及取得成功的续集作品。同时还应明确它们的发行日期；但是不需要过于精确标注出来， 就像1998年第一季度或1998年春天如此即可。在这种研究过程中我们可能需要追溯到早前的一些信息，所以你最好能够按照时间顺序罗列这些数据。

列出这些游戏所属平台（如果这些游戏所在平台，与提案游戏不同）。因为平台的改变也会引起市场变化，所以你应该始终罗列出目标平台上一些相同类型的游戏，即使它们的市 场表现不如其它游戏；因为这些数据能够提醒你某种特殊类型游戏在某一平台上的发展较为萧条。例如，回合制策略游戏在PC平台上具有非常好的销量，但是在索尼的PlayStation 上却成绩惨淡。所以如果你面对的是回合制策略游戏，你就应该在最佳表现者的列表上同时呈现出糟糕表现者的情况。

比较特色：分解这些最佳表现者的卖点，将其与理念文件中的主要特色进行比较；并尝试着提供一些细节描写。举个例子来说，如在《命令与征服》，《黑暗王朝》以及《神话》 中的策略战斗中，你将出于某种优势而命令自己的单位去攻击特定的目标并将其移动到特殊位置或范围内。玩家在游戏过程中将会发现大多数单位的独特优势和劣势，并因此备受 鼓励而创造出超级战术。Tanktics》中拥有各种类型的命令，让玩家能够在此执行超级战术，如捕获，撞击以及击跑配合等。而因为游戏中的地形，移动以及奖励范围；射击弧 以及后击和侧击位置的弱点使单位位置的设置和目标的选择变得更加重要。所有的单位都拥有不同的武器，装甲以及速度，以此能够区别它们的优劣势并鼓励玩家制定战术。随着 时间的流逝，你不仅能够精通这些战术，你也能够根据自己的命令而编写策略脚本了。

技术分析：技术分析一般是由经验丰富的程序设计员执笔，如果是技术总监或者首席程序员便再好不过；随后再进行编辑而成为最终的提案。提案评论者将使用这些技术分析做出 决策。并且老实说，技术分析还能够让评论者更加乐观地面对游戏机遇。

实验性功能：明确设计中那些具有实验性的功能，即未经实验或未经证明的技术，方法，看法或其它独特的理念。排除那些已经在现有游戏中得到证实的功能，即使它们对于你们 的开发团队来说还很陌生。例如，即使团队从未开发过3D引擎，也不能轻易将其当成实验性功能；而是应该将其归为技术分析内容中一个或多个类别中。另一方面，如果你的开发 团队正在使用quads体系开发3D引擎，那么你便能够将这种体验记录在实验性功能列表中。

估计实验性功能达到评价状态需要多长时间，以及完成整个功能又需要多长时间。一般来说，你的安排列表中总需要为实验性领域挪出更多时间，所以如果你罗列出更多实验性功 能，你就需要投入更长的时间。尽管很多公司都尽量回避那些耗时18至24个月的游戏项目，但是也有很多开发者意识到，如果要开发一款具有领先优势的游戏，这种实验值得一试 。

主要开发任务：通过一个段落或者一些项目符号明确列出主要的开发任务，并使用普通人也能够理解的非技术类语言。“主要”主要指开发月数。你需要假设你拥有开发所需要的 所有资源，而因此估计你完成该任务需要多少时间。你同样也可以估计你所需要的资源。例如：“人工智能脚本解析器：需要两个程序设计员花费3至4个月的时间。解析器将阅读 并以较低级别的逻辑编辑AI脚本，并基于运行时间做出指示。”

风险：列出任何技术风险。如果你不能预见任何技术风险，请务必说出来。风险是指研究开发过程中因为失败而造成的挫折（引起工作延误数周或数月）。记录下技术——尽管这 些技术可能已经得到竞争者的成功证实，但是你们公司却从未尝试过或者说对此没有任何经验。例如，如果你的公司从未开发过一款即时策略游戏，那就记录下即时策略内容；或 者如果你们公司首次接触3D，那就记录下3D渲染技术等。记录下之前提过的任何主要开发任务——如果你察觉到其中的风险。同时，所有未经实验的解决方法（游戏邦注：包括3D 引擎，编辑器，代码库，API以及驱动器等）也应该被当成是风险而记录下来，因为这些方法可能最终也不会满足你的特殊需求。记录下任何经由外部承包商进行的开发工作，因为 通常来说这种行为总是具有较大风险。当你在评估风险的同时，你也应该清楚修改或替换这些风险技术会带来何种影响。以周或月为单位指示发行日期。记录下时间对于任何特殊 资源的影响。记录下任何能够修改风险的新资源（包括人力，软件，硬件等）。虽然这个阶段看起来很繁琐，但是它却能够为你的文件评论者创造一个舒适的阅读环境，即他们将 会认为游戏执行始终处于适当的控制之下（特别是当他们自己也能够察觉到风险的存在时）。除此之外，你还能够有理地说道：“你可别说我没有警告你”之类的话。

替代性选择（如果有的话）：替代选择是你围绕着这些实验性或风险性功能，以及致力于主要开发任务时所必需的元素。通过明确替代选择，有助于文件阅读者自己做出选择。例 如列出任何需要耗费更多时间和金钱但却能够获得更好结果的选择，或者相反的内容（花费更少的时间和金钱但是结果却不如预期那般令人满意）。不管你给予何种选择，都需要 明确说明它们的优劣。

估计资源：记录下估计资源：员工，承包商，软件以及硬件等等。对于公司外部人员（如那些也有可能阅读文件的发行商或投资者）则使用一般的产业标准模式。以月或周为单位 记录下所需要的时间。此时无需考虑实际成本（以美元为单位），因为这是我们在之后才需要明确的内容。

估计时间表：时间表是遵循我们的里程表估算的全面开发周期，即从最早的起始日期开始，然后经历开端，测试以及正式发行。

法律分析（如果有的话）：如果你的游戏涉及版权，商标，特许权协议或者其它牵扯到费用，诉讼成本，版权声明或者限制条件的合同问题，请务必在此罗列出来。并且无需提及 游戏名称或logo版权的必要性，因为这都是众所周知的内容。

成本和收益预测：与财务和采购部门协作进行成本和收益的预测。这些数据应该让读者们能够基于技术分析所估算的资源大概清楚资源所需成本。

资源成本：资源成本是基于技术分析所估算的资源。就像员工成本将基于工资和日常开支，而这也是财务或工资管理部门应该提供的数据。你可以通过名称或标准去记录这些平均 数值。同时，你也应该记录下你所购买的任何软件或硬件，即使你将在其它项目中使用这些资源或者它们将被整合进日常开支预算中。使用表格或嵌入式表格以帮助你更加轻松地 进行编辑，并让读者更加清晰地进行阅读。如下图：

追加成本（如果有的话）：这是指估算授权，承包，外包测试等产生的额外费用。

建议零售价（SRP）：你应该在你的游戏沦为讨价还价牺牲品之前明确一个建议零售价。建议零售价应该基于现有游戏的价格，并评估游戏开发的总体价值以及生产开发成本等。当 然了，发行商总是想要压低游戏的定价，或者通过各种促销方法进一步压低游戏价格，不过这些方法最终也能帮助你的游戏取得不错成绩。因为你需要牢记，越高的定价也就意味 着越低的销量，特别是当你面对的是市场上竞争激烈的游戏类型（即供过于求）时。

收益预测：你应该根据自己所罗列出的成本以及建议零售价而呈现出悲观，预期以及乐观三种销量值。而市场营销或者公司日常开支等元素则不包含在此范围中，因为这些内容都 属于可变化的内容；但是如果你知道最低市场营销预算值，你就应该将其涵括在考虑范围内。通常情况下，圆形分格统计图表或者长条图都非常适合呈现收益预测数据。除此之外 ，你还应该呈现出技术评估所描写的风险成本，以及使用或不使用风险评估的预期总值。

美术：如果你的游戏理念中未包含任何美术内容，那么你的游戏提案中就不能缺少这些内容。美术内容必须由熟练的设计师所创造，所以你应该删除或替换掉理念文件中那些非设 计师创造的美术内容。美术能够明确游戏基调。如果你的读者只是根据美术效果去评估提案，你就需要确保在美术内容中展现出游戏的风格和目的。美术内容包括彩色或黑白的角 色，单位，建筑，武器示意图；动作动画；并且如果你的游戏是驾驶模拟游戏，也可以包含GUI实物模型等。确保你拥有精致的封面图像。在文件页面中张贴图像能够为你的文件加 分，并更好地引起读者的兴趣。

描述：整份提案文件应该包含改订过的理念文件，印刷成册并与美术副本一起装订在特定的报告文件夹中。你应该将这份文件呈现给那些前来你的办公室拜访的商务人士。你应该 始终牢记你需要一大笔的投资，所以要尽可能让你的提案看起来更加吸引人，从而能够吸引投资者的注意。用某些程序（如微软的Persuasion）播放灯片能够帮助你更好地阐述关 键点并呈现美术内容。

常见问题

准备游戏提案时常常出现的一些问题是：

用一些没有根据的数字进行分析。通过罗列资源或者解释你如何获得这些数据进行证实。如果制作人凭空捏造一些数字并将其用于文件中，读者便不会信任并阅读他的文件。

提案太过乏味。这是一份有关销售的文件，所以不要让你的读者感到无聊。将事实呈现给他们，并且确保这些事实足够有趣，简洁且有说服力。

提案不能提前解决一些常见的问题。你应该清楚你的提案真正面临的是什么——其它提案，竞争产品，财务问题，成本和时间预期值，游戏偏见以及历史灾难等问题。而如果你能 够先发制人地解决这些问题而不是留到评论过程中等待评论者逐步挖掘，你的提案便有可能获得认可。

提案作者对于批评总是太过敏感。不要惊讶你的游戏提案发起人提出一些完全相反的观点。你需要做的只是保证提案的一致性，相信它并保持自信，如此你才能经受各种批评的挑 战，并让支持者始终站在你这边。

提案作者过于刻板而不愿意改变游戏。通常在收集研究或接受来自评审委员会的批评意见时，你会发现一些需要你改变游戏或压缩设计的合理建议。游戏开发是一个相互合作的过 程。你应该接受反馈并改变设计，否则你的游戏将只会止步不前；并且只有这样你的游戏才能保持活力并持续发展。

功能 vs 技术说明文件

游戏行业传统上只有一种说明文件，涉及多少技术内容主要取决于文件撰写人的意愿。而程序员之后所写的用于执行过程的文件，一般都是非正式内容，通常写在白板或记事本上 。但为了确保项目执行顺畅，按期交付并且不超出预算，这种项目说明文件就应该包含更多技术内容。制作如此详细的技术说明文件需花费一些时间——而如果产品目标和功能发 生变化，或者未通过批准，那么这些时间就白费了。

但随着更多富有经验的程序员和软件开发项目经理加入游戏行业，这个问题也得到了妥善解决。这些人才引进了新的文件设计标准，确保项目规划更明确，并减少了技术性问题。 他们将设计文件按照目标、方法、功能和技术类别，将其划分为功能说明文件和技术说明文件。这样产品客户、用户或主设计师就可以浏览功能规范书，直接反馈是否赞同指定软 件的目标和功能，而无需考虑将由程序员等人员来处理的技术性决策和文件。

因此，技术人员需等到功能说明文件通过审核并签收之后，才开始制作技术规格书。他们无需理会功能文件签收之后的任何设计变化，除非该文件更新并制定出新规划。这样就可 以节省程序员的时间，让他们更好把握自己的工作安排，专注于解决执行过程中的开发方法和技术问题。

不过也有许多公司至今仍将功能规范书称为“设计文件”，但同时也会制作技术说明文件。

游戏中包含哪些内容及其用途都是功能规范书所涵盖的内容。其中包含内容通常取决于撰写者的立场和想法。而如何执行及其运行这些功能则是技术规格书的内容（游戏邦注：其 撰写原则主要取决于系统角度）。这两者都是游戏开发过程中设计阶段的重要环节。

功能规范书撰写原则

功能规范书（以下简称规范书）是产品功能及特色的概括。其瞄准的读者则是执行这些工作的团队，以及负责审核游戏设计的人员。规范书是游戏理念、评论及讨论的顶点，它是 游戏理念大纲及项目提案所描述愿景的具体化版本，它是技术规格书、项目进程安排和执行的起点。

必须从用户角度撰写其中所有内容。换句话说，这个文件中要描述的重点就是用户所看到、所经验或接触的内容。人们总是易于将其制作成以系统为导向的文件（尤其是程序员） ，但这些抽象内容非常不利于目标读者阅读和理解。读者只希望通过这份文件想象游戏中发生的情况，而不是其运行原理。

这种规范书可能短至10页，也可能长达数百页，其长短要取决于游戏系统的复杂性。但一定不能指望一页纸就了事。我曾见过不少非常出色的设计文件，有些不足50页而有些却更 为冗长，重要的是内容明确而非篇幅长短。

这类文件的撰写时长也不尽相同，如果是益智游戏可能几天就足矣，射击游戏游戏是一个月，而RPG或策略游戏等更复杂的项目可能长达数月。需注意，文件撰写时长与其篇幅长短 未必成正比。造成这种情况的原因包括考虑时间长短不同，当游戏拥有独一无二、原创的特性，或者玩法极具深度时更是如此。当然，主设计师制定决策的效率也会对文件撰写时 长造成影响，尤其是当大家对这个游戏项目都很有想法和激情的时候。

对多数人来说，这个功能规范书就是设计文件的开端。他们可以直接跳过概念文件和项目提纳中的市场调研和评审阶段（游戏邦注：这方面内容旨在锁定项目愿景和目标市场）。

游戏首席设计师通常就是功能规范书的撰写人。这份文件可能是集体智慧的结晶，也可能只是落实到书面上的制作人项目愿意。有时候制作人也会自己动手完成这个文件，这就可 以确保文件表达的正是其本人的想法。与打电话游戏一样，在撰写这种文件的时候，项目负责人所表达的想法可能与后来写在书面上的内容存在出入。无论是哪种撰写过程，或者 由谁负责撰写文件，重要的是制作人和首席设计师对这个文件达成了一致意见。不可出现口头所说与纸上所写内容相左，或者完全无视文件内容的情况。

我还没见过不会在执行过程中发生变化的设计，重要的是针对文件内容进行沟通和交流，即使需要更改或添加内容也不例外。有些变动由于时间有限，需要立即处理，这样才能让 文件清晰明了。即使这些变动只是写在电子备忘录或者纸张上，也要确保将其添加到未来的规范文件中。但如果游戏版本发生变化，最好从一个新理念大纲和项目提议重新开始入 手。更新版文件的准确性有利于节省未来的大量时间。

另一方面，这个文件不能出现太多技术倾向，因为它的读者基本上不是程序员。如果你发现它出现技术倾向，那就要收手了，因为这是技术规格书所写的内容，否则就会让非技术 读者像看天书一样不知所云。与此同理，你或者其他撰写者可能也未必是技术人员，所以无权通过这份文件指令程序员如何执行工作。这要让他们在书写技术规格书时自己决定。 毕竟这个文件纯粹是用于交流和审核产品内容，而非指导如何完成任务。但你可以针对自己认为非常重要的地方进行一些简短描述。例如，你不能指令使用哪些变量，以及如何使 用这些变量去模拟一个物理定律，但你可以指出与这个物理公式有关的因素。同理，你不应该告诉程序员如何定义他们的数据结构和对象，但可以针对数据输入界面和数据描述提 出一些建议。

功能规范书可以划分为以下6个主要版块：

*游戏机制

*用户界面

*美术和视频

*声音和音乐

*故事（视情况而定）

*关卡需求

游戏机制

游戏机制要以详细术语描述游戏玩法，它始于核心玩法，其次是追随玩家游戏活动的游戏流程。剩下的都属于无限的细节内容。

核心玩法：要用数个段落描述游戏本质。这些文字好比是设计发芽的种子，将其植入一个已知市场的土壤，它们就会开始生根，牢牢把握目标愿景，以繁衍出成功的游戏。这与游 戏理念大纲中的描述版块内容相似，但它属于非故事内容，并且其要点描述更明确，但这一点主要取决于不同游戏类型的要求。

游戏流程：对玩家活动进行详细描述，注意玩家在这一过程中的挑战性和娱乐性的发展。如果说核心玩法是大树的根，那么游戏流程就是树干和分枝，所有游戏活动都是从核心玩 法扩展而来。要明确指出玩家所执行操作，尽量使用“射击”、“指挥”、“选择”和“移动”等准确的词语而非“点击”、“摁压”和“拖拽”等字眼来描述内容。因为这种描 述差异可能会对GUI运行方式产生影响。如果你在此首次提到屏幕、窗口或指令条等GUI元素，那就要记得将读者引向“用户界面”版块的内容。

角色/单位（视情况而定）：它们是在游戏中受玩家或AI控制的演员。这里应包含一个简短描述和一些合适的数值。这些数值需划分成A到Z或者“高到低”等级，这样才能明确每个 单位彼此间的地位。但此时不宜插入准确数据，因为程序员到时候自然会在技术规格书中提到这一点，并创建一个可让你试验这些数值的环境。除了数值之外，这里还要列出单位 的特殊技能或能力，并进行简要描述，但如果这些内容很复杂，可以在“玩法元素”版块进行扩展。

玩法元素：这是针对玩家（或者角色/单位）所能接触或获取的所有元素的功能描述。其内容包括武器、建筑、转换器、升降机、陷阱、道具、咒语、升级能量和特殊技能等。在描 述每个种类特点之前，要用一段话指明这些元素的引进或交互方式。

游戏物理和数值：要划分游戏中的物理元素，例如移动、爆炸、战斗等，将每个种类分成一个子集。根据分配给角色、单位和玩法元素的数值来描述这些物理内容的外观和感觉。 要指出催生这些物理功能所需的数值。描写这部分内容时要征求程序员的看法，例如游戏如何处理这些物理内容，数量如何严重影响玩家表现等问题。

这里的内容可能有点枯燥，但切记不可过于技术化。不要使用确切的数字或编程术语。因为这些都是程序员之后撰写技术规格书所考虑的内容。只要告诉他们你希望获得什么效果 即可。例如，“这些单位上坡时会减速，下坡时会加速，除非它们是滑翔或飞行工具。攀升和加速的数值，以及倾斜角度会影响它们的表现。”你不可告诉程序员应该使用哪种算 法调整速度，因为你自己并非程序员，他们才是这方面的行家。

人工智能（视情况而定）：这里要描述游戏AI的理想行为和可用性。其中包括移动（寻径），反应、触发器、目标选择，其他作战决策（游戏邦注：例如射程、定位等），以及与 玩法元素的互动。要描述关卡设计师控制AI的路径，例如使用.INI文件，包含游戏数值或C代码的文件，专用AI脚本等。

多人模式（视情况而定）：要指明多人玩法模式（例如：贴身肉博战、合作对付AI、团队等），以及在不同网络中这种模式所支持的玩家人数。要描述多人模式与单人模式在游戏 流程、角色/单位、玩法元素和AI上的区别。

用户界面

因为界面变动很频繁，所以我们看似没必要将其列入文件。但是，我们将其组织到文件中，就可以最小化设计变动所造成的影响。这里的内容包括屏幕和窗口导航流程图，所有的 屏幕和窗口功能需求。完成这一步后，GUI美工才可以根据需求自由发挥创意。而在美术动工之前，你得先提供模型。然后描述所有需要编程的CUI对象。

流程图：这是多个屏幕和窗口的导航图表。可以使用VISIO或类似的流程图工具将已标签和标数的方框连接起来，使其代表屏幕、窗口、菜单等元素。要记得在每个表格的角落列出 所有项目的序号，以方便程序员理解和落实工作。

功能需求：这是每个屏幕、窗口以及菜单的功能分解，它应列出用户操作及预期结果，可能还会包含图表和模型。可以适当列出一些具体交互行为（例如按钮、点击、拖放和产生 动画），但最好不要在此添加过多这种内容，因为这会涉及到执行方式。当然，如果点击按钮这种描述更易理解，或者真的很有必要指出某物的特定运行方式，那就要详细指出其 交互方式。

模型：针对所有屏幕、窗口和菜单创建模型。这一点通常被人所忽视，但如果美工对其工作没有概念，就可以利用模型启发他们。不要费太多时间创建精美的模型，只要用一些文 本标签画些简单的线条即可。没有必要上色，因为这可能弄巧成拙，除非颜色真的很重要。可以利用一些绘图软件提供的模板快速建模。

GUI对象：这是创建所有屏幕、窗口和菜单的基本模块。这里并不包括主视图入口的项目，因为它们会出现这后的美术列表中。罗列在此的GUI对象主要用于帮助程序员了解自己需 要编辑的内容。你应该详细说明这些模块的交互方式。虽然这看似不值一提的内容，但结合技术规格书与项目安排来考虑事情，无疑更有助于了解项目整体需求。

有些游戏很容易整合GUI对象列表中的按钮、图标、指针、滑块、HUD元素等内容，但界面截然不同的游戏则未必如此。但无论如何，对象之间的交互方式不会有太大出入，毕竟按 钮就是按钮，点击女妖的头部与点击灰色矩形并无区别。

美术和视频

这里就需要列出游戏中的所有美术和视频内容。可以添加一些占位符参照内容以便之后命名，例如特定任务的美术内容，用于营销材料、样本、网页、手册和包装的美术内容。

总体目标：在这里你要将图案、特点、风格、基调、色彩等与美术目标有关的内容描述清楚。要确保主要美术设计人员和美术总监与项目总监或制作人达成一致意见。这样就可以 节省下日后的返功时间。

2D美术&动画：这真是一个足以纳入美术工作安排的大型内容列表，必要的话也可以加入描述内容。有些美术内容需要额外说明，而有些可能有特殊的设计要求，这些都要一一说明 。可以将美术内容划分为多个版块。主设计人员可能有一些自己喜欢的安排方式。以下是我列出的这些典型版块内容：

*GUI：屏幕、窗口、指针、标记、图标、按钮、菜单、外形等。

*营销及包装美术设计：你在这里和美术工作安排中可能都要考虑到这一点，其中包括网页美术设计、销售传单设计、样本启动画面、杂志等平面媒体以及包装合、手册中的美术设 计。

*地形：例如区块、纹理、地势目标和背景等场景美术。

*玩法元素：玩家和敌人动画（精灵或模型）、玩法结构和互动物体、武器、升级道具等。不要忘了还有受伤状态。

*特效：喝彩、爆炸、火花、足迹、血迹、碎片、残骸等。

3D美术&动画：这里的需求和用途与2D美术列表相同。其中差别可能就在于任务分工不同。美术团队通常会将3D美术任务并入建模、纹理、动画和特效工作，以便最大化利用成员的 技术，并保持工作一致性。

电影艺术：这通常是指介于不同任务之间，以及出现在游戏尾声的2D或3D场景。这原本应该像电影脚本一样另外撰写一个文件，但这属于制作方面的工作。功能规范书一般也会将 其纳入文件在，列出其一般用途、内容和目标长度。如果涉及相关视频内容，就会将其列入以下的子集。

视频：除非你是制作全动态影象（简称FMV）游戏，否则就没必要在这个子集中投入太多精力。如果你的GUI中有个用来阐述情节内容的视频，就可以将它纳入此列。所有的视频任 务都需要编写脚本，但这属于制作工作。这里也要列出一般用途，预期长度，以及演员数量、场景设计等一般内容，即便它只是个由蓝屏切入3D渲染背景的镜头。

声音和音乐

总体目标：强调声音和音乐的美学和技术目标。描述你所追求的主题或基调，可以列出原有游戏或电影作为参照。要指出技术要求和剪辑目标，例如采样率，磁盘空间，音乐格式 和转换方法。

音效：列出游戏所需要的所有音效及其使用位置。要列出预期的文件名称，但在文件命名规范上要与声音程序员和音效技术人员进行沟通，以便大家快速找到音效文件，并将其运 用到游戏中。

不要忘了所有可能需要使用音效的地方。所以要浏览一遍游戏元素及美术列表，看看还有哪些地方需要添加声音元素，以下就是一些值得考虑的地方：

*GUI：点击按钮、打开窗口、确认命令

*特效：武器开火、爆炸、雷达鸣响

*单位/角色：对话录音、跺脚、碰撞等

*玩法元素：拾取物品、警报、环境声效

*地形（环境）：鸟声、丛林声、虫鸣声

*移动：风声、脚步声、地板咯吱声、涉水声、踏入泥淖的声音

音乐：列出游戏中的音乐需求及其使用位置。描述音乐基调和其他微妙特点。游戏通常会重复使用一个主题和旋律，要指出需要重用这些主题的地方，并且咨询作曲人的看法。

*事件：成功/失败/死亡/胜利/发现等。

*屏幕：针对开头、鸣谢和结尾屏幕设置的音乐基调。

*关卡主题：针对特定关卡的音乐（由其设计师选择音乐主题）。

*情境：设置不同情境的基调（游戏邦注：例如危险逼近、战斗和探索的时候）。

*电影音轨

故事（视情况而定）

写下游戏所讲述的故事概要，包括背景故事和角色细节描述。要指时游戏文本和对话需求，以便将其添加到项目进程安排中。但也不可过份纠缠于这些细节以至于忽视其他内容， 毕竟讲述故事并非多数游戏的重点。当然，如果你开发的是一款冒险游戏，那就很有必要在此多下一番功夫。

关卡需求

关卡图表：不论这是一个线性活动，拥有分枝的任务树，还是一个自由开放世界，这个图表都应该是所有关卡创建的基础。如果关卡结构仅需一个简单的列表就能表述清楚，就不 需要创建图表了。下图是一个典型的成功/失败分枝任务树图表。当然每款游戏特点不同，其图表结构也会有所差异，重要的是要让它成为有助于关卡设计师和读者理解内容的线路 图。

内容揭露计划表：它应该是一个玩家首次接触游戏时所会看到的游戏内容表格或电子表格。它可以是以关卡为行，以每种内容为列。其中的内容包括升级道具、武器、敌人类型、 诀窍、陷阱、目标类型、挑战、建筑以及其他所有游戏玩法元素。这个表格可确保游戏中的内容，即促使玩家进入下个关卡的元素妥当分配，不会出现超量或没有充分使用的情况 。

如果有些内容已经停用，那就最好将这个计划表绘制为Gannt图，用线条指出可用的内容和资产。这样才好让关卡设计师知道自己该在何处下功夫，这样就不会搞砸自己或其他人的 关卡。

关卡设计核心：在写出详细的设计文件之前，要先点出设计核心。设计师用工具试验并开发了首个可玩关卡之后再推出的设计，更有可能获得成功。所以此时最好先列出每个关卡 的核心，描述关卡目标，玩法以及它如何与故事（如果游戏有故事内容）相结合。可以选择先勾勒一个草图，如果设计师对此已经拥有明确想法那就再好不过了。要确保文件列出 了地形、目标、新揭露的内容，以及目标难度等级等特定的关卡需求。

普遍误区

以下是设计师需要注意的一些普遍问题：

*细节不足：要用充分的细节传达关卡目的和功能，避免使用一些含糊不清的字段，除非你补充了更多详情。

*越俎代庖：正如你不应该告诉厨师如何使用沙司调味，你也不可告诉美工如何管理自己的256调色盘，不能教程序员如何定义一个特定的数据结构。只要列出重要的目标愿景即可 ，否则只会浪费彼此的时间，毕竟这种细节更适合出现在程序员所撰写的技术规格书中。

*模糊不清或自相矛盾的内容：要警惕这种情况，因为它会使项目愿景偏离方向，产生一些误解，导致功能规范书失效。

*内容繁冗：这份文件可能没有什么明显错误，没有模糊不清的地方，也没有任何缺乏，但就是内容太多了。在充实这份文件时要把握好执行设计的时长，删减非必要的冗余功能， 可以将其保存起来运用到游戏继作中，或者为保留这些功能而争取推迟项目交付日期。

*过于个人化的设计：我曾经强调过游戏设计是一个协作的过程，虽然大家是各司其职地完成自己的工作，但功能规范书应该是集体智慧的结晶，因此它不可以是一项个人产物。否 则会让人觉得自己与设计过程没多大关系，同时也会让这份文件更像是一份命令和计划。团队成员更乐意阅读大家合力完成的设计文件，这样人们提出批评意见时也主要是针对文 件本身而非作者，这样可以让大家更自在地对文件提出改进意见。

*偏离项目愿景：即使拥有一个良好的理念大纲和项目提案，功能规范书也仍有可能出现一些不同解释内容。创意人员通常都有人马行空的想象力，并且很可能在撰写这一文件时受 到自己当时所玩游戏的影响。

技术规格书撰写原则

如果说功能规范书描述的是产品应该包含哪些内容，那么技术规格书解释的就是如何添加内容。技术规格书是游戏的工作蓝图，其作用是促使程序员将设计师的设想转变为现实， 在这一过程中程序员需吃透游戏该执行哪些内容，如何减少执行/集成中的障碍，如何描述编程区以及任务安排。

许多公司都会略过这个步骤，因为撰写这种文件极为耗时，而且只有程序员可以从中受益。但撰写这份文件总比因未撰写文件而对错误问题采取补救措施更省时省力。技术规格书 的主要作者是主程序员或技术总监，不过如果可以让负责不同编程区域的程序员分工完成内容，这会提高文件撰写效率。必须采用每个程序员都能理解和入手的编辑格式。

该文件的目标读者是项目主程序员以及公司技术总监。因此它是以系统而非用户角度出发撰写内容，看起来会很枯燥，对制作人和其他非技术人员来说简直像是天书。但制作人要 求撰写这一文件的目的在于，确保技术人员考虑周全，即便制作人本身对此并不了解。对主程序员来说，这是一个组织思维和勾勒项目框架的方法。这种编写文件的过程有助于显 示编程环节中的不确定因素和漏洞，以及功能规范书中的模糊或荒谬之处。

许多出色的技术规格书编写格式与本文描述并不相同。这里的格式主要与功能规范书相对应，以确保覆盖所有的功能规范内容。有时候开发团队也可以出于分工不同，或因为基础 系统组织方式而选择不同编写形式。如果这样的话，我建议他们细读功能规范书的每行文字，并以萤光笔标出相关内容，以免忽略某些内容。毕竟疏漏一个细节可能会令产品、项 目和团队动态产生令人不快的结果。

这些原则不会教你如何执行游戏开发，其假设前提是你已经是一个技术能手，富有经验的游戏程序员，而生手则不应该参与这项任务。我认为优秀的技术规格书应该遵从这些原则 ，它们会要求你定义所有游戏中的最普遍元素。有些原则可能并不适用于你的项目，但每个原则都值得认真考虑，毕竟它可能对你有所启发，而这也正是撰写这份文件的意义之一 。

游戏机制

这当然也是这份文件的组成部分。但在这里你会发现将其与功能规范书中的游戏机制部份一一对应的做法有多荒唐了。因为这份文件应以系统为出发点，而不是以设计师或用户的 角度来写作。开篇要提到的是硬件平台和操作系统，外部供应码对象（例如DLL、EXE、驱动器等），并描述内部生成码对象。然后再区分起源于控制环路的特定游戏代码机制。

平台及操作系统：要指出项目所需的硬件平台、操作系统以及支持版本。对PC/Mac游戏来说，要提到最小系统需求和目标运行设备。如果游戏并非以CD而是以卡盘等形式发售，那 就要提到相应的ROM要求。

外部代码：要描述并非项目团队所开发的所有代码来源和用途。这包括操作系统代码和针对不同游戏平台的预处理工具，驱动器和DirectX等代码库，以及项目所需的3D API，或其 他现成解决方案。

代码对象：分解多种代码对象编码、编译和创建到EXE的用途和范围。如果使用到非进程内或者同进程的代码库（例如DLL），那也要分别进行说明，要说清使用对象实例及其存在 目的。

控制环路：每款游戏都有一个控制环路。要详细说明启动代码、主游戏代码的控制转换过程。说明核心循环的功能名称及其作用，例如碰撞、移动和渲染路径。要解释多线程、驱 动器、DLL和内存管理的使用原因。当然，多线程和内存管理的更多详情应该出现于它们使用最频繁的区域，例如渲染或精灵引擎，声音代码和AI。

这部分内容概括的是支持核心玩法的系统和内在框架，以及功能规范书所描述的游戏流程内容。

游戏对象数据：先仔细阅读功能规范书中关于所有角色/单位的描述，以及游戏玩法元素内容。然后规划并列出所有数据结构，以及能够支持这些描述特点、功能和行为的标识符。 从某种程度上说，只有游戏物理、统计数值和AI部分内容考虑周全并载入文件时才可能做到这一点。在为用户界面或任何包含单位/玩法对象特定数据（游戏邦注：例如图票、HUD 元素、动画或特效参照内容）的区域添加统计数值。

如果使用的是面向对象的编程方法，那就要提供类继承树和每个类的界面属性和功能。描述集合的使用方式。列出可能作为全程变量以增强性能的变量，例如可能在碰撞时、移动 或渲染等重要游戏惯例中命被多次引用的对象变量。需要重申的是，我并非教你如何为游戏编程，只是想让你多考虑其中的普遍技术问题，尤其是与整洁性、多功能化或速度有关 的数据结构优化问题。

数据流：要说明数据如何存储、加载、转换、处理、保存和修复。要为数据输入或处理工具提供参考内容，任何复杂或与用户集中型工具都要分别说明功能和技术规范。

游戏物理和统计数值：这里的内容多而繁杂（例如移动、碰撞和战斗等等），但可能也是最有趣的编写和执行内容。但它的代码可能也是编程中变动最为频繁的内容。设计师喜欢 更改内容，并且通常是在游戏具有一定可玩性时才能决定采用哪个设计。因此你的执行计划应该具有模块化和灵活性。要将控制操作行为的所有元素导入可以在运行时间阅读的数 据文件中，这样可以方便设计师在闲暇时间进行调整，无需介入编程调整过程。这个说明文件应该明确区分代码及其控制数据的组合性和分类。

要定义每个函数或程序，描述它的用途，确定由哪些数值来控制它的行为（如常量、变量等）及其修改方法。这包括列出所有参数的函数原型。如果使用到了函数指标和函数重载，则需详细说明要使用哪个版本的函数。例如，你可能有多个处理不同单位类型移动过程的函数——其中一个处理着陆移动方式，一个负责空中移动方式，一个负责水中移动等，可以简要描述函数运行方式。对于复杂的函数，可以使用伪代码去说明编码方式。这一点对于要经常进行数值运算的CPU密集型函数来说尤为重要。要考虑如何对其进行优化以增强运行性能。也许进行一点位移或者使用宏指令就可以提高运行速度。

人工智能（AI）：这个环节通常易于延伸成主要内容，但如果根据项目进程表来安排，又总会削减其中篇幅，仅保留必要内容。这说明设计师对复杂AI的追求有增无减，但由于时
间和资源有限，最后总会让AI变成模拟智能或脚本行为。设计AI方案的时候尤其要注意这个问题。尽量在无需添加大层次的情况下完成功能规范书所描述的行业和决策制定方法， 以免让这一过程呈现不必要的现实主义色彩。在此要运用基本的制作法则，假如可以用更少的成本和时间完成一项工作，那就没有必要投入过多时间和资金把事情复杂化。

当然，这里也需要注意一些例外情况。有时候总有些内容需要更长的创建时间，但完成这些内容有利于节省设计师创建关卡的时间。此外，创建一些更有弹性或强大的内容，也可 以为公司开发其他项目提供宝贵的现成素材，或者让项目更易处理设计变更的问题。所以在制定这种决策之前，要先跟制作人和开发主管讨论可行性。

要确保这里的内容包含功能规范书所提到的AI控制方法，例如它是由数据驱动，还是嵌入编译代码，以及它究竟是一个脚本语言还是一个固定的变量集合，抑或是这两者的合体。

AI内容还应该包括寻径、目标选择、测试和附带相应行为的事件，角色制定的其他决策，与游戏情境相关的单位/智能游戏元素以及单位统计数值。

不要在其中添加驱动AI的实际脚本或数据。因为这是制作团队的工作。只要解释清楚决策和行为起因即可。要区别说明控制行为的统计数值。

多人模式：从多人模式角度来评估执行方案，这一点也非常重要。这部分内容应该分别说明游戏机制中的所有多人模式考虑因素，以及功能规范书中所有与多人模式相关的特定需 求。

在多台PC上的多人模式（不同于共享控制器或hotseat模式）有许多需要解决的独特需求。例如，要考虑游戏支持的是哪种连网方式和网络协议？它是基于客户端服务器还是对等网 络？数据包大小是多少，发送频率又如何？数据包结构是什么？如何解决数据包丢失和延迟的问题？要向特定主机传送什么信息？共有多少不同信息，它们何时使用？

用户界面

外观和风格是开发过程中最常变化的设计内容。因此，针对GUI的编程很有必要保持灵活性，要将玩法用途与GUI功能相分离，这样用户交互方法的改变就不会影响到游戏的其他层 面，或者产生重大的改编程序。要使用继承类创建多种GUI对象（控制方法）以保持代码界面在事件中的一致性和数值。这样就可以在无需重大改变调用函数的情况下，将滑动块变 换为文本框或按钮。最好将任何GUI对象都设置为可更改状态。

为此，你的文件应该具有弹性和通用性。需要将GUI划分为屏幕、窗口和菜单分别说明，但不可以延伸至特定交互方法，只需写下不同GUI对象运行方式，使用位置即可。

可以引用之前章节所记录的游戏机制功能，但与界面有关的所有信息都要写在这部分内容中。有关图像引擎的绘图和剪辑路径的内容应该纳入美术和视频章节，但如果涉及视察窗 口和HUD附件，以及玩家交互活动的信息就要引用这里的内容。

要列出所有的全程变量、常量、宏指令、函数名或界面属性，这样程序员就知道如何快速引用文件。这也可以避免重复和不一致性问题。

游戏外壳：列出所有组成游戏外观的屏幕——这包括主游戏屏幕之外的所有屏幕及窗口。它们是由功能规范书中的流程图衍生而来，但可能包括一些主设计师所疏忽的额外屏幕（ 例如安装或设置屏幕）。所列的每个项目都要纳入其应用的片段，并描述其用途和范围（例如是在特定关卡数据加载之前还是之后），它将访问和设置的相关数值，它将调用的函 数等。

主游戏屏幕：游戏中可能会有一个或更多与核心游戏玩法有关的屏幕。虽然许多人习惯从GUI角度再到其中复杂性进行考虑，但撰写本文件时要从低级别机制着手，然后再延伸至 GUI。这样即使GUI外观发生变化，也可以保持文件一致性。

美术和视频

功能规范书已经详细列出了美术和视频内容，技术规格书的作用则是解释这些美术和视频内容如何在游戏中进行存储、加载、处理和播放。其中包括动画系统（2D或3D），视频解 压和串流系统。当然有些内容可以采用现成的解决方案，尤其是视频代码。但这里应该提到所有接口技术的问题。

图像引擎：无论你使用精灵、立体像素或3D多边形渲染还是两者兼用，都要在此分别进行说明。虽然只是两句话的描述，但它却可能是这份文件的重要组成部分。要描述视察窗口 、剪辑、特效以及游戏机制中所描述的碰撞和移动函数的关系。

美工说明：要为美工指出其中的重要细节，例如解决方案、色彩深度、调色板、文件格式、压缩、配置文件定义以及美工所需要注意的任何数据。要考虑应创造哪种工具来优化美 术通道，并在此指出其特定说明，或针对更复杂及用户密集型工具创建单独的说明文件。

声音及音乐

在此要描述音乐加载及播放方式。要详细说明混频、DMA、多频道、3D音效等情况。如果用到了第三方驱动器，就要描述它们的界面和用途。要确保能够解决功能规范书所提到的一 切相关需求。

音频编程说明：要为音频工程师及作曲人指出重要细节，例如采样频率、多频道使用、3D音效定义、样本长度等。如果使用到MIDI，要指出其使用版本、数量、可以使用及保存的 乐器类型。要注明数据路径，以及包含特定配置文件的文件需求。要考虑到创建何种工具来优化音频通道，并指出它们的规格，针对更复杂或用户密集型工具创建独立说明文件。

关卡特定码

根据功能规范书中的关卡设计基础，描述如何执行关卡特定码，以及它如何达到预期效果。同时也要描述如果出现更多需求时，其他关卡特定码如何与游戏代码对接。一般来说， 你应该让关卡特定码具有通用性和灵活性，使其方便快捷地运用于其他关卡或新创意的相似需求。

普遍误区

以下是你需要警惕的一些常见错误：

*遗漏详情：不可只是列出功能而没有补充如何执行功能的所有详情。撰写这份文件的用意是让程序员事先把开发流程过滤一遍，否则他们无法正确预估执行任务所需时间。

*尽管让各个任务指定程序员完成相应文件内容是一种很有效率的方法，但这并不意味着它能给游戏项目带来最大好处，或者程序员就会在没有监督的情况下自觉完成撰写文件的任 务。在这一过程中初级程序员可能需要一些指导，而在所有文件整合在一起时，所有相关程序员都应该对文件内容进行一番讨论和点评。一些公司设置了让程序员相互评论对方工 作的常规代码复查制度，最好在设计阶段尽早展开这种审核工作。

纸质关卡设计原则

在使用编辑器创建关卡之前，设计师应首先制作纸质关卡设计版本。理想情况下，设计师在项目动工之前就已熟悉设计画板、关卡编辑器和游戏引擎功能。要在执行阶段就根据功 能规范书中的关卡设计核心制作好纸质关卡。

这些核心是关卡或基本需求（会指明需要引进哪些新资产或者设计的限制条件）的核心理念。最好不要一次性做齐所有的纸质关卡设计，因为设计师挨个落实每个新关卡时可以学 到更多。

而制作人通常都希望马车跑在马前面，所以在真正的关卡设计开始之前，要首先制作具有可玩性的原型关卡。这通常是确保工具和游戏引擎顺利运行以制作关卡的一个基础。它也 可以作为编辑器和引擎可实现目标的指南，以及关卡设计愿景的缩影。

紧接着就可以开展真正的关卡设计，但即使到了这一步，说明文件在节省时间和确保产品质量方面仍会发挥重要作用。以下是关卡设计需遵从的重要步骤：

步骤1：小样和讨论

关卡设计师要设想一个符何功能规范书和内容揭露安排要求的关卡布局。然后他们就可以制作一个草图并与主设计师进行讨论。这个小样可以是画在白板上或笔记本上，它是促进 讨论的视觉辅助工具。这里不需要表达整个关卡设计理念或所有关卡细节，因为这些通常是讨论过程中所涉及的内容。

制作草图和进行讨论的好处在于节省时间，无需迫使设计师事先规划好一切并将其编入文件中。高级或主设计师可以在数分钟内决定大家所提出的关卡设计是否可行，并提出富有 价值的改进建议。一份内容详尽的纸质文件可能需要数天甚至一周时间才能完成。设计师的稿件是否会被退回重新修改，则要视其技能水平而定。这在项目动工初期表现尤为明显 ，因为此时设计师仍在揣摩主设计师想要的效果是什么，临近项目尾声时，要得到原创而富有吸引力的关卡设计就更困难了。

步骤2：详尽的纸质版本

在小样和关卡理念获得批准后，关卡设计师就可以开始制作详细的纸质关卡设计版本了。关卡布局应比草图更详细，并且要按比例绘制出来。最好使用彩色铅笔在大张方格纸中绘 图，在地图中要标注对象、行为、建筑、敌人、事件、位置等信息，也可以将其列入另一份单独的索引文件中。还要列出任务特定美术或代码内容。完成这些细节可能需要花费数 天甚至长达一周时间，但比起在真正的编辑器中“搜索”或“重新设计”，这种方法可以省下更多时间。

完成这一步后，主设计师、制作人和其他主要决策制定者就要对其进行一番审核。他们可能批准这一理念，也可能提出一些修改意见，或是直接否决了这个关卡设计。

另外也要让技术型人员，最好是高级程序员从编程角度审核这份书面关卡设计。这样程序员就会留意关卡设计师的理念所涉及的工具和图像引擎。他们可能向工具添加一些功能， 或者对代码进行调整以让关卡设计更具可行性或更易于执行。他们也可能要求移除或修改任何可能破坏游戏或几乎不可行的关卡设计。

人们通常倾向于跳过这个步骤，直接使用编辑器制作关卡，因为创建一个关卡原型往往比制作纸质版本更快。在项目进度安排较为紧凑的时候尤其如此。但项目安排越是紧凑，就 越有必要使用书面文件来规范设计工作，因为事先考虑周全有助于一次性把事情做完，减少意外情况发生次数，节省返功时间。制作纸上关卡设计版本的好处在于，它可能让设计 师事先就考虑到所有事项，在落实设计之前就表达出关卡的趣味和挑战性所在。这份文件还可以确保在设计师开始工作之前，程序员、美工和音频技术人员就已掌握自己的任务安 排。

步骤3：创造关卡核心

设计师需确定关卡核心游戏玩法，应该在纸上设计版本中就体现其想象的趣味性和挑战性。然后征求主设计师和制作人的反馈意见，让他们决定这个设计的好坏。最终的关卡设计 可能未必有纸上设计版本那样可行，或者有预期那样好玩。但这一做法却有助于节省设计师时间，以免发生重大修改或导致整个关卡都被否决。

步骤4：补充更多细节

确定关卡核心玩法后，要确保其他内容都有助于优化和提升核心玩法。这包括确立设置、充实关卡，使游戏更富生气（例如提供更多选项、解决方案或惊喜）的所有内容。

新美术或代码资产通常看起来都不会很协调，所以要确保设计师在植入占位符前就找到所需内容。然后再更新纸上设计和任务列表。

步骤5：玩法测试

让设计师体验这些关卡，并尽量收集更多反馈。这一过程仍然离不开设计文件。要确保设计师至少要用笔记本记录下所有漏洞，反馈和任务。有时候人们很容易遗漏一些问题，所 以最好是将其归档到含关卡特定问题和反馈内容的数据库中。

文件阶段和开发安排

以下是关于项目进度安排中的典型阶段列表，在每个阶段（或称标志性事件）都有一个评审过程。因为只有当文件大部分内容都完成才能制定项目开发安排，所以要确保重新撰写 文件或创建大家都认同的说明书这一过程不会影响到项目开发时间。为了赶时间发售游戏而匆匆编撰设计文件，并草率投入制作是造成项目失败的一大原因。并且这并不能为你节 省什么时间，事实上它只会浪费大家的精力，并且造成更重大的项目延期。

概念阶段：

*文件：游戏理念

*文件：游戏提案

设计阶段：

*文件：功能规范书

*文件：技术规格书

*文件：工具说明文件（视情况而定）

制作阶段（游戏邦注：有时也称执行阶段）：

*制作安排

*技术和美术样本

*首个可玩关卡

*文件：纸上关卡设计（不一定是可交付成果）

*Alpha

测试阶段（QA）：

*Beta——发布首个潜在码

*Gold Master——发布代码

我们还可以列出更多阶段，因为发行商有必要掌握一些决定和确保项目执行顺利进行的途径。有时候它们会针对特定美术、代码和设计制定每月固定标志性事件。这里所列举的只 是一些最为常见并且更有影响力的情况。

应对变化

看到一个项目依从这些原则而顺利运转应该是一件美妙之事，但有时由于灵感或市场趋势的变化也会让项目愿景转向。人们习惯使用“即时设计”模式以应对新变化，并且不影响 项目安排。有时候这种情况确实难以避免，但这种模式也存在弊端。在这种情况下，唯一可用的方法就是固守这些原则及其程序。如果在合同上提到这一点那就更好了。不要在未 更新有关文件的情况下调整项目内容。要知道功能规范书中的一个变化，可能就会导致技术规格书中的有关内容失效，并影响后续的项目安排。主设计师在签收并交付功能规范书 时必须清楚哪些人可能提出修改要求。如果他们确实需要进行一些更改，那就可以通过更新文件和重新制定项目安排而减少其影响。只要想想卡在项目开发过程中，或被迫延迟任 务的痛苦，就足以成为促使你事先考虑周全，制作好这些文件的动力了。希望本系列文件对你的项目开发过程有所帮助。

篇目2，阐述如何制作一流的游戏设计文件

作者：Tzvi Freeman

我必须做出一个游戏。就在不知失措、头昏眼花之时，我一头撞在了电脑显示屏上。接着，古铜色的灯里轻烟似地冒出了个灯神，许诺我三个愿望。我不假思索地说：“我想要……

*一支有才能、有技巧、有献身精神的程序师和美工组成的团队（包括非常善解人意的老婆一枚）且个个擅长人际交往。

*足够的时间和资金允许搞砸一两次。

*一流的设计文件。

很久以前，编写一款游戏只需要一名程序师（和一名美工）加上接了就做的预算和宽松的开发期限，所以大家对文件编制没必要太上心。你知道想要什么就去做什么。因此，如果在这过程中发生了个把重大变故，你只能责怪你自己。现在，一份周全易读的设计文件意味着什么呢？就是迅速地坠入一文不值的地狱和平稳地飞升到富丽堂皇的天堂之间的差别。

如何展开工作？

大多数游戏的开发从概念到制作完成需要经历三个阶段，即“产生灵感”、“纸上计划”和“身体力行”。

在第一阶段，概念文件不仅是一封写给自己的信——提醒你不要忘记它们；还是一个应对投资商和营销商的销售工具。有时候，还要在这个阶段制作一个微型原型，这样你就可以用它做实验并修改自己的创意。

第二阶段是和一大堆美工、动画师、音乐师和编程人员讨论——实验想法，然后找出组织办法，最后敲定主意。

在最后阶段，管理制作过程的工作通常交给一些擅长处理流程和冲突的行家负责。原创意的设计师可能只允当团队的主要成员，但在许多情况下——特别是在大公司，这位设计师往往变成旁观的顾问。

毫无疑问，如果说设计文件是项目的父母，那么它对项目的成长影响当然最大。即使作为设计师的你兼任项目经理，你也不能欺骗自己：你确实不能全盘兼顾。复杂的项目需要许多有才能的人共同完成。有技术的程序师和美工往往有自己的一套心思。当你打算做一匹马，美工画出的可能是只独角兽，而程序师想到则是吃苦耐劳的骆驼。好的设计文件可以确保大伙想法一致、感觉一致。这好比一支大乐队的爵士乐总乐谱，尽管仍然有大量即兴表演的余地，但在总乐谱统领作用下，大家的心思都被放在一处。

设计文件是想法与现实之间的桥梁。它能确保承载想法的野马不会脱缰跑出现实所能驾驭的范围，同时又保证最后抵达的终点正是最初创意的指向。

最后，记住这句久经玩家证实的格言：“伟大的艺术来自细节”。光彩夺目的细节自然而然地从游戏中流露出来，就好像它们当初从第一道灵感中闪现光芒一样。但是，一旦你进入实际的执行阶段，细节的火花往往容易熄灭。

挑战

给项目制做局部原型当然是个好主意——尽可能画出所有草图。但此外，那些细节才是最重要的。你的想象能承载的细节越多，你的作品就会越出色。

根据文件工作也有消极面。刺激的游戏的开发过程本身就必须刺激。例如，有许多项目的闪光点往往是到了令人恐慌的截止期时才被发现。诚然，时间和成本预算的压力不允许概念的不断重复，但你只是不希望做出一款干巴巴、没惊喜的游戏。制作设计文件的挑战在于，能够忍受你的项目发生意料之外的调整，但又不迷失原创意的整体方向和视野。

成功的设计文件十个要点

1、除了形体，还要描述灵魂。 如果游戏开发只是自动输入/输出的问题（就像编写代码和预测过程）——那么你只需要一份干巴巴、描述性的文件就行了。但事实是，开发是人做的， 这些人是有创意的人、有独立想法的人、想在所有自己做的工作上盖个戳的人。

再继续说你想要的那匹马的故事：你把说明书交给美工，然后和他们讨论要做什么。之后你给程序师看了下说明书。两边都对你所说的话点头称是。

当天晚上，大约凌晨2点，正当C++的群星闪烁在西天，处于中年危机的程序师开始胡思乱想：“什么，我的下半辈子就是一个程序呆子？我妈对我的指望就这样？为什么，我也可以像其他人一样设计游戏！“然后继续埋头输代码。

大约与此同时，美工等着他那台陷入死机的电脑完成复杂的3D渲染，等着等着就睡着了，这会儿刚醒过来。他不确定也不关心他是不是在做梦，或者从这些工作中取得报酬，只是沉浸在艺术天才的狂想世界里，在不可思议的幻想和现实的融合作用下，神兽诞生了——当然不是你文件所描述的那匹马。

第二天一大早，你的马，当然没来，来的是长着两个驼峰的独角兽。对于这些创意星人，光给指示行不通，启发才是硬道理。

在你的设计文件中，别满足于对各个物品和细微差别的细节性描述。花时间形容一下游戏应该有的感觉、各个元素潜在的目的、玩家应该有的体验和你可以想到的、能够形容的游戏灵魂的方方面面。

例如，你在设计一款射击游戏。你的目标是通过游戏训练玩家如何应对现实中遇到的某些挑战，所以一开始设定的难度不高。你得向团队的所有成员解释你的用意，这样他们才会理解为什么某些东西要放在这，为什么要这样做。即使你的团队不太认真地对待或胡乱删改你的创意，你仍然可以抱着希望，即结果达到或接近整体效果。或者可能还更好。

2、易读性。给团队成员一份每页标明10个要点、无衬线字体印刷、80个字符一行的文本，并且要求每个人都要阅读。你可能得在每件份文件里准备一捆止痛药了——这是为那些确实要忍痛遵守指令的人准备的。

以下是我遵循的页面布局原则：

大片空白

文本主体以衬线字体（游戏邦注：指西文中有衬线的字体，与汉字字体中的黑体相对应）印刷

粗体字标题

段与段之间有空隙

文本句子简短

引导视线直指重点内容

分层次，大纲视图

用表格、图表、图片等说明例子。把图表、表格、图片等制作得醒目一些。

3、区分优先次序。既然你意识到你是和头脑清楚、有自我的人一起工作，就有必要让这些人意识到某些加标记的游戏元素的神圣性。我确实不敢打包票，但如果你能好好利用标记，你想强调的地方大概还是能得到一点尊重吧。这还没完，既然打了标记，当然还要区分不同的标记含义——有些是你计划要做的，有些是时间、预算和技术允许就做的。

然后垃圾来了——那些听起来很棒，实际上完全有理由当成垃圾的东西。你需要明确地指出来并解释需对其警惕的原因。如果你不这么做，我敢说这些垃圾还是会再跑出来。以下是标记列表：

不可缺少

重要

如果可能

否绝

你可能希望用上一些视觉符号来代替标记。但不要依赖颜色，因为文件不一定总是彩色印刷。

4、深入细节。没有细节的文件毫无用处。大家可以随意地理解大纲。“Thou Shalt Not Kill”（不可杀生） 这句话对摩西来说是一个意思，对西班牙征服者来说是另一个意思。详细地说明哪些角色不能杀、为什么不能杀、还有什么用途。设计文件也是一样：一旦你描述了一些实用的细节并给出相应的例子，你的想法就具体化了——不会被轻易地晒在一边。

例如，不要只说：“铜鸟是无敌的。”明确地描述这家伙被攻击时会发生什么情况及之后如何恢复。确实，如果动画师有脾气又有艺术家的尊严，你可以肯定他不会听从你的指示。但至少他会另想出一个更清楚的、又不违背你的主意，且他的修改不会严重地改变相关的部分。

别只说：“此时，用户会按下带箭头的跳跃键爬上墙。”而是详尽描述如果玩家不那么做会发生什么情况。解释为什么你认为用户能够想到你所提供的操作组合。解释环境暗示玩家爬墙的可能性。

另外，美工也会冒出其他想法，可能比你最初的设想更适合。如果是那样，那就真是太好了，因为成品可能甚至比你的纸上描述更接近你最初的灵感。但除非你一开始就清楚地描述了你的概念，不然这种事不可能发生。

别只说：“Bongo Man 比Bongo Boy更强大，但Bongo Boy的反应更快。”请用表格来表现角色的动作速度值、角色可拥有的攻击点数、角色的攻击伤害点数、发动攻击需要的能量等等。这种表格在Q/A和制作阶段是非常有价值的。

别只说：“大多数人会在几天内想通整个游戏。”制作表格，用于预测不同用户持有的产品的寿命；表明你希望各种功能特征被发现的时间点。之后的用户测试会为下一款游戏的设计提供有价值的反馈。

5、演示某些东西。有时候，几张草稿就够了，但如果这个创意对你的概念和项目确实重要，你可能得亲自制作粗略的动画。当元素的活动太过复杂和模糊，难以用文字表达，你就得制做原型。原型的好处之一是，通过实践往往可以催生更简单更高明的解决方案。

除了提供动画和原型，你还是需要提供概念的文字描述。动画确实比十亿字节的文字更有价值，可是文字也有动画无法达到的交流效果。看动画时可能会遗忘了某些重要的差别，而文字可以清晰地描述出细微之处。

6、别只说“什么”而不说“如何”。在现实世界，“如何”决定了“什么”。例如，假设你已经选择了粘土动画，那么就要制定出捕捉画面的方法，然后在文件中描述这个过程。背景应该用什么材料和什么颜色？应该用什么摄像技术和为什么用这种摄相技术？塑造框架的步骤是什么？等等等。如果你尝试过，你会知道这些因素中的任意一个对结果都有重大影响。

或假设你在制作一款摩托车竞赛游戏。你表示摩托车必须在优势和弱点之间达到平衡，所以你要在文件中提供实现平衡的表格，并注明调整是必要的，还要说明你打算如何实现调整——过程是什么？假设游戏的主要角色是歌剧幽灵。描述玩家的键盘如何映射管风琴键。提供一张各个键的映射图。列举发声的可用渠道的数量。和你的程序师讨论一下怎么实现各个细节，再用文件记录下来。两个不同的“如何”可能会产生非常不同的结果。

7、提供替代性选择。项目经理耗费大把时间在制作甘特图和PERT项目评估上。个人认为，我真的不敢说这种东西对游戏开发是有效的——很大程度上是因为未知的东西太多了。你的游戏技术越激进越新，开发过程中可预测的情况就越少。要保证你的团队达到日程表上的阶段时间点，你能做的不过就是提供另一条通路。（游戏邦注：甘特图：美国工商业管理专家甘特设计的，是一种用平行线表示一定时间内生产的计划数字和实际完成数字的图表；PERT项目评估：在一个给定的项目中对潜在任务进行分析的一种方法。）

我们返回键盘映射管风琴键这个例子。你的程序师向你描述实现最佳效果的最终方法，此法需要50人/小时来执行。因为我们已经讨论过其他事了，所以你已经记下所有东西。

你不能止步于此。你得问：“如果我们只需要一个切边、8槽的管风琴，要费多少人力时间？如果是绝对最小值呢？如是要我们只有几个助理能做这个怎么办？”然后你照旧记下一切。当最后面临抉择之时，你只需要脱口而出：“好吧，计划C。”

在文件设计方面，我犯下的最大的错误就是问程序师：“这办得到吗？”除非你问的是一流的程序师，否则这个问题根本就是白问。更具体地说，回答可以分成以下三种：

（差劲的程序师）：“当然，没问题。”

（一般的程序师）：“不，不能。”

（一流的程序师）：“我这样做要花两周的时间。或者我可以小调整一下，只要五小时。”

总是不忘问另种方法和所需时间。然后表明你的倾向——如果有时间就这样做，否则就做罢。

8、允许修改。灵感和创意往往与兴奋和乐趣同在，我已经警告你要防止闷死这种灵感和自然的创意。你得允许设计文件被你自己或其他人（但愿是有才能的人）修改。

我在British Columbia大学主修音乐作曲时第一次吸取了这个教训。千辛万苦，我终于写好了一个新文艺复兴的铜管五重奏，我真是相当自豪。我的导师也很喜欢。当我们把乐曲拿给学院的铜管乐队演练，然而，在十秒钟的时间内，我的情绪就经历了几个阶段的起伏：惊骇、怀疑、愤怒和沮丧。乐队开始演奏了，一个大号手停下来向其他乐手示意，接着他取出笔开始修改几个音节，然后所有人又继续演奏。这种情况发生了不止一次。

我的导师，注意到我的脸色突然苍白了，转过身来对我说：“别担心，他们对莫扎特的曲子也这样。他们通常是对的。”

真相是，无论在纸上看起来有多好的东西，被置于现实世界的客观解读之下，最棒的专家仍然会修改它。虽然如此，你不想目睹自己的设计和梦想被无情地篡改。你希望自己的灵感以一种自然的姿态成长——永远是那颗你播下的种子，它的成长不经过外来根枝的嫁接。

以下技巧可以帮助你制作出一份可接受修改，又不会中断原始想法或扼杀开发进程的文件：

如果某方面是游戏概念的重点，确保大家牢记于心。

确保所有人领会游戏的灵魂及各个细节的用意。

如果有信息重复，必须互相参照。否则，如有改变，就会产生矛盾指示。

以下是实际执行阶段的技巧：

当有人提出改变时，回头检查你的设计文件，看看它是否和游戏的“灵魂”一致。

检查这是否是独立的改变，或它是否产生系统性影响（牵一发而动全身）。如果是后者，就在下一份计划中拯救它吧。

及时更正设计文件，包括修改的原因。或如果你不想修改，明确指出并解释原因。

修改、删除和否绝想法应该保留在主控文件中，以免重复讨论相同的事。

所有人都必须以相同的版本作为工作对象。过去的版本应该销毁。

重要的、关键的和紧急的一点：设计文件必须置于一人且仅有一人的监管之下。

9、应提供必要的参照和指示内容。我曾见过有些人的文件甚至连页码都没有，结果却抱怨成员没有遵循文件指示。优秀的文字处理器会自动计算页数并且印刷每一页的日期和页眉或页角。有些甚至允许你在新章节里改变页眉。用黑体字印刷重要的内容。你可以随意在不同的部分重申你自己的想法，前提是你把重申的部分相互参照了，这样你就可以一次性更新所有内容。制作一个周全的内容表格。

你可能希望用HTML写下你的文件和运用超链接。有些高级的文字处理器不需HTML也能使用超链接。但记着，人们往往更喜欢看着死复印件文本（因为有了实实在在的文件在手，那么在系统崩溃后重新启动的一个小时内，就还有点东西可以读）。

10、好文件也要好包装。最后，你需要做的就是使文件便于阅读和使用。没有愿意阅读一叠纸——因为看起来也不重要。只有带硬封面的东西看起来才重要。

制作一份应持有复印件人员的名册并进行保存。打印出所有东西，且每一页都要带眉头和日期。接着在每一页上打洞做成活页。最后在每一份活页本的书脊和封面上贴标签。更新时，人手一份校订页。有时，你可能需要提拱新活页本，丢掉旧活页本。

总结

电影制作人使用步骤原稿。建筑师使用蓝图。音乐家使用乐谱。根据古代的传说，甚至是宇宙造物主也制作了设计文件，在最初的文明之光普照大地之前，他让一小撮先知瞄了一眼——所以有了这个古代传说。既然神都是这么做的，那么游戏开发者就以之为榜样吧。

篇目3，如何使用GDD有效地组织游戏开发过程

作者：Gamux

你是否曾经因为缺少计划而在游戏开发过程中不断地改变设计和玩法方向？你应该考虑使用游戏设计文件（即Game Design Document，以下简称GDD）。它是整体游戏的指导愿景，把游戏的设计、开发和商业等方面的想法和计划组织在一起。

引言

简单地说：我们都喜欢讲故事。有些人非常喜欢，有些人可能没那么喜欢。但关键是，我们都曾经花很长的时间构思故事，随着时间流逝，这些故事开始演变，变得越来越复杂，细节更加丰富，背景更加充实，剧情更加曲折。一个全新的世界就这样从无到有地在我们的头脑中成形了。

随着故事越来越复杂，构造故事世界的工具也越来越多。美术分离成若干不同的类型，音乐变得更精致，影片也进入这个世界了。技术增强带来信息共享，把艺术传播到全球。每天都在创造新的幻想世界。世界这么丰富多彩，使人们开始渴望成为它们的一部分。一个新概念就诞生了。

尽管电子游戏一开始只是关于争取最高分的娱乐活动，开发者很快就意识到游戏的无限潜力。玩电子游戏不只是简单地经历另一个故事。这是第一种在故事如何叙述自己上有发言权的媒体。玩家可以扮演角色，亲身体验旅程的艰难，探索特定的世界和精通那个世界的技能，经历主人公的胜利和失败。

游戏以前所未有的方式将玩家和故事联系起来。这种联系可以以多种方式建立，可以是故事发生的幻想世界，可以是特定角色的丰满个性。它迫使玩家努力去看到更多他们想要的东西。

不幸的是，因为游戏是由如此众多的不同元素组成的，它的制作又需要来自不同领域的不同专家的参与，使协调开发过程变成一件非常棘手的工作。为了顺利协调工作，开发者通常会使用一种叫作GDD的东西。

GDC是帮助组织游戏部件的工具。它记录游戏各个方面的总体想法，从图像设计到剧情线。总之它记录游戏概念，是对项目成品的预测和计划。

尽管编写GDD并不是制作过程的关键部分，却对开发团队有莫大的帮助，特别是当所开发的项目由大量人员参与时。另外，编写GDD的方法有很多种。事实上，不同的游戏开发公司的GDD是不同的，但一般来说，大部分游戏都是围绕这些文件展开制作的。

那么言归正传，以下是这个重要工具的几个你必须知道的要点。

概述

你所编写的游戏设计文件必须告诉阅读它的人，这款游戏是怎么样的。为此，你不仅必须解释游戏的机制，还有游戏的对象（游戏邦注：例如主角、敌人、谜题、武器、环境等）之间是如何互动的，你的游戏主题是什么，风格是什么。在GDD中，这些要点通常放在几个主要章节中阐述。

营销

营销是一个大章节，可以划分成几个章节。它主要解释游戏的商业方面，如目标受众、截止日期、竞争对手和卖点等。这个章节对商业有非常大的指导意义，因为它显示了你的游戏胜过对手的优势和如何满足消费者的需求。换句话说，它解释了你的游戏的吸引力。

高概念

在你开始告诉读者（阅读GDD的人）你的游戏如何运作以前，你必须阐明你的游戏的核心概念，即简明扼要地表述游戏的主要方面，这样读者就能预期到这份GDD要说什么以及需要注意的重点是什么。所以，GDD中有一个关于高概念的章节，这样读者不必阅读文件的所有方面就能对你的游戏有一个大致的了解。

例如：如果你告诉读者你的项目是一款未来派太空射击游戏，他就能想象到这款游戏中出现的武器、活动、敌人和其他东西应该是怎么样的。

玩法

这个章节是GDD中最重要的部分，因为它解释了如何控制游戏中的对象，如何使对象进行互动以及玩家如何执行活动等。另外，它还解释了游戏流程和各个游戏环节发生的事件。

第一分钟

这是玩法章节的一个子章节，它解释了玩家在游戏加载完后首先看到的内容。它解释了此时游戏和玩家之间的活动和反应，帮助理解游戏的进程和操作方法。这是一个重要的子章节，因为它决定了这款游戏是否有趣。

流程

这是一个比“第一分钟”更详尽的子章节。它描述了玩家在游戏时可以选择的所有选项。它是一种反映各个选项会产生的结果的流程图，显示了整个游戏的概貌。通常来说，这个流程图是由游戏截图组成的（例如，从“主菜单”到“选择关卡”），但你也可以把动作和结果放在里面（比如，如果玩家选择“法师”角色，所有背景都会变成与魔法有关）。如它的标题所示，这个子章节准确地解释了游戏的进展方法。

获胜条件

在这个子章节中，你必须告诉读者做什么怎么做才能在游戏中获胜、在什么情况下会失败。也就是说，这个子章节解释了游戏的目标。

玩家数量

指定该游戏可以由多少人一起玩是非常重要的，因为它决定了游戏的类型或游戏支持的模式——单人的还是多人的。例如：分屏、LAN连接、网络连接。注意：这个子章节对“获胜条件”有影响，因为在竞技型游戏和合作型游戏中的获胜条件是不同的。

美术

解释完如何玩你的游戏后，就可以阐释你的游戏的外观和美术风格了。这也是非常重要的章节，因为它决定了游戏世界中的元素的共存方式和影响玩家游戏的情绪。这还是游戏营销的一个关键点，因为这显示了游戏的外观和传递给玩家的感觉。

技术

GDD中必须包含的另一个章节是“技术”，因为它确定了游戏要求、运行平台、开发引擎等等。这影响营销，因为游戏所适用的硬件会影响玩家基础和目标受众——消费这款游戏的人。

有没有公式？

你必须记住，即使不同的GDD中存在若干相同的子章节，制作这种文件也不存在唯一的方法，不存在所谓的“完美公式”。每一位游戏设计师都有自己的编写方法，你必须寻找适合你自己的方法。这是很艰难的工作，但在本文中，我将提供一些解释如何编写GDD的各个子章节的技巧——然而，什么子章节是设计你的游戏所必需的，仍然取决于你自己。

你的文本必须总是保持清楚简明，最好配合大量插图，因为它们能让读者更快地想象到游戏的最终结果，并且有助于解释谜题（如果你的游戏中有的话）以及角色、环境、怪物、武器和其他物品之间是如何运作的。

此外，你还可以在你的GDD中加入一些能够帮助理解游戏的核心的新论题。应该注意的是，你的游戏的创新和细节。例哪，如果你的游戏项目具有全新的游戏方式，或特殊的图像概念或如果它以音乐为重点（像游戏音乐），你应该在GDD中讨论佗，以便让读者理解为什么这个创意是好的。

目录

GDD最好以“营销”章节为开头，因为它是你的投资商和客户最感兴趣的部分，这样就能让他们更快对你的游戏产生兴趣。在独立游戏的GDD中可能不会出现这个章节，因为独立游戏通常没有投资商，然而，如果你认为在其他不存在商业目的的项目如苹果的免费游戏，那么就必须记录与营销方面有关的计划，因为它对发行计划具有非常重要的意义。

此外，高概念很重要，这样读者才能马上理解游戏的核心和注意它的主要方面。你会发现，在GDD中，通常以游戏的基本和总结性的定义开头， 然后再逐步深入游戏的各方面的细节。

在下一章节中，应该解释游戏的“玩法”，它包含“第一分钟”、“流程”、“获胜条件”和“玩家数量”等。

这个章节后你必须显示你的游戏的外观，也就是讨论游戏的美术方面，尽量使用图片。最后，你可以讨论“特殊性”，即解释：创新、并非所有游戏都有的方面如情节、AI、角色和其他特殊的设定。

上述提到的所有东西都显示在下面的流程图中，这只是一个供你（应该）参考的一般架构。记住：没有完美的公式。现在，你已经有了GDD的骨骼，你可以在本文的“构成”这部分找到对GDD的章节的更详细的解释。

构成

尽管编写GDD的章节没有完美的公式，但必须包含几个重要的论题和避免一些主要错误。本节主要告诉你如何细化上文“概述”中所提到的章节和子章节，并且附上正确和错误的案例。

营销章节

这个章节没有什么统一的编写方法，因为你的目标取决于你的游戏。并且它也不是必须的，你可以把它结合到其他子章节中，也可以穿插在整个文件旧城 ，因为这个论题的某些方面与其他的大有关联。无论你选择如何阐释这个论题，以下几点是必不可少的：

目标受众

谁会玩你的游戏？这不是一个普通的章节，所以不要简单地描述成“针对儿童”之类的。“分类”游戏的方法非常多，你必须好好研究。解释它将如何吸引各类玩家，他们可能与你的产品没有太多共性，但总是有一些共性的。

正确：

《Turret Defense》针对年龄介于15-25岁、经常玩FPS和RTS PC游戏的男性玩家；本作的太空冒险背景和主题尤其吸引喜爱科幻主题的游戏、电影和小说的玩家。

根据ESRB（娱乐软件分级委员会）有关暴力的内容描述，本作被评为T级（青少年），仅适合年龄在13岁及以上的玩家。为了满足发行要求，《Turret Defense》将不使用血腥或任何超过ESRB对暴力的内容描述的内容。

错误：

《Turret Defense》将吸引大量玩家。根据类似游戏的经验，它应该会在电子游戏市场上大获成功。我们计划在流量大的游戏网站上为它做大量广告。

（“大量玩家”不是有效的描述，不能解释为什么他们会喜欢你的游戏。没有提到ERSB分级或该游戏是否包括年龄限制的内容。）

另一个优秀的案例：

《OrBlitz是》的预期ERSB分级是全年龄向。本作的主要目标市场是益智游戏的粉丝，但本作的许多原创内容将吸引更广大的玩家，包括喜爱动作游戏的玩家。RTS游戏的粉丝也可能对本作感兴趣，因为它的具有某些与RTS游戏类似的玩法。因为画面不含暴力元素，且界面直观，本游戏也能吸引女性玩家。本作画面可爱、色彩丰富，既能吸引美国玩家，也能唤起日本玩家的兴趣。

注意案例中提到的分类词：性别、年龄、国家和类型。记住，取决于你的游戏，可能还要提到更多分类。预测ERSB分级也是比较好的，这样开发者就会注意到某些与暴力、性和禁忌语有关的限制需要好好处理。

平台

非常简单的章节。只要列举出你的游戏针对的平台就行了。也可以在这个部分提及系统要求。如果有必要，你还可以解释移植游戏可能遇到的困难。

竞争对手

这是GDD中的重要子章节。这里，你必须把你的游戏与市场上已经存在的其他游戏作比较。必须简要地描述游戏的竞争对手，以及你的游戏与它们的相似点。通过详尽的比较，可以让读者更清楚地看到这款游戏的真实情况。

在最后，总结你的产品的优势，使读者相信你的产品能够战胜竞争对手。这是最棘手的部分，因为你必须挑对竞争对手，读者不可能在不知道你在说什么的情况下还对你的游戏保持乐观态度。所以，文笔是很重要的。你的“自吹自擂”也能劝说读者相信你的市场有多大。

进度表

在“进度表”章节，你必须定义开发游戏的每个必要环节，也就是完成你的游戏的环节的时间线。有了这个，不只是你，包括投资商，都可以对完成项目必须的时间有一个大致的估计。

其他子章节

你可能会添加一些重商业的论题如“成本”，包括设备成本、人力成本、附加成本和预期利润等。

未来计划

有时候，可以补充到游戏中的想法太多了，但开发进度紧张，所以只能把那些想法放在一边。这个章节就是用来记录那些未能实现的想法的，这样以后你就能根据进度决定是否执行。DLC、可能的续作、玩法上的微调、图像修改等等，都可以放在这里。你还可以收集一些可能用于补充游戏成品的想法。

例子：

添加一些支线任务

使角色能够执行跳跃动作

做一段讲述开发者故事的视频

简介章节

简介章节应该首先简单地介绍游戏的高概念，然后加上“摘要”，让读者对游戏本身有一个基本的了解。你还可以在“关键特征”中强调游戏的创新方面。

高概念

这个段落描述了你的游戏关于什么；应该写得摘要的摘要。避免谈及技术、图像或声音设计、复杂的玩法或不是非常必要的营销细节（比如，如果你做的是音乐游戏，你应该提到你使用的音乐风格；但如果你做的是益智游戏，就暂时没有必要提它的音乐；而最好描述一下谜题的类型）。关键就是，用最简洁的语句描述你的游戏，不要使用技术术语中。给你一个技巧，使用知名的游戏作为比较例子，比如“X是一款3D赛车游戏，与《马里奥赛车》类似”。

正确：

《Scavenger Hunt》是一款3D街机风格游戏，玩家的目标就是与对手竞争，看谁先收集齐任务列表上的道具。

错误：

《Scavenger Hunt》是一款3D街机游戏，背景是50年代的虚构街区，具有益智元素和卡通风格的图像和音乐，玩家的目标是和对手竞争，看谁先收集到各个阶段的任务列表上的道具。这款游戏在单人模式时，由电脑控制对手；在多人模式时对手为另一名人类玩家。

（尽量保持简洁）

摘要

这部分更加详细地描述你的游戏，限制没有高概念部分那么多。从玩法的核心方面开始，描述玩家的作用，目标、完成目标所需的行为、失败条件以及游戏的乐趣。

接着，简要介绍游戏的背景和历史（如果有的话）。最好使用图片而不是文字来说明游戏的外观如何，所以如果你没有草图或概念图，你应该贴一些风格类似的图片（比如其他游戏的截图）。

关键特征

最好用短句而不是很长的段落来组织这个章节（即小点列表）。在这部分，你应该告诉读者所有你认为会为游戏添彩的创意想法。

正确：

-简单而强大的物理学让一系列简单的规则产生惊人的结果。

-2.5D卡通风格的图像

-前所未见的绘图系统，当游戏加速到疯狂的程度时，游戏会变成色彩斑斓的世界。

-强大的陆地制作功能，允许你构建复杂的路径，如隧道和桥梁。

-丰富的游戏模式和场景，流畅的动作和反应。

错误：

本游戏有简单而强大的物理学，让一系列简单的规则产生惊人的结果，同时使用2.5D卡通风格图像和前所未有的绘图系统，当游戏加速到疯狂的程度时，游戏会变成色彩斑斓的世界；玩家可以使用其强大的陆地制作功能，构建复杂的路径；游戏有丰富的游戏模式和场景。

（一口气说了太多想法，让读者摸不着头脑）

第三方软件

简单地声明你开发游戏将使用的程序语言、库、软件以及图像与声音引擎等（游戏邦注：包括多人游戏需要的网络）。

如果你受到严格的软件/硬件限制，你应该在此说明（即如果你制作的游戏是针对苹果设备的，你必须声明你将使用iOS兼容的技术）。另外如果你的游戏是PC平台的，你应该声明最低配置要求。尽管在这个项目中不搞程序的人可能不理解什么是“NVIDIA Cg 1.2.1”，但至少应该让他们知道这么一个名称。

玩法章节

这个章节旨在描述游戏如何有效地运作、游戏的目标及其元素（菜单、获胜条件、敌人、道具、关卡……），和这些元素与玩家之间的交互作用。如果你觉得一个子章节“敌人”包含的内容太多，那么你可以把它单列成一个章节。

第一分钟

描述游戏加载后玩家的反应会是什么，这是很有趣的。比如可以描述玩家可以马上开始玩游戏，浏览菜单修改选项，通过尝错误或教程学习操作，一开始就能玩所有关卡还是需要解锁，等等。考虑到你之前已经准备好一些关卡，你可以简单地叙述一下玩家如何通关、在这个关卡中遇到的敌人和/或谜题。

正解：

标题页面后，玩家将看到一列他可加入的游戏和新建游戏的选项。选择新建游戏后，一列预设关卡将出现在屏幕的右边。（……）修改好设置后，当有三名其他玩家加入游戏，游戏就可以开始了。计时器从5秒开始倒计，这是玩家的准备时间。游戏开始后，玩家使用少量的金钱布置方块。随着轻快的背景音乐，游戏面板绕着屏幕中心旋转，逐渐展开关卡的布局。（……）玩家的目标就在游戏面板的各角。（……）计时到0时，屏幕中间出现“GO！”命令，魔法球从云中落下，沿途造成严重破坏。（……）玩家要迅速地把方块放在面析的边缘，这样魔法球就会从边缘弹开，玩家完成目标时半听到熟悉的点镖机的声音。玩家的得分和金钱变成200，他现在可以进入下一关（……）。

错误：

这款游戏一开始，玩家在相反的角落面对面。玩家1使用游戏开头赠送的钱，和布置石块挣得分，来获得。

（缺少细节）

流程

对“第一分钟”的完美补充莫过于“游戏流程”，它通常用流程图表示。与之前的子章节相反，这个部分不强调第一印象，而是显示玩家从游戏加载完毕到按下“退出键”（结束游戏回合）的过程中可以执行的活动，让读者对整个游戏的进程有一个总体认识。

正确：

错误：

（太简单了，至少应该包括玩家看到的所有页面）

获胜条件

在此声明玩家通关、获胜应该满足什么条件。比如，如果你的游戏是拼图游戏，那么玩家必须把所有拼图块以正确的方式组合起来才能进入下一关；如果你的游戏是横版射击游戏，玩家必须击败最后的BOSS才能通关……显然，这完全取决于你所设计的游戏类型。

案例：

在《太空侵略者》中，玩家扫清当前所有敌人后，游戏就会刷出新一波敌人。因为敌人是无限刷出的，所以直到玩家耗尽命值，游戏才会结束。

图像

事实上你无法向读者提供任何你还没做出来的游戏的截图，所以在这个部分，你只要描述你计划使用的图像引擎，可能再附加几张游戏的草图或你想使用的风格的原画。提前设计游戏的HUD会帮你节省大量时间。

HUD

HUD是指玩家在游戏过程中使用的内置界面。与游戏菜单如设置或目录面板不同，这是特指通常不游戏本身互动而只具有提供信息作用的浮动窗口和数值条，比如命值条、小地图、计时器、装备栏、钱袋等。尽管HUD的大小因游戏类型而异（MMORPG和RTS通常有很大的HUD，而横版游戏和益智游戏的HUD通常很小），记住，HUD不应该占据屏幕太多空间。

案例：

声音

另一方面，你也无法描述声音，所以你只要声明你将使用的声音引擎和（也许）歌曲风格。尽管对于大部分游戏，你只要简单地声明不同场景将有不同的背景音乐，但毫无疑问，这个部分对音乐游戏来说是最重要的。

操作

用文字介绍按钮/键盘的对应功能，可能有一点麻烦，特别是当按键对应的功能不止一个时（比如《塞尔达传说》的“A”键）。用简单的控制器或键盘图示来解释各个按键的功能更合理。此外，如果你的游戏有高级的连击或类似的东西，你要详细地解释它们，声明在什么情况下会“激活”什么操作组合。

案例：

游戏特定的子章节

拼图游戏可能有“拼图块”章节，横版游戏可能有“关卡设计”章节，太空射击也许有“敌人”章节等等。正如标题所暗示的，每一种游戏都有它们自己的特定的子章节，因为我们列举一个GDD可能有的所有子章节，所以下面我只举三个例子。

拼图块

假设你的游戏是拼图游戏，玩家的目标是通过把相同的图像拼成一行，以获得积分。最好能在这个部分展示不同类型的拼图块的草图，以及解释它们的旋转方式、分值和布局。如果能配合图片就太好了！

案例：

关卡设计

假设我们的游戏是2D平台游戏。这款游戏的核心元素之一是玩家必经的台面。必须让各个台面显得独一无二，否则玩家就会觉得自己只是在重复玩某个关卡。另一方面，玩家应该仍然熟悉流程，即如果关卡中间总有一个保存点或可收集道具，那么其他关卡也应该如此。

不同类型的敌人、地形、道具等是怎么样的？关卡设计师是否可以根据它们设计出不同的台面？你可以展示一些测试版台面的图解。

案例：

敌人

太空射击游戏往往有许多不同类型的敌人，每一种都有不同的进攻招式、移动模式、命值、速度和攻击范围。因此，你当然需要再写一个章节专门介绍游戏中的敌人和它们的属性。另外，你可以陈述一些他们的模糊行为，比如当它们命值过低时会发射额外的光波。

案例：

情节

许多游戏都发幻想世界为背景，各有自己的地理、历史和角色，玩家可以扮演的主角当然很多。如果你的游戏有特别有趣的背景，那么最好能加入游戏的故事板，描述主角在冒险过程中遇到的主要事件和传说。

角色

玩家在游戏中通常不会只遇到敌人。可能有主角和同伴来帮助他打败敌人。例如，甚至在无玩家控制角色的塔防游戏中，在开头部分仍然可能有像向导NPC这样的辅助角色来指点你如何克服某个挑战。如果你的游戏确实有玩家操作的角色，那么他是怎么样的？他是否有什么技能和专长？记住，不要把这部分写得像“怎么玩”。

AI

所有游戏都需要一个恒定的世界来处理所有的玩家行为和其他活动。这包括敌人移动、玩家操作、碰撞、计时、随机数生成和许多其他东西。尽管没学过程序的人也许不能完全理解这个章节，但他们至少应该知道基本知识。最重要的是，不要在这里出现代码，简单地描述敌人的移动模式、拼图块下落的算法，用流程图来解释战斗系统。

案例：

面板上的角色通过简单的寻径/集群算法来躲避魔法球。每一个关卡会使用三个不同的脚本文件来向动画化的角色发布指令。（……）玩家角色将用于模拟真实的玩家。由AI系统将决定的是：

-是否放新方块？如果是：

-在哪里放新方块？

-这个方块是什么类型/材料？

技术章节

组成一系列游戏数据技术，如系统要求、开发工具、算法以、屏幕上可出现的元素的最大数目。图像技术方面包括软件、建模类型、美术风格和其他与此有关的东西。

所谓的系统要求是指电脑运行游戏必须达到的配置，如游戏占用的硬盘空间、需要多少RAM。

另一个重要的技术方面是，不要忘记ESRB评级，之前已经解释过了。评级例子如下所示：

要不要包含？什么时候？为什么？

负责推广该游戏的公司或将使用该技术开发游戏的人会对技术方面感兴趣，所以当你把这个GDD拿给审查这款游戏的人时，总是保证介绍它的技术方面。你可能会写出一些错误的论题，比如，把平台和推广游戏模式放在营销章节中，而不是技术部分。

更多案例

至于提供专业的GDD的网站，我推荐Shred Nebula、Play With Fire、Grim Fandango Puzzle Document等，当然在gamepitches.com上也有许多。

如果想进一步学习GDD的结构和组成，可以看Gamasutra上的文章《 The Anatomy of a Design Document》的第一和第二部分、《Creating a Great Design Document》和《How to write an effective Design Document》（它与游戏开发无关，但关于软件开发）。

《Game Design: The Two C’s of Video Game Design》也值得一看。

另外，游戏圈对如何编写游戏设计文件有不同的观点。虽然看似与本文所说的有矛盾，但这是因为分析的案例不同，而且还要考虑到团队规模、预算和截止日期。

总结

对于需要投资商批准的设计师，你必须首先吸引他的注意力，为此，你的文件必须做到：

高概念：你永远没有机会给别人留下第二个第一印象。你已经知道怎么写这个章节了，现在只要记住，首先写好这个部分，点出所有你认为可以让游戏更吸引人的东西。

图片：不要以这读者会老老实实地把整个GDD看完，更别说有些文件还超过一千页（真的有这种事！）。但读者肯定会好好地看吸引他眼球的东西，所以还有什么比图片更有效的？毕竟，图片胜过千言万语。

不用说，你的文件必须有好的外观。花点时间把文本排列成方便阅读的格式。另外，不要忘记本文只是告诉你一般的GDD的结构是怎么样的，你必须根据自己的游戏做修改！

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

The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal

by Tim Ryan

October 19, 1999

The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise. Unfortunately, design documents are sometimes ignored or fall short of their purpose, failing the producers, designers, artists, or programmers in one way or another. This article will help you make sure that your design document meets the needs of the project and the team. It presents guidelines for creating the various parts of a design document. These guidelines will also serve to instill procedures in your development project for ensuring the timely completion of a quality game.

The intended audience is persons charged with writing or reviewing design documentation who are not new to game development but may be writing documents for the first time or are looking to improve them.

Design documents come in stages that follow the steps in the development process. In this first of a two-part series of articles, I’ll describe the purpose of documentation and the benefits of guidelines and provide documentation guidelines for the first two steps in the process – writing a concept document and submitting a game proposal. In the next part, I’ll provide guidelines for the functional specification, technical specification and level designs.

The Purpose of Documentation

In broad terms, the purpose of documentation is to communicate the vision in sufficient detail to implement it. It removes the awkwardness of programmers, designers and artists coming to the producers and designers and asking what they should be doing. It keeps them from programming or animating in a box, with no knowledge of how or if their work is applicable or integrates with the work of others. Thus it reduces wasted efforts and confusion.

Documentation means different things to different members of the team. To a producer, it’s a bible from which he should preach. If the producer doesn’t bless the design documents or make his team read them, then they are next to worthless. To a designer they are a way of fleshing out the producer’s vision and providing specific details on how the game will function. The lead designer is the principle author of all the documentation with the exception of the technical specification, which is written by the senior programmer or technical director. To a programmer and artist, they are instructions for implementation; yet also a way to express their expertise in formalizing the design and list of art and coding tasks. Design documentation should be a team effort, because almost everyone on the team plays games and can make great contributions to the design.

Documentation does not remove the need for design meetings or electronic discussions. Getting people into a room or similarly getting everyone’s opinion on an idea or a plan before it’s fully documented is often a faster way of reaching a consensus on what’s right for the game. Design documents merely express the consensus, flesh out the ideas, and eliminate the vagueness. They themselves are discussion pieces. Though they strive to cement ideas and plans, they
are not carved in stone. By commenting on them and editing them, people can exchange ideas more clearly.

The Benefits of Guidelines

Adhering to specific guidelines will strongly benefit all of your projects. They eliminate the hype, increase clarity, ensure that certain procedures are followed, and make it easier to draft schedules and test plans.

Elimination of hype. Guidelines eliminate hype by forcing the designers to define the substantial elements of the game and scale back their ethereal, far- reaching pipe dreams to something doable.

Clarity and certainty. Guidelines promote clarity and certainty in the design process. They create uniformity, making documents easier to read. They also make documents easier to write, as the writers know what’s expected of them.

Guidelines ensure that certain processes or procedures are followed in the development of the documentation – processes such as market research, a technical evaluation, and a deep and thorough exploration and dissemination of the vision.

Ease of drafting schedules and test plans. Design documents that follow specific guidelines are easy to translate to tasks on a schedule. The document lists the art and sound requirements for the artists and composers. It breaks up the story into distinct levels for the level designers and lists game objects that require data entry and scripting. It identifies the distinct program areas and procedures for the programmers. Lastly, it identifies game elements, features, and functions that the quality assurance team should add to its test plan.

Varying from the guidelines. The uniqueness of your project may dictate that you abandon certain guidelines and strictly adhere to others. A porting project is often a no-brainer and may not require any documentation beyond a technical specification if no changes to the design are involved. Sequels (such as Wing Commander II, III, and so on) and other known designs (such as Monopoly or poker) may not require a thorough explanation of the game mechanics, but may instead refer the readers to the existing games or design documents. Only the specifics of the particular mplementation need to be documented.

Guidelines for the Game Concept

A game-concept document expresses the core idea of the game. It’s a one- to two-page document that’s necessarily brief and simple in order to encourage a flow of ideas. The target audience for the game concept is all those to whom you want to describe your game, but particularly those responsible for advancing the idea to the next step: a formal game proposal.

Typically, all concepts are presented to the director of product development (or executive producer) before they get outside of the product development department. The director will determine whether or not the idea has merit and will either toss it or dedicate some resources to developing the game proposal.

The director might like the concept but still request some changes. He or she may toss the concept around among the design staff and producers or open it up to the whole department or company. The concept can become considerably more compelling with the imagination and exuberance of a wide group of talented people.

A game concept should include the following features:

Introduction

Background (optional)

Description

Key features

Genre

Platform(s)

Concept art (optional)

Introduction: The introduction to your game concept contains what are probably the most important words in the document – these words will sell the document to the reader. In one sentence, try to describe the game in an excited manner. Include the title, genre, direction, setting, edge, platform, and any other meaningful bits of information that cannot wait until the next sentence. The edge is what’s going to set this game apart from the other games in the genre.
For example:

“Man or Machine is a first-person shooter for the PC that uses the proven Quake II engine to thrust players into the role of an android space marine caught up in the epic saga of the interstellar techno-wars of the thirty-seventh century.”

Breaking the introduction up into several sentences for the sake of clarity is acceptable. Just know that the longer your introduction, the more diluted your vision will seem.

Background (optional): The background section of your game concept simply expands upon other products, projects, licenses, or other properties that may be mentioned in the introduction; so it’s optional. The background section is physically separated from the introduction so that readers can skip it if they already have the information presented. But the background section is important for licensed properties and sequels and concepts with strong influences from previously released titles in the same genre. If you intend to use an existing set of code or tools or to license a game engine, then describe these items and their success stories here.

Description: In a few paragraphs or a page, describe the game to the readers as if they are the players. Use the second-person perspective — “you.” Try to make this section an exciting narrative of the player’s experience. Encompass all the key elements that define the core game play by describing exactly what the player does and sees. Avoid specifics such as mouse-clicks and keystrokes, but don’t be too vague. You want the readers to become the player’s character. Hover your detail level right above the GUI interaction. You would say something such as, “You scan your tactical radar and pick up two more bogies coming up the rear,” instead of “You click on your tactical radar button and the window pops up revealing two bogies coming up the rear.” The description section should make the content and entertainment value of the game obvious and convincing.

Key features: Your game concept’s key features section is a bullet point list of items that will set this game apart from others and provide goals to which the subsequent documentation and implementation should aspire. It’s a summary of the features alluded to in the description. These bullet points are what would appear on the back of the game box or on a sell sheet, but include some supporting details. For example:

“Advanced Artificial Intelligence (AI): Man or Machine will recreate and advance the challenging and realistic AI that made Half-Life game of the year.”

Determining how many features to list is a delicate balancing act. Listing only one or two key features is a bad idea if you’re doing anything more complex than a puzzle game; listing more than a page of features implies that the project would be a Herculean task and may scare off the bean counters. Listing too few features might sell your concept short; listing too many waters down the concepts’ strongest features.

Keep in mind that you need not list features that are given, such as “great graphics” and “compelling music,” unless you really think such features are going to be far superior to those of the competition. Great graphics, compelling music, and the like are the understood goals of every game project. On the other hand, if the particular flavor of graphics and music provides your game with an edge in the market, then you should spell that out.

Genre: In a few words, define the game genre and flavor. Use existing games’ classifications from magazines and awards as a guide. For example, you could choose one of the following: sports, real-time strategy, first-person shooter, puzzle, racing simulation, adventure, role-playing game, flight simulation, racing shooter, god simulation, strategy, action-strategy, turn-based strategy, side-scrolling shooter, edutainment, or flight shooter. Then you can refine your game’s niche genre with these or other words for flavor: modern, WWII, alternate reality, post-apocalyptic, futuristic, sci-fi, fantasy, medieval, ancient, space, cyberpunk, and so on.

Platform(s): In a few words, list the target platform(s). If you think the game concept is applicable to multiple platforms, you should also indicate which platform is preferred or initial. If you intend multiplayer support on the Internet, indicate that as well.

Concept art (optional): A little bit of art helps sell the idea and puts the readers in the right frame of mind. Use art to convey unique or complex ideas. Screen mock-ups go a long way to express your vision. Art for the game concept may be beyond most employees’ capabilities, so requiring it would limit the number of submissions; thus, it is optional. If a concept has merit, the art can come later from a skilled resource. Often art from previous projects or off of the Internet will jazz up a document. Just be careful with any copyrighted material.

Common Mistakes

Here are some common mistakes that developers make in creating a game concept:

The concept is totally off base or inapplicable to the company’s current plans. If you don’t want to waste your time writing up concepts that get tossed, find out what the company in question is looking for and keep an ear to the ground for opportunities with which your idea may be a good fit.

In terms of resources, the document asks for the moon. Try to keep your concept within the realm of possibility. Keeping the budgets down by suggesting existing tools or properties to reuse is helpful. Limit your ideas to that which can be accomplished in a timely fashion and with a reasonable budget. Limit experimental technologies to one area. Don’t suggest revolutionary AI as well as a new, state-of-the-art 3D engine. If you are being solicited to produce the game concept, find out what the time frame and budget expectations are first.

The document lacks content. Simply saying, “It’s Command & Conquer meets MechWarrior where you order your ‘Mechs in tactical combat,” is insufficient. Your description has to explain the actions that the player will perform and make them seem fun. A good description might read, for example, “You order your ‘Mech to fire at point-blank range on the exposed right torso of the Clan MadCat OmniMech.” This kind of descriptive content will help mitigate misinterpretations of the core game play that you envision.

The game isn’t fun. A useful exercise is to break down all of the player verbs (such as shoot, command, run, purchase, build, and look) and envision how player performs each. Then, for each verb, ask yourself if it’s fun. Then ask yourself if the target market would find it fun. Be objective. If the action that the player takes isn’t fun, figure out another action for the player to take that is fun or drop the verb entirely.

The game-concept document employs poor language and grammar. Don’t make yourself look like an ass or an idiot. Check your grammar and spelling and avoid four-letter words and sexual innuendo. You don’t know who will ultimately read your document or whom you might offend with some particularly expressive words. Even the macho, politically incorrect, culturally insensitive, slang-using manager with whom you exchange dirty jokes over a beer at lunchtime can get quite sensitive with documented verbiage.

The designer gives up. Don’t give up submitting ideas. You never know when one of them will take off. Persistence pays off, believe me.

Guidelines for the Game Proposal

A game proposal is a formal project proposal used to secure funding and resources for a game development project. As a game proposal takes time (and therefore, money) to do correctly, it should only be developed for promising game concepts.

The proposal is an expansion upon the game concept. Writing a proposal may involve gathering feedback and information from other departments, especially the marketing department (if it exists). You may need your marketing department to perform some market research and analysis on the concept. If the game requires licensing, you may need your finance and legal departments to investigate the availability and costs involved in securing the license.

The programming staff, typically senior programmers or the technical director, should perform an initial technical evaluation of the concept. They should comment on the technical feasibility of the concept and the programming areas that may require research. They should assess the risks and major tasks in the project and suggest solutions and alternatives. They should give a rough estimate as to the required research and development time and resources.

The game proposal should include a revised version of the game concept. Technical, marketing, and finance feedback to the concept document might force you to scale back the concept. It might also suggest modifying or adding features. These changes should not take anyone by surprise, as this is the first time that the concept has been subjected to major criticism and the collaborative process. Giving copies of the feedback and analysis to the director of development
(or whoever asked for the game proposal) before they are folded into the game proposal or effect changes in the concept is a good idea. This process not only provides written confirmation that the concept has been reviewed by certain people or departments, but it arms the director with the knowledge to veto, alter, or otherwise approve any proposed changes.

The game proposal includes the following features:

Revised game concept (preceding)

Market analysis

Technical analysis

Legal analysis (if applicable)

Cost and revenue projections

Art

Market analysis: The marketing department and/or a market research firm, assuming your company can afford it, should compile this information. If you are compiling this information yourself, you should try to avoid pure guesses on numbers. Look for info on the Internet (www.gamestats.com is a good source) and use existing hits in the same genre as indicators for market performance.

Target market: The target market is defined by the genre and the platform, issues that have been already addressed in the concept document. You can qualify this definition by mentioning specific titles that epitomize this market. The most successful of these titles will indicate the viability and size of the market. Also mention the typical age range, gender, and any other key characteristics. If this game involves a licensed property or is a sequel, describe the existing market.

Top performers: List the top performers in the market. Express their sales numbers in terms of units, breaking out any notable data-disk numbers and any successful sequels. Include their ship date. You can be vague — Q1 1998 or spring 1998. This research can go way back, so present your data in chronological order.

List their platforms if they vary from the platform for the proposed game. However, because the markets change depending on the platform, you should always present some title of the same genre on the target platform, even if it didn’t perform as well as the others. Such data may indicate a sluggishness for that particular genre of games on the platform. For example, turn-based strategy games may have great sales on the PC platform, but have terrible numbers on the Sony PlayStation. This list of top performers should indicate this discrepancy if you’re doing a turn-based strategy game.Feature comparison: Break down the selling features of these top performers. Compare and contrast them to the key features described in the concept document.

Try to provide some specifics. For example:
Tactical Combat: In Command & Conquer, Dark Reign, and Myth, you order your units to attack specific targets and move to specific places or ranges for an advantage. Most units have a unique strength and weakness that become apparent during play, thus encouraging you to develop superior tactics. Tanktics has a wider variety of orders to allow you to apply superior tactics, such as capture, ram, and hit-and-run. Unit position and target selection become even more important due to terrain, movement, nd range bonuses; firing arcs; and soft spots in rear- and side-hit locations. All of the units have distinct weaponry, armor, and speed to differentiate their strengths and weaknesses and encourage tactics. Not only do you learn to master these tactics over time, but you can also script these tactics into custom orders.

Technical analysis: The technical analysis should be written by a seasoned programmer, preferably the technical director or a lead programmer, and then edited and compiled into the proposal. Reviewers of this proposal will use this technical analysis to help them make their decisions. Be honest; it will save you a lot of grief in the end. Overall, this analysis should make the reviewers optimistic about the game’s chance of succeeding.

Experimental features: Identify the features in the design that seem experimental in nature, such as untried or unproven technologies, techniques, perspectives, or other unique ideas. Do not include features that have been proven by existing games, even if they are new to the development team. For example, if the team has never developed a 3D engine, don’t list it as experimental. Rather, list it in one or more of the other categories in the technical analysis section. On the other hand, if your development team is working on a 3D engine using the theoretical system of quads, then this effort should be listed as experimental. Of course, by the time you read this article, quads could be in common use.

Include an estimate of the time that it will take to bring the experimental feature to an evaluation state, as well as an overall time estimate for completing the feature. Experimental areas generally need more time in the schedule, so the more experimental features you list, the longer the schedule will be. While some companies shy away from such 18- to 24-month projects, many see these experiments as worthwhile investments in creating leading-edge titles. So tell it like it is, but don’t forget to tell them what they will get out of it. Make them feel comfortable that the experiments will work out well.

Major development tasks: In a paragraph or a few bullet points, make clear the major development tasks. Use language that non-technical people can understand. Major means months of development. Give a time estimate that assumes that you have all of the resources that you’ll need to accomplish the task. You could also give an estimate of the resources that you’ll need. For example:“Artificial Intelligence Script Parser: Three t four months with two programmers. The parser reads and compiles the AI scripts into lower-level logic and instructions that are executed at run-time.”

Risks: List any technical risks. If you don’t foresee any technical risks, by all means say so. Risks are any aspect of research and development that will cause a major set back (weeks or months) if they fail. List technologies that, though they’ve been proven to work by competitors, your company has never developed or with which your company has little experience. List, for example, real-time strategy if your team has never developed a real-time strategy game before; or 3D rendering if this is your first foray into 3D. List any of the major development tasks mentioned previously if you perceive any risk. All untried off-the-shelf solutions (3D engines, editors, code libraries and APIs, drivers, and so on) should be listed as risks because they may end up not fulfilling your particular needs. Any development done by an outside contractor should also be listed, as that’s always a big risk. When assessing risks, you should also indicate the likely impact that fixing or replacing the technology will have on the schedule. Indicate the time in weeks or months that the ship date will slip. List the time impact on specific resources. List any new resources (people, software, hardware, and so on) that would be required to fix it. This section may seem pessimistic, but it creates a comfort level for your document’s reviewers – they will come away with the impression that the game implementation is under control, especially if they can perceive these risks themselves. Plus you’ll have the opportunity to say, “You can’t say I didn’t
warn you.”

Alternatives (if any): Alternatives are suggestions for working around some of these experimental or risky features and major development tasks. By presenting alternatives, you give the reviewers options and let them make the choices. List anything that might cost more money or time than desired but might have better results, or vice versa (it may cost less money and time but it may have less desirable results). Whatever you do, be sure to spell out the pros and cons.

Estimated resources: List the estimated resources: employees, contractors, software, hardware, and so on. Use generic, industry-standard titles for people outside of the company: for instance, the publisher or investor who might read your document. List their time estimates in work months or weeks. Ignore actual costs (dollars), as that comes later.

Estimated Schedule: The schedule is an overall duration of the development cycle followed by milestone estimates, starting with the earliest possible start date, then alpha, beta, and gold master.

Guidelines for the Game Proposal, continued

Legal analysis (if applicable): If this game involves copyrights, trademarks, licensing agreements, or other contracts that could incur some fees, litigation costs, acknowledgments, or restrictions, then list them here. Don’t bother mentioning the necessity of copyrighting the game’s title or logo, as these are par for the course and likely to change anyway.

Cost and revenue projections: The cost and revenue projections can be done in conjunction with the finance and purchasing departments. This data should give the reader a rough estimate of resource costs based on the technical analysis’s estimated resources.

Resource cost: Resource cost is based on the estimated resources within the technical analysis. Employee costs should be based on salaries and overhead, which the finance or payroll department should provide. You can list these as average by title or level. Any hardware or software that you purchase should be listed as well, even if it will ultimately be shared by other projects or folded into the overhead budget. Use a table or embedded spreadsheet as it is easier to read and edit. For example:

Additional costs (if any): This section is an assessment of additional costs incurred from licensing, contracting, out-source testing, and so on.

Suggested Retail Price (SRP): You should recommend a target retail price before your game goes in the bargain bin – pray that it does not. The price should be based on the price of existing games and an assessment of the overall value being built into the product and the money being spent to develop and manufacture it. Of course, your distributors will likely push for a lower sticker price or work some deals to use your game in a promotion that will cut the price even further, but that will all be ironed out later. Keep in mind that the higher the sticker price, the lower your sales, especially in a competitive genre where there’s not as much demand as supply.

Revenue projection: The revenue projection should show pessimistic, expected, and optimistic sales figures using the costs that you’ve already outlined and the suggested retail price. Other factors, such as marketing dollars and company overhead, should be left out of the picture as these are subject to change; if a minimum marketing budget is known, however, then you should certainly factor it in. Often the revenue projection is best represented with a pie chart or
a bar chart. Be sure to indicate with an additional wedge or bar the costs incurred from any of the risks described in the technical evaluation and show totals with and without the risk assessment.

Art: If your game concept did not include any art, then the game proposal certainly should. The art should be created by skilled artists. Dispose of or replace any of the art in the concept document that was not created by the artists. The art will set the tone for the game. Assume that the readers may only look at the art to evaluate the proposal, so be sure that it expresses the feel and purpose of the game. Include a number of character, unit, building, and weapon sketches, in both color and black and white. Action shots are great. Include a GUI mock-up if your game is a cockpit simulation. Be sure to have good cover art. Paste some of the art into the pages of the documents, as it helps get your points across and makes the documents look impressive.

Presentation: The whole proposal, including the revised concept document, should be printed on sturdy stock and bound in a fancy report binder along with copies of the art. This document is to be presented to business people – you know, those people who walk around your office wearing fine suits to contrast with the t-shirts and cut-offs that you normally wear. Don’t forget that you’re proposing a major investment, so make the proposal look good and dress well
if you’re going to handle the presentation. Preparing a slide show in a program such as Microsoft Persuasion is helpful for pitching your key points and art.

Common Mistakes

Some common mistakes in preparing a game proposal include:

The analysis is based on magic numbers. Try to back up your numbers by listing your sources or explaining how you came up with them. Watching a producer pull some numbers from thin air and throw them in the document is almost laughable.

The proposal is boring. This is a selling document. Don’t bore the readers. Give them facts, but make these facts exciting, concise, and convincing.

The proposal fails to anticipate common-sense issues and concerns. You should find out what this proposal is up against — other proposals, competitive products, financing concerns, cost and time expectations, game prejudices, and historical mishaps. Your proposal will stand a much better chance of being approved if it addresses these issues preemptively rather than getting besieged by them during the review process.

The proposal writer is overly sensitive to criticism. My experience might be unique, but don’t be surprised if the major promoter for your game proposal decides to play devil’s advocate. Make sure your proposal is solid. Believe in it and remain confident, and you’ll weather the criticism and make believers out of those reviewing your proposal.

The proposal writer is inflexible to changes to the game. Often during the process of gathering research or receiving criticism from the review committee, some reasonable suggestions will arise for changing or scaling back the design. Game development is a collaborative process. Take the feedback and change the design, or the game could die right there. The key word here, as tattooed on the arm of my buddy who served in the Vietnam War, is transmute. He had to
transmute to stay alive and keep going, and your game idea may have to do the same.

This concludes part one of a two-part series on the anatomy of a design document. In the next part, I’ll taunt you with some more colorful metaphors interspersed with some useful guidelines for creating functional and technical specifications and level-design documents. I’ll also give you an overview of the document review process and how it facilitates the game development cycle.

Did you ever look at one of those huge design documents that barely fit into a four-inch thick, three-ring binder? You assume that by its page count that it must be good. Well, having read some of those design volumes from cover to cover, I can tell you that size does not matter. They are often so full of ambiguous and vague fluff that it was difficult finding the pertinent information. So why does this happen? Because the authors didn’t follow guidelines.

This article is part two of a two part series that provides guidelines that when followed will ensure that your design documents will be pertinent and to the point.

Unlike the authors of those prodigious design volumes, I believe in breaking up the design document into the portions appropriate to the various steps in the development process – from concept and proposal to design and implementation. I covered the first two steps in part one of the article, providing guidelines for the game concept and game proposal. This part will provide guidelines for the two heaviest undertakings – the functional specification and technical specification, as well as some guidelines for the paper portion of level design.

Functional vs Technical Specifications

Traditionally in the game industry, there was only one spec. How technical it was depended on who wrote it. Any documentation the programmers wrote afterwards to really plan how they were going to implement it was informal and often remained on white-boards or notepads. Yet in order to ensure the project would proceed without hazard and on time and on budget, the documentation needed to be more technical. Such detailed technical specifications took time –
time wasted if the goals and function of the product should change or fail to gain approval.

This problem was tackled as more and more seasoned programmers and managers of business software development moved into games. They brought with them new standards for documentation that helped ensure more accurate plans and less technical problems. They introduced a division in the design document between goals and method and between function and technique. They separated the design document into the functional specification and technical pecification. This
way, the clients, users or principal designers of the product could review the functional specification and approve the goals and functions of the proposed software – leaving the determination and documentation of the methods and technique up to the technical staff of programmers.

Therefore, the technical staff waited until the functional specification was approved and signed-off before starting on the technical specification. They worked from the functional specification alone, ignoring any design changes that occurred after sign-off unless the spec was updated and a new schedule agreed to. Thus the division saved time for the rogrammers and gave them more control of the schedule, while still ensuring they had a complete plan for the methods and technique for implementation.

Many companies still refer to the functional specification as the “design document” and yet also produce a technical specification. The term “functional” is a clearer term adapted by businesses and these guidelines to clarify what is expected in the document. Here is a link to a formal definition:

http://webopedia.internet.com/Software/functional_specification.html

In short, what goes into the game and what it does is documented in the functional specification. This is often written from the perspective of the user. How it is implemented and how it performs the function is documented in the technical specification. This is often written from the system perspective. Both form important deliverable milestones in the design stage of the game development process.

Guidelines for the Functional Specification

The functional specification (or spec for short) outlines the features and functions of the product. The target audience is the team doing the work and those responsible for approving the game design. The functional spec is a culmination of the ideas, criticisms and discussions to this point. It fleshes out the skeleton of the vision as expressed in the game concept and game proposal. It is a springboard from which the technical specification and schedule is derived and the implementation begins.

It’s important that it is all written from the user perspective. In other words, what is seen, experienced or interacted with should be the focus of the document. It’s often very tempting (especially to programmers) to create something that’s very system oriented. This often leads to distraction and hard- to-fathom documents.

Readers are really just looking to this document to visualize what’s in the game, not how it works.

The length can vary from ten pages to a few hundred, depending on the complexity of the game. You really should not aim for a page count. I’ve seen and written really GOOD design documents that were less than fifty pages and some that were much more. It is just important that each section under these guidelines be addressed.

This will eliminate the vagaries and guesswork that comes with insufficient documentation and the apparent need to ramble-on that comes with aiming for a high page count.

The time involved in writing the functional spec is anywhere from a few days for say a puzzle game, a month for a shooter, to a few months for a complex game such as an RPG or strategy game. The amount of time spent may not be congruent to the resulting length. The discrepancy comes with deliberation time, especially if the game has any unique, unexplored qualities or if the game play is particularly deep. Of course, how efficient the principal designers are in
making their decisions is of enormous impact as well, especially if everyone is particularly imaginative and passionate about the game.

For many, this functional specification is where the documentation begins. They skip the important research and review phase of the concept document and game proposal, which would otherwise help it anchor the vision and target market firmly in place. By skipping the first steps, they also put off the inevitable criticism from marketing, finance and technical staff, which leads to wasted efforts.

The game’s lead designer usually produces the functional specification. It may be a compilation of other’s work and hence a cooperative effort or it could simply be a matter of putting the vision of the producer on paper. Sometimes the producer will produce the document him/herself; which is ideal for assuring that the vision expressed is indeed what the producer desires. Like the game of telephone, sometimes the message gets altered when it goes from the lead visionary to the author.

Whatever the process and whoever the author, it’s important that the producer and lead designer totally agree with everything expressed in this document. They cannot be preaching one thing and documenting another or the documents will be ignored and serve no purpose.

I’ve never seen a design that didn’t undergo some changes during implementation, but the process of communication has to be expressed through the specification, even if it requires updates or an addendum. Some changes need to be fast and furious due to time constraints so the documentation may be light. So, even if it’s an electronic memorandum or notes on a piece of paper, be sure to distribute these and attach them to all future copies of the specification. If the vision of the game changes, however, it’s best to start from the beginning with a new concept document and proposal. The clarity the updated documentation brings will save time in the long run.

Unlike the game concept and proposal, the functional specification is not a selling document. It merely breaks down and elaborates on the vision in very clear terms understandable by every reader. It can be a little boring or dry as the necessary details are filled in. I’d recommend putting in summary level paragraphs at the start of every section, so that readers can get the gist without skipping any sections or losing any confidence in the thoroughness of the specification. Why do I recommend this? Well, the question should really be “Why do some people never find the time to thoroughly read the project specifications?” While your company’s managers and team members might not fail in this regard, there’s always a third party, like the publisher or contractor.

On the other hand, this document cannot be technically explicit, as its readers are mostly non-programmers. If you find yourself getting technical, stop. That’s what the subsequent technical specification is for. Besides, getting technical with a bunch of non-technical readers can make their eyes glaze over or open up a can-of-worms. You don’t want to give them an invitation to stick their nose into something they don’t necessarily understand and really shouldn’t care about. Likewise, you or the other authors may be non-technical, and you shouldn’t be dictating to the programmers how they accomplish what you want them to do. Let them determine that when they write the technical specification. This document is purely for the communication and approval of what goes into the product as opposed to how to accomplish it. Limit descriptions of how something should be accomplished to those areas that are you believe are really important that it work a certain way. For example, you would not indicate what variables to use and how to use them to simulate a law of physics; however, you might want to indicate the factors involved in the physics equation. Similarly, telling a programmer how to define his data structures and objects is a bad idea, but proposing the interface for data entry and the delineation of data is certainly within the confines of function.

The functional specification can be broken down into a few major sections:

•Game Mechanics

•User Interface

•Art and Video

•Sound and Music

•Story (if applicable)

•Level Requirements

Game Mechanics

The game mechanics describe the game play in detailed terms, starting with the vision of the core game play, followed by the game flow, which traces the player activity in a typical game. The rest is all the infinite details.

Core Game Play: In a few paragraphs describe the essence of the game. These few words are the seeds from which the design should grow. Planted in the fertile soil of a known market, they should establish roots that anchor the vision firmly in place and help ensure a successful game. This is similar to the description section in the game concept, except that it’s non-narrative, and usually expressed clearest in bullet points, though this could vary depending on the type of game.

Game Flow: Trace the typical flow of game play with a detailed description of player activity, paying close attention to the progression of challenge and entertainment. If the core game play is the root of a tree, the game flow is the trunk and the branches. All activity should actualize and extend from the core game play. Be specific about what the player does, though try to use terms like “shoot”, “command”, “select” and “move” rather than “click”, “press” and “drag”. This keeps the description distinct from how the actual GUI will work, which is likely to change. Refer readers to specific pages in
the User Interface section when you first mention a GUI element such as a screen or window or command bar.

Characters / Units (if applicable): These are the actors in the game controlled by the players or the AI. This should include a brief description and any applicable statistics. Statistics should be on a rating scale i.e. A to Z or Low to High, so that it’s clear where units stand in relation to each other in broad terms. It’s a waste of time plugging in the actual numbers until the programmers have written the technical specification and created an environment for you to experiment with the numbers. Special talents or abilities beyond the statistics should be listed and briefly described, but if they are complex, they should be expanded upon in the game play Elements section.

Game Play Elements: This is a functional description of all elements that the player (or characters/units) can engage, acquire or otherwise interactive with. These are such things as weapons, buildings, switches, elevators, traps, items, spells, power-ups, and special talents. Write a paragraph at the start of each category describing how these elements are introduced and interacted with.

Game Physics and Statistics: Break out how the physics of the game should function, i.e. movement, collision, combat etc., separating each into subsections. Describe the look and feel and how they might vary based on statistics assignable to the characters, units and game play elements. Indicate the statistics required to make them work. Get feedback from the programmers as you write this, as how the game handles the physics and the quantity of the statistics will
severely impact performance issues.

This can get a little dry, but avoid getting too technical. Avoid using actual numbers or programming terms. These will come later in the technical specification, written by the programmers who will want to do things their way (usually the right way). Just tell them what you want to accomplish. For example: “The units should slow down when going up hill and speed up when going down, unless they are a hover or flying vehicle. How much they are affected should be a factor of their climbing and acceleration statistic as well as the angle of the incline.” You would not tell the programmers what math to use to adjust the speed. Assuming you are not a programmer yourself, they’re just better at that than you.

Artificial Intelligence (if applicable): Describe the desired behavior and accessibility of the AI in the game. This includes movement (path finding), reactions and triggers, target selection and other combat decisions such as range and positioning, and interaction with game play elements. Describe the avenue through which the AI should be controlled by the level designers, i.e. using .INI files, #include files of game stats or C-code, proprietary AI scripts, etc.

Multiplayer (if applicable): Indicate the methods of multi-player play (i.e. head-to-head, cooperative vs. AI, teams, every man for himself, hotseat) and how many players it will support on the various networking methods. Describe how multi-player differs from solo-play in game flow, characters/units, game play elements and AI.

User Interface

The interface changes so very often that it almost seems pointless to document it; however, it’s got to start somewhere. It’s structured here to minimize the impact of changes. It’s starts with a flowchart of the screen and window navigation, then breaks down the functional requirements of all the screens and windows. That done, the GUI artist is free to do what he or she feels is right as long as it meets the requirements. To get him or her started you should provide mock-ups. This often is to the designer’s benefit to think everything through. Then follow up with a description of all the GUI objects that need to be programmed to make all the screens work.

Flowchart: This charts the navigation through the various screens and windows. Use VISIO or similar flowcharting tool to connect labeled and numbered boxes together, representing screens, windows, menus, etc. On the corner of each sheet, put a numbered list of all the items for easy referencing and ease of defining tasks for the programmers.

Functional Requirements: This functional breakdown of every screen, window and menu lists the user actions and the desired results and may include diagrams and mock-ups. While the specific interaction (buttons, hotspots, clicks, drags and resulting animations) can be listed, it’s often best to keep this separate from the list of functional requirements as these can evolve during implementation. Of course if it’s just easier to think in terms of clicking a button or it’s really important that something work a certain way, then by all means get specific about the method of interaction.

Mockups: Create a mock-up for all the screens, windows and menus. This may end up getting ignored, but it’s a good starting point for the artists if they have no idea what else they may want to do. Don’t waste your time creating anything really pretty. Just create simple line drawings with text labels. Color can be very distracting if it’s bad, but if it’s important, go ahead. Some drawing programs have templates that make creating mock-ups very quick and easy.

GUI Objects: These are the basic building blocks used to create all the screens, windows and menus. This should not include the items seen in the main view portal, as these are covered in the art list in the next section. The GUI objects are primarily listed here for the programmers to know what pieces they’ll need to code and have for putting together the screens. You should explain in detail how each is interacted with and how they behave. It may seem a bit obvious and not worth documenting, but it really helps when drafting together the technical spec and schedule to know exactly everything the game will need.

For some games, this can be a very quick list to put together – buttons, icons, pointers, sliders, HUD displays etc. But it’s much more complicated in games where the interface is at all different. However, keep in mind that the methods of interaction are not all that different. A button is still a button, even if it’s clicking on a gorgon’s head instead of a gray rectangle.

Art and Video

This should be the definitive list for all the art and video in the game. We all know how things creep up, though, so add a couple of placeholder references for art to be named later, like mission specific art and art for marketing materials, demos, web pages, manual and packaging.

Overall Goals: This is where you should spell out the motifs, characteristics, style, mood, colors etc. that make up the goals for the art. Gather consensus with the lead artists and art director and make sure they see eye to eye with the project’s director or producer. Doing so now will save a lot of time later if they end up redoing everything because the goals were never clearly defined.

2D Art & Animation: This is really just a huge list that can be thrown into the art schedule. It can also include descriptions if needed. Some art isn’t self-explanatory, and other may involve specific needs from a design standpoint. Be sure to explain it all. Break your art down into sections. The lead artist may have some particular way he or she would like you to do that. I’ll list the typical section and their contents. Read them all to be sure you don ’t forget anything.

GUI: Screens, windows, pointers, markers, icons, buttons, menus, shell etc.

Marketing and Packaging Art: You might as well list it here and the schedule, because they’ll ask for it. This includes web page art, sell sheet design, demo splash screens, magazine adds, press art, the box and manual.

Terrain: Environment art like tiles, textures, terrain objects, backgrounds

Game Play Elements: Player and enemy animations (sprites or models), game play structures and interactive objects, weapons, power-ups, etc. Don’t forget damage states.

Special Effects: Salvo, explosions, sparks, footprints, blood spots, debris, wreckage

3D Art & Animation: This serves the same purpose and has the same requirement of the 2D Art list above. The difference may be in how the work may be divided. Art teams like to divide 3D art task lists into models, textures, animations and special effects, as they usually divide the tasks this way to maximize talent and skill and maintain consistency.

Cinematics: These are the 2D or 3D scenes often shown as an intro, between missions, and at the end of the game. These should be scripted like a film script as separate documents. This, however, is production work. For the purposes of the functional spec, just list them here with the general purpose, content and target length. If any video is involved, list it in the following subsection.

Video: Unless you are doing an FMV (full motion video) game, this subsection is pretty light. If you have any video in your GUI for say pilot messages, break it down here. All video tasks will require scripting, but that is production work. List the general purpose, expected length, and general content like number of actors and set design, even if it ends up being blue-screened into a 3D rendered background.

Sound and Music

Overall Goals: Stress the aesthetic and technical goals for the sound and music. Describe the themes or moods you want. Name existing games or films as examples to aspire to. Issue technical edicts and editing objectives, such as sampling rates, disk space, music formats, and transition methods.

Sound FX: List all the sound FX required in the game and where they will be used. Include the intended filenames, but be sure to consult with the sound programmer and sound technician (or composer) on the file naming convention. This makes it easier for people to find the sound FX and fold them into the game.Don’t forget about all the areas that sound FX may be used. You don’t want to overlook anything and throw off the schedule. Go through all the game elements and your art lists to see if there should be some sound associated with them. Here are some to consider:

•GUI: Button clicks, window opening, command acknowledgments

•Special Effects: Weapons fire, explosions, radar beeping

•Units/Characters: Voice recordings, radio chatter, stomping, collisions

•Game Play Elements: Pick-up jingle, alerts, ambient sounds

•Terrain (Environment): Birds, jungle sounds, crickets, creaks

•Motion: Wind, footfalls, creaking floors, wading, puddle stepping

Music: List all the music required in the game and where it will be used. Describe the mood and other subtleties. Music will often reuse the same themes and melodies. Mention where these themes

should be reused. Consult the composer on this.

•Event Jingles: Success/failure/death/victory/discovery etc.

•Shell Screen: Mood setting for title screens, credits, end game

•Level Theme: Level specific music (designers choose the theme)

•Situations: Sets the mood for situations (lurking danger, combat, discovery)

•Cinematic Soundtracks

Story (if applicable)

Write the synopsis of the story told by the game. Include the back-story and detailed character descriptions if it helps. Indicate the game text and dialogue requirements so they can be added to the schedule. Some game designs focus so much on this that they overlook everything else that should be in the spec. Telling a story is not the focus of most games. Of course, if you are doing an adventure game, it is extremely important. Expand and organize this section as is necessary to tell the story.

Level Requirements

Level Diagram: Whether this is a linear campaign, a branching mission tree, or a world-hopping free-for-all, this diagram should be the backbone upon which all the levels are built. A diagram isn’t necessary if the structure is so simple that a list would suffice. The following is an example of a typical success/fail branching mission tree. Of course this will vary greatly for each game.

The important thing is that it just presents a road map for the level designers and for the readers.

Asset Revelation Schedule: This should be a table or spreadsheet of what level the game’s assets are to be revealed to the player for the first time. There should be a row for each level and a column for each general type of asset. Assets include power-ups, weapons, enemy types, tricks, traps, objective types, challenges, buildings and all the other game play elements. The asset revelation schedule ensures that assets, the things that keep the players looking forward to the next level, are properly spaced and not over or under used.

If it’s important to the game that certain assets stop being used, then the schedule might be better drawn as a Gannt chart with lines indicating the availability of assets. This gives the level designers a guide to what assets they have to work with so they don’t ruin their level or anyone else’s.

Level Design Seeds: These are the seeds for the detailed paper designs to follow. Detailed paper designs at this point are less legitimate and unlikely to survive intact. Designs created after the designers have had time to experiment with the tools and develop the first playable level are much more likely to succeed. It’s best to just plant the seeds for each level with a description of the goals and game play and where it ties into the story (if applicable). A thumbnail sketch is optional, but very helpful if the designer already has a clear idea of what he or she wants. Be sure to list any specific requirements for the level, such as terrain, objectives, the revelation of new assets, and target difficulty level.

Common Mistakes

Here are some common mistakes to look out for:

•Insufficient details: The descriptions need to be specific enough to convey intent and function. Avoid using vague terms unless you follow up with
specifics.

•Patronizing material: You wouldn’t give a chef a recipe that told him how to make a marinara sauce, so you don’t tell artists how to manage their 256
color palette or programmers how to define a particular data structure. Just list the facts important to the vision. Not only does it waste their time (and annoy them), but it wastes the writers’ time. Such details are more appropriate for the technical specification anyway, which is written by the programmers.

•Ambiguous or contradictory material: Watch for this. It clouds the vision, creates misunderstandings, and invalidates the functional specification.•The Design Document from Hell: Nothing stupid, nothing ambiguous, nothing lacking – it just is too damn much. Try to keep a mental total of how long the design is going to take to implement when fleshing out the specification. Cut extraneous, non-essential features and save them for the sequel; or be prepared to argue the merits of keeping the features and extending the ship date.

•Getting too personal with the design: You are not your work. Your personal boundaries should not include the design. As I have stressed throughout this document, game design is a collaborative process. While you want people to take ownership and responsibility for their work, the functional specification should have joint ownership. This keeps people from feeling isolated and more a part of the process, and it makes the documents feel less like marching orders and more like a plan. The team members are also much more likely to read something that they helped put together. Criticism is then aimed at the design not the documentors who put is all together; thus making the team more comfortable and productive in offering their criticism.

•Wandering vision: This may happen as you write the functional spec. Even with a good concept document and proposal championing the vision, there’s still some room for interpretation. Creative folks have a wandering imagination and may be influenced strongly by whatever game they may be playing at the momentWhile the functional specification explains what is going into the product, the technical specification explains how. The technical specification (or tech spec) is a working blueprint for the game.

It turns conjecture into reality by forcing the programmers to think through how the game will be implemented, by reducing implementation/integration headaches, and by delineating the program areas and tasks for the schedule.

Many companies will skip this step, as it is time consuming and seemingly benefits only the programmers. However, time spent working on a tech spec is less than the time lost from pitfalls that come with not writing one. The primary author is the lead programmer or technical director, though it is often more timely and useful if the programmers responsible for implementing the various program areas be responsible for documenting them. In its compiled form, it should present a plan that any programmer can understand and work from.

The target audience is the lead programmer on the project and the technical director of the company. Therefore it will generally be written from the system perspective as opposed to the user perspective. It will be boring and Greek to the producer and any other non-technical readers. By asking for one, the producer is just making sure the technical staff thinks everything through, even if he or she doesn’t understand it. To the lead programmer, it’s a way of organizing his or her thoughts and creating an accurate picture of the work involved. The process of writing it will flag any of the ncertainties on the programming side and any of the holes, ambiguities or absurdities in the functional spec.

Many good technical specifications vary from the form described here. This form mirrors the functional specification to ensure that all areas of the functional specification are covered. Sometimes it’s easier for a team writing this spec to organize it differently, if only because they are splitting the work differently or because of the organization of the underlying system. If they do, I’d recommend going through every line of the functional specification and do a correlation with a highlighter to make sure nothing has been overlooked. An overlooked detail can lead to undesirable results in the product,
project and team dynamic.

These guidelines will not tell you how to implement your game. It’s assumed that you are a technically competent, experienced game programmer. An inexperienced or untrained game programmer should not attempt this task. These guidelines are the result of what I’ve come to expect in a good technical specification, though I certainly couldn’t tell you how to program your game. These guidelines force you to define the most common elements one finds in all
games. Some may not be applicable, but each should be considered carefully. It may spark a question you haven’t asked yourself yet; which is sort of the whole point of writing this spec.

Game Mechanics

This is certainly the bulk of the document. Right away you’ll see that any attempt to match up specific subsections with the game mechanics section of the functional spec is totally ludicrous. The perspective must be from the system out as opposed to the designers’ or users’ perspective. This starts with the hardware platform and the operating system, the use of externally provided code objects (DLLs, EXEs, drivers), and the delineation of internally generated code objects (if any). Then it breaks down the specific mechanics of game code stemming from the control loop.

Platform and OS: Indicate the hardware platform and the operating system and the versions supported. For PC/Mac games, mention the minimum system requirements and the target machine. If distributed on something other than a CD like a cartridge, indicate the target ROM.

External Code: Describe the source and purpose of all the code used but not developed by the project team. This includes OS code and preprocessing tools of the various game platforms, drivers and code libraries like DirectX, any acquired 3D API, or any other off-the-shelf solution.

Code Objects: Break down the purpose and scope of the various code objects coded, compiled and built into the EXE. If any out-of-process or in-process code libraries (DLLs) are used, break them down as well, but be sure to explain the use of object instancing and their persistence (like Direct Draw objects).

Control Loop: Every game has one. Be specific about how control is transferred from the start-up code to the shell and down into the main game code. Spell out the names of the functions in the core loop and what they will do, like the collision, movement and rendering routines. Explain the use of multi- threading, drivers, DLLs and memory management. Of course further details on the likes of multi-threading and memory management will be covered in the areas
that they will be used most, like the rendering or sprite engine, sound code and AI.

This subsection summarizes the system and underlying framework that supports the core game play and game flow described in the functional specification.

Game Object Data: Read carefully over the functional spec at all the character/unit descriptions and game play elements. Then list and formulate all the data structures and their identifiers that are required to support the described attributes, functions and behaviors. To a certain extent, these will not be complete until the game physics and statistics and AI subsections are completely thought through and documented. Add statistics for user interface or any other area of the game that have unit or game play object specific data (i.e. icons, HUD displays, animation or special effect references, etc.).

If using object oriented programming methods, show the class inheritance tree and each class’ interface properties and functions. Describe the use of collections. Identify any variables that could possibly be made into global variables to increase performance, such as any objects variables that may be referenced multiple times during critical game routines such as collision, movement or rendering. Again, I’m not telling you how to program your game. I’m just trying to get you thinking about common technical issues, specifically in regard to optimizing data structures for neatness, versatility or speed.

Data Flow: Explain how data is stored, loaded, transferred, processed, saved and restored. While references should be made to data entry or processing tools, separate functional and technical specifications should be made for any complex or user intensive tools.

Game Physics and Statistics: This is the nitty gritty – movement, collision, combat – and probably the most fun to document and implement. However, it can also be the code that gets altered more than any other part of the program. Designers like to change things. It’s often only after they can play it for a while before they can really decide what is right. For this reason, you should plan to implement things as modular and flexible as possible. Put all the factors that control behavior into data files read at run-time, so the designers can change and balance things at their leisure without involving coding changes and new builds. The specification should clearly identify the modularity and divisions between code and the data that controls it.

Define each function or procedure. Describe its purpose. Define what statistics control its behavior (constants, variables etc.) and how they can be modified. Include the function prototype listing all the parameters. If using function pointers and function overloading, specify where the different versions of the function will be used. For example, you may have multiple functions that handle movement for the various unit types – one for land movement, one for air, one for water, etc. Briefly describe how the function will work. For complex functions, use pseudo code to specify exactly how you will code it. This is especially important for CPU intensive functions that do a lot of number crunching or are just called very often. Think about how they can be optimized to increase performance. Perhaps bit-shiting or macros could speed things up.

Artificial Intelligence: This often grows to a major section unto itself and is then scaled back when the schedule dictates the necessity to keep it simple. This shows a growing enthusiasm for complex AI, but a lack of time and resources to make AI anything more than simulated intelligence or scripted behaviors. Be mindful of this when you design the AI scheme. Try to accomplish the behaviors and decision making described in the functional specification without
adding a huge layer of unnoticed and therefore unappreciated realism to the process. The basic rule of production applies here. If something that costs less and takes less time to build does the job, then don’t spend more time and money creating something else.

Of course, there are exceptions that should be mentioned. Sometimes something might take longer to build, but it saves the designers a lot of time working on their levels. Also, creating something more flexible or powerful may make it a valuable asset to the company for other projects or just make it more capable of handling design changes should they occur. Discuss these with your producer and director of development before making a decision.

Be sure to include the methods of manipulating the AI as dictated by the functional spec, i.e. whether it’s data driven or embedded into compiled code, and whether it’s a scripted language or a fixed set of variables or a combination of both.

AI should include path finding, target selection, tests and events to attach reactionary behaviors to, and other decisions made by characters, units or intelligent game elements involving game situations and unit statistics.

DO NOT include the actual scripts or data driving the AI. That’s production work. Merely be specific enough to explain how the decisions and behaviors will be derived. Break down the statistics used to control the behavior.

Multiplayer: It’s extremely important that the implementation plan is reviewed from a multiplayer perspective. This subsection should break down all the multiplayer considerations in game mechanics and all the multiplayer specific requirements specified in the functional spec.

Multiplayer over multiple PCs (as opposed to console sharing or hotseat) has a lot of unique requirements that should be addressed. What connection methods and protocols are supported? Is it client-server or peer-to-peer? What are the packet sizes and how often are they sent? What is the structure of the packet? How are missed packets and latency issues handled? What messages are broadcast and what are sent to specific hosts? How many different messages are there and when are they used?

User Interface

Look and feel is one area of the design that undergoes the most changes during development. Therefore, its necessary that the programming for the GUI be as flexible as possible, separating game purpose from GUI function, so that changes that occur to the user interaction methods will not affect other areas of the game or require significant reprogramming. Create a variety of GUI objects (controls) using inheritance to maintain a consistent code interface to the events and the values. This way a slider bar can be exchanged with a text box or radial buttons with little or no changes to the calling functions. Assume that any of the GUI objects can be exchanged at any point in the project.

To this end, your documentation should be flexible and generic. While it should break down the GUI into the screens, windows and menus, it should not go any further into the specific interaction.

Instead, document how the various GUI objects will work, wherever they are used.

Make references to functions in the game mechanics documented in the previous section, but anything that’s interface related should go here. Explanation of the drawing and clipping routines of the graphics engine should be left for the Art and Video section, but certainly they should be referenced here in terms of view ports and HUD attachments and anything the player can interact with.

Document the names for any of the global variables, constants, macros, function names or interface properties, so that other programmers can refer to the documentation without having to dig through code. This also avoids replication and inconsistency and increases clarity.

Game Shell: List all the screens that make up the game shell – all the screens and windows other than the main play screens. These are derived from the flowchart in the functional specification, but may include some additional screens that the lead designer may have overlooked or brushed over (like installation or setup screens). Each item listed should be its own subsection with a description of its purpose, its scope (i.e. before or after level specific data is loaded), the pertinent values it will be accessing and setting, and what functions it will call.

Main Play Screen(s): These are the one or more screens in which the core of the game is played. Though many people think from the GUI perspective down to the complexities of what’s under the hood, this should be written from the low-level mechanics perspective (the engine and rotors) out to the GUI (the hood and the dash). This keeps it consistent even if the outward appearance of the GUI should change.

Art and Video

While this section in the functional spec pretty much just listed the art and video, the technical spec has to explain how the art and video will be stored, loaded, processed and displayed in the game. This includes the animation system, whether it’s 2D or 3D, and the video decompression and streaming system. Of course some of these might be off the shelf solutions, especially the video code. But all the interfacing should be mentioned here.

Graphics Engine: Whether you are using sprites, voxels or 3D-polygon rendering or a combination, break down their functions in very specific detail. While it ’s only 2 sentences of description here, it will likely prove to be a very meaty piece of the spec. Describe areas like view ports, clipping, special effects, and the connection to the collision and movement functions described in the game mechanics.

Artist Instructions: Break out the details important to the artists, like resolutions, bit depth, palettes, file formats, compression, configuration file definitions and any other data the artists need to define to fold in the art. Consider what tools can be created to streamline the art pipeline, and indicate their specifications here or create separate specifications for the more complex or user intensive tools.

Sound and Music

Describe how sound will be loaded and played. Be specific about the use of mixing, DMA, multiple channels, 3D sound, and methods of determining priority. If using third party drivers, describe their interface and purpose. Be sure to address all of the requirements specified in the functional spec.

Sound Engineering Instructions: Break out the details important to the sound engineers and composers, like sample rates, the use of multiple channels, 3D sound definitions, sample length etc. If using MIDI, indicate the version to use and the number and type of instruments that can be used and possibly stored. Indicate the data path and file requirements including any specific configuration files that need to be created. Consider what tools can be created to streamline the sound pipeline, and indicate their specifications here or create separate specifications for the more complex or user intensive tools.

Level Specific Code

Based on the level design seeds in the functional specification, describe how code specific to those levels will be implemented and how it will accomplish the desired effect. Also describe how any other level specific code can be interfaced to the game code should the need arise to add more. In general, you should try to make any of the level specific code as generic and as flexible as possible so that it may be freely used to accommodate similar needs for other
levels or new ideas.

Common Mistakes

Here are some common mistakes to look out for:

•Hand waving: It’s very tempting to just list the functions and not fill in all the details that force you to really plan how you are going to implement them. Sometimes they are just glossed over, but really the hand waving should end with the functional spec. This spec is supposed to force the programmers to really think everything through ahead of time. How else are they going to estimate the task time correctly?

•While it can be very effective to assign portions of the technical spec to the individual programmers responsible for implementing it, it’s not always in the best interest of the game or indeed the programmer to do so without some supervision. An entry-level programmer should get some guidance, and all the programmers should discuss and critique their documentation before it gets all folded together. Some companies have regular code reviews where programmers
critique each other’s work. That should start even sooner during the design phase.

Guidelines for Paper Level Designs

The designers should do paper versions of level designs before they begin creating the levels in the editor. Ideally, the designers will be familiar with the design palette, the level editor and game engine capabilities before they get started. Paper level designs are creating during the implementation phase, though they are based off of level design seeds expressed in the functional specification. These seeds are the core idea for the level and/or the basic requirements that may indicate what new assets are being introduced or what to limit the design to. It’s best not to do all of the paper designs at once, either, as the designers usually learn a lot while implementing each new level.

For some reason, producers often expect the cart to come before the horse, so before serious level design begins, push for a playable, prototype level to be created first. It’s often a milestone unto itself that ensures that the tools and game mechanics are working well enough to develop levels. It should also serve as a guide to what can be accomplished with the editor and engine and epitomize the vision for level design.

Following the first playable mission, level design can start in earnest. Yet even here, documentation plays an important role in saving time and ensuring quality through meticulous planning and the critical process. The process of level design that works:

Step 1: Thumbnail & Discussion

The level designer conceives of a level layout that meets the requirements laid out in the functional specification and asset revelation schedule. He or she then produces a thumbnail sketch and discusses the concept with the lead designer. The thumbnail could be on a white board or a note pad. It is a visual aid in the discussion. It does not need to convey the entire idea or all the details for the level, as these often evolve during the discussion or get tossed out altogether.

The benefit of doing a thumbnail sketch and discussion rather than forcing a designer to first think everything through and document it is that it saves time. A senior or lead designer can in a matter of minutes determine whether a proposed level design has merit and give valuable advice that can drastically alter the design. A fully detailed and documented paper version can take days or even a week to put together. Depending on the skill of the designer, a designer might get sent back to the drawing board many times. This is especially true near the beginning of the project, when the designer is still learning what the lead designer wants, and near the end of the project, when original, compelling level concepts are harder to come by.

Step 2: Detailed Paper Version

With an approved thumbnail and level concept, the level designer can work on a detailed paper version of the level design. The layout (or map) of the level should be much more detailed than the sketch and should be drawn to scale. This is best done on a large sheet of graph paper using colored pencils. Information about objectives, behaviors, buildings, enemies, events, locations etc. should either appear on the map or on a separate document with reference points on the map. Any mission specific art or code should also be listed. This amount of detail can take a few days or as long as a week to draw and document, but it saves a lot of time that would otherwise be spent “searching” or “redesigning” in the actual editor.

When completed, the lead designer, producer and any other principal decision-makers should subject the paper design to an approval process. They may approve it, throw in some changes, or kill the level right then and there.

It’s also important that someone technical, preferably a senior programmer, review the paper design from a technical standpoint. This gives the programmers a heads up on what the level designers are going to attempt to do with the tools and graphics engine. They might add some features to the tools or make some code adjustments to make the level possible or just easier to implement. They may also vote to eliminate or alter any level designs that may break the game
or are similarly unfeasible.

It’s often very tempting to skip this step and jump right into the editor as it’s often faster to just build a prototype of the level than to write up the paper version. This is especially tempting in tight schedule situations. Yet, it’s these tight schedules that make documentation that much more important, because it means there’s even more reason to get it right the first time and reduce the number of surprises and time to redo the work. The benefit of a detailed paper version is that it forces a designer to think everything through and express the fun and challenges before he or she implements it. It also ensures that the details that may involve more tasks for programmers, artists and sound technicians get documented and scheduled for completion before the designer begins working on the level.

This article is focused on documentation, but for completeness to this section and to this process, here are the remaining steps to level design as I see them:

Step 3: Creating the Core of the Level

The designers should establish the core game play of the level using broad strokes. They should get it to the point that it gives them the fun and challenge they envisioned in the paper design. The designer should then get feedback from the lead designer and producer, who will determine whether the level has merit or not. It may indeed prove impossible to accomplish what the paper design suggested, or it may prove to not be as fun as was expected. This is simply a review point in the level design that saves the designer time should drastic changes need to be made or the level dropped entirely.

Step 4: Filling in the Finer Details

Once the core game play of the level is established, everything else should just make it better. These are all the things that establish the setting, flesh out the level, and liven up the fun by providing more options, solutions, or surprises.

Often new art or code assets may seem appropriate, so be sure the designers find out they can get them before putting placeholders in. Then update the paper design and task lists.

Step 5: Play Test

Have the designers play their levels and get as much feedback as possible. Again, documentation plays a role here. Be sure they keep track of all their bugs, feedback and tasks with at least a notebook and pencil. It’s very easy to lose track of issues at times (not to mention sheets of paper), so a centralized database with level specific issues and feedback is ideal.

For further guidelines for level design, I encourage you to read my articles on level design that present a background to level design and some rules to design by. The first part “Level Design Theory” can be found here. The second part “Rules to Design By and Parting Advice” is available here.

Documentation Milestones and the Development Schedule

Below is a list of the typical milestones in a schedule and where the documents described in this series serve as deliverable items. Following each milestone would be a review of that milestone, which would require approval to go on to the next. As the production schedule isn’t due until after the bulk of the documentation, then there shouldn’t be an impact on the schedule if time needs to be spent going back to the drawing board and creating specifications that everyone can agree with. It’s a recipe for disaster to race into production with iffy design documents just because of the urgency to meet an arbitrary ship date. In the end, it usually doesn’t save you any time, and in fact often leads to wasted efforts and significant delays.

Conceptual Phase

•Document: Game Concept

•Document: Game Proposal

Design Phase

•Document: Functional Specification

•Document: Technical Specification

•Documents: Tool Specifications (if applicable)

Production Phase (sometimes called Implementation Phase)

•Production Schedule

•Technology and Art Demo

•First Playable Level

•Documents: Paper Level Designs (not always a deliverable)

•Alpha – Functionally Complete

Testing Phase (Quality Assurance)

•Beta – First Potential Code Release

•Gold Master – Code Release

There could be more milestones, as it’s often necessary for publishers to have some means of determining and ensuring that progress is being made. Sometimes there are arbitrary monthly milestones for particular art, code, and design. The ones suggested here are the most common and have the greatest significance.

Dealing with Change

It can be a beautiful thing to witness a project run smoothly following these guidelines, but what typically happens is some change to the vision due to inspiration or market trends. It’s very easy to slip into design-on-the-fly mode to try to adapt to the new vision without impacting the schedule. Of course it inevitably does anyway, because design-on-the-fly has its dangers. In these cases, the only way to make sure this doesn’t happen is to be adamant about the guidelines and the procedures they promote. This is easier if it’s spelled out in the contract. Don’t make any changes to the game without it going through the documentation. A change to the functional specification potentially invalidates the technical specification and subsequent schedule. It’s certainly grounds for reassessing the schedule. It should be very clear to the principle designers who may want these changes that when they sign-off on the functional specification and deliver it, they do so with no expectations on being able to make changes. Then, if they really want the change, the impact can be lessened with a period of updating the documentation and a reassessment of the schedule. The threat of being stuck with what you got or being late is certainly compunction enough to put as much forethought as possible into the design and produce the best possible documentation. The guidelines presented in this series of articles should help you do just that.

For more details on how to deal with change, I encourage you to read my article “Controlling Chaos in the Development Process” published here.

This concludes part 2 of a 2 part series of articles on the anatomy of a design document.

篇目2，Creating A Great Design Document

by Tzvi Freeman

I’ve got to get product out. In the panic and dizziness, my head smashes against the CRT and next thing I know this genie whiffs up out of a virtual bronze-texture-mapped lamp and offers me three wishes. Without missing a beat, I answer, “I need…

A great team of talented, skilled, and dedicated engineers and artists (including a very understanding wife) with strong interpersonal skills.

Enough time and money to allow for a mess-up or two.

A first class design document.

Once upon a time, when coding a game involved one programmer (and maybe an artist) with a take-it-as-you-go budget and a loose deadline, documentation didn’t need to be taken so seriously. You knew what you wanted to make and you made it. If there were a few major changes along the way, the only one to complain was you. Nowadays, a thorough and readable document can mean the difference between a swift descent to budgetless Hell and a smooth ride to shrinked-wrapped Nirvana.

How the System Works

Most games go through three development stages, from concept to design to production. Think of them as “flash,” “paper,” and “grind.”

In the first stage, the concept paper acts both as a letter to yourself – setting out your goals clearly so you won’t lose sight of them – and as a sales tool for whomever takes the product to market down the road. Sometimes, this stage involves a working mini-prototype as well, which gives you a chance to experiment and revise your ideas.

The intermediate stage of design involves a lot of discussions with artists, animators, musicians, and engineers – trying things out, and finding ways to organize and set down your ideas.

In the final stage, production management is often left up to some expert in moving trains and tracks without major collisions. The original designer may be an integral part of the team, but in many cases – especially in large companies – the designer ends up as a kind of outside consultant.

Without question, the design document is where the original parent of the project exercises the most influence on how this little baby is going to grow up. Even if you, the designer, have decided to double as project manager, don’t delude yourself into thinking that you hold all the reins. A complex project involves many talented people. Skilled programmers and artists tend to have minds of their own. While you intend to create a horse, the artist may be envisioning a unicorn and the programmer a highly efficient camel. A good document ensures that you are all planning to make the same thing. A great document ensures you all have the same feel for the inner soul of this thing. Think of it as a big band jazz score – it puts everybody’s mind in the same place, even when there’s still plenty of room for the stars to improvise.

Your document is a sort of intermediary between your mind and the real world. It ensures that what you have in mind is something that the real world is able to handle, and that what you end up with will be what you originally had in mind.

Finally, remember the adage to which any salty gamer will attest: “Great art is in the details.” Brilliant details flow naturally from the general gestalt as though they were present in that first flash of inspiration. But once you get into the hands-on implementation, it’s easy to lose that spark.

The Challenge

Prototyping parts of the project yourself is definitely a good idea – make whatever rough sketches you can. But again, it’s those details that count. The more details your imagination can hold, the greater a masterpiece your work will be.

Working from a document has a flip side, as well. Developing an exciting game has to be exciting. Some of the best parts of many projects were discovered in the heat of last-minute deadline panic. True, the pressures of time and cost budgeting don’t allow for perpetual reiteration of concept, but you simply cannot expect a killer game to come out of dry, predictable work. The challenge is to create a design document that will allow your project to tolerate surprise adaptations without losing the integrity of its original direction and scope.

Table 1. The three stages of documentation.

Contents Purpose

1. Concept Paper Genre; target audience; description; most compelling features; market information; cost and time to develop. It defines the concept, scope, worthiness and feasibility; sells the idea to your client, publisher, employer, and venture capitalist.

2. Design Document Description of the body and soul of the entire project, with all the details, and the method by which each element will be implemented. It ensures that what is produced is what you want to produce.

3. Production Documents Time-management charts (Gantt, PERT, and so on); task database; budget spreadsheet; technical specifications; Q/A database. It implements the design document on time and within budget.

Ten Points for a Successful Design Document

1. DESCRIBE NOT JUST THE BODY, BUT THE SOUL. If game development was just an automated input/output issue – something like writing code and being able to predict how it’s going to work – you could get by with a dry, descriptive document. The reality is that development is done by people, many of them creative people, who have their own minds; most will want to leave a stamp of that mind on everything they do.

It works like this: You provide specs to the artists and discuss with them what to do. You then visit the programmers and go over their specs. Both groups nod to everything you say.

That night, around 2AM, just as the constellation of C++ is rising in the west, the programmer reaches a mid-life crisis and begins to think, “What, a geek programmer the rest of my life? Is this what my mother expected from me? Why, I can design a game just as well as anybody else!” And the hands keep typing code.

Around the same time, the artist has just woken up before his machine, having fallen into a deep stupor while waiting for a complex 3D rendering to finish. Unsure and not really caring whether he’s dreaming or is actually getting paid for all this, immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways previously unimagined – certainly not by you.

By the next morning, your horse has become a unicorn with two humps. With creative people, instructing is not good enough. You need to inspire.

In your design document, don’t satisfy yourself with a detailed description of every article and nuance. Take time to describe the feel that the game should have, the purpose behind each element, the experience each user will have, and any other aspects of the game’s soul you can envision and describe.

For example, say you’re designing a shooter. You want to train your players to deal with certain challenges before they actually meet them, so you place less lethal mini-challenges a few steps in advance. You’re going to have to explain that to everybody on the development team, so they’ll understand why certain things are where they are and why they work the way they do. That way, even if (read: when) your team toys with and mangles your ideas as they exist on paper, you can still harbor hopes that the outcome will have the same or similar overall effect. Or maybe even better.

2. MAKE IT READABLE. Go ahead, provide your people with full pages of 10-point, sans serif, 80-characters-per-line text, and demand that they read it. You may want to bundle Advil in the package – for those who actually take the pains to obey orders.

I try to follow at least some of the guidelines of good page layout.

Plenty of white space

Serif font for body text

Bold headers

Spaces between paragraphs

Short lines of text

Direct the eye towards important material

Use a hierarchical, “2D” format (see what I wrote about outliners in the “Design Documentation Tools” sidebar)

Many instances call for a table, spreadsheet, or chart. Use them and make them sensibly attractive.

3. PRIORITIZE. Now that you realize that you’re working with other conscious egos, you’ll appreciate the urgency of tagging certain game elements as sacred. True, there are no guarantees, but if you use the tag sparsely enough, it may get some respect. But don’t stop there. As long as you’re tagging ideas, you’ll also want to distinguish between things that you intend to do and things that you’d like to do if time, budget, skill sets, and technicalities permit.

Then there’s the trash bin – things that sounded great, but were trashed for good reason. Refer to them explicitly and explain the reason that they were trashed. If you don’t, I can almost guarantee that they will be resurrected. Here’s your list of tags:

Indispensable

Important

If Possible

Rejected

You may wish to use visual symbols to represent these. Don’t rely on color, since documents aren’t always printed in color.

4. GET INTO THE DETAILS. A document without details is useless. Generalities can be interpreted by anybody in any way that they like. “Thou Shalt Not Kill” meant one thing to Moses and another to a Spanish conquistador. Detailing whom you shouldn’t kill and under which circumstances would have been more helpful. The same holds true for your document: Once you’ve described some practical details and given some examples, your idea becomes more concrete – and harder to shove around.

For example, don’t just say, “Bronze bird is invincible.” Describe exactly what happens to this creature in each possible instance of its being hit, and how it recovers afterward. True, if the animator has any spunk and artistic dignity, you can rest assured that he won’t follow your specifications. But at least he’ll have a clear idea of what you want to achieve, and his modifications won’t seriously alter the related portions of the game.

Don’t just say, “At this point, users will have to press the jump key with the arrow key to climb the wall.” Describe what will happen if a player tries anything else. Explain why you think users will be able to figure out the combination that you’ve provided. Explain what about the environment suggests that it’s possible to climb this wall.

Again, your artist will come up with something else, perhaps something even more suitable than what you originally conceived. That’s real success: When your developers’ results come out even closer to your original flash of conception than what you were able to describe on paper. But this won’t happen unless you first lucidly describe your concept.

Don’t just say, “Bongo Man is stronger than Bongo Boy, but Boy has faster reflexes.” Use tables, spreadsheets, and charts to assign real values to the character’s speed of movement, how many hits the character can take, how much damage the character’s hits do, how many cels it takes to animate a hit, and so on. This sort of spreadsheet is invaluable in the Q/A and tweaking stages of production.

Don’t just say, “Most people will figure out the whole game in a few days.” Make a chart of predicted product life in different households, indicating at which points in time you expect various features to be discovered. User testing will later provide valuable feedback for designing your next game.

5. SOME THINGS MUST BE DEMONSTRATED. Sometimes a few rough sketches are enough, but if the idea is truly important to your concept of the project, you may want to make a rough animation yourself. When behaviors of elements become too complex and ambiguous to describe on paper, you’ll want to make a prototype. A side benefit of prototyping is that this practice often leads to a simpler, more elegant solution.

Even when you provide animations and prototypes, put the concept in words as well. True, an animation is worth a gigabyte of words, but words can communicate in ways that animations can’t. Words also clearly spell out the vital nuances that may be missed when watching the animation.

6. NOT JUST “WHAT” BUT “HOW.” In the real world, the “how” determines the “what.” For example, suppose you’ve opted for claymation. Work out the process of how the images will be captured and document everything. What material and what color should the backdrop be? What camera should be used and why? What are the steps for processing the captured frames? And on and on. If you’ve tried it, you’ll know that any one of these factors can have a serious impact on the end result.

Or suppose you’re working on a motorcycle racing game. You state that the motorbikes must be balanced by their differing pros and cons. You even provide a chart that shows how balanced they are. Then you state that tweaking will be necessary. State how you plan to tweak – what is the process? Suppose the main character in your game is the Phantom of the Opera. Describe how the player’s keyboard is mapped as a pipe organ. Provide a map of each key. Specify how many channels of sound will be available. Talk it over with your programmer and work out every detail of how. Then document it. Two different “hows” can mean two very different results.

7. PROVIDE ALTERNATIVES. Project managers spend a lot of time with their Gantts and PERTs. Personally, I can’t really say that this stuff is effective for game development – principally because there are just so many unknowables. The more radical and pioneering your game technology, the less predictable the development stream is going to be. The best thing you can do to ensure that your team reaches your milestones on schedule is to provide more than one way of doing things.

Lets go back to the keyboard as pipe organ example. Your engineer describes to you the ultimate method of getting awesome and funky results with tremendous power and depth to the user – at a cost of about 50 person-hours to implement. As with everything else we’ve discussed, you document the whole thing.

You can’t stop there. You’ve got to ask, “What would it take if we just wanted a trimmed-down, eight-channel pipe-organ? And what will we need to achieve the bare minimum? And what if we just had some assistant doing this?” And then you document all that as well. When the FedEx truck is on its way over for the final daily pickup, you’ll be able to save your skin with a simple, “OK, do Plan C.”

One of the biggest mistakes I’ve made in product design is asking engineers, “Can it be done?” Unless you’re asking a first-class programmer, the question is useless. More specifically, responses fall into one of three categories:

(Lousy programmer) “Sure, that’s no problem.”

(Mediocre programmer) “Nope. Can’t be done.”

(First-class programmer) “I could do it like this and it’ll take two weeks. Or I could make a slight modification like this and it’ll take five hours.”

Always ask for more than one alternative and an estimate of how long each will take. Then indicate your preference – do this is if we have time, or this if we don’t.

8. GIVE IT A LIFE. I’ve already warned you against strangling the inspiration and spontaneous creativity that comes with the excitement and fun of seeing ideas become living objects in your hands. You’ve got to allow your document to tolerate change – by you or by (hopefully intelligent) others.

I first learned this lesson as a music composition major at the University of British Columbia. With much toil, I had written a neo-renaissance brass quintet of which I was quite proud. My professor liked it, too. When we brought it to the college’s star brass quintet for rehearsal, however, I passed through several stages of horror, disbelief, indignation, and clinical depression within ten seconds. The quintet began to play, then stopped on signal from the tuba player. The fellow took out his pencil and began to change a few notes, and then everyone continued. It happened more than once.

My professor, noting my sudden faint state of health, turned to me and commented, “Don’t worry, they did that to Mozart as well. And they’re usually right.”

The fact is, no matter how good something looks on paper, the greatest expert still modifies things when it enters the concrete world of objective perception. Nevertheless, you don’t want to witness the ruthless rape of your design and dreams. Rather, you’re hoping for a kind of organic growth – ideas growing naturally out of the seeds you’ve planted without needing foreign limbs and bodies grafted onto them.

Here are some tips for creating a document that can tolerate change without corrupting the original idea or sabotaging the development process:

Make certain to engrave in stone those aspects that are so essential to the game concept that they must not be changed.

Make certain everybody understands the feel that the game is supposed to have and the purpose of each of its details.

If information is repeated, it must be cross-referenced. Otherwise, if there are changes, you can end up with contradictory instructions.

And here are some tips for the actual implementation stage:

When a change is suggested, check back in your design document and see if it is in concordance with the “soul” of your game.

Check whether this is just an isolated change, or it’s of major global ecological impact (see “The Ecology of Improvement”). If it’s the latter, save it for your next project.

Update the design document and include the reasons for the change. Or if you didn’t make the change, say so and explain why it was rejected.

Changes, deletions, and rejected ideas should be retained in a master document to avoid discussing the same thing twice.

Everyone must be working from the same version. Past versions should be destroyed.

Crucial, Vital, and Urgent: The design document must be maintained under one person’s supervision only.

9. NOBODY SHOULD BE ABLE TO SAY, “I DID IT THAT WAY BECAUSE I COULDN’T FIND ANY REFERENCE TO IT IN THE DOCUMENT.” I’ve seen documents that didn’t even have the pages numbered. And then they complain that people didn’t follow instructions. Every good word processor will auto-number pages and print the date and title in the header or footer of every page. Some will even allow you to change the header at new chapters. Use bold text to direct attention to important material. Repeat yourself in different parts of the document as much as you like, as long as you cross-reference so you can update everything together as well. Make a thorough Table of Contents.

You may wish to write your document using HTML and provide hot links. Some progressive word processors provide hot link capabilities without HTML. But remember that more often than not, people prefer to work from a hard copy. (That way there’s something to read while rebooting after the hourly system crash.)

10. DELIVER IT IN GOOD CONDITION. After all this, you need to do whatever you can to facilitate everyone actually reading and using the thing. A pile of papers doesn’t get read – it doesn’t look important enough. Only things with hard covers look important.

Create a list of everyone who is supposed to have a copy. Keep the list. Print out the whole thing with the date in the header of each page. Have holes made and put it in binders. Label the spine and cover of each binder. When there are updates, provide everyone with the revised pages. At some points, you may need to provide new books and throw out the old ones.

In Sum Check…

Movie makers use move scripts. Architects use blueprints. Musicians use a score. According to ancient hearsay evidence, even the Cosmic Creator created a design document – which He later let a few prophets take a peek at – before the primal “Let there be light!” So game developers, following their Supernal Role Model, can certainly do the same. Do it right and it’s smooth sailing the rest of the way.

Tzvi Freeman teaches Game Design and Documentation at Digipen School of Computer Gaming in Vancouver, British Columbia, Canada. He has designed several commercial games and has acted as a consultant on many others. He can be reached at TzviF@aol.com.

篇目3，Effectively Organize Your Game’s Development With a Game Design Document

By Gamux

Have you ever dived right in to developing a game, but found yourself having to constantly change aspects of the design or the gameplay due to a lack of planning? You should consider using a game design document: a guiding vision of the game as a whole, pulling together ideas and plans for the design, development, and business sides of your game.
Introduction

To put it simply: we like to tell stories. Some true, some not so much. But the point is that we have been crafting tales for a very long time, and as time went by these tales began to evolve, becoming more complex, with richer details, with more and more fantastic backgrounds and appealing plots. Whole new worlds were born from thin air, hammered into shape in the anvils of the human brain.

And as the stories grew in complexity, so did the tools used in their making. Art diverged into several different categories, music became more elaborated and movies found their way into the world. Technological enhancements allowed sharing of information, spreading art all around the globe. New fantasy worlds were created each day. Worlds so rich made people began to desire becoming a part of them. A new concept was being brought to life.

Although video games were first just about getting the highest score possible when faced with a determined task, developers soon realized the endless possibilities laying ahead of them. Playing a video game is more than simply sitting through another story. For the first time one could have a say in how the tale told itself. Players could take hold of characters and live the hardships of the journey themselves, diving into that particular world and mastering it, making theirs the protagonist’s conquests and failures.

A game has the potential to bond player and story in a way never seen before. This connection can be established in a variety of ways. Be it the fantastic landscapes in which the story unravels, the soundtracks or the well-constructed personality of a particular character. It forces the player to thrive in order to see more of what he wants.

Unfortunately, since a game is composed of so many different elements, different experts from different areas are required in its creation, making the coordination of the development process a rather tricky job. In order to help developers do their job, a document known as a GDD, or Game Design Document, is often employed.

A GDD is a tool that helps merging the components of a game together. It registers the general ideas of every aspect of it, from graphics design to story line. In short it registers the game concept, creating the closer feeling of the finished product.

Although the writing of a GDD is not a vital part of the creation process, it is of major help to the team of developers, especially when in major projects, involving large amounts of personnel. Also, there is not only one way of writing a GDD. In fact, GDDs differ vastly among game development companies, but as a general rule, most games are built around these documents.

So without further ado, here is what you need to know about this important tool.

Overview

A Game Design Document must teach everyone who reads it how the game that you’re talking about works. In order to do this, you need to explain not just the mechanics, but also how the game’s objects (characters, enemies, puzzles, weapons, environment, and so on) interact with each other, what your game is about, and how it looks. In a GDD, these points are discussed in some general sections.

Marketing

Marketing is a big section subdivided in many subsections that explain the major commercial aspects of the game, like public target, deadlines, competitors and selling points. This section is very helpful for business, since it shows what your game has in advantage over others and how it meets the consumer demand. In others words, it shows the game’s appeal.

High Concept

Before you start to tell the reader how your game works, you must clarify the core concept of your game, i.e., you must talk about the major aspects of your game in a very short way, so that the reader can anticipate what will be said in the GDD and pay attention to what is important to the game. For this, there is the High Concept section, which explains all of it, so that the reader won’t have to read many pages of the document just to know what your game is about.

For example: if you tell the reader that your project is a futuristic space shooter game, he will be able to imagine what kind of weapons, movements, enemies and others things will be used in the game.

Gameplay

This section is one of the most important in the GDD, because it explains how to control the objects in the game and how to make them interact with the other parts. Also, it explains how the player will execute the possible moves. Moreover, it’s interesting to comment the way that the game flows and what happens during the course of the game.

First Minutes

This is a subsection of the Gameplay section, and it exposes what the player will see in the game when it has just finished loading. It exposes the actions and reactions between the game and the players during this interval, helping understand the game’s progress throughout the gameplay and give a better idea of how to play it. It’s also an important subsection, since it will determine whether or not the game is fun.

Gameflow

This is a more detailed subsection of the Gameplay than the First Minutes. It describes all the options that the player can choose while he is playing. It’s a kind of flowchart that shows which reaction each option has, giving a picture of the game as a whole. Generally it shows a flow of screens (e.g. from the “Main menu” screen it goes to the “Select level” screen), but you can also put actions and consequences in it (e.g. if the player chooses the “Mage” character, all the backgrounds will have a “magical” feeling). It literally explains the way that the game flows, as the name suggests.

Victory Conditions

You also need to teach the reader in the Victory Conditions subsection, what must be done to win, when the player loses and under which conditions this happens. In other words, this section explains the goals of the game.

Number of Players

It’s important to specify how many people can play, because this implies the type of multiplayer – where applicable – that the game will support; for example: split-screen, LAN connections, Internet connections. Note: this section has influence over the Victory Conditions, since the players will need to do different things to win in a competition than in a cooperative game.

Art

Once you explained how to play your game, it’s import to show how your game will look like and which kind of art is behind it, since it’ll influence how the elements of your game’s universe will coexist, mixing the emotions of who is playing. This is a crucial point in the game’s marketing, because it shows the appearance of the game and the feelings it will pass to the player.

Technical Aspects

Another section that must be put in a GDD is the Technical aspects, since it defines the physical game requirements needed to play and specifies on which platforms the game will be developed, which engines will be used, and more. This affects the Marketing, as the kind of hardware used affects both the fanbase and the public target, i.e., the people who consume the game.

Is There a Formula?

All things said, you need to keep in mind that even if some general subsections are common between the GDDs, there is no static form to make this kind of document, and no such thing as a perfect formula. Every game designer has his own way to do this and you must discover yours. This is a hard job, but in this article we’ll give some tips explaining how to create each subsection of the GDD – however, it’s up to you to decide which of them are necessary to design your game.

Always be clear and concise in your text and use a lot of images, because they give the reader a faster and more real view about the game’s final result and they also ease the explanation about puzzles (if your game has them) and how characters, environment, monsters, screens, weapons and other objects from the game will work.

Moreover, you can also find new topics to add in your GDD, as long as it’s necessary to the understanding of the game’s core. Some things that deserve attention are the innovations and the particularities of your game. For example, if your game project brings up a new way of playing, or a specific graphic concept or if it’s focused in music (like a music game), you should discuss it in the document, to convince everyone why this innovation is a good idea.

Guidelines

A good way to start your Game Design Document is with the Marketing section, because it will be the section that your investor or client is interested in, thus allowing them to gain interest in your game faster. In indie game development, it is not a common section due to the common lack of investors, however, if you think in other projects not related to commercial purposes, such as a free game on App Store of Apple to help a charity institution, it’s important to keep track of plans related to the marketing aspect, since it will be really important to have a publishing plan.

After this, it’s important to put the High Concept, so the reader immediately will understand the core of the game and pay attention in the major aspects. You will figure out that in GDDs it’s common to always start with a basic and summarized definition of the game, and go on to present every detail step-by-step.

In the next section you should write about the Gameplay, which should include, as sub-sections, the First Minutes, the Game Flow, the Victory Conditions and Number of Players.

After that, you need to show how your game will look, so talk about the Art, using as many images as you can. In the end, you can talk about the Specific Sections, which should bring topics that explain: the innovations, the aspects that not necessarily all games have, like story, artificial intelligence, characters and others particulars things.

All the things said above are represented in the flowchart bellow, but it’s just a general schema and you can (and should) adapt to your game. Remember: there isn’t a perfect formula. Now that you have a kind of skeleton of the GDD, you will find in the Composition topic of this tutorial a more detailed explanation about what which section of a GDD holds.

Composition

Although there isn’t such a thing as a perfect formula for composing your GDD sections, it’s important for you to include some crucial topics in it, as well as avoid some major mistakes. This section teaches you how to detail the sections presented in the Overview topic, while showing examples of how it’s done and some common mistakes.

The Marketing Section

There is no correct way of dealing with this subject, since your objectives for it will depend on your game. It’s also not really needed; you can either concatenate it all in a major subsection or spread it across the document, as some of the topics discussed here have much in common with others elsewhere. Despite the way you choose to do it, some topics should always be addressed:

Target Audience

Who will play it? This is no ordinary section, so don’t settle for a simple “for children” description, for example. There are endless ways to “classify” gamers, and you must explore this. Comment on how it will appeal to each category and try not to leave anyone out; they might share little in common with your product, but they still share something.

Right:

Turret Defense will appeal to male gamers of ages 15 – 25 who typically play FPS and RTS PC titles. In particular, fans of Sci-Fi themed games, movies, and books will be immediately attracted to Turret Defense’s space adventure setting and theme.

Turret Defense will have an ESRB rating of T (Teen) for ESRB Content Descriptor of Violence, suitable for ages 13 or older. To conform to the wishes of the publisher, Turret Defense will not use blood or any other content that would lead to further ESRB Content Descriptors related to violence.

Wrong:

Turret Defense will appeal to a large audience. Based on the experience of similar games, it should be a huge financial success in the video games market. We plan to advertise it heavily with ads on games-related websites with huge traffic.

(“A large audience” isn’t a valid fanbase, and it doesn’t explain why they would enjoy it. No mention of the ERSB rating or whether the game has any age-restricted material.)

Another good example:

OrBlitz is expected to receive an ESRB rating of Everyone. The main target market will be puzzle games fans, but the game’s many original aspects will attract a wider audience, including people that prefer to buy action-based games. Real time strategy games fans could also be interested in the game for its tweakability and other similarities with RTS games. Because of the lack of graphic violence and the intuitive interfaces, this game can target women as well as men. The game is relatively cute and colorful, and is expected to appeal to both American and Japanese audiences due to the content in it.

Notice all the classifications in the example: gender, age, nationality and genre. Keep in mind that many more categories may arise depending on your game. Predictions on the ESRB rating are also welcomed, therefore some restrictions regarding violence, sexual content and language should be addressed if needed.

Platform

Extremely straight-forward section. Just enumerate the platforms that your game is being designed for. An estimate of the system requirements are also a good call. If needed, you can comment on porting the game and the difficulties involved.

Competitors

This is a key subsection of your document. In here you must compare your game to others already developed. It is important to give a small description of the game being compared to, and point the similarities between both. This is an excellent opportunity to expand the comparisons that were already made across the GDD and give the reader a better picture of what the game will actually be.

At the end summarise your product’s strong points and convince the reader why would your product sell despite its competitors. This is the trickiest part, because you must pick good opponents, otherwise the reader just won’t know what you are talking about, and still keep your game’s image shining; therefore a good writing is crucial. Your ‘adversaries’ also help on the notion of how big your market can be.

Milestone Schedule

The Milestone Schedule subsection is where you must define each necessary steps in order to develop the game, which is basically a timeline of the intended completion of phases of your game. Through that, not only you, but also the investors, can have a very rough estimate of the interval of time needed to complete the project.

Other Subsections

You may choose to add some heavy market-related topics such as Costs Overview, that can comprehend equipment costs, people costs, additional costs and expected profit.

Future Plans

Sometimes there are so many ideas to complement a game that some of it must be put aside in order to meet the tight schedule of development. This section is specifically made to store those ideas, so that you can work on it later depending on how things work out. DLCs, possible sequels, minor improvements to gameplay, graphics and so on, all comes in here. You can also gather some ideas of what to do with the game once it is finished.

Example:

Add some side quests.

Enable the character to jump.

Make a movie telling your story as a developer.

The Introduction Section

The introduction section should provide the reader with a basic overview of the game itself, first with a light approach with the High Concept subsection and then with a broader one within the Summary subsection. You can also highlight the more innovative aspects of your game in a Key Features subsection.

High Concept

A one paragraph description of what your game is about. This should sound like the summary of a summary. Avoid any technical aspects, graphic or sound designs, complex gameplay features, or marketing details that aren’t strictly required (for example, if you’re making a rhythm game you should mention what kind of music style you will be using, whereas if your game is a puzzle you can just forget about music for now; it’s better to describe what type of puzzle the player will have to solve instead). The idea is to describe your game in the most non-technical and shortest way. A good tip is to use well-known games as examples for comparison, such as “X is a three-dimensional racing game with power-ups like Mario Kart”.

Right:

Scavenger Hunt is a three-dimensional arcade-style game where players race to collect items from a list before their opponents do.

Wrong:

Scavenger Hunt is a three-dimensional arcade game with puzzle elements set in a fictional neighborhood in the 50′s with cartoony graphics and music, where the player races to collect various home-related items from a given list in each stage, while using gags as powerups, before his opponents, which can be either CPU-controlled when in singleplayer mode or human-controlled players in multiplayer mode.

(Keep it short and simple)

Summary Overview

A more detailed description of your game, with less restrictions than the High Concept subsection. Start with the core aspects of the gameplay, describing what role the player will take, what’s his goal, what he will have to do in order to accomplish it, what will hold him back and why the game will be entertaining.

Next, do a quick introduction to the game’s setting and a brief description of the history (if any). It’s always nice to use an image instead of describing what the graphics will look like, so if you don’t have any sketches or conceptual art you should just paste pictures with similar art to what you will be using (that includes screenshots of other games as well!).

Key Features

The best way to compose this is using short topics (i.e. bullet lists) instead of long paragraphs. Basically you should tell the reader right away about all of the creative ideas you had which you thought would make your game a great game.

Right:

- Simple yet powerful physics that provides surprising results from a set of simple rules.

- Amazing Hatched and Cel-Shaded graphics.

- Never seen before paint system where color spreads out to the world as the gameplay picks up speed to a frantic pace.

- Powerful land crafting abilities that allow you to build complex paths the orbs can take, like tunnels and bridges.

- Various game modes and scenarios to choose from, each of which feels like a totally different game, favoring action or reflection.

Wrong:

The game will have simple yet powerful physics that provides surprising results from a set of simple rules, while using amazing Hatched and Cel-Shaded graphics and a never seen before paint system where color spreads out to the world as the gameplay picks up speed to a frantic pace, when players build complex paths by using powerful land crafting abilities which the orbs can take, in various game modes and scenarios.

(Too many ideas at once makes the reader lose the train of thought.)

Third-Party Software Used

A little explanation of the programming languages, libraries and software you will be using to create your game, as well as the programs you will use to adjust your graphics and sound engines and any other engines your game may need (like a networking one for multiplayer games).

If you’re under some heavy software/hardware restrictions, you should specify that in here (i.e. if you’re making a game for Apple devices, you have to tell you’ll be using iOS-compatible technology). Also if your game is aimed at PCs and you have an idea what the minimum requirements will be you should note them here. Although the non-programming people of the project probably won’t understand what the heck a “NVIDIA Cg 1.2.1” is, they’ll have to know it by name since that’s what the game will run on.

The Gameplay Section

This section is designed to describe how the game will effectively work, describing the game’s objective as well as its elements (menus, victory conditions, enemies, powerups, stages, …), and the interaction between each one of these elements with the player. If you feel like one subsection, such as “Enemies”, has too much content to be just a subsection you may promote it to a section of its own.

First Minute

It’s interesting for you to describe what the player’s reaction is going to be like as soon as the game loads, such as describing whether he can start playing right away or if he can navigate through menus to change some options beforehand, whether the player will have to learn the controls by trial and error or a tutorial will be presented to him, whether all stages will be available at the get-go or if he will have to unlock them in progression, and so on. Given you have already planned some stages ahead, you could narrate a short run of the player clearing a stage, describing the enemies and/or puzzles he had to go through in said stage.

Right:

After the title screen the player is presented with a list of games he can join and an option to create a new one. After selecting the option to create a new game a list of predefined levels appears on the right of the screen. (…) After the settings are adjusted three other players join and the game begins. A timer counts down from five while the players get ready, using the small amount of money they start with to place a few blocks. As a simple beat plays in the background, the board rotates around the middle of the screen, revealing the layout of the level. (…) The player’s goals are on each corner of the board. (…) As soon as the count down reaches zero, ‘Go!’ is displayed in the middle of the screen and the orbs start falling from the cloud, creating havoc on their path. (…) The player quickly places a stone corner block on the edge of the level and the orb bounces off it, only to end up in the player’s goal followed by a familiar cashier sound. The player’s score and cash are updated to 200, and he starts going through the blocks he can now place (…).

Wrong:

The game begins with the players facing each other in opposite corners. Player 1 decides to use all his money from the get-go and wins the game by using well-placed stone blocks to earn points.

(Although being essentially how the game will run, it needs more details.)

Gameflow

A nice complement to the “First minute” would be the “Game Flow”, which is usually represented as a flowchart. In contrast to the previous subsection, this one won’t focus on the first impression but rather give an overview of the whole picture, showing step-by-step which actions the player can take from the moment the game is loaded to when the player hits the “exit button” – i.e., ends his gaming session – including the gameplay itself in a somewhat high concept.

Right:

Wrong:

(Nothing THIS simple. Include, at least, all the screens that the player will run through!)

Victory Conditions

Here you state what is required for the player to clear a stage, win a match, or advance another level, whether your game is a puzzle, where the player advances to the next level when all pieces are combined in a certain way, or a sidescrolling shooter where the player advances a stage when he defeats the boss at the end, or whatever. Obviously, this depends entirely on what kind of game you’re designing.

Example:

In Space Invaders, the player advances to a new wave each time he destroys all enemies from the current wave. Since the waves are endless, the game will keep going until the player runs out of lives.

Graphics

You can’t really provide the reader with screenshots or video footage of something you may haven’t even designed yet, so in this subsection you should simply describe how do you plan to handle your graphical engine and maybe show some sketches of your game or a few drawings in the art style you intend to use. Planning the game HUD from the beginning will save you a lot of time later on, for example.

HUDs

The head-up-display is the in-game interface the player will have when playing the game. Rather than in-game menus like settings or inventory screens, this refers specifically to the floating windows and bars which don’t normally interact with the game and serve a information-only purpose. This includes health bars, mini-maps, time counters, equipped items and their amounts, money and etc. Although the size of the HUD will vary according to the game type (MMORPGs and RTSs will have big HUDs while sidescrollers and puzzles will have very small ones) keep in mind that a HUD shouldn’t occupy too much of the screen.

Example:

Sounds

On the other hand, one cannot sketch sounds, so you’ll just have to detail your sound engine here, and maybe the style of songs your game will use. Although for most games you will simply state that there will be different background music for different situations, it goes without saying that this subsection is most important for a rhythm game.

Controls

Stating which buttons/keys do what can be troublesome in the case where a single button does more than one action (i.e. The ‘A’ button in any 3D Zelda). Start by putting a simple picture of a controller or a keyboard with each button highlighted with their function in a more general sense. After that, if your game has advanced combos or something similar to that, explain them carefully, stating under which conditions each combo is “activated”.

Example:

Game-Specific Subsections

Puzzles could have a “Pieces” subsection, sidescrollers will probably have a “Level Design” one, space shooters may have “Enemies” and so on. As the title in bold above says, each game will have their own specific subsections, and since we can’t compose a subsection for all the possible ones that one GDD can have, we will provide you with the three bold subsections presented here as examples.

Pieces

Suppose we have a puzzle game, where the player rotates different pieces in order to create a line of matching pieces to gain points. This would be a nice subsection to show some sketches of the many different types of pieces, as well as explaining their rotation pattern, stating their points value, and maybe describe their positioning placement. Pictures are welcome as always!

Example:

Level Design

Now let’s pretend we have a typical 2D platformer. One of the core elements of the game is the stages the player has to go through. It’s important that each stage feels unique so the player won’t feel like he’s just repeating the same thing over and over again. On the other hand, the player should still be familiar with the flow of the stage, i.e. if there’s always a checkpoint somewhere halfway through it, or some collectible items along the way.

What are the different types of enemies, terrains, doodads and power ups and do they allow the level designers to come with many different stages? You could present some beta stage diagrams to illustrate how will they be carried out.

Example:

Enemies

It’s very popular for space shooters to have many kinds of enemies, each one with different attacks and movement patterns, as well as different values for health, speed and targetable area. As such, it’s no surprise you would need an extra section to present all the game’s foes and their stats. Also, you could state some of their more obscure behaviour like shooting an extra beam when their health is low and so on.

Example:

Plot

Many games are set in fictional worlds, each with their own geography, history and characters, in which the player will undoubtedly play a large role as the protagonist. If your game has a particularly interesting setting, it would be interesting to include a little insight on the game’s storyboard, describing the protagonist’s main events during his adventures and details about the lore.

Characters

Lots of games aren’t made of enemies alone. There may be a protagonist and allies to help him overcome his foes. For example, even a tower-defense game without a controlled character can still have side-characters like a tutorial-NPC giving you tips on how to overcome certain challenges at the beginning of each stage. If you do have a protagonist that the player controls, then what’s he like? Does he have any abilities and powers? Keep in mind that this shouldn’t feel like a “How to Play” subsection.

Artificial Intelligence

Any game will need a persisting world to handle all the player’s actions to the game and the other way around. That includes enemy movements, player controls, collision handling, time counting, random number generators and many other things one could need in a game. Although people not directly related to the programming may not understand this subsection entirely, they should at least grasp the basic of it. Most of all, keep the coding out of here and simply state the enemies’ moving patterns, the chain puzzle piece falling algorithm, maybe illustrate the combat system with a flowchart and so on.

Example:

The characters on the board will escape the orbs using simple pathfinding / flocking algorithms. Every level will use up to three different script files to issue commands to the animated characters. (…) Player bots will be used to simulate real players. This will allow any level to be played even if there are more goals than players. The decision process that the A.I. system is trying to solve is this:

– Should I place a new block? If so:

– Where do I place the block?

– What type / material should the block be?

Technical Aspects Section

The technical aspects consist of a series of game data, such as the system requirements on which it will play and the framework in which it was developed, the method or algorithm it was based on, and the maximum number of elements that can be rendered on screen. The graphical technical aspects consists of software used, modeling type, art style and others according to these topics.

The system requirements are the necessary computer settings for the game to be played, like the size it occupies on the computer’s HD and how much RAM is needed.

Another important technical aspect not to forget is the ESRB (Entertainment Software Rating Board) rating (or similar), already explained earlier. Some of the ratings are shown below.

To Include or Not to Include? When? Why?

Technical aspects interest the companies that will distribute it or that will use the technology developed in the game, so always add something in it if you’re showing this to someone that will approve or disapprove the game. There has to be some care when writing technical aspects. You can write something in the wrong subject. For example: limiting the platform and distribution game mode belongs to Marketing Aspects, not to Technical Aspects.

More Examples

For professional examples of Design Documents provided by the developers, we have: Shred Nebula, Play With Fire, Grim Fandango Puzzle Document, and many more avaliable at gamepitches.com.

For more material about the structure and composition of a GDD, one could try the featured Gamasutra article The Anatomy of a Design Document, Part 1 and Part 2; the self explanatory Creating a Great Design Document; and a more general How to write an effective Design Document, which isn’t about GDD, but about software development.

More on Game Design: The Two C’s of Video Game Design.

Moreover, there are other visions of how should documentation be done in the Game Industry, as seen in Game Design Logs and Return of the GDD. Although they seem to contradict what had been told here, this should fall in a case-by-case analysis considering team size, budget and deadlines.

Conclusion

For designers who need the approval of an investor: truth be told, before you can make any progress with an investor, you must first get his attention, and to do so, the following key points of your document must be in excellent shape.

High concept: you never get a second chance to make a first impression, and here is where you will make it. We have already given you the tools to make this section, now just remember to give its construction a high priority and point everything that makes your game more appealing here.

Pictures: do not be fooled that the reader will always go through your entire GDD, there are some documents that surpass a thousand pages (yes, this is true!). But he will surely take a better look if something catches his attention, and what better way of doing so than with pictures? After all, one image is worth a thousand words.

It goes without saying that your document must have a great appearance. Take your time to make everything readable and nice. Also, don’t forget that this article only presented a skeleton structure of a GDD for you; you will have to adapt it to your own game!