如何撰写一份好的设计文档？
英国一家小型工作室的商务总监 Strike Gamelabs 艾拉·罗曼诺斯（Ella Romanos）谈到了现代设计文档应该是什么样的。
最近我读了一篇非常不错的文章，作者是詹姆斯·斯韦特曼（James Sweatman），标题为 「游戏设计文档的死亡」。这篇文章让我开始反思我自己撰写设计文档的经历。
我完全同意詹姆斯的观点。文章与我的经历相契合，描述了我们在工作过程中所形成的文档类型。多年来，我们通过反复试验和错误，逐渐形成了一套编写设计文档（以下简称GDD）的算法。最终，我们得到了一个标准的设计文档格式，便于使用。
詹姆斯清晰明确地解释了为什么传统的游戏设计文档不再适用，因此我不打算详细阐述。我只是想重申一下：传统GDD的问题在于，它试图一次性描述游戏的每一个细节。我们都知道，这几乎是一项不可能完成的任务，因为更新设计文档需要耗费大量时间。此外，由于格式的局限性，这种设计文档无法满足灵活多变的创作过程的需求。
我将讨论如何创建一个现代且方便的设计文档，即一个既实用又有效，同时从一开始就容易理解和直观呈现的文档。
这个过程与 用户体验 密切相关，正如我和马丁·达比（Martin Darby）在今年的开发者会议上讨论的一样，我之前在我的博客中也曾发布过相关内容。
那么，方便的设计文档的关键在于：
- 首先，确定你游戏的目标，以及你希望用户获得的体验。实际上，这意味着你的GDD应该描绘出游戏的整体过程以及用户能做什么。在这个阶段，不需要描述所有的细节。只要清楚你想要达成的目标，以及每个元素和特性如何融入游戏就可以。你可以稍后再回到细节，不必冒着过度复杂化游戏流程或失去游戏目标的风险。
- 阅读你文档的人，应该能够快速轻松地理解游戏是什么以及用户在其中应该做什么。
- 确保文档中有足够的空间容纳可以改进、补充或修改的细节。设计文档应该设计得足够灵活，以至于不需要变动时完全重写。
在初步阶段，你的游戏设计文档应该包含以下内容：
游戏的总体描述
这部分是所谓的概念文档或媒体包。篇幅大约为2页。包括项目摘要、简要的剧情概述、非常简洁的游戏情节描述以及最重要的项目特性列表。在这个阶段，我经常会利用设计部门的资源，并在文本中插入图像来帮助我阐明观点。
游戏的“核心”描述
这一部分限于游戏循环，展示游戏的关键特性以及用户如何进行这些操作。（如何定义关键特性和创建游戏循环，我在之前的文章中已经讲过）。
循环应描述每个包含在内的特性，并解释其用途。最佳方式是每个特性的描述不超过半页。你可能需要为每个元素附加额外的循环，这比文字更能解释你的想法。
在循环的图示中加入伪屏幕截图通常是有帮助的，因为这可以直观展示你的目标以及用户如何看到和与游戏互动。
游戏元素
这是一个详细描述所有特性的部分，这将需要你添加细节。
你可能需要包括表格，详细描述特性和其他元素，例如游戏的修改、发展、GUI、货币化、可更新内容、社交特性、游戏世界、游戏菜单在过程中如何变化以及任何其他之前未提及的附加细节。
如果你正在制作游戏的测试版本，就不必将所有内容都包含在内，但一定要提及你确实想在游戏中看到的特性，或者在后期发布中会添加的特性。
这一部分最终会与传统的GDD非常相似。在开发项目的过程中可以不断扩展和补充。在这个部分内，必然会发生变化；在这个阶段，这是合理的。重要的是，总体的游戏描述和游戏核心描述在最终确认后应基本保持不变，因为对它们的改变将导致游戏外观的根本变化。在进行任何修订之前，请仔细考虑。
可能你不希望将这一部分的GDD展示给公司的股东：它主要用于内部使用，因为它解释了游戏究竟是如何制作的。
总结
那么，通过将GDD分为几个部分，我们实现了什么呢？现在，所有阅读设计文档的人都能从一开始轻松理解游戏，而不会陷入琐碎的细节中。你越是深入阅读文档，信息将变得越详细。你可以在游戏开发过程中扩展GDD，同时设计文档将保持结构化和易懂。重要的是，你不会失去对项目目标的关注，并且能够看到用户如何进行游戏。
游戏设计文档应确保你确信设定的目标能够实现，用户能够获得你希望他们获得的体验。为此，你不需要立刻描述项目的每一个细节。首先，要知道游戏的起始点以及用户通过哪些步骤达到游戏目标。其次，你需要确认能够吸引用户并成功销售游戏。最后，有必要能够简洁地向公司的股东和管理层展示你的构思。这种描述游戏的方式是你实现目标的保障，而不会被多余的文档所困扰。专注于你想要达成的目标，而不是琐碎的细节——这就是成功的关键。
