|
篇目1，Tim Ryan解构游戏设计文档的设定问题 作者：Tim Ryan 创造设计文件的目的是传达游戏创意，描述游戏内容，呈现执行计划。设计文件是制片人宣传目标，设计师倡导理念的权威材料，也是美术人员和程序员的任务指南。不幸的是， 有时候设计文件很容易被忽视，或者达不到制作人，设计师，美术人员以及程序员的预期。本文将通过展现撰写设计文件各部分内容的相关指导原则，助你根据项目和团队需求制 作文件。 在本系列文章的第一部分中，我将描述创造设计文件的目的，以及遵循这些原则的好处。本文包括编写设计文件的前两个步骤，即编写理念文件和游戏提案。而在第二部分，我将 进一步阐述撰写功能说明，技术规范以及关卡设计的相关原则。  game design document(from willdonohoe.wordpress.com)
撰写设计文件的目的 从广义上来说，撰写设计文件的目的便是详细阐述游戏观点从而让开发者更好地执行它。它能够避免程序员，设计师以及美术人员手足无措地向设计师、制作人询问自己的工作职 责这种无序状态。设计文件让他们不再局限于一个狭小空间编制程序或制作动画，而是让他们真正清楚该如何将自己的工作与其他人的工作有效地整合在一起。如此便大大减少了 不必要的投入并避免各种混乱。 对于团队中的不同角色来说，文件的含义也不同。对于制作人来说，设计文件是他“布道”的圣经；如果制作人不能认同设计文件或者不能让团队成员理念文件，那么它就失去了 原有的价值。对于设计师来说，文件是一种传达制作人理念的方法，能够告知他们更多关于游戏执行的细节内容。首席设计师可以说是所有文件的作者——除了技术说明，因为这 是高级程序员或技术总监所撰写的。而对于程序员和美术人员来说，设计文件则是他们的执行指令，也是他们表现自己设计，美工以及编码技能的重要方式。设计文件应该是团队 共同努力的结晶，因为几乎团队中的所有人都会玩游戏，并都将为游戏设计做出自己的贡献。 设计文件也不会取代设计会议或电子讨论会议。在撰写出文件之前让所有人聚集在会议室中进行讨论，或者根据每个人的观点做出总结性规划都是决定游戏内容的最快速方法。设 计文件只能够表达出一致意见，具体化各种观点并消除模糊性。但是它本身也只是讨论的一部分内容。尽管设计文件的宗旨是巩固想法和计划，但它们也并非板上钉钉的内容。应 该允许团队成员编辑文件内容或发表评论，让大家更好地交换彼此的意见。 明确文件设计大纲的益处 遵从明确的设计原则将能够让你的所有项目受益。因为这类大纲有助于开发者摆脱华而不实的内容，让所有成员更加明确自己的任务，并确保你的项目能够遵循一定的规程，从而 助你更加轻松地安排工作并执行测试计划。 减少华而不实的内容。大纲通过要求设计师确定游戏中的实质元素并减少那些不切合时机的白日梦，从而让他们能够投入那些更加切实可行的任务中。 清晰性和确定性。大纲能够进一步保证设计过程中的清晰性和确定性。它创造出了一种一致性，让读者能够更容易理解文件内容。并且也让作者从读者角度出发，撰写更加通俗易 懂的内容。 大纲可以确保特定的流程遵从设计文件的安排——这些安排包括市场研究，技术评估，深入探索以及观点传播的过程。 大纲有助于拟定安排和测试计划。遵循明确大纲的设计文件能够帮助你更快速地落实行动。文件中明确列出了美术人员和作曲人员所需要创作的图像和声音要求；帮助关卡设计师 有序地分解了故事中的不同关卡，并罗列出了要求数据输入和脚本撰写的游戏对象；确定了程序员所需负责的不同程序领域和规程；最后，它还明确了QA团队在测试计划中需要重 视的各种游戏元素，特征和功能等内容。 大纲会发生变化。基于项目的独特性，你有可能需要放弃一定的原则转而遵循其它内容。例如移植项目通常都比较简单，除了技术说明之外它们并不会要求额外的文件内容（除非 改变了原先的设计）。续集游戏（游戏邦注：如《银河飞将II》，《银河飞将III》等）以及其它非常有名的设计（如《大富翁》或扑克游戏）便不需要过多地解释相关机制内容， 而是应该提供给读者们关于现有游戏或设计的相关文件。只有一些具体的特殊执行项目需要提供明确的文件。 游戏理念大纲 游戏理念大纲能够传达游戏的核心理念。通常这只要1至2页的文件描述，因为简洁的表达才能够鼓励更多创造性理念的涌现。游戏理念文件的目标读者应该是那些你希望介绍游戏 的对象，特别是那些能够帮助你在接下来的正式游戏提案中出谋划策的人。 一般来说，所有的理念在传达给产品开发部之前都需要先给开发部主管（或执行制作人）过目。而该主管则需要判断这些理念是否具有价值，是否值得他们投入更多资源落实开发 。 开发主管或许会认可游戏理念，但是他们仍会要求做出一些改变。他们将会与一些设计人员和制作人，甚至整个部门或公司成员分享这些理念；如此汇聚了大量人才的想法和想象 力后，游戏理念必然会变得更具有吸引力。 游戏理念应该包含以下内容： 介绍 背景（非必要选项） 描述 主要功能 类型 平台 概念艺术（非必要选项） 介绍：游戏理念中的介绍包含了文件中一些最重要的关键字——能够帮助读者更好地理解文件内容。尝试着将游戏中一些重要内容以一个句子简要地表达出来，包括游戏名称，类 型，方向，设置，差异性，平台以及其它关键内容（差异性是指如何让你的游戏有别于同类型的其它游戏）例如： “《Man or Machine》是一款PC平台上的第一人称射击游戏，游戏使用《Quake II》引擎将玩家带进了37世纪的高科技星际战争中，他们将在此扮演一个机器人太空战士的角色。 ” 用几个句子描写介绍能够更加清晰地向读者解说内容。但是你同时也需要记住，如果你介绍的内容越繁琐，读者便很容易觉得你的观点不具有说服力。 背景（非必要选项）：游戏理念的背景内容与你在介绍中所提到的产品，项目，授权或者其它属性相关。本质上来看，背景是独立于介绍内容，所以如果读者已经拥有了相关的背 景知识便可以轻易跳过它。不过对于那些授权游戏，续集游戏或者深受早前相同类型影响的游戏，背景尤为重要。如果你想要使用现有代码，工具或授权使用一个游戏引擎，你就 需要在背景中描写清楚这些内容以及它们的优势。 描述：通过使用几个段落或者一页的空间，将读者当成玩家对他们阐述你的游戏。你需要以第二人称的表达方法——“你”进行描述，并努力让这部分内容成为让玩家兴奋的叙述 体验。在此，你可以通过描写玩家该做些什么或者能够看到些什么而向他们传达核心游戏玩法；避免一些细节描述，如点击鼠标或击键，但是也不能太过含糊。你希望读者们都能 融入游戏角色中。同时你需要将细节关卡适当地安置在GUI互动上。你的表达方式应该像“查看你的战术雷达并捕捉更多靠近你的妖怪”，而不是“你应该点击战术雷达按钮，随后 会挑出一个窗口告知你有两个妖怪正在逼近你。”你必须利用描述内容有效且清晰地呈现出游戏内容和娱乐价值。 主要特色：游戏理念的主要特色就像是一个项目清单，能够帮助你的游戏区别于其它游戏，并为后来的文件明确方向。这是对于描述阶段所提到的功能的总结。而这些项目内容将 最终出现在游戏包装背面或促销单上，并且同时也将包含一些延伸内容。例如： “高级人工智能（AI）：《Man or Machine》将使当年《半条命》中富有挑战性和真实感的AI实现更大的飞跃。” 判断该罗列出多少特色也需要仔细掂量。如果你面对的是比益智游戏更复杂的游戏，那么只罗列出1、2个主要特色便不是明确的决策；相反地，如果你的特色超过1页篇幅，玩家便 会感觉自己好像面临非常艰巨的任务，并因此感到胆怯。总之，罗列出过少特色便不能很好地传达你的理念，而滔滔不绝的内容也会冲淡游戏特色的价值。 要切记，不要列出那些众所周知的特色，如“炫目的图像”或“动人的音乐”等，除非你真的认为这些特色远远超越其它竞争对手。华丽的图像以及吸引人的音乐等都是人们对每 一个游戏项目的默认目标。但是，如果你的游戏真的拥有独特的图像或音乐并且能它脱颖而出，那你就应该明确地指出这一点。 类型：也就是定义游戏的类型。以来自杂志或者获奖游戏类别为向导。例如，你可以从如下游戏类型中做出选择：运动类，即时策略，第一人称射击，益智，赛车模拟，冒险，角 色扮演，飞行模拟，竞速射击，模拟上帝，策略，行动策略，回合制策略，卷轴射击，教育类或飞行射击游戏等。然后你可以根据这些名称或重新使用其它短语定义游戏，如现代 ，二战，现实交替，后启示录，未来主义，科幻，幻想，中世纪，古老，太空，网络朋克等。 平台：也就是列出目标平台。如果你认为游戏理念同时适合多个平台，你也应该明确那个属于优先平台。如果你希望创造的是在线多人游戏模式，你也需要注明。 概念艺术（非必要选项）：采用一定的美术元素能够帮助你更好地传达理念，并让读者以更加积极的心态感受你的游戏。使用美术去传达独特或复杂的理念。屏幕模型能够帮助你 有效地传达各种想法。但是因为游戏概念艺术超出了许多开发人员的能力范围，如此便可能导致他们所提交的创造理念大大减少；所以这是一种可选择的项目。如果你确定一个理 念具有价值，那就可以从其他技术资源中提取其美术元素。通常，来自于早前项目或者网上的美术内容都有助为文件增色。但要注意避免版权问题。 常见错误 以下是开发者在创造游戏理念时最常遇到的问题： 理念完全不符合公司当前的规划。如果你不想浪费时间去撰写一些矛盾的理念，你就需要好好寻找真正适合自己公司的理念，并学会判断哪些哪些想法才是真正有帮助的。 从资源上来看，文件中的某些要求总是背离现实。你需要尽可能将自己的理念保持在适度范围内；通过使用现有的工具或属性控制预算。确保你能够在特定时间以及合理预算范围 内实践想法。将你的实验技术限制在一个特定区域内；最好不要轻易尝试具有变革性的AI以及最先进的3D引擎。如果你正在创造自己的游戏理念，你就必须先明确时间安排和预期 预算。 文件缺少内容。就像是“《命令与征服》结合《机甲战士》，你命令自己的‘Mech加入战斗，’”但是这种表达却远远不够充分。你的描述必须解释清楚玩家应该执行何种行动， 从而让他们能够对此感兴趣。优秀的描述应该是：“你命令自己的Mech直接朝着Clan MadCat OmniMech暴露的躯壳射击。”这样的描述内容才能消除玩家对于核心游戏玩法的误解 。 游戏并不有趣。一个真正有效的方法便是分解所有玩家可能执行的动词（游戏邦注：包括射击，命令，奔跑，购买，构建以及观看等）并想象玩家是如何执行每个动词。随后，基 于每个动词询问自己这是否有趣；然后问自己目标玩家是否会觉得有趣。你必须确保自己足够客观地回答这些问题。如果你认为玩家所采取的行动不够有趣，你就应该立即为其设 定其它更加有趣的行动。 使用了拙劣的语言和语法表达。你应该仔细检查语法和拼写，避免出现一些不雅或具有诽谤性的言语。因为你并不知道谁最终将阅读你的文件，所以你很难判断某些特别表达的单 词是否会侵犯读者。不论是带有大男子主义，歪曲的政治立场，文化冲突等元素的表达，还是你在午餐时间所开的一个低俗笑话都不应该出现在文件中的。 设计师放弃表达理念。千万不要放弃提交更多创意理念，因为你永远不知道哪个理念才能真正创造出成功的游戏。相信我，坚持总是会有回报的。 游戏提案 游戏提案是用于明确游戏开发项目所需要的资金和资源的正式项目提案。你需要投入一定的时间（当然还有金钱）才能创造出合理的游戏提案，并且它却只针对于那些具有发展前 景的游戏理念。 游戏提案是游戏理念的延伸。撰写游戏提案也需要包含来自于其它部门的反馈和信息，特别是来自于市场营销部门（如果存在的话）的信息。你的市场营销部门必须能够针对于游 戏理念进行一定的市场研究和分析。而如果你的游戏是授权产品，那么财务和法律部门就需要出面审查许可证的可用性以及其中所需要的成本。 程序员，特别是高级程序员或技术总监，应该执行理念的最初技术评估。他们应该评估理念的技术可行性以及那些需要深入研究的程序编制领域。他们应该评估项目的风险以及主 要任务，并制定相关策略或找出替代选择。同时他们也需要粗略评估研究与开发所需要的时间和资源。 游戏提案中应该包含游戏理念的修订版本。关于理念文件的技术，市场营销以及财务反馈都将要求你适当压缩理念内容；但同时你也可能需要修改并添加其它功能。并且你需要确 保这种改变不会让任何人感到惊讶，因为这是理念首次接受批评与协作讨论的过程。在正式创造出游戏提案之前将相关反馈和分析副本提交给开发总监（或其他要求审查游戏提案 的人士）过目；这不仅能够让一些特定人士或部门给予理念相应的书面评价，同时也给予了总监否决，修改或主张其它提案的权利。 游戏提案包含以下内容： 修订后的游戏理念（前序要素） 市场分析 技术分析 法律分析（如果可行的话） 成本和收益预测 美术 市场分析：市场营销部门或者市场研究公司（如果你的公司支付得起这笔费用）应该编辑这些信息。而如果你是自己进行编辑，你就应该竭力避免乱猜数字的可能性。在网络上寻 找信息，并基于现有同类型游戏的点击数研究它们的市场表现。 目标市场：目标市场是基于游戏类型和平台进行定义，在理念文件中已经相应地处理了这些问题。你可以根据一些已经成功占领市场的特定游戏进一步分析这一定义。最成功的游 戏总是能够预测市场的发展潜能以及规模；并且你也能够因此了解到典型的用户年龄范围，性别以及其它重要的市场用户特征。而如果你的游戏包含有授权属性或者属于续集游戏 ，你就有必要描述原有市场情况。 表现最佳者：列出市场中的表现最佳的游戏。你应该指出它们的销量，获得突破的数据以及取得成功的续集作品。同时还应明确它们的发行日期；但是不需要过于精确标注出来， 就像1998年第一季度或1998年春天如此即可。在这种研究过程中我们可能需要追溯到早前的一些信息，所以你最好能够按照时间顺序罗列这些数据。 列出这些游戏所属平台（如果这些游戏所在平台，与提案游戏不同）。因为平台的改变也会引起市场变化，所以你应该始终罗列出目标平台上一些相同类型的游戏，即使它们的市 场表现不如其它游戏；因为这些数据能够提醒你某种特殊类型游戏在某一平台上的发展较为萧条。例如，回合制策略游戏在PC平台上具有非常好的销量，但是在索尼的PlayStation 上却成绩惨淡。所以如果你面对的是回合制策略游戏，你就应该在最佳表现者的列表上同时呈现出糟糕表现者的情况。 比较特色：分解这些最佳表现者的卖点，将其与理念文件中的主要特色进行比较；并尝试着提供一些细节描写。举个例子来说，如在《命令与征服》，《黑暗王朝》以及《神话》 中的策略战斗中，你将出于某种优势而命令自己的单位去攻击特定的目标并将其移动到特殊位置或范围内。玩家在游戏过程中将会发现大多数单位的独特优势和劣势，并因此备受 鼓励而创造出超级战术。Tanktics》中拥有各种类型的命令，让玩家能够在此执行超级战术，如捕获，撞击以及击跑配合等。而因为游戏中的地形，移动以及奖励范围；射击弧 以及后击和侧击位置的弱点使单位位置的设置和目标的选择变得更加重要。所有的单位都拥有不同的武器，装甲以及速度，以此能够区别它们的优劣势并鼓励玩家制定战术。随着 时间的流逝，你不仅能够精通这些战术，你也能够根据自己的命令而编写策略脚本了。 技术分析：技术分析一般是由经验丰富的程序设计员执笔，如果是技术总监或者首席程序员便再好不过；随后再进行编辑而成为最终的提案。提案评论者将使用这些技术分析做出 决策。并且老实说，技术分析还能够让评论者更加乐观地面对游戏机遇。 实验性功能：明确设计中那些具有实验性的功能，即未经实验或未经证明的技术，方法，看法或其它独特的理念。排除那些已经在现有游戏中得到证实的功能，即使它们对于你们 的开发团队来说还很陌生。例如，即使团队从未开发过3D引擎，也不能轻易将其当成实验性功能；而是应该将其归为技术分析内容中一个或多个类别中。另一方面，如果你的开发 团队正在使用quads体系开发3D引擎，那么你便能够将这种体验记录在实验性功能列表中。 估计实验性功能达到评价状态需要多长时间，以及完成整个功能又需要多长时间。一般来说，你的安排列表中总需要为实验性领域挪出更多时间，所以如果你罗列出更多实验性功 能，你就需要投入更长的时间。尽管很多公司都尽量回避那些耗时18至24个月的游戏项目，但是也有很多开发者意识到，如果要开发一款具有领先优势的游戏，这种实验值得一试 。 主要开发任务：通过一个段落或者一些项目符号明确列出主要的开发任务，并使用普通人也能够理解的非技术类语言。“主要”主要指开发月数。你需要假设你拥有开发所需要的 所有资源，而因此估计你完成该任务需要多少时间。你同样也可以估计你所需要的资源。例如：“人工智能脚本解析器：需要两个程序设计员花费3至4个月的时间。解析器将阅读 并以较低级别的逻辑编辑AI脚本，并基于运行时间做出指示。” 风险：列出任何技术风险。如果你不能预见任何技术风险，请务必说出来。风险是指研究开发过程中因为失败而造成的挫折（引起工作延误数周或数月）。记录下技术——尽管这 些技术可能已经得到竞争者的成功证实，但是你们公司却从未尝试过或者说对此没有任何经验。例如，如果你的公司从未开发过一款即时策略游戏，那就记录下即时策略内容；或 者如果你们公司首次接触3D，那就记录下3D渲染技术等。记录下之前提过的任何主要开发任务——如果你察觉到其中的风险。同时，所有未经实验的解决方法（游戏邦注：包括3D 引擎，编辑器，代码库，API以及驱动器等）也应该被当成是风险而记录下来，因为这些方法可能最终也不会满足你的特殊需求。记录下任何经由外部承包商进行的开发工作，因为 通常来说这种行为总是具有较大风险。当你在评估风险的同时，你也应该清楚修改或替换这些风险技术会带来何种影响。以周或月为单位指示发行日期。记录下时间对于任何特殊 资源的影响。记录下任何能够修改风险的新资源（包括人力，软件，硬件等）。虽然这个阶段看起来很繁琐，但是它却能够为你的文件评论者创造一个舒适的阅读环境，即他们将 会认为游戏执行始终处于适当的控制之下（特别是当他们自己也能够察觉到风险的存在时）。除此之外，你还能够有理地说道：“你可别说我没有警告你”之类的话。 替代性选择（如果有的话）：替代选择是你围绕着这些实验性或风险性功能，以及致力于主要开发任务时所必需的元素。通过明确替代选择，有助于文件阅读者自己做出选择。例 如列出任何需要耗费更多时间和金钱但却能够获得更好结果的选择，或者相反的内容（花费更少的时间和金钱但是结果却不如预期那般令人满意）。不管你给予何种选择，都需要 明确说明它们的优劣。 估计资源：记录下估计资源：员工，承包商，软件以及硬件等等。对于公司外部人员（如那些也有可能阅读文件的发行商或投资者）则使用一般的产业标准模式。以月或周为单位 记录下所需要的时间。此时无需考虑实际成本（以美元为单位），因为这是我们在之后才需要明确的内容。 估计时间表：时间表是遵循我们的里程表估算的全面开发周期，即从最早的起始日期开始，然后经历开端，测试以及正式发行。 法律分析（如果有的话）：如果你的游戏涉及版权，商标，特许权协议或者其它牵扯到费用，诉讼成本，版权声明或者限制条件的合同问题，请务必在此罗列出来。并且无需提及 游戏名称或logo版权的必要性，因为这都是众所周知的内容。 成本和收益预测：与财务和采购部门协作进行成本和收益的预测。这些数据应该让读者们能够基于技术分析所估算的资源大概清楚资源所需成本。 资源成本：资源成本是基于技术分析所估算的资源。就像员工成本将基于工资和日常开支，而这也是财务或工资管理部门应该提供的数据。你可以通过名称或标准去记录这些平均 数值。同时，你也应该记录下你所购买的任何软件或硬件，即使你将在其它项目中使用这些资源或者它们将被整合进日常开支预算中。使用表格或嵌入式表格以帮助你更加轻松地 进行编辑，并让读者更加清晰地进行阅读。如下图：  table(from gamasutra)
追加成本（如果有的话）：这是指估算授权，承包，外包测试等产生的额外费用。 建议零售价（SRP）：你应该在你的游戏沦为讨价还价牺牲品之前明确一个建议零售价。建议零售价应该基于现有游戏的价格，并评估游戏开发的总体价值以及生产开发成本等。当 然了，发行商总是想要压低游戏的定价，或者通过各种促销方法进一步压低游戏价格，不过这些方法最终也能帮助你的游戏取得不错成绩。因为你需要牢记，越高的定价也就意味 着越低的销量，特别是当你面对的是市场上竞争激烈的游戏类型（即供过于求）时。 收益预测：你应该根据自己所罗列出的成本以及建议零售价而呈现出悲观，预期以及乐观三种销量值。而市场营销或者公司日常开支等元素则不包含在此范围中，因为这些内容都 属于可变化的内容；但是如果你知道最低市场营销预算值，你就应该将其涵括在考虑范围内。通常情况下，圆形分格统计图表或者长条图都非常适合呈现收益预测数据。除此之外 ，你还应该呈现出技术评估所描写的风险成本，以及使用或不使用风险评估的预期总值。 美术：如果你的游戏理念中未包含任何美术内容，那么你的游戏提案中就不能缺少这些内容。美术内容必须由熟练的设计师所创造，所以你应该删除或替换掉理念文件中那些非设 计师创造的美术内容。美术能够明确游戏基调。如果你的读者只是根据美术效果去评估提案，你就需要确保在美术内容中展现出游戏的风格和目的。美术内容包括彩色或黑白的角 色，单位，建筑，武器示意图；动作动画；并且如果你的游戏是驾驶模拟游戏，也可以包含GUI实物模型等。确保你拥有精致的封面图像。在文件页面中张贴图像能够为你的文件加 分，并更好地引起读者的兴趣。 描述：整份提案文件应该包含改订过的理念文件，印刷成册并与美术副本一起装订在特定的报告文件夹中。你应该将这份文件呈现给那些前来你的办公室拜访的商务人士。你应该 始终牢记你需要一大笔的投资，所以要尽可能让你的提案看起来更加吸引人，从而能够吸引投资者的注意。用某些程序（如微软的Persuasion）播放灯片能够帮助你更好地阐述关 键点并呈现美术内容。 常见问题 准备游戏提案时常常出现的一些问题是： 用一些没有根据的数字进行分析。通过罗列资源或者解释你如何获得这些数据进行证实。如果制作人凭空捏造一些数字并将其用于文件中，读者便不会信任并阅读他的文件。 提案太过乏味。这是一份有关销售的文件，所以不要让你的读者感到无聊。将事实呈现给他们，并且确保这些事实足够有趣，简洁且有说服力。 提案不能提前解决一些常见的问题。你应该清楚你的提案真正面临的是什么——其它提案，竞争产品，财务问题，成本和时间预期值，游戏偏见以及历史灾难等问题。而如果你能 够先发制人地解决这些问题而不是留到评论过程中等待评论者逐步挖掘，你的提案便有可能获得认可。 提案作者对于批评总是太过敏感。不要惊讶你的游戏提案发起人提出一些完全相反的观点。你需要做的只是保证提案的一致性，相信它并保持自信，如此你才能经受各种批评的挑 战，并让支持者始终站在你这边。 提案作者过于刻板而不愿意改变游戏。通常在收集研究或接受来自评审委员会的批评意见时，你会发现一些需要你改变游戏或压缩设计的合理建议。游戏开发是一个相互合作的过 程。你应该接受反馈并改变设计，否则你的游戏将只会止步不前；并且只有这样你的游戏才能保持活力并持续发展。 功能 vs 技术说明文件 游戏行业传统上只有一种说明文件，涉及多少技术内容主要取决于文件撰写人的意愿。而程序员之后所写的用于执行过程的文件，一般都是非正式内容，通常写在白板或记事本上 。但为了确保项目执行顺畅，按期交付并且不超出预算，这种项目说明文件就应该包含更多技术内容。制作如此详细的技术说明文件需花费一些时间——而如果产品目标和功能发 生变化，或者未通过批准，那么这些时间就白费了。 但随着更多富有经验的程序员和软件开发项目经理加入游戏行业，这个问题也得到了妥善解决。这些人才引进了新的文件设计标准，确保项目规划更明确，并减少了技术性问题。 他们将设计文件按照目标、方法、功能和技术类别，将其划分为功能说明文件和技术说明文件。这样产品客户、用户或主设计师就可以浏览功能规范书，直接反馈是否赞同指定软 件的目标和功能，而无需考虑将由程序员等人员来处理的技术性决策和文件。 因此，技术人员需等到功能说明文件通过审核并签收之后，才开始制作技术规格书。他们无需理会功能文件签收之后的任何设计变化，除非该文件更新并制定出新规划。这样就可 以节省程序员的时间，让他们更好把握自己的工作安排，专注于解决执行过程中的开发方法和技术问题。 不过也有许多公司至今仍将功能规范书称为“设计文件”，但同时也会制作技术说明文件。 游戏中包含哪些内容及其用途都是功能规范书所涵盖的内容。其中包含内容通常取决于撰写者的立场和想法。而如何执行及其运行这些功能则是技术规格书的内容（游戏邦注：其 撰写原则主要取决于系统角度）。这两者都是游戏开发过程中设计阶段的重要环节。 功能规范书撰写原则 功能规范书（以下简称规范书）是产品功能及特色的概括。其瞄准的读者则是执行这些工作的团队，以及负责审核游戏设计的人员。规范书是游戏理念、评论及讨论的顶点，它是 游戏理念大纲及项目提案所描述愿景的具体化版本，它是技术规格书、项目进程安排和执行的起点。 必须从用户角度撰写其中所有内容。换句话说，这个文件中要描述的重点就是用户所看到、所经验或接触的内容。人们总是易于将其制作成以系统为导向的文件（尤其是程序员） ，但这些抽象内容非常不利于目标读者阅读和理解。读者只希望通过这份文件想象游戏中发生的情况，而不是其运行原理。 这种规范书可能短至10页，也可能长达数百页，其长短要取决于游戏系统的复杂性。但一定不能指望一页纸就了事。我曾见过不少非常出色的设计文件，有些不足50页而有些却更 为冗长，重要的是内容明确而非篇幅长短。 这类文件的撰写时长也不尽相同，如果是益智游戏可能几天就足矣，射击游戏游戏是一个月，而RPG或策略游戏等更复杂的项目可能长达数月。需注意，文件撰写时长与其篇幅长短 未必成正比。造成这种情况的原因包括考虑时间长短不同，当游戏拥有独一无二、原创的特性，或者玩法极具深度时更是如此。当然，主设计师制定决策的效率也会对文件撰写时 长造成影响，尤其是当大家对这个游戏项目都很有想法和激情的时候。 对多数人来说，这个功能规范书就是设计文件的开端。他们可以直接跳过概念文件和项目提纳中的市场调研和评审阶段（游戏邦注：这方面内容旨在锁定项目愿景和目标市场）。 游戏首席设计师通常就是功能规范书的撰写人。这份文件可能是集体智慧的结晶，也可能只是落实到书面上的制作人项目愿意。有时候制作人也会自己动手完成这个文件，这就可 以确保文件表达的正是其本人的想法。与打电话游戏一样，在撰写这种文件的时候，项目负责人所表达的想法可能与后来写在书面上的内容存在出入。无论是哪种撰写过程，或者 由谁负责撰写文件，重要的是制作人和首席设计师对这个文件达成了一致意见。不可出现口头所说与纸上所写内容相左，或者完全无视文件内容的情况。 我还没见过不会在执行过程中发生变化的设计，重要的是针对文件内容进行沟通和交流，即使需要更改或添加内容也不例外。有些变动由于时间有限，需要立即处理，这样才能让 文件清晰明了。即使这些变动只是写在电子备忘录或者纸张上，也要确保将其添加到未来的规范文件中。但如果游戏版本发生变化，最好从一个新理念大纲和项目提议重新开始入 手。更新版文件的准确性有利于节省未来的大量时间。 另一方面，这个文件不能出现太多技术倾向，因为它的读者基本上不是程序员。如果你发现它出现技术倾向，那就要收手了，因为这是技术规格书所写的内容，否则就会让非技术 读者像看天书一样不知所云。与此同理，你或者其他撰写者可能也未必是技术人员，所以无权通过这份文件指令程序员如何执行工作。这要让他们在书写技术规格书时自己决定。 毕竟这个文件纯粹是用于交流和审核产品内容，而非指导如何完成任务。但你可以针对自己认为非常重要的地方进行一些简短描述。例如，你不能指令使用哪些变量，以及如何使 用这些变量去模拟一个物理定律，但你可以指出与这个物理公式有关的因素。同理，你不应该告诉程序员如何定义他们的数据结构和对象，但可以针对数据输入界面和数据描述提 出一些建议。 功能规范书可以划分为以下6个主要版块： *游戏机制 *用户界面 *美术和视频 *声音和音乐 *故事（视情况而定） *关卡需求 游戏机制 游戏机制要以详细术语描述游戏玩法，它始于核心玩法，其次是追随玩家游戏活动的游戏流程。剩下的都属于无限的细节内容。 核心玩法：要用数个段落描述游戏本质。这些文字好比是设计发芽的种子，将其植入一个已知市场的土壤，它们就会开始生根，牢牢把握目标愿景，以繁衍出成功的游戏。这与游 戏理念大纲中的描述版块内容相似，但它属于非故事内容，并且其要点描述更明确，但这一点主要取决于不同游戏类型的要求。 游戏流程：对玩家活动进行详细描述，注意玩家在这一过程中的挑战性和娱乐性的发展。如果说核心玩法是大树的根，那么游戏流程就是树干和分枝，所有游戏活动都是从核心玩 法扩展而来。要明确指出玩家所执行操作，尽量使用“射击”、“指挥”、“选择”和“移动”等准确的词语而非“点击”、“摁压”和“拖拽”等字眼来描述内容。因为这种描 述差异可能会对GUI运行方式产生影响。如果你在此首次提到屏幕、窗口或指令条等GUI元素，那就要记得将读者引向“用户界面”版块的内容。 角色/单位（视情况而定）：它们是在游戏中受玩家或AI控制的演员。这里应包含一个简短描述和一些合适的数值。这些数值需划分成A到Z或者“高到低”等级，这样才能明确每个 单位彼此间的地位。但此时不宜插入准确数据，因为程序员到时候自然会在技术规格书中提到这一点，并创建一个可让你试验这些数值的环境。除了数值之外，这里还要列出单位 的特殊技能或能力，并进行简要描述，但如果这些内容很复杂，可以在“玩法元素”版块进行扩展。 玩法元素：这是针对玩家（或者角色/单位）所能接触或获取的所有元素的功能描述。其内容包括武器、建筑、转换器、升降机、陷阱、道具、咒语、升级能量和特殊技能等。在描 述每个种类特点之前，要用一段话指明这些元素的引进或交互方式。 游戏物理和数值：要划分游戏中的物理元素，例如移动、爆炸、战斗等，将每个种类分成一个子集。根据分配给角色、单位和玩法元素的数值来描述这些物理内容的外观和感觉。 要指出催生这些物理功能所需的数值。描写这部分内容时要征求程序员的看法，例如游戏如何处理这些物理内容，数量如何严重影响玩家表现等问题。 这里的内容可能有点枯燥，但切记不可过于技术化。不要使用确切的数字或编程术语。因为这些都是程序员之后撰写技术规格书所考虑的内容。只要告诉他们你希望获得什么效果 即可。例如，“这些单位上坡时会减速，下坡时会加速，除非它们是滑翔或飞行工具。攀升和加速的数值，以及倾斜角度会影响它们的表现。”你不可告诉程序员应该使用哪种算 法调整速度，因为你自己并非程序员，他们才是这方面的行家。 人工智能（视情况而定）：这里要描述游戏AI的理想行为和可用性。其中包括移动（寻径），反应、触发器、目标选择，其他作战决策（游戏邦注：例如射程、定位等），以及与 玩法元素的互动。要描述关卡设计师控制AI的路径，例如使用.INI文件，包含游戏数值或C代码的文件，专用AI脚本等。 多人模式（视情况而定）：要指明多人玩法模式（例如：贴身肉博战、合作对付AI、团队等），以及在不同网络中这种模式所支持的玩家人数。要描述多人模式与单人模式在游戏 流程、角色/单位、玩法元素和AI上的区别。 用户界面 因为界面变动很频繁，所以我们看似没必要将其列入文件。但是，我们将其组织到文件中，就可以最小化设计变动所造成的影响。这里的内容包括屏幕和窗口导航流程图，所有的 屏幕和窗口功能需求。完成这一步后，GUI美工才可以根据需求自由发挥创意。而在美术动工之前，你得先提供模型。然后描述所有需要编程的CUI对象。  game UI flowchart(from behance.net)
流程图：这是多个屏幕和窗口的导航图表。可以使用VISIO或类似的流程图工具将已标签和标数的方框连接起来，使其代表屏幕、窗口、菜单等元素。要记得在每个表格的角落列出 所有项目的序号，以方便程序员理解和落实工作。 功能需求：这是每个屏幕、窗口以及菜单的功能分解，它应列出用户操作及预期结果，可能还会包含图表和模型。可以适当列出一些具体交互行为（例如按钮、点击、拖放和产生 动画），但最好不要在此添加过多这种内容，因为这会涉及到执行方式。当然，如果点击按钮这种描述更易理解，或者真的很有必要指出某物的特定运行方式，那就要详细指出其 交互方式。 模型：针对所有屏幕、窗口和菜单创建模型。这一点通常被人所忽视，但如果美工对其工作没有概念，就可以利用模型启发他们。不要费太多时间创建精美的模型，只要用一些文 本标签画些简单的线条即可。没有必要上色，因为这可能弄巧成拙，除非颜色真的很重要。可以利用一些绘图软件提供的模板快速建模。 GUI对象：这是创建所有屏幕、窗口和菜单的基本模块。这里并不包括主视图入口的项目，因为它们会出现这后的美术列表中。罗列在此的GUI对象主要用于帮助程序员了解自己需 要编辑的内容。你应该详细说明这些模块的交互方式。虽然这看似不值一提的内容，但结合技术规格书与项目安排来考虑事情，无疑更有助于了解项目整体需求。 有些游戏很容易整合GUI对象列表中的按钮、图标、指针、滑块、HUD元素等内容，但界面截然不同的游戏则未必如此。但无论如何，对象之间的交互方式不会有太大出入，毕竟按 钮就是按钮，点击女妖的头部与点击灰色矩形并无区别。 美术和视频 这里就需要列出游戏中的所有美术和视频内容。可以添加一些占位符参照内容以便之后命名，例如特定任务的美术内容，用于营销材料、样本、网页、手册和包装的美术内容。 总体目标：在这里你要将图案、特点、风格、基调、色彩等与美术目标有关的内容描述清楚。要确保主要美术设计人员和美术总监与项目总监或制作人达成一致意见。这样就可以 节省下日后的返功时间。 2D美术&动画：这真是一个足以纳入美术工作安排的大型内容列表，必要的话也可以加入描述内容。有些美术内容需要额外说明，而有些可能有特殊的设计要求，这些都要一一说明 。可以将美术内容划分为多个版块。主设计人员可能有一些自己喜欢的安排方式。以下是我列出的这些典型版块内容： *GUI：屏幕、窗口、指针、标记、图标、按钮、菜单、外形等。 *营销及包装美术设计：你在这里和美术工作安排中可能都要考虑到这一点，其中包括网页美术设计、销售传单设计、样本启动画面、杂志等平面媒体以及包装合、手册中的美术设 计。 *地形：例如区块、纹理、地势目标和背景等场景美术。 *玩法元素：玩家和敌人动画（精灵或模型）、玩法结构和互动物体、武器、升级道具等。不要忘了还有受伤状态。 *特效：喝彩、爆炸、火花、足迹、血迹、碎片、残骸等。 3D美术&动画：这里的需求和用途与2D美术列表相同。其中差别可能就在于任务分工不同。美术团队通常会将3D美术任务并入建模、纹理、动画和特效工作，以便最大化利用成员的 技术，并保持工作一致性。 电影艺术：这通常是指介于不同任务之间，以及出现在游戏尾声的2D或3D场景。这原本应该像电影脚本一样另外撰写一个文件，但这属于制作方面的工作。功能规范书一般也会将 其纳入文件在，列出其一般用途、内容和目标长度。如果涉及相关视频内容，就会将其列入以下的子集。 视频：除非你是制作全动态影象（简称FMV）游戏，否则就没必要在这个子集中投入太多精力。如果你的GUI中有个用来阐述情节内容的视频，就可以将它纳入此列。所有的视频任 务都需要编写脚本，但这属于制作工作。这里也要列出一般用途，预期长度，以及演员数量、场景设计等一般内容，即便它只是个由蓝屏切入3D渲染背景的镜头。 声音和音乐 总体目标：强调声音和音乐的美学和技术目标。描述你所追求的主题或基调，可以列出原有游戏或电影作为参照。要指出技术要求和剪辑目标，例如采样率，磁盘空间，音乐格式 和转换方法。 音效：列出游戏所需要的所有音效及其使用位置。要列出预期的文件名称，但在文件命名规范上要与声音程序员和音效技术人员进行沟通，以便大家快速找到音效文件，并将其运 用到游戏中。 不要忘了所有可能需要使用音效的地方。所以要浏览一遍游戏元素及美术列表，看看还有哪些地方需要添加声音元素，以下就是一些值得考虑的地方： *GUI：点击按钮、打开窗口、确认命令 *特效：武器开火、爆炸、雷达鸣响 *单位/角色：对话录音、跺脚、碰撞等 *玩法元素：拾取物品、警报、环境声效 *地形（环境）：鸟声、丛林声、虫鸣声 *移动：风声、脚步声、地板咯吱声、涉水声、踏入泥淖的声音 音乐：列出游戏中的音乐需求及其使用位置。描述音乐基调和其他微妙特点。游戏通常会重复使用一个主题和旋律，要指出需要重用这些主题的地方，并且咨询作曲人的看法。 *事件：成功/失败/死亡/胜利/发现等。 *屏幕：针对开头、鸣谢和结尾屏幕设置的音乐基调。 *关卡主题：针对特定关卡的音乐（由其设计师选择音乐主题）。 *情境：设置不同情境的基调（游戏邦注：例如危险逼近、战斗和探索的时候）。 *电影音轨 故事（视情况而定） 写下游戏所讲述的故事概要，包括背景故事和角色细节描述。要指时游戏文本和对话需求，以便将其添加到项目进程安排中。但也不可过份纠缠于这些细节以至于忽视其他内容， 毕竟讲述故事并非多数游戏的重点。当然，如果你开发的是一款冒险游戏，那就很有必要在此多下一番功夫。 关卡需求 关卡图表：不论这是一个线性活动，拥有分枝的任务树，还是一个自由开放世界，这个图表都应该是所有关卡创建的基础。如果关卡结构仅需一个简单的列表就能表述清楚，就不 需要创建图表了。下图是一个典型的成功/失败分枝任务树图表。当然每款游戏特点不同，其图表结构也会有所差异，重要的是要让它成为有助于关卡设计师和读者理解内容的线路 图。 内容揭露计划表：它应该是一个玩家首次接触游戏时所会看到的游戏内容表格或电子表格。它可以是以关卡为行，以每种内容为列。其中的内容包括升级道具、武器、敌人类型、 诀窍、陷阱、目标类型、挑战、建筑以及其他所有游戏玩法元素。这个表格可确保游戏中的内容，即促使玩家进入下个关卡的元素妥当分配，不会出现超量或没有充分使用的情况 。 如果有些内容已经停用，那就最好将这个计划表绘制为Gannt图，用线条指出可用的内容和资产。这样才好让关卡设计师知道自己该在何处下功夫，这样就不会搞砸自己或其他人的 关卡。 关卡设计核心：在写出详细的设计文件之前，要先点出设计核心。设计师用工具试验并开发了首个可玩关卡之后再推出的设计，更有可能获得成功。所以此时最好先列出每个关卡 的核心，描述关卡目标，玩法以及它如何与故事（如果游戏有故事内容）相结合。可以选择先勾勒一个草图，如果设计师对此已经拥有明确想法那就再好不过了。要确保文件列出 了地形、目标、新揭露的内容，以及目标难度等级等特定的关卡需求。 普遍误区 以下是设计师需要注意的一些普遍问题： *细节不足：要用充分的细节传达关卡目的和功能，避免使用一些含糊不清的字段，除非你补充了更多详情。 *越俎代庖：正如你不应该告诉厨师如何使用沙司调味，你也不可告诉美工如何管理自己的256调色盘，不能教程序员如何定义一个特定的数据结构。只要列出重要的目标愿景即可 ，否则只会浪费彼此的时间，毕竟这种细节更适合出现在程序员所撰写的技术规格书中。 *模糊不清或自相矛盾的内容：要警惕这种情况，因为它会使项目愿景偏离方向，产生一些误解，导致功能规范书失效。 *内容繁冗：这份文件可能没有什么明显错误，没有模糊不清的地方，也没有任何缺乏，但就是内容太多了。在充实这份文件时要把握好执行设计的时长，删减非必要的冗余功能， 可以将其保存起来运用到游戏继作中，或者为保留这些功能而争取推迟项目交付日期。 *过于个人化的设计：我曾经强调过游戏设计是一个协作的过程，虽然大家是各司其职地完成自己的工作，但功能规范书应该是集体智慧的结晶，因此它不可以是一项个人产物。否 则会让人觉得自己与设计过程没多大关系，同时也会让这份文件更像是一份命令和计划。团队成员更乐意阅读大家合力完成的设计文件，这样人们提出批评意见时也主要是针对文 件本身而非作者，这样可以让大家更自在地对文件提出改进意见。 *偏离项目愿景：即使拥有一个良好的理念大纲和项目提案，功能规范书也仍有可能出现一些不同解释内容。创意人员通常都有人马行空的想象力，并且很可能在撰写这一文件时受 到自己当时所玩游戏的影响。 技术规格书撰写原则 如果说功能规范书描述的是产品应该包含哪些内容，那么技术规格书解释的就是如何添加内容。技术规格书是游戏的工作蓝图，其作用是促使程序员将设计师的设想转变为现实， 在这一过程中程序员需吃透游戏该执行哪些内容，如何减少执行/集成中的障碍，如何描述编程区以及任务安排。  Game-Design-Document(from gamedesigndocument.org)
许多公司都会略过这个步骤，因为撰写这种文件极为耗时，而且只有程序员可以从中受益。但撰写这份文件总比因未撰写文件而对错误问题采取补救措施更省时省力。技术规格书 的主要作者是主程序员或技术总监，不过如果可以让负责不同编程区域的程序员分工完成内容，这会提高文件撰写效率。必须采用每个程序员都能理解和入手的编辑格式。 该文件的目标读者是项目主程序员以及公司技术总监。因此它是以系统而非用户角度出发撰写内容，看起来会很枯燥，对制作人和其他非技术人员来说简直像是天书。但制作人要 求撰写这一文件的目的在于，确保技术人员考虑周全，即便制作人本身对此并不了解。对主程序员来说，这是一个组织思维和勾勒项目框架的方法。这种编写文件的过程有助于显 示编程环节中的不确定因素和漏洞，以及功能规范书中的模糊或荒谬之处。 许多出色的技术规格书编写格式与本文描述并不相同。这里的格式主要与功能规范书相对应，以确保覆盖所有的功能规范内容。有时候开发团队也可以出于分工不同，或因为基础 系统组织方式而选择不同编写形式。如果这样的话，我建议他们细读功能规范书的每行文字，并以萤光笔标出相关内容，以免忽略某些内容。毕竟疏漏一个细节可能会令产品、项 目和团队动态产生令人不快的结果。 这些原则不会教你如何执行游戏开发，其假设前提是你已经是一个技术能手，富有经验的游戏程序员，而生手则不应该参与这项任务。我认为优秀的技术规格书应该遵从这些原则 ，它们会要求你定义所有游戏中的最普遍元素。有些原则可能并不适用于你的项目，但每个原则都值得认真考虑，毕竟它可能对你有所启发，而这也正是撰写这份文件的意义之一 。 游戏机制 这当然也是这份文件的组成部分。但在这里你会发现将其与功能规范书中的游戏机制部份一一对应的做法有多荒唐了。因为这份文件应以系统为出发点，而不是以设计师或用户的 角度来写作。开篇要提到的是硬件平台和操作系统，外部供应码对象（例如DLL、EXE、驱动器等），并描述内部生成码对象。然后再区分起源于控制环路的特定游戏代码机制。 平台及操作系统：要指出项目所需的硬件平台、操作系统以及支持版本。对PC/Mac游戏来说，要提到最小系统需求和目标运行设备。如果游戏并非以CD而是以卡盘等形式发售，那 就要提到相应的ROM要求。 外部代码：要描述并非项目团队所开发的所有代码来源和用途。这包括操作系统代码和针对不同游戏平台的预处理工具，驱动器和DirectX等代码库，以及项目所需的3D API，或其 他现成解决方案。 代码对象：分解多种代码对象编码、编译和创建到EXE的用途和范围。如果使用到非进程内或者同进程的代码库（例如DLL），那也要分别进行说明，要说清使用对象实例及其存在 目的。 控制环路：每款游戏都有一个控制环路。要详细说明启动代码、主游戏代码的控制转换过程。说明核心循环的功能名称及其作用，例如碰撞、移动和渲染路径。要解释多线程、驱 动器、DLL和内存管理的使用原因。当然，多线程和内存管理的更多详情应该出现于它们使用最频繁的区域，例如渲染或精灵引擎，声音代码和AI。 这部分内容概括的是支持核心玩法的系统和内在框架，以及功能规范书所描述的游戏流程内容。 游戏对象数据：先仔细阅读功能规范书中关于所有角色/单位的描述，以及游戏玩法元素内容。然后规划并列出所有数据结构，以及能够支持这些描述特点、功能和行为的标识符。 从某种程度上说，只有游戏物理、统计数值和AI部分内容考虑周全并载入文件时才可能做到这一点。在为用户界面或任何包含单位/玩法对象特定数据（游戏邦注：例如图票、HUD 元素、动画或特效参照内容）的区域添加统计数值。 如果使用的是面向对象的编程方法，那就要提供类继承树和每个类的界面属性和功能。描述集合的使用方式。列出可能作为全程变量以增强性能的变量，例如可能在碰撞时、移动 或渲染等重要游戏惯例中命被多次引用的对象变量。需要重申的是，我并非教你如何为游戏编程，只是想让你多考虑其中的普遍技术问题，尤其是与整洁性、多功能化或速度有关 的数据结构优化问题。 数据流：要说明数据如何存储、加载、转换、处理、保存和修复。要为数据输入或处理工具提供参考内容，任何复杂或与用户集中型工具都要分别说明功能和技术规范。 游戏物理和统计数值：这里的内容多而繁杂（例如移动、碰撞和战斗等等），但可能也是最有趣的编写和执行内容。但它的代码可能也是编程中变动最为频繁的内容。设计师喜欢 更改内容，并且通常是在游戏具有一定可玩性时才能决定采用哪个设计。因此你的执行计划应该具有模块化和灵活性。要将控制操作行为的所有元素导入可以在运行时间阅读的数 据文件中，这样可以方便设计师在闲暇时间进行调整，无需介入编程调整过程。这个说明文件应该明确区分代码及其控制数据的组合性和分类。 要定义每个函数或程序，描述它的用途，确定由哪些数值来控制它的行为（如常量、变量等）及其修改方法。这包括列出所有参数的函数原型。如果使用到了函数指标和函数重载，则需详细说明要使用哪个版本的函数。例如，你可能有多个处理不同单位类型移动过程的函数——其中一个处理着陆移动方式，一个负责空中移动方式，一个负责水中移动等，可以简要描述函数运行方式。对于复杂的函数，可以使用伪代码去说明编码方式。这一点对于要经常进行数值运算的CPU密集型函数来说尤为重要。要考虑如何对其进行优化以增强运行性能。也许进行一点位移或者使用宏指令就可以提高运行速度。 人工智能（AI）：这个环节通常易于延伸成主要内容，但如果根据项目进程表来安排，又总会削减其中篇幅，仅保留必要内容。这说明设计师对复杂AI的追求有增无减，但由于时
间和资源有限，最后总会让AI变成模拟智能或脚本行为。设计AI方案的时候尤其要注意这个问题。尽量在无需添加大层次的情况下完成功能规范书所描述的行业和决策制定方法， 以免让这一过程呈现不必要的现实主义色彩。在此要运用基本的制作法则，假如可以用更少的成本和时间完成一项工作，那就没有必要投入过多时间和资金把事情复杂化。 当然，这里也需要注意一些例外情况。有时候总有些内容需要更长的创建时间，但完成这些内容有利于节省设计师创建关卡的时间。此外，创建一些更有弹性或强大的内容，也可 以为公司开发其他项目提供宝贵的现成素材，或者让项目更易处理设计变更的问题。所以在制定这种决策之前，要先跟制作人和开发主管讨论可行性。 要确保这里的内容包含功能规范书所提到的AI控制方法，例如它是由数据驱动，还是嵌入编译代码，以及它究竟是一个脚本语言还是一个固定的变量集合，抑或是这两者的合体。 AI内容还应该包括寻径、目标选择、测试和附带相应行为的事件，角色制定的其他决策，与游戏情境相关的单位/智能游戏元素以及单位统计数值。 不要在其中添加驱动AI的实际脚本或数据。因为这是制作团队的工作。只要解释清楚决策和行为起因即可。要区别说明控制行为的统计数值。 多人模式：从多人模式角度来评估执行方案，这一点也非常重要。这部分内容应该分别说明游戏机制中的所有多人模式考虑因素，以及功能规范书中所有与多人模式相关的特定需 求。 在多台PC上的多人模式（不同于共享控制器或hotseat模式）有许多需要解决的独特需求。例如，要考虑游戏支持的是哪种连网方式和网络协议？它是基于客户端服务器还是对等网 络？数据包大小是多少，发送频率又如何？数据包结构是什么？如何解决数据包丢失和延迟的问题？要向特定主机传送什么信息？共有多少不同信息，它们何时使用？ 用户界面 外观和风格是开发过程中最常变化的设计内容。因此，针对GUI的编程很有必要保持灵活性，要将玩法用途与GUI功能相分离，这样用户交互方法的改变就不会影响到游戏的其他层 面，或者产生重大的改编程序。要使用继承类创建多种GUI对象（控制方法）以保持代码界面在事件中的一致性和数值。这样就可以在无需重大改变调用函数的情况下，将滑动块变 换为文本框或按钮。最好将任何GUI对象都设置为可更改状态。 为此，你的文件应该具有弹性和通用性。需要将GUI划分为屏幕、窗口和菜单分别说明，但不可以延伸至特定交互方法，只需写下不同GUI对象运行方式，使用位置即可。 可以引用之前章节所记录的游戏机制功能，但与界面有关的所有信息都要写在这部分内容中。有关图像引擎的绘图和剪辑路径的内容应该纳入美术和视频章节，但如果涉及视察窗 口和HUD附件，以及玩家交互活动的信息就要引用这里的内容。 要列出所有的全程变量、常量、宏指令、函数名或界面属性，这样程序员就知道如何快速引用文件。这也可以避免重复和不一致性问题。 游戏外壳：列出所有组成游戏外观的屏幕——这包括主游戏屏幕之外的所有屏幕及窗口。它们是由功能规范书中的流程图衍生而来，但可能包括一些主设计师所疏忽的额外屏幕（ 例如安装或设置屏幕）。所列的每个项目都要纳入其应用的片段，并描述其用途和范围（例如是在特定关卡数据加载之前还是之后），它将访问和设置的相关数值，它将调用的函 数等。 主游戏屏幕：游戏中可能会有一个或更多与核心游戏玩法有关的屏幕。虽然许多人习惯从GUI角度再到其中复杂性进行考虑，但撰写本文件时要从低级别机制着手，然后再延伸至 GUI。这样即使GUI外观发生变化，也可以保持文件一致性。 美术和视频 功能规范书已经详细列出了美术和视频内容，技术规格书的作用则是解释这些美术和视频内容如何在游戏中进行存储、加载、处理和播放。其中包括动画系统（2D或3D），视频解 压和串流系统。当然有些内容可以采用现成的解决方案，尤其是视频代码。但这里应该提到所有接口技术的问题。 图像引擎：无论你使用精灵、立体像素或3D多边形渲染还是两者兼用，都要在此分别进行说明。虽然只是两句话的描述，但它却可能是这份文件的重要组成部分。要描述视察窗口 、剪辑、特效以及游戏机制中所描述的碰撞和移动函数的关系。  game document(from trac.wildfiregames.com)
美工说明：要为美工指出其中的重要细节，例如解决方案、色彩深度、调色板、文件格式、压缩、配置文件定义以及美工所需要注意的任何数据。要考虑应创造哪种工具来优化美 术通道，并在此指出其特定说明，或针对更复杂及用户密集型工具创建单独的说明文件。 声音及音乐 在此要描述音乐加载及播放方式。要详细说明混频、DMA、多频道、3D音效等情况。如果用到了第三方驱动器，就要描述它们的界面和用途。要确保能够解决功能规范书所提到的一 切相关需求。 音频编程说明：要为音频工程师及作曲人指出重要细节，例如采样频率、多频道使用、3D音效定义、样本长度等。如果使用到MIDI，要指出其使用版本、数量、可以使用及保存的 乐器类型。要注明数据路径，以及包含特定配置文件的文件需求。要考虑到创建何种工具来优化音频通道，并指出它们的规格，针对更复杂或用户密集型工具创建独立说明文件。 关卡特定码 根据功能规范书中的关卡设计基础，描述如何执行关卡特定码，以及它如何达到预期效果。同时也要描述如果出现更多需求时，其他关卡特定码如何与游戏代码对接。一般来说， 你应该让关卡特定码具有通用性和灵活性，使其方便快捷地运用于其他关卡或新创意的相似需求。 普遍误区 以下是你需要警惕的一些常见错误： *遗漏详情：不可只是列出功能而没有补充如何执行功能的所有详情。撰写这份文件的用意是让程序员事先把开发流程过滤一遍，否则他们无法正确预估执行任务所需时间。 *尽管让各个任务指定程序员完成相应文件内容是一种很有效率的方法，但这并不意味着它能给游戏项目带来最大好处，或者程序员就会在没有监督的情况下自觉完成撰写文件的任 务。在这一过程中初级程序员可能需要一些指导，而在所有文件整合在一起时，所有相关程序员都应该对文件内容进行一番讨论和点评。一些公司设置了让程序员相互评论对方工 作的常规代码复查制度，最好在设计阶段尽早展开这种审核工作。 纸质关卡设计原则 在使用编辑器创建关卡之前，设计师应首先制作纸质关卡设计版本。理想情况下，设计师在项目动工之前就已熟悉设计画板、关卡编辑器和游戏引擎功能。要在执行阶段就根据功 能规范书中的关卡设计核心制作好纸质关卡。 这些核心是关卡或基本需求（会指明需要引进哪些新资产或者设计的限制条件）的核心理念。最好不要一次性做齐所有的纸质关卡设计，因为设计师挨个落实每个新关卡时可以学 到更多。 而制作人通常都希望马车跑在马前面，所以在真正的关卡设计开始之前，要首先制作具有可玩性的原型关卡。这通常是确保工具和游戏引擎顺利运行以制作关卡的一个基础。它也 可以作为编辑器和引擎可实现目标的指南，以及关卡设计愿景的缩影。 紧接着就可以开展真正的关卡设计，但即使到了这一步，说明文件在节省时间和确保产品质量方面仍会发挥重要作用。以下是关卡设计需遵从的重要步骤： 步骤1：小样和讨论 关卡设计师要设想一个符何功能规范书和内容揭露安排要求的关卡布局。然后他们就可以制作一个草图并与主设计师进行讨论。这个小样可以是画在白板上或笔记本上，它是促进 讨论的视觉辅助工具。这里不需要表达整个关卡设计理念或所有关卡细节，因为这些通常是讨论过程中所涉及的内容。  sketched-level(from petermcclory.com)
制作草图和进行讨论的好处在于节省时间，无需迫使设计师事先规划好一切并将其编入文件中。高级或主设计师可以在数分钟内决定大家所提出的关卡设计是否可行，并提出富有 价值的改进建议。一份内容详尽的纸质文件可能需要数天甚至一周时间才能完成。设计师的稿件是否会被退回重新修改，则要视其技能水平而定。这在项目动工初期表现尤为明显 ，因为此时设计师仍在揣摩主设计师想要的效果是什么，临近项目尾声时，要得到原创而富有吸引力的关卡设计就更困难了。 步骤2：详尽的纸质版本 在小样和关卡理念获得批准后，关卡设计师就可以开始制作详细的纸质关卡设计版本了。关卡布局应比草图更详细，并且要按比例绘制出来。最好使用彩色铅笔在大张方格纸中绘 图，在地图中要标注对象、行为、建筑、敌人、事件、位置等信息，也可以将其列入另一份单独的索引文件中。还要列出任务特定美术或代码内容。完成这些细节可能需要花费数 天甚至长达一周时间，但比起在真正的编辑器中“搜索”或“重新设计”，这种方法可以省下更多时间。 完成这一步后，主设计师、制作人和其他主要决策制定者就要对其进行一番审核。他们可能批准这一理念，也可能提出一些修改意见，或是直接否决了这个关卡设计。 另外也要让技术型人员，最好是高级程序员从编程角度审核这份书面关卡设计。这样程序员就会留意关卡设计师的理念所涉及的工具和图像引擎。他们可能向工具添加一些功能， 或者对代码进行调整以让关卡设计更具可行性或更易于执行。他们也可能要求移除或修改任何可能破坏游戏或几乎不可行的关卡设计。 人们通常倾向于跳过这个步骤，直接使用编辑器制作关卡，因为创建一个关卡原型往往比制作纸质版本更快。在项目进度安排较为紧凑的时候尤其如此。但项目安排越是紧凑，就 越有必要使用书面文件来规范设计工作，因为事先考虑周全有助于一次性把事情做完，减少意外情况发生次数，节省返功时间。制作纸上关卡设计版本的好处在于，它可能让设计 师事先就考虑到所有事项，在落实设计之前就表达出关卡的趣味和挑战性所在。这份文件还可以确保在设计师开始工作之前，程序员、美工和音频技术人员就已掌握自己的任务安 排。 步骤3：创造关卡核心 设计师需确定关卡核心游戏玩法，应该在纸上设计版本中就体现其想象的趣味性和挑战性。然后征求主设计师和制作人的反馈意见，让他们决定这个设计的好坏。最终的关卡设计 可能未必有纸上设计版本那样可行，或者有预期那样好玩。但这一做法却有助于节省设计师时间，以免发生重大修改或导致整个关卡都被否决。 步骤4：补充更多细节 确定关卡核心玩法后，要确保其他内容都有助于优化和提升核心玩法。这包括确立设置、充实关卡，使游戏更富生气（例如提供更多选项、解决方案或惊喜）的所有内容。 新美术或代码资产通常看起来都不会很协调，所以要确保设计师在植入占位符前就找到所需内容。然后再更新纸上设计和任务列表。 步骤5：玩法测试 让设计师体验这些关卡，并尽量收集更多反馈。这一过程仍然离不开设计文件。要确保设计师至少要用笔记本记录下所有漏洞，反馈和任务。有时候人们很容易遗漏一些问题，所 以最好是将其归档到含关卡特定问题和反馈内容的数据库中。 文件阶段和开发安排 以下是关于项目进度安排中的典型阶段列表，在每个阶段（或称标志性事件）都有一个评审过程。因为只有当文件大部分内容都完成才能制定项目开发安排，所以要确保重新撰写 文件或创建大家都认同的说明书这一过程不会影响到项目开发时间。为了赶时间发售游戏而匆匆编撰设计文件，并草率投入制作是造成项目失败的一大原因。并且这并不能为你节 省什么时间，事实上它只会浪费大家的精力，并且造成更重大的项目延期。 概念阶段： *文件：游戏理念 *文件：游戏提案 设计阶段： *文件：功能规范书 *文件：技术规格书 *文件：工具说明文件（视情况而定） 制作阶段（游戏邦注：有时也称执行阶段）： *制作安排 *技术和美术样本 *首个可玩关卡 *文件：纸上关卡设计（不一定是可交付成果） *Alpha 测试阶段（QA）： *Beta——发布首个潜在码 *Gold Master——发布代码 我们还可以列出更多阶段，因为发行商有必要掌握一些决定和确保项目执行顺利进行的途径。有时候它们会针对特定美术、代码和设计制定每月固定标志性事件。这里所列举的只 是一些最为常见并且更有影响力的情况。 应对变化 看到一个项目依从这些原则而顺利运转应该是一件美妙之事，但有时由于灵感或市场趋势的变化也会让项目愿景转向。人们习惯使用“即时设计”模式以应对新变化，并且不影响 项目安排。有时候这种情况确实难以避免，但这种模式也存在弊端。在这种情况下，唯一可用的方法就是固守这些原则及其程序。如果在合同上提到这一点那就更好了。不要在未 更新有关文件的情况下调整项目内容。要知道功能规范书中的一个变化，可能就会导致技术规格书中的有关内容失效，并影响后续的项目安排。主设计师在签收并交付功能规范书 时必须清楚哪些人可能提出修改要求。如果他们确实需要进行一些更改，那就可以通过更新文件和重新制定项目安排而减少其影响。只要想想卡在项目开发过程中，或被迫延迟任 务的痛苦，就足以成为促使你事先考虑周全，制作好这些文件的动力了。希望本系列文件对你的项目开发过程有所帮助。 篇目2，阐述如何制作一流的游戏设计文件 作者：Tzvi Freeman 我必须做出一个游戏。就在不知失措、头昏眼花之时，我一头撞在了电脑显示屏上。接着，古铜色的灯里轻烟似地冒出了个灯神，许诺我三个愿望。我不假思索地说：“我想要…… *一支有才能、有技巧、有献身精神的程序师和美工组成的团队（包括非常善解人意的老婆一枚）且个个擅长人际交往。 *足够的时间和资金允许搞砸一两次。 *一流的设计文件。 很久以前，编写一款游戏只需要一名程序师（和一名美工）加上接了就做的预算和宽松的开发期限，所以大家对文件编制没必要太上心。你知道想要什么就去做什么。因此，如果在这过程中发生了个把重大变故，你只能责怪你自己。现在，一份周全易读的设计文件意味着什么呢？就是迅速地坠入一文不值的地狱和平稳地飞升到富丽堂皇的天堂之间的差别。  game design document(from techenclave)
如何展开工作？ 大多数游戏的开发从概念到制作完成需要经历三个阶段，即“产生灵感”、“纸上计划”和“身体力行”。 在第一阶段，概念文件不仅是一封写给自己的信——提醒你不要忘记它们；还是一个应对投资商和营销商的销售工具。有时候，还要在这个阶段制作一个微型原型，这样你就可以用它做实验并修改自己的创意。 第二阶段是和一大堆美工、动画师、音乐师和编程人员讨论——实验想法，然后找出组织办法，最后敲定主意。 在最后阶段，管理制作过程的工作通常交给一些擅长处理流程和冲突的行家负责。原创意的设计师可能只允当团队的主要成员，但在许多情况下——特别是在大公司，这位设计师往往变成旁观的顾问。 毫无疑问，如果说设计文件是项目的父母，那么它对项目的成长影响当然最大。即使作为设计师的你兼任项目经理，你也不能欺骗自己：你确实不能全盘兼顾。复杂的项目需要许多有才能的人共同完成。有技术的程序师和美工往往有自己的一套心思。当你打算做一匹马，美工画出的可能是只独角兽，而程序师想到则是吃苦耐劳的骆驼。好的设计文件可以确保大伙想法一致、感觉一致。这好比一支大乐队的爵士乐总乐谱，尽管仍然有大量即兴表演的余地，但在总乐谱统领作用下，大家的心思都被放在一处。 设计文件是想法与现实之间的桥梁。它能确保承载想法的野马不会脱缰跑出现实所能驾驭的范围，同时又保证最后抵达的终点正是最初创意的指向。 最后，记住这句久经玩家证实的格言：“伟大的艺术来自细节”。光彩夺目的细节自然而然地从游戏中流露出来，就好像它们当初从第一道灵感中闪现光芒一样。但是，一旦你进入实际的执行阶段，细节的火花往往容易熄灭。 挑战 给项目制做局部原型当然是个好主意——尽可能画出所有草图。但此外，那些细节才是最重要的。你的想象能承载的细节越多，你的作品就会越出色。 根据文件工作也有消极面。刺激的游戏的开发过程本身就必须刺激。例如，有许多项目的闪光点往往是到了令人恐慌的截止期时才被发现。诚然，时间和成本预算的压力不允许概念的不断重复，但你只是不希望做出一款干巴巴、没惊喜的游戏。制作设计文件的挑战在于，能够忍受你的项目发生意料之外的调整，但又不迷失原创意的整体方向和视野。  策划的三个阶段（from gamerboom.com ）
成功的设计文件十个要点 1、除了形体，还要描述灵魂。 如果游戏开发只是自动输入/输出的问题（就像编写代码和预测过程）——那么你只需要一份干巴巴、描述性的文件就行了。但事实是，开发是人做的， 这些人是有创意的人、有独立想法的人、想在所有自己做的工作上盖个戳的人。 再继续说你想要的那匹马的故事：你把说明书交给美工，然后和他们讨论要做什么。之后你给程序师看了下说明书。两边都对你所说的话点头称是。 当天晚上，大约凌晨2点，正当C++的群星闪烁在西天，处于中年危机的程序师开始胡思乱想：“什么，我的下半辈子就是一个程序呆子？我妈对我的指望就这样？为什么，我也可以像其他人一样设计游戏！“然后继续埋头输代码。 大约与此同时，美工等着他那台陷入死机的电脑完成复杂的3D渲染，等着等着就睡着了，这会儿刚醒过来。他不确定也不关心他是不是在做梦，或者从这些工作中取得报酬，只是沉浸在艺术天才的狂想世界里，在不可思议的幻想和现实的融合作用下，神兽诞生了——当然不是你文件所描述的那匹马。 第二天一大早，你的马，当然没来，来的是长着两个驼峰的独角兽。对于这些创意星人，光给指示行不通，启发才是硬道理。 在你的设计文件中，别满足于对各个物品和细微差别的细节性描述。花时间形容一下游戏应该有的感觉、各个元素潜在的目的、玩家应该有的体验和你可以想到的、能够形容的游戏灵魂的方方面面。 例如，你在设计一款射击游戏。你的目标是通过游戏训练玩家如何应对现实中遇到的某些挑战，所以一开始设定的难度不高。你得向团队的所有成员解释你的用意，这样他们才会理解为什么某些东西要放在这，为什么要这样做。即使你的团队不太认真地对待或胡乱删改你的创意，你仍然可以抱着希望，即结果达到或接近整体效果。或者可能还更好。 2、易读性。给团队成员一份每页标明10个要点、无衬线字体印刷、80个字符一行的文本，并且要求每个人都要阅读。你可能得在每件份文件里准备一捆止痛药了——这是为那些确实要忍痛遵守指令的人准备的。 以下是我遵循的页面布局原则： 大片空白 文本主体以衬线字体（游戏邦注：指西文中有衬线的字体，与汉字字体中的黑体相对应）印刷 粗体字标题 段与段之间有空隙 文本句子简短 引导视线直指重点内容 分层次，大纲视图 用表格、图表、图片等说明例子。把图表、表格、图片等制作得醒目一些。 3、区分优先次序。既然你意识到你是和头脑清楚、有自我的人一起工作，就有必要让这些人意识到某些加标记的游戏元素的神圣性。我确实不敢打包票，但如果你能好好利用标记，你想强调的地方大概还是能得到一点尊重吧。这还没完，既然打了标记，当然还要区分不同的标记含义——有些是你计划要做的，有些是时间、预算和技术允许就做的。 然后垃圾来了——那些听起来很棒，实际上完全有理由当成垃圾的东西。你需要明确地指出来并解释需对其警惕的原因。如果你不这么做，我敢说这些垃圾还是会再跑出来。以下是标记列表： 不可缺少 重要 如果可能 否绝 你可能希望用上一些视觉符号来代替标记。但不要依赖颜色，因为文件不一定总是彩色印刷。 4、深入细节。没有细节的文件毫无用处。大家可以随意地理解大纲。“Thou Shalt Not Kill”（不可杀生） 这句话对摩西来说是一个意思，对西班牙征服者来说是另一个意思。详细地说明哪些角色不能杀、为什么不能杀、还有什么用途。设计文件也是一样：一旦你描述了一些实用的细节并给出相应的例子，你的想法就具体化了——不会被轻易地晒在一边。 例如，不要只说：“铜鸟是无敌的。”明确地描述这家伙被攻击时会发生什么情况及之后如何恢复。确实，如果动画师有脾气又有艺术家的尊严，你可以肯定他不会听从你的指示。但至少他会另想出一个更清楚的、又不违背你的主意，且他的修改不会严重地改变相关的部分。 别只说：“此时，用户会按下带箭头的跳跃键爬上墙。”而是详尽描述如果玩家不那么做会发生什么情况。解释为什么你认为用户能够想到你所提供的操作组合。解释环境暗示玩家爬墙的可能性。 另外，美工也会冒出其他想法，可能比你最初的设想更适合。如果是那样，那就真是太好了，因为成品可能甚至比你的纸上描述更接近你最初的灵感。但除非你一开始就清楚地描述了你的概念，不然这种事不可能发生。 别只说：“Bongo Man 比Bongo Boy更强大，但Bongo Boy的反应更快。”请用表格来表现角色的动作速度值、角色可拥有的攻击点数、角色的攻击伤害点数、发动攻击需要的能量等等。这种表格在Q/A和制作阶段是非常有价值的。 别只说：“大多数人会在几天内想通整个游戏。”制作表格，用于预测不同用户持有的产品的寿命；表明你希望各种功能特征被发现的时间点。之后的用户测试会为下一款游戏的设计提供有价值的反馈。 5、演示某些东西。有时候，几张草稿就够了，但如果这个创意对你的概念和项目确实重要，你可能得亲自制作粗略的动画。当元素的活动太过复杂和模糊，难以用文字表达，你就得制做原型。原型的好处之一是，通过实践往往可以催生更简单更高明的解决方案。 除了提供动画和原型，你还是需要提供概念的文字描述。动画确实比十亿字节的文字更有价值，可是文字也有动画无法达到的交流效果。看动画时可能会遗忘了某些重要的差别，而文字可以清晰地描述出细微之处。 6、别只说“什么”而不说“如何”。在现实世界，“如何”决定了“什么”。例如，假设你已经选择了粘土动画，那么就要制定出捕捉画面的方法，然后在文件中描述这个过程。背景应该用什么材料和什么颜色？应该用什么摄像技术和为什么用这种摄相技术？塑造框架的步骤是什么？等等等。如果你尝试过，你会知道这些因素中的任意一个对结果都有重大影响。 或假设你在制作一款摩托车竞赛游戏。你表示摩托车必须在优势和弱点之间达到平衡，所以你要在文件中提供实现平衡的表格，并注明调整是必要的，还要说明你打算如何实现调整——过程是什么？假设游戏的主要角色是歌剧幽灵。描述玩家的键盘如何映射管风琴键。提供一张各个键的映射图。列举发声的可用渠道的数量。和你的程序师讨论一下怎么实现各个细节，再用文件记录下来。两个不同的“如何”可能会产生非常不同的结果。 7、提供替代性选择。项目经理耗费大把时间在制作甘特图和PERT项目评估上。个人认为，我真的不敢说这种东西对游戏开发是有效的——很大程度上是因为未知的东西太多了。你的游戏技术越激进越新，开发过程中可预测的情况就越少。要保证你的团队达到日程表上的阶段时间点，你能做的不过就是提供另一条通路。（游戏邦注：甘特图：美国工商业管理专家甘特设计的，是一种用平行线表示一定时间内生产的计划数字和实际完成数字的图表；PERT项目评估：在一个给定的项目中对潜在任务进行分析的一种方法。） 我们返回键盘映射管风琴键这个例子。你的程序师向你描述实现最佳效果的最终方法，此法需要50人/小时来执行。因为我们已经讨论过其他事了，所以你已经记下所有东西。 你不能止步于此。你得问：“如果我们只需要一个切边、8槽的管风琴，要费多少人力时间？如果是绝对最小值呢？如是要我们只有几个助理能做这个怎么办？”然后你照旧记下一切。当最后面临抉择之时，你只需要脱口而出：“好吧，计划C。” 在文件设计方面，我犯下的最大的错误就是问程序师：“这办得到吗？”除非你问的是一流的程序师，否则这个问题根本就是白问。更具体地说，回答可以分成以下三种： （差劲的程序师）：“当然，没问题。” （一般的程序师）：“不，不能。” （一流的程序师）：“我这样做要花两周的时间。或者我可以小调整一下，只要五小时。” 总是不忘问另种方法和所需时间。然后表明你的倾向——如果有时间就这样做，否则就做罢。 8、允许修改。灵感和创意往往与兴奋和乐趣同在，我已经警告你要防止闷死这种灵感和自然的创意。你得允许设计文件被你自己或其他人（但愿是有才能的人）修改。 我在British Columbia大学主修音乐作曲时第一次吸取了这个教训。千辛万苦，我终于写好了一个新文艺复兴的铜管五重奏，我真是相当自豪。我的导师也很喜欢。当我们把乐曲拿给学院的铜管乐队演练，然而，在十秒钟的时间内，我的情绪就经历了几个阶段的起伏：惊骇、怀疑、愤怒和沮丧。乐队开始演奏了，一个大号手停下来向其他乐手示意，接着他取出笔开始修改几个音节，然后所有人又继续演奏。这种情况发生了不止一次。 我的导师，注意到我的脸色突然苍白了，转过身来对我说：“别担心，他们对莫扎特的曲子也这样。他们通常是对的。” 真相是，无论在纸上看起来有多好的东西，被置于现实世界的客观解读之下，最棒的专家仍然会修改它。虽然如此，你不想目睹自己的设计和梦想被无情地篡改。你希望自己的灵感以一种自然的姿态成长——永远是那颗你播下的种子，它的成长不经过外来根枝的嫁接。 以下技巧可以帮助你制作出一份可接受修改，又不会中断原始想法或扼杀开发进程的文件： 如果某方面是游戏概念的重点，确保大家牢记于心。 确保所有人领会游戏的灵魂及各个细节的用意。 如果有信息重复，必须互相参照。否则，如有改变，就会产生矛盾指示。 以下是实际执行阶段的技巧： 当有人提出改变时，回头检查你的设计文件，看看它是否和游戏的“灵魂”一致。 检查这是否是独立的改变，或它是否产生系统性影响（牵一发而动全身）。如果是后者，就在下一份计划中拯救它吧。 及时更正设计文件，包括修改的原因。或如果你不想修改，明确指出并解释原因。 修改、删除和否绝想法应该保留在主控文件中，以免重复讨论相同的事。 所有人都必须以相同的版本作为工作对象。过去的版本应该销毁。 重要的、关键的和紧急的一点：设计文件必须置于一人且仅有一人的监管之下。 9、应提供必要的参照和指示内容。我曾见过有些人的文件甚至连页码都没有，结果却抱怨成员没有遵循文件指示。优秀的文字处理器会自动计算页数并且印刷每一页的日期和页眉或页角。有些甚至允许你在新章节里改变页眉。用黑体字印刷重要的内容。你可以随意在不同的部分重申你自己的想法，前提是你把重申的部分相互参照了，这样你就可以一次性更新所有内容。制作一个周全的内容表格。 你可能希望用HTML写下你的文件和运用超链接。有些高级的文字处理器不需HTML也能使用超链接。但记着，人们往往更喜欢看着死复印件文本（因为有了实实在在的文件在手，那么在系统崩溃后重新启动的一个小时内，就还有点东西可以读）。 10、好文件也要好包装。最后，你需要做的就是使文件便于阅读和使用。没有愿意阅读一叠纸——因为看起来也不重要。只有带硬封面的东西看起来才重要。 制作一份应持有复印件人员的名册并进行保存。打印出所有东西，且每一页都要带眉头和日期。接着在每一页上打洞做成活页。最后在每一份活页本的书脊和封面上贴标签。更新时，人手一份校订页。有时，你可能需要提拱新活页本，丢掉旧活页本。 总结 电影制作人使用步骤原稿。建筑师使用蓝图。音乐家使用乐谱。根据古代的传说，甚至是宇宙造物主也制作了设计文件，在最初的文明之光普照大地之前，他让一小撮先知瞄了一眼——所以有了这个古代传说。既然神都是这么做的，那么游戏开发者就以之为榜样吧。 篇目3，如何使用GDD有效地组织游戏开发过程 作者：Gamux 你是否曾经因为缺少计划而在游戏开发过程中不断地改变设计和玩法方向？你应该考虑使用游戏设计文件（即Game Design Document，以下简称GDD）。它是整体游戏的指导愿景，把游戏的设计、开发和商业等方面的想法和计划组织在一起。 引言 简单地说：我们都喜欢讲故事。有些人非常喜欢，有些人可能没那么喜欢。但关键是，我们都曾经花很长的时间构思故事，随着时间流逝，这些故事开始演变，变得越来越复杂，细节更加丰富，背景更加充实，剧情更加曲折。一个全新的世界就这样从无到有地在我们的头脑中成形了。 随着故事越来越复杂，构造故事世界的工具也越来越多。美术分离成若干不同的类型，音乐变得更精致，影片也进入这个世界了。技术增强带来信息共享，把艺术传播到全球。每天都在创造新的幻想世界。世界这么丰富多彩，使人们开始渴望成为它们的一部分。一个新概念就诞生了。 尽管电子游戏一开始只是关于争取最高分的娱乐活动，开发者很快就意识到游戏的无限潜力。玩电子游戏不只是简单地经历另一个故事。这是第一种在故事如何叙述自己上有发言权的媒体。玩家可以扮演角色，亲身体验旅程的艰难，探索特定的世界和精通那个世界的技能，经历主人公的胜利和失败。 游戏以前所未有的方式将玩家和故事联系起来。这种联系可以以多种方式建立，可以是故事发生的幻想世界，可以是特定角色的丰满个性。它迫使玩家努力去看到更多他们想要的东西。 不幸的是，因为游戏是由如此众多的不同元素组成的，它的制作又需要来自不同领域的不同专家的参与，使协调开发过程变成一件非常棘手的工作。为了顺利协调工作，开发者通常会使用一种叫作GDD的东西。 GDC是帮助组织游戏部件的工具。它记录游戏各个方面的总体想法，从图像设计到剧情线。总之它记录游戏概念，是对项目成品的预测和计划。 尽管编写GDD并不是制作过程的关键部分，却对开发团队有莫大的帮助，特别是当所开发的项目由大量人员参与时。另外，编写GDD的方法有很多种。事实上，不同的游戏开发公司的GDD是不同的，但一般来说，大部分游戏都是围绕这些文件展开制作的。 那么言归正传，以下是这个重要工具的几个你必须知道的要点。 概述 你所编写的游戏设计文件必须告诉阅读它的人，这款游戏是怎么样的。为此，你不仅必须解释游戏的机制，还有游戏的对象（游戏邦注：例如主角、敌人、谜题、武器、环境等）之间是如何互动的，你的游戏主题是什么，风格是什么。在GDD中，这些要点通常放在几个主要章节中阐述。 营销 营销是一个大章节，可以划分成几个章节。它主要解释游戏的商业方面，如目标受众、截止日期、竞争对手和卖点等。这个章节对商业有非常大的指导意义，因为它显示了你的游戏胜过对手的优势和如何满足消费者的需求。换句话说，它解释了你的游戏的吸引力。 高概念 在你开始告诉读者（阅读GDD的人）你的游戏如何运作以前，你必须阐明你的游戏的核心概念，即简明扼要地表述游戏的主要方面，这样读者就能预期到这份GDD要说什么以及需要注意的重点是什么。所以，GDD中有一个关于高概念的章节，这样读者不必阅读文件的所有方面就能对你的游戏有一个大致的了解。 例如：如果你告诉读者你的项目是一款未来派太空射击游戏，他就能想象到这款游戏中出现的武器、活动、敌人和其他东西应该是怎么样的。 玩法 这个章节是GDD中最重要的部分，因为它解释了如何控制游戏中的对象，如何使对象进行互动以及玩家如何执行活动等。另外，它还解释了游戏流程和各个游戏环节发生的事件。 第一分钟 这是玩法章节的一个子章节，它解释了玩家在游戏加载完后首先看到的内容。它解释了此时游戏和玩家之间的活动和反应，帮助理解游戏的进程和操作方法。这是一个重要的子章节，因为它决定了这款游戏是否有趣。 流程 这是一个比“第一分钟”更详尽的子章节。它描述了玩家在游戏时可以选择的所有选项。它是一种反映各个选项会产生的结果的流程图，显示了整个游戏的概貌。通常来说，这个流程图是由游戏截图组成的（例如，从“主菜单”到“选择关卡”），但你也可以把动作和结果放在里面（比如，如果玩家选择“法师”角色，所有背景都会变成与魔法有关）。如它的标题所示，这个子章节准确地解释了游戏的进展方法。 获胜条件 在这个子章节中，你必须告诉读者做什么怎么做才能在游戏中获胜、在什么情况下会失败。也就是说，这个子章节解释了游戏的目标。 玩家数量 指定该游戏可以由多少人一起玩是非常重要的，因为它决定了游戏的类型或游戏支持的模式——单人的还是多人的。例如：分屏、LAN连接、网络连接。注意：这个子章节对“获胜条件”有影响，因为在竞技型游戏和合作型游戏中的获胜条件是不同的。 美术 解释完如何玩你的游戏后，就可以阐释你的游戏的外观和美术风格了。这也是非常重要的章节，因为它决定了游戏世界中的元素的共存方式和影响玩家游戏的情绪。这还是游戏营销的一个关键点，因为这显示了游戏的外观和传递给玩家的感觉。 技术 GDD中必须包含的另一个章节是“技术”，因为它确定了游戏要求、运行平台、开发引擎等等。这影响营销，因为游戏所适用的硬件会影响玩家基础和目标受众——消费这款游戏的人。 有没有公式？ 你必须记住，即使不同的GDD中存在若干相同的子章节，制作这种文件也不存在唯一的方法，不存在所谓的“完美公式”。每一位游戏设计师都有自己的编写方法，你必须寻找适合你自己的方法。这是很艰难的工作，但在本文中，我将提供一些解释如何编写GDD的各个子章节的技巧——然而，什么子章节是设计你的游戏所必需的，仍然取决于你自己。 你的文本必须总是保持清楚简明，最好配合大量插图，因为它们能让读者更快地想象到游戏的最终结果，并且有助于解释谜题（如果你的游戏中有的话）以及角色、环境、怪物、武器和其他物品之间是如何运作的。 此外，你还可以在你的GDD中加入一些能够帮助理解游戏的核心的新论题。应该注意的是，你的游戏的创新和细节。例哪，如果你的游戏项目具有全新的游戏方式，或特殊的图像概念或如果它以音乐为重点（像游戏音乐），你应该在GDD中讨论佗，以便让读者理解为什么这个创意是好的。 目录 GDD最好以“营销”章节为开头，因为它是你的投资商和客户最感兴趣的部分，这样就能让他们更快对你的游戏产生兴趣。在独立游戏的GDD中可能不会出现这个章节，因为独立游戏通常没有投资商，然而，如果你认为在其他不存在商业目的的项目如苹果的免费游戏，那么就必须记录与营销方面有关的计划，因为它对发行计划具有非常重要的意义。 此外，高概念很重要，这样读者才能马上理解游戏的核心和注意它的主要方面。你会发现，在GDD中，通常以游戏的基本和总结性的定义开头， 然后再逐步深入游戏的各方面的细节。 在下一章节中，应该解释游戏的“玩法”，它包含“第一分钟”、“流程”、“获胜条件”和“玩家数量”等。 这个章节后你必须显示你的游戏的外观，也就是讨论游戏的美术方面，尽量使用图片。最后，你可以讨论“特殊性”，即解释：创新、并非所有游戏都有的方面如情节、AI、角色和其他特殊的设定。 上述提到的所有东西都显示在下面的流程图中，这只是一个供你（应该）参考的一般架构。记住：没有完美的公式。现在，你已经有了GDD的骨骼，你可以在本文的“构成”这部分找到对GDD的章节的更详细的解释。  GDD(from dev.tutsplus)
构成 尽管编写GDD的章节没有完美的公式，但必须包含几个重要的论题和避免一些主要错误。本节主要告诉你如何细化上文“概述”中所提到的章节和子章节，并且附上正确和错误的案例。 营销章节 这个章节没有什么统一的编写方法，因为你的目标取决于你的游戏。并且它也不是必须的，你可以把它结合到其他子章节中，也可以穿插在整个文件旧城 ，因为这个论题的某些方面与其他的大有关联。无论你选择如何阐释这个论题，以下几点是必不可少的： 目标受众 谁会玩你的游戏？这不是一个普通的章节，所以不要简单地描述成“针对儿童”之类的。“分类”游戏的方法非常多，你必须好好研究。解释它将如何吸引各类玩家，他们可能与你的产品没有太多共性，但总是有一些共性的。 正确： 《Turret Defense》针对年龄介于15-25岁、经常玩FPS和RTS PC游戏的男性玩家；本作的太空冒险背景和主题尤其吸引喜爱科幻主题的游戏、电影和小说的玩家。 根据ESRB（娱乐软件分级委员会）有关暴力的内容描述，本作被评为T级（青少年），仅适合年龄在13岁及以上的玩家。为了满足发行要求，《Turret Defense》将不使用血腥或任何超过ESRB对暴力的内容描述的内容。 错误： 《Turret Defense》将吸引大量玩家。根据类似游戏的经验，它应该会在电子游戏市场上大获成功。我们计划在流量大的游戏网站上为它做大量广告。 （“大量玩家”不是有效的描述，不能解释为什么他们会喜欢你的游戏。没有提到ERSB分级或该游戏是否包括年龄限制的内容。） 另一个优秀的案例： 《OrBlitz是》的预期ERSB分级是全年龄向。本作的主要目标市场是益智游戏的粉丝，但本作的许多原创内容将吸引更广大的玩家，包括喜爱动作游戏的玩家。RTS游戏的粉丝也可能对本作感兴趣，因为它的具有某些与RTS游戏类似的玩法。因为画面不含暴力元素，且界面直观，本游戏也能吸引女性玩家。本作画面可爱、色彩丰富，既能吸引美国玩家，也能唤起日本玩家的兴趣。 注意案例中提到的分类词：性别、年龄、国家和类型。记住，取决于你的游戏，可能还要提到更多分类。预测ERSB分级也是比较好的，这样开发者就会注意到某些与暴力、性和禁忌语有关的限制需要好好处理。 平台 非常简单的章节。只要列举出你的游戏针对的平台就行了。也可以在这个部分提及系统要求。如果有必要，你还可以解释移植游戏可能遇到的困难。 竞争对手 这是GDD中的重要子章节。这里，你必须把你的游戏与市场上已经存在的其他游戏作比较。必须简要地描述游戏的竞争对手，以及你的游戏与它们的相似点。通过详尽的比较，可以让读者更清楚地看到这款游戏的真实情况。 在最后，总结你的产品的优势，使读者相信你的产品能够战胜竞争对手。这是最棘手的部分，因为你必须挑对竞争对手，读者不可能在不知道你在说什么的情况下还对你的游戏保持乐观态度。所以，文笔是很重要的。你的“自吹自擂”也能劝说读者相信你的市场有多大。 进度表 在“进度表”章节，你必须定义开发游戏的每个必要环节，也就是完成你的游戏的环节的时间线。有了这个，不只是你，包括投资商，都可以对完成项目必须的时间有一个大致的估计。 其他子章节 你可能会添加一些重商业的论题如“成本”，包括设备成本、人力成本、附加成本和预期利润等。 未来计划 有时候，可以补充到游戏中的想法太多了，但开发进度紧张，所以只能把那些想法放在一边。这个章节就是用来记录那些未能实现的想法的，这样以后你就能根据进度决定是否执行。DLC、可能的续作、玩法上的微调、图像修改等等，都可以放在这里。你还可以收集一些可能用于补充游戏成品的想法。 例子： 添加一些支线任务 使角色能够执行跳跃动作 做一段讲述开发者故事的视频 简介章节 简介章节应该首先简单地介绍游戏的高概念，然后加上“摘要”，让读者对游戏本身有一个基本的了解。你还可以在“关键特征”中强调游戏的创新方面。 高概念 这个段落描述了你的游戏关于什么；应该写得摘要的摘要。避免谈及技术、图像或声音设计、复杂的玩法或不是非常必要的营销细节（比如，如果你做的是音乐游戏，你应该提到你使用的音乐风格；但如果你做的是益智游戏，就暂时没有必要提它的音乐；而最好描述一下谜题的类型）。关键就是，用最简洁的语句描述你的游戏，不要使用技术术语中。给你一个技巧，使用知名的游戏作为比较例子，比如“X是一款3D赛车游戏，与《马里奥赛车》类似”。 正确： 《Scavenger Hunt》是一款3D街机风格游戏，玩家的目标就是与对手竞争，看谁先收集齐任务列表上的道具。 错误： 《Scavenger Hunt》是一款3D街机游戏，背景是50年代的虚构街区，具有益智元素和卡通风格的图像和音乐，玩家的目标是和对手竞争，看谁先收集到各个阶段的任务列表上的道具。这款游戏在单人模式时，由电脑控制对手；在多人模式时对手为另一名人类玩家。 （尽量保持简洁） 摘要 这部分更加详细地描述你的游戏，限制没有高概念部分那么多。从玩法的核心方面开始，描述玩家的作用，目标、完成目标所需的行为、失败条件以及游戏的乐趣。 接着，简要介绍游戏的背景和历史（如果有的话）。最好使用图片而不是文字来说明游戏的外观如何，所以如果你没有草图或概念图，你应该贴一些风格类似的图片（比如其他游戏的截图）。 关键特征 最好用短句而不是很长的段落来组织这个章节（即小点列表）。在这部分，你应该告诉读者所有你认为会为游戏添彩的创意想法。 正确： -简单而强大的物理学让一系列简单的规则产生惊人的结果。 -2.5D卡通风格的图像 -前所未见的绘图系统，当游戏加速到疯狂的程度时，游戏会变成色彩斑斓的世界。 -强大的陆地制作功能，允许你构建复杂的路径，如隧道和桥梁。 -丰富的游戏模式和场景，流畅的动作和反应。 错误： 本游戏有简单而强大的物理学，让一系列简单的规则产生惊人的结果，同时使用2.5D卡通风格图像和前所未有的绘图系统，当游戏加速到疯狂的程度时，游戏会变成色彩斑斓的世界；玩家可以使用其强大的陆地制作功能，构建复杂的路径；游戏有丰富的游戏模式和场景。 （一口气说了太多想法，让读者摸不着头脑） 第三方软件 简单地声明你开发游戏将使用的程序语言、库、软件以及图像与声音引擎等（游戏邦注：包括多人游戏需要的网络）。 如果你受到严格的软件/硬件限制，你应该在此说明（即如果你制作的游戏是针对苹果设备的，你必须声明你将使用iOS兼容的技术）。另外如果你的游戏是PC平台的，你应该声明最低配置要求。尽管在这个项目中不搞程序的人可能不理解什么是“NVIDIA Cg 1.2.1”，但至少应该让他们知道这么一个名称。 玩法章节 这个章节旨在描述游戏如何有效地运作、游戏的目标及其元素（菜单、获胜条件、敌人、道具、关卡……），和这些元素与玩家之间的交互作用。如果你觉得一个子章节“敌人”包含的内容太多，那么你可以把它单列成一个章节。 第一分钟 描述游戏加载后玩家的反应会是什么，这是很有趣的。比如可以描述玩家可以马上开始玩游戏，浏览菜单修改选项，通过尝错误或教程学习操作，一开始就能玩所有关卡还是需要解锁，等等。考虑到你之前已经准备好一些关卡，你可以简单地叙述一下玩家如何通关、在这个关卡中遇到的敌人和/或谜题。 正解： 标题页面后，玩家将看到一列他可加入的游戏和新建游戏的选项。选择新建游戏后，一列预设关卡将出现在屏幕的右边。（……）修改好设置后，当有三名其他玩家加入游戏，游戏就可以开始了。计时器从5秒开始倒计，这是玩家的准备时间。游戏开始后，玩家使用少量的金钱布置方块。随着轻快的背景音乐，游戏面板绕着屏幕中心旋转，逐渐展开关卡的布局。（……）玩家的目标就在游戏面板的各角。（……）计时到0时，屏幕中间出现“GO！”命令，魔法球从云中落下，沿途造成严重破坏。（……）玩家要迅速地把方块放在面析的边缘，这样魔法球就会从边缘弹开，玩家完成目标时半听到熟悉的点镖机的声音。玩家的得分和金钱变成200，他现在可以进入下一关（……）。 错误： 这款游戏一开始，玩家在相反的角落面对面。玩家1使用游戏开头赠送的钱，和布置石块挣得分，来获得。 （缺少细节） 流程 对“第一分钟”的完美补充莫过于“游戏流程”，它通常用流程图表示。与之前的子章节相反，这个部分不强调第一印象，而是显示玩家从游戏加载完毕到按下“退出键”（结束游戏回合）的过程中可以执行的活动，让读者对整个游戏的进程有一个总体认识。 正确：  main menu(from dev.tutsplus)
错误：  Wrong(from dev.tutsplus)
（太简单了，至少应该包括玩家看到的所有页面） 获胜条件 在此声明玩家通关、获胜应该满足什么条件。比如，如果你的游戏是拼图游戏，那么玩家必须把所有拼图块以正确的方式组合起来才能进入下一关；如果你的游戏是横版射击游戏，玩家必须击败最后的BOSS才能通关……显然，这完全取决于你所设计的游戏类型。 案例： 在《太空侵略者》中，玩家扫清当前所有敌人后，游戏就会刷出新一波敌人。因为敌人是无限刷出的，所以直到玩家耗尽命值，游戏才会结束。 图像 事实上你无法向读者提供任何你还没做出来的游戏的截图，所以在这个部分，你只要描述你计划使用的图像引擎，可能再附加几张游戏的草图或你想使用的风格的原画。提前设计游戏的HUD会帮你节省大量时间。 HUD HUD是指玩家在游戏过程中使用的内置界面。与游戏菜单如设置或目录面板不同，这是特指通常不游戏本身互动而只具有提供信息作用的浮动窗口和数值条，比如命值条、小地图、计时器、装备栏、钱袋等。尽管HUD的大小因游戏类型而异（MMORPG和RTS通常有很大的HUD，而横版游戏和益智游戏的HUD通常很小），记住，HUD不应该占据屏幕太多空间。 案例：  example-conversation(from dev.tutsplus)
声音 另一方面，你也无法描述声音，所以你只要声明你将使用的声音引擎和（也许）歌曲风格。尽管对于大部分游戏，你只要简单地声明不同场景将有不同的背景音乐，但毫无疑问，这个部分对音乐游戏来说是最重要的。 操作 用文字介绍按钮/键盘的对应功能，可能有一点麻烦，特别是当按键对应的功能不止一个时（比如《塞尔达传说》的“A”键）。用简单的控制器或键盘图示来解释各个按键的功能更合理。此外，如果你的游戏有高级的连击或类似的东西，你要详细地解释它们，声明在什么情况下会“激活”什么操作组合。 案例：  basic controls(from dev.tutsplus)
游戏特定的子章节 拼图游戏可能有“拼图块”章节，横版游戏可能有“关卡设计”章节，太空射击也许有“敌人”章节等等。正如标题所暗示的，每一种游戏都有它们自己的特定的子章节，因为我们列举一个GDD可能有的所有子章节，所以下面我只举三个例子。 拼图块 假设你的游戏是拼图游戏，玩家的目标是通过把相同的图像拼成一行，以获得积分。最好能在这个部分展示不同类型的拼图块的草图，以及解释它们的旋转方式、分值和布局。如果能配合图片就太好了！ 案例：  tetris pieces(from dev.tusplus)
关卡设计 假设我们的游戏是2D平台游戏。这款游戏的核心元素之一是玩家必经的台面。必须让各个台面显得独一无二，否则玩家就会觉得自己只是在重复玩某个关卡。另一方面，玩家应该仍然熟悉流程，即如果关卡中间总有一个保存点或可收集道具，那么其他关卡也应该如此。 不同类型的敌人、地形、道具等是怎么样的？关卡设计师是否可以根据它们设计出不同的台面？你可以展示一些测试版台面的图解。 案例：  Map(from dev.tutsplus)
敌人 太空射击游戏往往有许多不同类型的敌人，每一种都有不同的进攻招式、移动模式、命值、速度和攻击范围。因此，你当然需要再写一个章节专门介绍游戏中的敌人和它们的属性。另外，你可以陈述一些他们的模糊行为，比如当它们命值过低时会发射额外的光波。 案例：  marauder-example(from dev.tutsplus)
情节 许多游戏都发幻想世界为背景，各有自己的地理、历史和角色，玩家可以扮演的主角当然很多。如果你的游戏有特别有趣的背景，那么最好能加入游戏的故事板，描述主角在冒险过程中遇到的主要事件和传说。 角色 玩家在游戏中通常不会只遇到敌人。可能有主角和同伴来帮助他打败敌人。例如，甚至在无玩家控制角色的塔防游戏中，在开头部分仍然可能有像向导NPC这样的辅助角色来指点你如何克服某个挑战。如果你的游戏确实有玩家操作的角色，那么他是怎么样的？他是否有什么技能和专长？记住，不要把这部分写得像“怎么玩”。 AI 所有游戏都需要一个恒定的世界来处理所有的玩家行为和其他活动。这包括敌人移动、玩家操作、碰撞、计时、随机数生成和许多其他东西。尽管没学过程序的人也许不能完全理解这个章节，但他们至少应该知道基本知识。最重要的是，不要在这里出现代码，简单地描述敌人的移动模式、拼图块下落的算法，用流程图来解释战斗系统。 案例： 面板上的角色通过简单的寻径/集群算法来躲避魔法球。每一个关卡会使用三个不同的脚本文件来向动画化的角色发布指令。（……）玩家角色将用于模拟真实的玩家。由AI系统将决定的是： -是否放新方块？如果是： -在哪里放新方块？ -这个方块是什么类型/材料？ 技术章节 组成一系列游戏数据技术，如系统要求、开发工具、算法以、屏幕上可出现的元素的最大数目。图像技术方面包括软件、建模类型、美术风格和其他与此有关的东西。 所谓的系统要求是指电脑运行游戏必须达到的配置，如游戏占用的硬盘空间、需要多少RAM。  system requirements(from dev.tutsplus)
另一个重要的技术方面是，不要忘记ESRB评级，之前已经解释过了。评级例子如下所示：  ESRB(from dev.tutsplus)
要不要包含？什么时候？为什么？ 负责推广该游戏的公司或将使用该技术开发游戏的人会对技术方面感兴趣，所以当你把这个GDD拿给审查这款游戏的人时，总是保证介绍它的技术方面。你可能会写出一些错误的论题，比如，把平台和推广游戏模式放在营销章节中，而不是技术部分。 更多案例 至于提供专业的GDD的网站，我推荐Shred Nebula、Play With Fire、Grim Fandango Puzzle Document等，当然在gamepitches.com上也有许多。 如果想进一步学习GDD的结构和组成，可以看Gamasutra上的文章《 The Anatomy of a Design Document》的第一和第二部分、《Creating a Great Design Document》和《How to write an effective Design Document》（它与游戏开发无关，但关于软件开发）。 《Game Design: The Two C’s of Video Game Design》也值得一看。 另外，游戏圈对如何编写游戏设计文件有不同的观点。虽然看似与本文所说的有矛盾，但这是因为分析的案例不同，而且还要考虑到团队规模、预算和截止日期。 总结 对于需要投资商批准的设计师，你必须首先吸引他的注意力，为此，你的文件必须做到： 高概念：你永远没有机会给别人留下第二个第一印象。你已经知道怎么写这个章节了，现在只要记住，首先写好这个部分，点出所有你认为可以让游戏更吸引人的东西。 图片：不要以这读者会老老实实地把整个GDD看完，更别说有些文件还超过一千页（真的有这种事！）。但读者肯定会好好地看吸引他眼球的东西，所以还有什么比图片更有效的？毕竟，图片胜过千言万语。 不用说，你的文件必须有好的外观。花点时间把文本排列成方便阅读的格式。另外，不要忘记本文只是告诉你一般的GDD的结构是怎么样的，你必须根据自己的游戏做修改！
| 
IP卡
狗仔卡
发表于 2015-8-12 09:51:58
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
楼主
