作者：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）播放灯片能够帮助你更好地阐述关键点并呈现美术内容。

常见问题

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

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

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

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

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

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

游戏邦注：原文发表于1999年10月19日，所涉事件和数据均以当时为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

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 implementation 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, and 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 to 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. (source:GAMASUTRA)