创造设计文件的目的是传达游戏创意，描述游戏内容，呈现执行计划。设计文件是制片人宣传目标，设计师倡导理念的权威材料，也是美术人员和程序员的任务指南。不幸的是， 有时候设计文件很容易被忽视，或者达不到制作人，设计师，美术人员以及程序员的预期。本文将通过展现撰写设计文件各部分内容的相关指导原则，助你根据项目和团队需求制 作文件。
从广义上来说，撰写设计文件的目的便是详细阐述游戏观点从而让开发者更好地执行它。它能够避免程序员，设计师以及美术人员手足无措地向设计师、制作人询问自己的工作职 责这种无序状态。设计文件让他们不再局限于一个狭小空间编制程序或制作动画，而是让他们真正清楚该如何将自己的工作与其他人的工作有效地整合在一起。如此便大大减少了 不必要的投入并避免各种混乱。
对于团队中的不同角色来说，文件的含义也不同。对于制作人来说，设计文件是他“布道”的圣经；如果制作人不能认同设计文件或者不能让团队成员理念文件，那么它就失去了 原有的价值。对于设计师来说，文件是一种传达制作人理念的方法，能够告知他们更多关于游戏执行的细节内容。首席设计师可以说是所有文件的作者——除了技术说明，因为这 是高级程序员或技术总监所撰写的。而对于程序员和美术人员来说，设计文件则是他们的执行指令，也是他们表现自己设计，美工以及编码技能的重要方式。设计文件应该是团队 共同努力的结晶，因为几乎团队中的所有人都会玩游戏，并都将为游戏设计做出自己的贡献。
设计文件也不会取代设计会议或电子讨论会议。在撰写出文件之前让所有人聚集在会议室中进行讨论，或者根据每个人的观点做出总结性规划都是决定游戏内容的最快速方法。设 计文件只能够表达出一致意见，具体化各种观点并消除模糊性。但是它本身也只是讨论的一部分内容。尽管设计文件的宗旨是巩固想法和计划，但它们也并非板上钉钉的内容。应 该允许团队成员编辑文件内容或发表评论，让大家更好地交换彼此的意见。
大纲有助于拟定安排和测试计划。遵循明确大纲的设计文件能够帮助你更快速地落实行动。文件中明确列出了美术人员和作曲人员所需要创作的图像和声音要求；帮助关卡设计师 有序地分解了故事中的不同关卡，并罗列出了要求数据输入和脚本撰写的游戏对象；确定了程序员所需负责的不同程序领域和规程；最后，它还明确了QA团队在测试计划中需要重 视的各种游戏元素，特征和功能等内容。
大纲会发生变化。基于项目的独特性，你有可能需要放弃一定的原则转而遵循其它内容。例如移植项目通常都比较简单，除了技术说明之外它们并不会要求额外的文件内容（除非 改变了原先的设计）。续集游戏（游戏邦注：如《银河飞将II》，《银河飞将III》等）以及其它非常有名的设计（如《大富翁》或扑克游戏）便不需要过多地解释相关机制内容， 而是应该提供给读者们关于现有游戏或设计的相关文件。只有一些具体的特殊执行项目需要提供明确的文件。
“《Man or Machine》是一款PC平台上的第一人称射击游戏，游戏使用《Quake II》引擎将玩家带进了37世纪的高科技星际战争中，他们将在此扮演一个机器人太空战士的角色。 ”
背景（非必要选项）：游戏理念的背景内容与你在介绍中所提到的产品，项目，授权或者其它属性相关。本质上来看，背景是独立于介绍内容，所以如果读者已经拥有了相关的背 景知识便可以轻易跳过它。不过对于那些授权游戏，续集游戏或者深受早前相同类型影响的游戏，背景尤为重要。如果你想要使用现有代码，工具或授权使用一个游戏引擎，你就 需要在背景中描写清楚这些内容以及它们的优势。
描述：通过使用几个段落或者一页的空间，将读者当成玩家对他们阐述你的游戏。你需要以第二人称的表达方法——“你”进行描述，并努力让这部分内容成为让玩家兴奋的叙述 体验。在此，你可以通过描写玩家该做些什么或者能够看到些什么而向他们传达核心游戏玩法；避免一些细节描述，如点击鼠标或击键，但是也不能太过含糊。你希望读者们都能 融入游戏角色中。同时你需要将细节关卡适当地安置在GUI互动上。你的表达方式应该像“查看你的战术雷达并捕捉更多靠近你的妖怪”，而不是“你应该点击战术雷达按钮，随后 会挑出一个窗口告知你有两个妖怪正在逼近你。”你必须利用描述内容有效且清晰地呈现出游戏内容和娱乐价值。
“高级人工智能（AI）：《Man or Machine》将使当年《半条命》中富有挑战性和真实感的AI实现更大的飞跃。”
类型：也就是定义游戏的类型。以来自杂志或者获奖游戏类别为向导。例如，你可以从如下游戏类型中做出选择：运动类，即时策略，第一人称射击，益智，赛车模拟，冒险，角 色扮演，飞行模拟，竞速射击，模拟上帝，策略，行动策略，回合制策略，卷轴射击，教育类或飞行射击游戏等。然后你可以根据这些名称或重新使用其它短语定义游戏，如现代 ，二战，现实交替，后启示录，未来主义，科幻，幻想，中世纪，古老，太空，网络朋克等。
概念艺术（非必要选项）：采用一定的美术元素能够帮助你更好地传达理念，并让读者以更加积极的心态感受你的游戏。使用美术去传达独特或复杂的理念。屏幕模型能够帮助你 有效地传达各种想法。但是因为游戏概念艺术超出了许多开发人员的能力范围，如此便可能导致他们所提交的创造理念大大减少；所以这是一种可选择的项目。如果你确定一个理 念具有价值，那就可以从其他技术资源中提取其美术元素。通常，来自于早前项目或者网上的美术内容都有助为文件增色。但要注意避免版权问题。
从资源上来看，文件中的某些要求总是背离现实。你需要尽可能将自己的理念保持在适度范围内；通过使用现有的工具或属性控制预算。确保你能够在特定时间以及合理预算范围 内实践想法。将你的实验技术限制在一个特定区域内；最好不要轻易尝试具有变革性的AI以及最先进的3D引擎。如果你正在创造自己的游戏理念，你就必须先明确时间安排和预期 预算。
文件缺少内容。就像是“《命令与征服》结合《机甲战士》，你命令自己的‘Mech加入战斗，’”但是这种表达却远远不够充分。你的描述必须解释清楚玩家应该执行何种行动， 从而让他们能够对此感兴趣。优秀的描述应该是：“你命令自己的Mech直接朝着Clan MadCat OmniMech暴露的躯壳射击。”这样的描述内容才能消除玩家对于核心游戏玩法的误解 。
游戏并不有趣。一个真正有效的方法便是分解所有玩家可能执行的动词（游戏邦注：包括射击，命令，奔跑，购买，构建以及观看等）并想象玩家是如何执行每个动词。随后，基 于每个动词询问自己这是否有趣；然后问自己目标玩家是否会觉得有趣。你必须确保自己足够客观地回答这些问题。如果你认为玩家所采取的行动不够有趣，你就应该立即为其设 定其它更加有趣的行动。
游戏提案中应该包含游戏理念的修订版本。关于理念文件的技术，市场营销以及财务反馈都将要求你适当压缩理念内容；但同时你也可能需要修改并添加其它功能。并且你需要确 保这种改变不会让任何人感到惊讶，因为这是理念首次接受批评与协作讨论的过程。在正式创造出游戏提案之前将相关反馈和分析副本提交给开发总监（或其他要求审查游戏提案 的人士）过目；这不仅能够让一些特定人士或部门给予理念相应的书面评价，同时也给予了总监否决，修改或主张其它提案的权利。
目标市场：目标市场是基于游戏类型和平台进行定义，在理念文件中已经相应地处理了这些问题。你可以根据一些已经成功占领市场的特定游戏进一步分析这一定义。最成功的游 戏总是能够预测市场的发展潜能以及规模；并且你也能够因此了解到典型的用户年龄范围，性别以及其它重要的市场用户特征。而如果你的游戏包含有授权属性或者属于续集游戏 ，你就有必要描述原有市场情况。
列出这些游戏所属平台（如果这些游戏所在平台，与提案游戏不同）。因为平台的改变也会引起市场变化，所以你应该始终罗列出目标平台上一些相同类型的游戏，即使它们的市 场表现不如其它游戏；因为这些数据能够提醒你某种特殊类型游戏在某一平台上的发展较为萧条。例如，回合制策略游戏在PC平台上具有非常好的销量，但是在索尼的PlayStation 上却成绩惨淡。所以如果你面对的是回合制策略游戏，你就应该在最佳表现者的列表上同时呈现出糟糕表现者的情况。
比较特色：分解这些最佳表现者的卖点，将其与理念文件中的主要特色进行比较；并尝试着提供一些细节描写。举个例子来说，如在《命令与征服》，《黑暗王朝》以及《神话》 中的策略战斗中，你将出于某种优势而命令自己的单位去攻击特定的目标并将其移动到特殊位置或范围内。玩家在游戏过程中将会发现大多数单位的独特优势和劣势，并因此备受 鼓励而创造出超级战术。Tanktics》中拥有各种类型的命令，让玩家能够在此执行超级战术，如捕获，撞击以及击跑配合等。而因为游戏中的地形，移动以及奖励范围；射击弧 以及后击和侧击位置的弱点使单位位置的设置和目标的选择变得更加重要。所有的单位都拥有不同的武器，装甲以及速度，以此能够区别它们的优劣势并鼓励玩家制定战术。随着 时间的流逝，你不仅能够精通这些战术，你也能够根据自己的命令而编写策略脚本了。
实验性功能：明确设计中那些具有实验性的功能，即未经实验或未经证明的技术，方法，看法或其它独特的理念。排除那些已经在现有游戏中得到证实的功能，即使它们对于你们 的开发团队来说还很陌生。例如，即使团队从未开发过3D引擎，也不能轻易将其当成实验性功能；而是应该将其归为技术分析内容中一个或多个类别中。另一方面，如果你的开发 团队正在使用quads体系开发3D引擎，那么你便能够将这种体验记录在实验性功能列表中。
估计实验性功能达到评价状态需要多长时间，以及完成整个功能又需要多长时间。一般来说，你的安排列表中总需要为实验性领域挪出更多时间，所以如果你罗列出更多实验性功 能，你就需要投入更长的时间。尽管很多公司都尽量回避那些耗时18至24个月的游戏项目，但是也有很多开发者意识到，如果要开发一款具有领先优势的游戏，这种实验值得一试 。
主要开发任务：通过一个段落或者一些项目符号明确列出主要的开发任务，并使用普通人也能够理解的非技术类语言。“主要”主要指开发月数。你需要假设你拥有开发所需要的 所有资源，而因此估计你完成该任务需要多少时间。你同样也可以估计你所需要的资源。例如：“人工智能脚本解析器：需要两个程序设计员花费3至4个月的时间。解析器将阅读 并以较低级别的逻辑编辑AI脚本，并基于运行时间做出指示。”
风险：列出任何技术风险。如果你不能预见任何技术风险，请务必说出来。风险是指研究开发过程中因为失败而造成的挫折（引起工作延误数周或数月）。记录下技术——尽管这 些技术可能已经得到竞争者的成功证实，但是你们公司却从未尝试过或者说对此没有任何经验。例如，如果你的公司从未开发过一款即时策略游戏，那就记录下即时策略内容；或 者如果你们公司首次接触3D，那就记录下3D渲染技术等。记录下之前提过的任何主要开发任务——如果你察觉到其中的风险。同时，所有未经实验的解决方法（游戏邦注：包括3D 引擎，编辑器，代码库，API以及驱动器等）也应该被当成是风险而记录下来，因为这些方法可能最终也不会满足你的特殊需求。记录下任何经由外部承包商进行的开发工作，因为 通常来说这种行为总是具有较大风险。当你在评估风险的同时，你也应该清楚修改或替换这些风险技术会带来何种影响。以周或月为单位指示发行日期。记录下时间对于任何特殊 资源的影响。记录下任何能够修改风险的新资源（包括人力，软件，硬件等）。虽然这个阶段看起来很繁琐，但是它却能够为你的文件评论者创造一个舒适的阅读环境，即他们将 会认为游戏执行始终处于适当的控制之下（特别是当他们自己也能够察觉到风险的存在时）。除此之外，你还能够有理地说道：“你可别说我没有警告你”之类的话。
替代性选择（如果有的话）：替代选择是你围绕着这些实验性或风险性功能，以及致力于主要开发任务时所必需的元素。通过明确替代选择，有助于文件阅读者自己做出选择。例 如列出任何需要耗费更多时间和金钱但却能够获得更好结果的选择，或者相反的内容（花费更少的时间和金钱但是结果却不如预期那般令人满意）。不管你给予何种选择，都需要 明确说明它们的优劣。
资源成本：资源成本是基于技术分析所估算的资源。就像员工成本将基于工资和日常开支，而这也是财务或工资管理部门应该提供的数据。你可以通过名称或标准去记录这些平均 数值。同时，你也应该记录下你所购买的任何软件或硬件，即使你将在其它项目中使用这些资源或者它们将被整合进日常开支预算中。使用表格或嵌入式表格以帮助你更加轻松地 进行编辑，并让读者更加清晰地进行阅读。如下图：
建议零售价（SRP）：你应该在你的游戏沦为讨价还价牺牲品之前明确一个建议零售价。建议零售价应该基于现有游戏的价格，并评估游戏开发的总体价值以及生产开发成本等。当 然了，发行商总是想要压低游戏的定价，或者通过各种促销方法进一步压低游戏价格，不过这些方法最终也能帮助你的游戏取得不错成绩。因为你需要牢记，越高的定价也就意味 着越低的销量，特别是当你面对的是市场上竞争激烈的游戏类型（即供过于求）时。
收益预测：你应该根据自己所罗列出的成本以及建议零售价而呈现出悲观，预期以及乐观三种销量值。而市场营销或者公司日常开支等元素则不包含在此范围中，因为这些内容都 属于可变化的内容；但是如果你知道最低市场营销预算值，你就应该将其涵括在考虑范围内。通常情况下，圆形分格统计图表或者长条图都非常适合呈现收益预测数据。除此之外 ，你还应该呈现出技术评估所描写的风险成本，以及使用或不使用风险评估的预期总值。
美术：如果你的游戏理念中未包含任何美术内容，那么你的游戏提案中就不能缺少这些内容。美术内容必须由熟练的设计师所创造，所以你应该删除或替换掉理念文件中那些非设 计师创造的美术内容。美术能够明确游戏基调。如果你的读者只是根据美术效果去评估提案，你就需要确保在美术内容中展现出游戏的风格和目的。美术内容包括彩色或黑白的角 色，单位，建筑，武器示意图；动作动画；并且如果你的游戏是驾驶模拟游戏，也可以包含GUI实物模型等。确保你拥有精致的封面图像。在文件页面中张贴图像能够为你的文件加 分，并更好地引起读者的兴趣。
描述：整份提案文件应该包含改订过的理念文件，印刷成册并与美术副本一起装订在特定的报告文件夹中。你应该将这份文件呈现给那些前来你的办公室拜访的商务人士。你应该 始终牢记你需要一大笔的投资，所以要尽可能让你的提案看起来更加吸引人，从而能够吸引投资者的注意。用某些程序（如微软的Persuasion）播放灯片能够帮助你更好地阐述关 键点并呈现美术内容。
功能 vs 技术说明文件
游戏行业传统上只有一种说明文件，涉及多少技术内容主要取决于文件撰写人的意愿。而程序员之后所写的用于执行过程的文件，一般都是非正式内容，通常写在白板或记事本上 。但为了确保项目执行顺畅，按期交付并且不超出预算，这种项目说明文件就应该包含更多技术内容。制作如此详细的技术说明文件需花费一些时间——而如果产品目标和功能发 生变化，或者未通过批准，那么这些时间就白费了。
但随着更多富有经验的程序员和软件开发项目经理加入游戏行业，这个问题也得到了妥善解决。这些人才引进了新的文件设计标准，确保项目规划更明确，并减少了技术性问题。 他们将设计文件按照目标、方法、功能和技术类别，将其划分为功能说明文件和技术说明文件。这样产品客户、用户或主设计师就可以浏览功能规范书，直接反馈是否赞同指定软 件的目标和功能，而无需考虑将由程序员等人员来处理的技术性决策和文件。
这类文件的撰写时长也不尽相同，如果是益智游戏可能几天就足矣，射击游戏游戏是一个月，而RPG或策略游戏等更复杂的项目可能长达数月。需注意，文件撰写时长与其篇幅长短 未必成正比。造成这种情况的原因包括考虑时间长短不同，当游戏拥有独一无二、原创的特性，或者玩法极具深度时更是如此。当然，主设计师制定决策的效率也会对文件撰写时 长造成影响，尤其是当大家对这个游戏项目都很有想法和激情的时候。
游戏首席设计师通常就是功能规范书的撰写人。这份文件可能是集体智慧的结晶，也可能只是落实到书面上的制作人项目愿意。有时候制作人也会自己动手完成这个文件，这就可 以确保文件表达的正是其本人的想法。与打电话游戏一样，在撰写这种文件的时候，项目负责人所表达的想法可能与后来写在书面上的内容存在出入。无论是哪种撰写过程，或者 由谁负责撰写文件，重要的是制作人和首席设计师对这个文件达成了一致意见。不可出现口头所说与纸上所写内容相左，或者完全无视文件内容的情况。
我还没见过不会在执行过程中发生变化的设计，重要的是针对文件内容进行沟通和交流，即使需要更改或添加内容也不例外。有些变动由于时间有限，需要立即处理，这样才能让 文件清晰明了。即使这些变动只是写在电子备忘录或者纸张上，也要确保将其添加到未来的规范文件中。但如果游戏版本发生变化，最好从一个新理念大纲和项目提议重新开始入 手。更新版文件的准确性有利于节省未来的大量时间。
另一方面，这个文件不能出现太多技术倾向，因为它的读者基本上不是程序员。如果你发现它出现技术倾向，那就要收手了，因为这是技术规格书所写的内容，否则就会让非技术 读者像看天书一样不知所云。与此同理，你或者其他撰写者可能也未必是技术人员，所以无权通过这份文件指令程序员如何执行工作。这要让他们在书写技术规格书时自己决定。 毕竟这个文件纯粹是用于交流和审核产品内容，而非指导如何完成任务。但你可以针对自己认为非常重要的地方进行一些简短描述。例如，你不能指令使用哪些变量，以及如何使 用这些变量去模拟一个物理定律，但你可以指出与这个物理公式有关的因素。同理，你不应该告诉程序员如何定义他们的数据结构和对象，但可以针对数据输入界面和数据描述提 出一些建议。
游戏流程：对玩家活动进行详细描述，注意玩家在这一过程中的挑战性和娱乐性的发展。如果说核心玩法是大树的根，那么游戏流程就是树干和分枝，所有游戏活动都是从核心玩 法扩展而来。要明确指出玩家所执行操作，尽量使用“射击”、“指挥”、“选择”和“移动”等准确的词语而非“点击”、“摁压”和“拖拽”等字眼来描述内容。因为这种描 述差异可能会对GUI运行方式产生影响。如果你在此首次提到屏幕、窗口或指令条等GUI元素，那就要记得将读者引向“用户界面”版块的内容。
角色/单位（视情况而定）：它们是在游戏中受玩家或AI控制的演员。这里应包含一个简短描述和一些合适的数值。这些数值需划分成A到Z或者“高到低”等级，这样才能明确每个 单位彼此间的地位。但此时不宜插入准确数据，因为程序员到时候自然会在技术规格书中提到这一点，并创建一个可让你试验这些数值的环境。除了数值之外，这里还要列出单位 的特殊技能或能力，并进行简要描述，但如果这些内容很复杂，可以在“玩法元素”版块进行扩展。
这里的内容可能有点枯燥，但切记不可过于技术化。不要使用确切的数字或编程术语。因为这些都是程序员之后撰写技术规格书所考虑的内容。只要告诉他们你希望获得什么效果 即可。例如，“这些单位上坡时会减速，下坡时会加速，除非它们是滑翔或飞行工具。攀升和加速的数值，以及倾斜角度会影响它们的表现。”你不可告诉程序员应该使用哪种算 法调整速度，因为你自己并非程序员，他们才是这方面的行家。
功能需求：这是每个屏幕、窗口以及菜单的功能分解，它应列出用户操作及预期结果，可能还会包含图表和模型。可以适当列出一些具体交互行为（例如按钮、点击、拖放和产生 动画），但最好不要在此添加过多这种内容，因为这会涉及到执行方式。当然，如果点击按钮这种描述更易理解，或者真的很有必要指出某物的特定运行方式，那就要详细指出其 交互方式。
关卡图表：不论这是一个线性活动，拥有分枝的任务树，还是一个自由开放世界，这个图表都应该是所有关卡创建的基础。如果关卡结构仅需一个简单的列表就能表述清楚，就不 需要创建图表了。下图是一个典型的成功/失败分枝任务树图表。当然每款游戏特点不同，其图表结构也会有所差异，重要的是要让它成为有助于关卡设计师和读者理解内容的线路 图。
内容揭露计划表：它应该是一个玩家首次接触游戏时所会看到的游戏内容表格或电子表格。它可以是以关卡为行，以每种内容为列。其中的内容包括升级道具、武器、敌人类型、 诀窍、陷阱、目标类型、挑战、建筑以及其他所有游戏玩法元素。这个表格可确保游戏中的内容，即促使玩家进入下个关卡的元素妥当分配，不会出现超量或没有充分使用的情况 。
关卡设计核心：在写出详细的设计文件之前，要先点出设计核心。设计师用工具试验并开发了首个可玩关卡之后再推出的设计，更有可能获得成功。所以此时最好先列出每个关卡 的核心，描述关卡目标，玩法以及它如何与故事（如果游戏有故事内容）相结合。可以选择先勾勒一个草图，如果设计师对此已经拥有明确想法那就再好不过了。要确保文件列出 了地形、目标、新揭露的内容，以及目标难度等级等特定的关卡需求。
*过于个人化的设计：我曾经强调过游戏设计是一个协作的过程，虽然大家是各司其职地完成自己的工作，但功能规范书应该是集体智慧的结晶，因此它不可以是一项个人产物。否 则会让人觉得自己与设计过程没多大关系，同时也会让这份文件更像是一份命令和计划。团队成员更乐意阅读大家合力完成的设计文件，这样人们提出批评意见时也主要是针对文 件本身而非作者，这样可以让大家更自在地对文件提出改进意见。
该文件的目标读者是项目主程序员以及公司技术总监。因此它是以系统而非用户角度出发撰写内容，看起来会很枯燥，对制作人和其他非技术人员来说简直像是天书。但制作人要 求撰写这一文件的目的在于，确保技术人员考虑周全，即便制作人本身对此并不了解。对主程序员来说，这是一个组织思维和勾勒项目框架的方法。这种编写文件的过程有助于显 示编程环节中的不确定因素和漏洞，以及功能规范书中的模糊或荒谬之处。
许多出色的技术规格书编写格式与本文描述并不相同。这里的格式主要与功能规范书相对应，以确保覆盖所有的功能规范内容。有时候开发团队也可以出于分工不同，或因为基础 系统组织方式而选择不同编写形式。如果这样的话，我建议他们细读功能规范书的每行文字，并以萤光笔标出相关内容，以免忽略某些内容。毕竟疏漏一个细节可能会令产品、项 目和团队动态产生令人不快的结果。
这些原则不会教你如何执行游戏开发，其假设前提是你已经是一个技术能手，富有经验的游戏程序员，而生手则不应该参与这项任务。我认为优秀的技术规格书应该遵从这些原则 ，它们会要求你定义所有游戏中的最普遍元素。有些原则可能并不适用于你的项目，但每个原则都值得认真考虑，毕竟它可能对你有所启发，而这也正是撰写这份文件的意义之一 。
外部代码：要描述并非项目团队所开发的所有代码来源和用途。这包括操作系统代码和针对不同游戏平台的预处理工具，驱动器和DirectX等代码库，以及项目所需的3D API，或其 他现成解决方案。
游戏对象数据：先仔细阅读功能规范书中关于所有角色/单位的描述，以及游戏玩法元素内容。然后规划并列出所有数据结构，以及能够支持这些描述特点、功能和行为的标识符。 从某种程度上说，只有游戏物理、统计数值和AI部分内容考虑周全并载入文件时才可能做到这一点。在为用户界面或任何包含单位/玩法对象特定数据（游戏邦注：例如图票、HUD 元素、动画或特效参照内容）的区域添加统计数值。
如果使用的是面向对象的编程方法，那就要提供类继承树和每个类的界面属性和功能。描述集合的使用方式。列出可能作为全程变量以增强性能的变量，例如可能在碰撞时、移动 或渲染等重要游戏惯例中命被多次引用的对象变量。需要重申的是，我并非教你如何为游戏编程，只是想让你多考虑其中的普遍技术问题，尤其是与整洁性、多功能化或速度有关 的数据结构优化问题。
游戏物理和统计数值：这里的内容多而繁杂（例如移动、碰撞和战斗等等），但可能也是最有趣的编写和执行内容。但它的代码可能也是编程中变动最为频繁的内容。设计师喜欢 更改内容，并且通常是在游戏具有一定可玩性时才能决定采用哪个设计。因此你的执行计划应该具有模块化和灵活性。要将控制操作行为的所有元素导入可以在运行时间阅读的数 据文件中，这样可以方便设计师在闲暇时间进行调整，无需介入编程调整过程。这个说明文件应该明确区分代码及其控制数据的组合性和分类。
外观和风格是开发过程中最常变化的设计内容。因此，针对GUI的编程很有必要保持灵活性，要将玩法用途与GUI功能相分离，这样用户交互方法的改变就不会影响到游戏的其他层 面，或者产生重大的改编程序。要使用继承类创建多种GUI对象（控制方法）以保持代码界面在事件中的一致性和数值。这样就可以在无需重大改变调用函数的情况下，将滑动块变 换为文本框或按钮。最好将任何GUI对象都设置为可更改状态。
游戏外壳：列出所有组成游戏外观的屏幕——这包括主游戏屏幕之外的所有屏幕及窗口。它们是由功能规范书中的流程图衍生而来，但可能包括一些主设计师所疏忽的额外屏幕（ 例如安装或设置屏幕）。所列的每个项目都要纳入其应用的片段，并描述其用途和范围（例如是在特定关卡数据加载之前还是之后），它将访问和设置的相关数值，它将调用的函 数等。
*尽管让各个任务指定程序员完成相应文件内容是一种很有效率的方法，但这并不意味着它能给游戏项目带来最大好处，或者程序员就会在没有监督的情况下自觉完成撰写文件的任 务。在这一过程中初级程序员可能需要一些指导，而在所有文件整合在一起时，所有相关程序员都应该对文件内容进行一番讨论和点评。一些公司设置了让程序员相互评论对方工 作的常规代码复查制度，最好在设计阶段尽早展开这种审核工作。
制作草图和进行讨论的好处在于节省时间，无需迫使设计师事先规划好一切并将其编入文件中。高级或主设计师可以在数分钟内决定大家所提出的关卡设计是否可行，并提出富有 价值的改进建议。一份内容详尽的纸质文件可能需要数天甚至一周时间才能完成。设计师的稿件是否会被退回重新修改，则要视其技能水平而定。这在项目动工初期表现尤为明显 ，因为此时设计师仍在揣摩主设计师想要的效果是什么，临近项目尾声时，要得到原创而富有吸引力的关卡设计就更困难了。
在小样和关卡理念获得批准后，关卡设计师就可以开始制作详细的纸质关卡设计版本了。关卡布局应比草图更详细，并且要按比例绘制出来。最好使用彩色铅笔在大张方格纸中绘 图，在地图中要标注对象、行为、建筑、敌人、事件、位置等信息，也可以将其列入另一份单独的索引文件中。还要列出任务特定美术或代码内容。完成这些细节可能需要花费数 天甚至长达一周时间，但比起在真正的编辑器中“搜索”或“重新设计”，这种方法可以省下更多时间。
人们通常倾向于跳过这个步骤，直接使用编辑器制作关卡，因为创建一个关卡原型往往比制作纸质版本更快。在项目进度安排较为紧凑的时候尤其如此。但项目安排越是紧凑，就 越有必要使用书面文件来规范设计工作，因为事先考虑周全有助于一次性把事情做完，减少意外情况发生次数，节省返功时间。制作纸上关卡设计版本的好处在于，它可能让设计 师事先就考虑到所有事项，在落实设计之前就表达出关卡的趣味和挑战性所在。这份文件还可以确保在设计师开始工作之前，程序员、美工和音频技术人员就已掌握自己的任务安 排。
以下是关于项目进度安排中的典型阶段列表，在每个阶段（或称标志性事件）都有一个评审过程。因为只有当文件大部分内容都完成才能制定项目开发安排，所以要确保重新撰写 文件或创建大家都认同的说明书这一过程不会影响到项目开发时间。为了赶时间发售游戏而匆匆编撰设计文件，并草率投入制作是造成项目失败的一大原因。并且这并不能为你节 省什么时间，事实上它只会浪费大家的精力，并且造成更重大的项目延期。
看到一个项目依从这些原则而顺利运转应该是一件美妙之事，但有时由于灵感或市场趋势的变化也会让项目愿景转向。人们习惯使用“即时设计”模式以应对新变化，并且不影响 项目安排。有时候这种情况确实难以避免，但这种模式也存在弊端。在这种情况下，唯一可用的方法就是固守这些原则及其程序。如果在合同上提到这一点那就更好了。不要在未 更新有关文件的情况下调整项目内容。要知道功能规范书中的一个变化，可能就会导致技术规格书中的有关内容失效，并影响后续的项目安排。主设计师在签收并交付功能规范书 时必须清楚哪些人可能提出修改要求。如果他们确实需要进行一些更改，那就可以通过更新文件和重新制定项目安排而减少其影响。只要想想卡在项目开发过程中，或被迫延迟任 务的痛苦，就足以成为促使你事先考虑周全，制作好这些文件的动力了。希望本系列文件对你的项目开发过程有所帮助。
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:
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.
“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.
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)
Legal analysis (if applicable)
Cost and revenue projections
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
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.
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:
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:
•Art and Video
•Sound and Music
•Story (if applicable)
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.
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)
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 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.
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
•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.
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?
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.
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.
•Document: Game Concept
•Document: Game Proposal
•Document: Functional Specification
•Document: Technical Specification
•Documents: Tool Specifications (if applicable)
Production Phase (sometimes called Implementation Phase)
•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.