怎样编辑一份最有效的游戏设计文件
- 来源：游戏邦 日期：2014-11-12 11:15:59
摘要:在一篇来自Jagex的James Sweatman的一篇优秀的文章《Death of the game design document》中，想到自己的游戏设计文件经验以及我是如何处理它们的。
在一篇来自Jagex的James Sweatman的一篇优秀的文章《Death of the game design document》中，想到自己的游戏设计文件经验以及我是如何处理它们的。
我非常同意James所说的，即这非常符合我自己的经验以及我们最终所编写的文件类型。经过几年的时间我们创造了编写自己的文件的过程，这同时也是一个不断发展与完善的过程，并提供给我们一个可遵循的标准模式。
game design document
James清楚地解释了传统游戏设计文件未能发挥作用，所以我并不打算在此详细说明，但总的来说，传统游戏设计文件的问题在于它们尝试着去解释游戏的每一个细节。我们都知道这几乎是不可能做到的事，因为这需要花费许多时间去更新内容，并且因为太过死板而难以支持一个创造性且迭代的开发过程。
我将在此讨论的是为何你需要使用一个更加与时俱进的游戏设计文件；就像James所提到的，这样的文件具有实用性，非常清楚且具有协同性。
这一过程与我和Martin Darby在年初于Develop大会上所讨论的用户体验设计过程具有密切的联系。
我认为拥有的游戏设计文件（GDD）必须具备三个要素：
1.定义你的游戏目标，即你希望玩家所拥有的体验。实际上，这意味着你的GDD应该规划出游戏的整体流程以及用户该做些什么。你不需要规划的内容是一些较小的细节。只要你知道自己想要实现怎样的目标以及游戏中的每个元素和功能是什么，你便能够在之后罗列出细节，而无需遭遇功能变化或违背游戏流程或目标的风险。
2.任何阅读你的GDD的人都应该能够快速且轻松地理解游戏是关于什么以及用户该做些什么。
3.你应该创造一份拥有足够可以完善，调整甚至是改变细节的空间，而无需重写整份文件，改变用户流程或整个游戏目标。
游戏概述
这就像是你心目中的概念文件或产品介绍书。大概有2页内容，其中应该包含执行概要，简短的介绍，关于背景的简要说明，以及最重要的关键功能的项目符号列表。我经常会包含一些设计核心，并使用图像帮助解释。
核心的游戏描述
这一部分是基于游戏的核心循环图，即呈现了游戏的关键功能以及用户经历它们的流程。
遵循这样的图表，你将获得一份说明书能够解释每个核心循环功能以及它们的作用。每一个描述只需要不到半页纸的内容。你还应该包含进一步的循环图表去分解每一个元素，因为这能比任何文本更清楚地解释你的理念。
在这一部分包含游戏画面模型很有用，因为这让人们能够想象出玩家将会看到什么以及如何在游戏中进行互动。
游戏元素
这一部分将进一步解释游戏的重要功能，在这里你将开始添加更多细节。
你可能需要包含一些表格去分解功能并解释游戏模式，进程，控制，盈利，可更新内容，社交功能，游戏世界，菜单页面流程图表以及任何未被作为重要功能的次要功能等等元素。
在这里，如果你是致力于创造最小可行产品的话，你便可以忽视其中的某些元素，但是你也可以添加人们所期待的功能，或者在游戏发行后再进行添加。
这一部分更像是传统的GDD，一开始较为简单，然后会随着开发过程而不断扩展。在创造性过程中，我们将会看到这一部分的改变，并且这样的改变是合理的。我们必须清楚，游戏概述和核心游戏描述部分应该始终保持不断，因为这里的改变将会从根本上改变你的游戏设计，所以你需要在做出改变前进行更慎重的考虑。你可能不想提供给这个第三部分额外的利益相关者；这一部分更适合内部使用，因为它准确解释了如何创造游戏。
结论
我们通过这种方式分解设计文件是为了是扩展之前的每一部分。任何阅读文件的人都能够快速且轻松地理解内容，随后才会沉浸于一些详细的信息中。当你进一步阅读文件时，你便能够获得更加详细的信息，因此你能够在开发过程中轻松地扩展文件，既不会失去它的易读性，同时也不会迷失整体目标和用户流程。
一份GDD必须使你确保自己能够实现之前所设定的目标，即用户能够获得你希望带给他们的体验。
为了做到这点，你并不需要直接呈现每一个细节，你需要清楚游戏是从哪里开始，并能够引导用户去实现目标。你需要清楚自己能够通过游戏去调动用户的兴趣，并且你也能够面向内部和外部利益相关者去宣传游戏。基于这种自上而下的方式定义游戏将帮助你做到这点，并且你还可以摆脱累赘的文件的束缚。专注于你尝试着实现的目标而不是在所有小细节中迷失方向才是重点。
