如何创建高质量的设计文档：来自Rocket Jump的建议
在游戏开发中，为什么要进行文档记录，如何正确地进行，以及使用什么工具进行文档记录，—— 来自Rocket Jump工作室的首席游戏设计师安东·波达金（Anton Podakin）进行了详细讲解。
本材料依据一场于十月初在高等经济学院的商业信息学院上演的报告撰写。
安东·波达金
为什么编写设计文档如此重要？
在八年的游戏行业从业生涯中，我曾遇到关于游戏设计文档编写的各种观点。在加入Rocket Jump之前，我听到过很多关于设计文档的负面看法。在Rocket Jump，我们建立了一个合理的游戏设计文档结构。许多游戏设计师想出各种巧妙的借口来拒绝撰写文档。以下是一些常见的借口：
那么，最终结果是什么呢？
- 您从执行者（例如艺术家）那里得到的并不是您想要的结果。
- 同样，制作人从您那里得到的也不是所需的内容。
- 您花时间做不必要的解释和补充，而这些本可以避免。
- 您忘记了已做出的决策。在这种情况下，您很可能需要重新考虑某个功能。而时间已经紧迫，而且结果很可能不会如最初预期那样。
编写游戏设计文档可以帮助解决这些问题。本质上，设计文档、设计说明或游戏设计文档（ГДД）是游戏的完整描述，持续记录项目中的决策。这是一个不断发展的文档，团队成员可以从中获取项目所需的任何信息。
文档有几种类型。它可以是包含市场营销方面的完整项目描述，也可以是对特定功能的详细描述。一般来说，游戏设计文档可以包含以下信息：
- 游戏描述（目标受众、平台、类型）；
- 游戏玩法图示；
- 机制和界面描述；
- 开发中使用的技术；
- 对图形/艺术设计/声音的要求；
- 故事/背景设定；
- 游戏设计师的笔记。
ГДД不仅解决了向团队通报游戏状态的问题。它还有助于有效、精准地给执行者（开发人员、艺术家、动画师）设定任务。因此，文档作为一类指示物，能够追踪进步，评估工作的质量并更好地规划工作。凭借详细描述的文档，更容易准确评估开发某一功能的成本。此外，设计文档也被视为游戏设计师工作的成果，是将明确表达的想法推向实现的终点。
文档的编写是为了简化团队内部的所有流程。不论怎样，几乎所有开发和支持项目的部门都将参考它：
- 游戏设计师；
- 制作人；
- 质量保证（QA）；
- 程序员；
- 用户界面设计师；
- 编剧；
- 艺术家；
- 市场营销人员/社区经理；
- 新员工。
在每种情况下，个人从文档中“提取”所需的信息。而文档的质量和完整性则依赖于游戏设计师的努力。
当然，设计文档并不是万灵药。但它能有效节省你的时间和同事的时间，最终提升最终产品的质量，避免“电话传话”的效果。
游戏设计文档的三驾马车
有三种错误可能会使设计文档的所有好处化为乌有。这些错误相当明显，但实践证明，即使是最显而易见的事情，有时也需要再次强调。于是：
模糊性/不清晰性
这里很简单——您所有的论点、想法和计算结果应该明确表述。不要让别人为您做推测，不要给出多个选择，让他人决定，别希望同事能读懂您的心思，也不要用复杂的文学修辞让同事困惑。
文书错误
如果文本中充满拼写、语法和标点符号问题，文档阅读将变得非常困难。请关注这一点。
无关的内容
在创意过程中，游戏设计师很容易在提到自己喜爱的角色、机制或物品时偏离主题。记住“框架”——设计文档中必须描述的内容（例如，如果我们谈论的是单位——伤害、攻击范围、战斗机制描述等等）。其余的都是多余的。所有新的想法和补充可以留在笔记中。主要文档中不应该包含这些内容。
还值得注意的是，始终要记住，您为谁编写ГДД。例如，对于艺术家而言，通常不需要某些指标的精确计算公式，而程序员则可能需要。对于用户界面设计师而言，界面图、数字顺序、所需元素和过渡列表非常重要，而对几乎所有其他部门而言，这些信息会显得多余。
工具选择
现在有许多工具可以用于文档处理。其中可以突出一类wiki引擎：
它们在使用的语言、开箱即用的功能（样式支持、不同权限的账户、文件的上传和存储类型等）以及可扩展性方面各不相同。甚至还有一个大型网站，在这里可以详细比较不同的引擎。
除了wiki引擎之外，还可以使用以下系统：
- Google文档（或类似的服务——例如，iCloud办公套件）；
- Evernote；
- GitHub。
您还可以使用普通的离线编辑器，并连接版本控制或分享系统。在这种情况下，文档可以在例如Word中编辑，然后上传到云端，以便其他人可以使用。但这会带来一些不便——例如，缺乏对整个文档的良好搜索功能和完整的版本控制。
我们在Rocket Jump使用的是Confluence和JIRA的组合。第一个服务是用于文档编写的工具，第二个则是一个著名的任务管理器。两者互为补充——例如，可以将JIRA中的任务整合到Confluence的文章中，跟踪其状态。在使用其他系统时，任务跟踪器与文档的整合可能会遇到困难。
这种组合的主要优点与缺点息息相关。问题在于，这是一个非常复杂的配置系统（甚至有专门的专家类型来将Confluence集成到大型组织的工作流程中）。但所有这些都因其出色的深思熟虑和灵活性而得以弥补——如果愿意，可以将Confluence几乎设置为满足任何需求。因此，这里一切都取决于您团队的规模和项目的需求。
实用建议
我将分享一些经验建议，期望能够简化游戏设计文档的工作。
1). 保持信息的时效性和完整性。过时或未完成的设计文档几乎与缺乏文档同样糟糕。为了理解项目并能够正确推进，您需要不断查看整体、真实且详细的图景。
2). 为文档的格式创建一个单独的小规定，使所有人都明白如何格式化ГДД。包括批准的字体、格式化细节、文档中斜体的含义、需要加粗的内容等。未来将大大加快文档导航并简化团队内部沟通。
3). 建立适合您团队的ГДД格式和结构的统一风格。以下是我们在Rocket Jump使用的简化文档结构：
4). 在处理配置的时候，请在设计文档中详细描述您将来希望在机制设置中变化的机制和结构。如果这一点提前没有做好，很可能之后需要请求程序员从代码中“提取”出可以直接显示的内容。这是我们文档中一页的示例，其中列出了一段我们将来需要处理的代码：
5). 在处理表格时，建议将分组的表格元素放在折叠项下，并突出标题（以便始终清楚列/行中记录的数据类型）并合理结构化数据。就像处理代码一样——如果其他人要处理您的数据，请确保他们不会陷入复杂的结构中。而且不应使用嵌套表格——这只是多余的复杂性。
6). 书写公式时，一定要提供解释（说明）——每个变量的作用是什么，它如何与公式中的其他元素交互。未来，如果您在ГДД的不同地方使用同一变量（这种情况是很常见的），将大大简化工作。
7). 遵循命名的一致性。在开始时就达成一致并在文档中固定团队中单位、物品等的名称。这将有助于后续的本地化工作，也不会导致误解和不必要的搜索。没有人愿意在补丁构建前一天发现，同一个单位在四个员工中被称为不同的名称：
因此，我们在Rocket Jump的每个项目中维持一个完整的术语表，其中列出所有实体的批准名称。
总结
我将所有内容概括为一个相当简单的观点。与游戏设计文档打交道时，最重要的是——它必须存在，并在整个项目生命周期内保持更新。维护ГДД比它所消耗的资源要节省得多。并且这一过程实际上并不需要想象中那么多时间。此外，这是游戏设计师工作中的关键工具，ГДД的质量在很大程度上影响着其工作的最终结果。
相关阅读：
