简短的游戏设计文档
原文为《Rust游戏开发实战》 的附录 B
一个简短的游戏设计文档可以帮助开发者把注意力集中到游戏的核心思想上，而不会把精力花费在一些听起来非常棒，但是只有等到游戏的基础功能完成以后才可以实现的周边功能上。它还可以帮助开发者克服写作困难症，一个结构合理的简短设计文档可以帮助开发者完成游戏。地下城探险类游戏的设计文档示例参见第 4 章。
首先从一个可以帮助克服写作困难症的窍门入手：做笔记。
记录下每一个想法
在玩游戏和制作游戏的过程中，开发者经常会发现自己的头脑里充满了创意。但灵感总是在我们最不方便的时候突然到来 —— 在淋浴时、在工作时或者在准备入睡时。所以，不妨在手边准备一个笔记本，实物笔记本或是电子笔记本都可以。当好的想法闯入脑海时，请立刻简略地记下来。只需要记录下足够事后回忆起当时想法的必要信息就够了。“类似 Pong 的游戏，但是用激光”是一个便于回忆的笔记。“超能力怪物”是一个很好的标题，但是可能需要更多的注释才能让你在回看笔记的时候记起来当时在想什么。
你可以使用任何一款自己喜欢的笔记管理系统。从 EMACS Org Mode 到 Evernote，从 Google Keep 到 Microsoft OneNote，有很多款笔记软件可以尝试使用。使用什么样的笔记工具并不重要，即便是一摞发黄的纸和一根破笔也没有关系。
把笔记按照游戏创意进行组织是一个好的做法。写下一个游戏创意并将其置顶，然后在下面书写关于各种细节特性的笔记。你需要思考这些细节特性对游戏的核心创意而已有多重要。举个例子：这个想法是游戏的一个核心概念，还是一个需要与其他想法配合才能实现的游戏视觉特效？
当你有强烈的创作欲望但是不知道具体应该做什么时，你就可以翻阅这些笔记，然后找到一些听起来有趣的东西。
有关游戏创意的笔记既不是设计文档，也不是开发计划。你经常会发现可以把来自不同笔记的创意结合起来 —— 很多更加有趣的游戏创意都来自对多种流派或创意的组合思考。在把笔记转换为设计计划之前，先来思考一下计划应该包含什么内容。
为什么需要设计文档
一份设计文档可以起到如下几个作用。
- 可以将希望制作的游戏的精髓浓缩成一个易于表达的目标。
- 将笔记“编译”为一个更加正式的文档可以使得开发者用心思考游戏内部是如何运作实现的，而不是仅仅停留在游戏最终的效果概念上。
- 编写设计文档可以帮助开发者分清楚哪些是基础的功能，哪些是锦上添花的功能。
- 一个精心编写的设计文档可以把整个任务拆分为大小适中的子任务。这样开发者发现自己有时间编写程序时，就知道可以着手做什么了，并且可以真切地感受到自己确实在这段时间内完成了一些工作。
综上所述，我们从理论上介绍了设计文档的必要性以及它应该有的样子。实际上，你所需要的开发文档取决于项目的规模如下表所示。
| 个人开发者 | 小型团队 | 游戏工作室雇员 |
|---|---|---|
| 一个简短的游戏设计文档 保持简单就好 | 能够让团队中的成员齐心协力 能够追踪每一个 Sprint 的进度 | 非常详细的文档 游戏制作人会把它写好，不需要自己动手写 |
本书假设你是初学者，所以大概率是一个人开发或者和一个朋友合作开发，这就拥有了非常大的自由空间。设计文档可以不那么正式，只需要包含足够的信息来提醒自己该做什么即可。
INFO
设计文档是动态的
通常情况下，设计文档并不是刻在石头上一成不变的碑文。相反，这些文档被称为动态文档 —— 它们会被不时修改，以满足实际情况的需要。
接下来，让我们讨论一个最小化的、目标清晰的设计文档里面应该有什么。
设计文档的若干小标题
记住要保持设计文档的短小、精悍。你只需要几个基础的小标题，以及一些为了实现创意而对完成的任务的粗略评估即可。这一节旨在让你了解如何编写一个目标明确的设计文档，该文档可以帮助开发者在开发游戏的道路上保持正确的轨迹。
游戏的名称
起名字是一件困难的事情，而且通常情况下，第一个名字并不会成为游戏最终的名字。你可以先起一个随意的名字，然后再去想一个有趣的好名字。用暂定名称开始编写设计文档，把它写在文档的第一行。
游戏简介
在设计文档的最前面应该包含游戏的简要介绍。Flappy Dragon 可以被描述为“一个 Flappy Bird 的仿版”。一个典型的 Rogue 类游戏可以这样描述：“一个具有随机生成的关卡、越来越难以打败的怪兽，以及回合制操作的地下城探险类游戏”。
游戏简介应尽量保持简短。这类似于营销手段中的“电梯推销” —— 当你想向朋友介绍这款游戏时可以使用的文案。
游戏剧情
并不是每一个游戏都有剧情。没有人知道为什么 Flappy Bird 游戏中的小鸟要不顾一切地向东飞，而且对于一个有趣的小游戏而言，有没有剧情并不重要。如果游戏配有剧情，那么就加入一个剧情的概要；如果没有剧情的话，就可以直接略过这个环节。
游戏的基本流程
游戏通常都具有设计循环 ( design loop )，它描述了游戏主人公的行为，以及这些行为对周边世界产生的影响。Flappy Dragon游戏的循环非常简单：飞龙向东飞，避开障碍物。一个回合制的地下城探险类游戏的循环机制应该是如下这样的。
- 进入一个随机生成的地下城关卡
- 探索地下城
- 遇到怪兽，与怪兽战斗或者逃离
- 捡起在行进路上遇到的物品
- 寻找关卡的出口，然后从步骤 1 重新开始
你所设计的游戏也可以包含多个循环。这样做没什么问题，但也可能是一种值得警惕的迹象 —— 它表明开发者可能正朝着开发一个大型或者复杂游戏的方向前进。一个即时战略类游戏一般会有下列几个不同的循环。
- 找到资源并且安排工人去开采
- 建造自己的基地，需要同时考虑资源消耗、游戏单位的建造，以及防御系统
- 组建自己的军队
- 找到敌人的据点，并指挥自己的军队消灭敌人
最简可行产品
为游戏想出各种创意是很容易的，但去繁就简找到游戏最本质的要素反而是一件困难的事情。能够实现最基础设计功能的最小程序称之为最简可行产品，也就是 MVP。
MVP 是开发者的最初目标。首先构建由 MVP 拆分出的各个部件，一旦这些部件可以拼合起来，那就已经有了一个实际可玩的游戏。虽然这不是最终的游戏，但这是一个值得骄傲的成就。你可以把它分享给朋友试玩以获取反馈意见。在实际试玩之前，你永远无法判断一个创意是不是一个好创意。把经历击中在实现 MVP 功能上可以避免花费好几个小时打磨一个听起来很有趣但在现实中并不理想的功能。
延展目标
一旦确定了 MVP 功能的列表，你就可以把其他所有希望开发的功能特性加入延展目标列表中。请试着把这些目标按照重要性排序，因为开发者可能无法实现其中的所有项目。理想情况下，开发者应该选择那些既符合游戏整体设计规划，又容易实现的目标。坐下来写一会儿就能完成的功能特性要比那些要花费数个星期才能实现的目标更能激发开发者的热情。
INFO
跳过森林，不要向摩多进军
如果你曾经就职于软件行业，那么大概率体验过“死亡行军”一般的项目。每个人都感到精疲力竭，在项目上投入的时间越多，反而感觉距离取得成功越遥远。这并不是在开玩笑，所以要尽量避免把这样的压力强加到自己身上。如果一个目标使自己感到有压力，那么就把它从设计中去掉。如果你是一个孤独的游戏爱好者，那么这一点尤为重要。如果连开发者本人都讨厌制作游戏，那么这种“怨念”最终会被玩家察觉到并使玩家对这款游戏产生厌恶。
关于永远不会用到的东西
如果想让游戏顺利完成，那就要粗暴一些，把所有不在 MVP 中的功能全部放到扩展目标里。开发者一旦开始享受开发游戏的乐趣，就会有层出不穷的想法，其中有一些想法是可行的，但也有一些是不好的。你可以先把它们都记下来，但是在把它们添加到游戏设计文档中作为一个新任务之前，问问自己，“我真的需要这个功能吗？”除了核心功能，你大概率并不需要这个功能 —— 它只是锦上添花而已。如果这些额外功能看起来可以实现，就把它们加入扩展目标中；否则，就让它们继续躺在笔记本里 —— 也许可以在游戏的 2.0 版本中加入它们，或者用它们打造一个全新的游戏。
Sprints 与信心保持
现在你有了最高层次的开发文档，接下来可以将其转化为计划。你需要把创意分解为多个容易处理的小任务块。游戏包含一个可以在地下城里游走的玩家角色吗？这个功能就是一个大小合理的任务块 —— 创建地图并且让玩家角色可以在其中移动。游戏是回合制的吗？搭建起回合制的框架是一个不错的 Sprint。本书的各个章节被特意设计为与真实开发中的各个 Sprint 相对应。
在讨论 Sprint 时，你需要考虑到它们之间的依赖关系。直到拥有了地图、玩家角色以及可以和玩家角色对战的元素之后，开发者才可能去实现战斗系统。直到玩家具有生命值属性以后，回血药才变得有用处。高能热核爆炸很酷炫，但是它需要先有被打击的目标、使用它的原因、以及一种用来展示其强大破坏力的表现方式。
保持 Sprint 短小的另一个原因是它可以很好地保持开发者的开发动力。一个小的 Sprint —— 特别是在一小段时间内就能完成的 —— 可以给开发者带来项目进度被显著推进的感觉。它们可以试玩新加入的功能，然后说，“看，我实现了这个功能。”这一点非常重要。要避免先把所有代码一口气写完再做集成的“瀑布式”开发模式，这种模式会导致开发者几个月都看不到一丁点有价值的进展，从而变得灰心并且对项目失去兴趣。
不要害怕说出“这段代码没什么用”的话，可以先把它删掉 —— 但是要记得把它备份在一个地方，即便是放在一个 Github 的分支里面也行，你在后面的开发中很有可能会再次回过头来使用它。
设计文档带来的长期受益
保持记笔记的习惯可以为开发者打造出一个创意池，当有写代码的冲动时，开发者可以从中寻找灵感。这可以帮助开发者克服写作困难症 —— 没有什么比面对一个新建的空文档冥思苦想更糟糕的事情了。从创意池中选择一个创意，先写一个简陋的设计文档，然后拼凑出一个原型。即使做出来的东西很糟糕也没关系，每个游戏开发者都是从制作糟糕的游戏开始的。重要的是，开发者实际尝试做了一些东西，并且在做的过程中学到了新东西。
随着开发者逐渐变得更优秀，经历过的失败项目和成功项目会越来越多，开发者的经验会逐渐积累起来，而且对于项目的成败也会有更加敏锐的直觉。此外，开发者还会开始编写很多可以复用的代码。如果一个游戏创意需要一些来自以前项目中的东西，那么可以直接拿过来使用。
认清自己的能力
如果你经常访问游戏开发论坛或者 Discord 网站，就会发现每一个人都有远大的想法。每当有信任开发者发帖介绍自己所设想的大规模多人在线游戏、大型角色扮演游戏、或者和《刺客信条》一样规模的游戏时，都会被类似“为什么不从写一个 Pong 开始呢？”这样的回复刷屏。虽然表面上看起来不太礼貌，但这些长期混迹于论坛的老油条们并不是故意对新人刻薄。因为开发者确实需要从小的项目做起，并且逐步积累经验。这就是本书以 Flappy Dragon 作为起点的原因 —— 你可以在一个章节内完成这个游戏，并且在这个过程中掌握很多基础知识。总有一天，你 ( 以及你所在的大型游戏团队 ) 将准备好去制作一个和《魔兽世界》( World of Warcraft ) 相媲美的游戏。如果一开始就从如此大规模的游戏入手，那么几乎可以预料到一个大家都熟悉的结局：信心满满地开始，然后意识到开发支持数千人在线的网络代码有多么复杂，于是决定写一个小一点的游戏，或者彻底放弃游戏开发。
记笔记的习惯可以使你能够描述自己的梦想。但要意识到，在具备相应的能力之前，它只是一个梦想。
快速试错
在设计一个新颖的游戏时，开发者有可能会忽略掉最重要的一点：游戏本身不好玩。然而问题是，除非实际试玩过，否则谁也不会知道好玩还是不好玩 ( 尽管有时经验可以帮助判断 )。创建一个能展现游戏核心玩法的简陋模型，然后把它展示给一个值得信任的好朋友。如果游戏的核心玩法是个非常好的创意，当他在享受游戏时会自然而然地露出喜爱之情。如果核心创意是无趣的，那也没关系。在这个创意的旁边标注上“这是一个好主意”并让它继续躺在笔记本中，然后继续尝试下一条创意。也许有一天，你会发现它可以成为一个在大型游戏中嵌入的迷你小游戏。最坏的情况是，你从中吸取了教训，并决定不再尝试这个创意。
不要强调截止日期
INFO
我喜爱截止日期。我喜爱它们来临时发出的呼啸声。—— Douglas Adams
如果你做游戏是兴趣使然，那么就不要被截止日期束住手脚。没有什么能比一个原本“有趣”的项目却让开发者因任务延期而感到痛苦更糟糕的事情了。如果你正在使用一个项目管理软件，那么不妨给自己留出足够富裕的时间 —— 如果真的逾期了，就重新调整时间安排。
小结
从用笔记本记录灵感到简短设计文档的模板，你应该已经了解了规划一个小型游戏项目的全部内容。你不需要花费数小时的时间来编写内容冗长的设计手册 —— 但是在开始前快速勾勒一个轮廓可以保证你在开发过程中不会走偏，从而保证项目能够完成。