如何写游戏策划文档？

我看了一个大佬分享如何撰写游戏设计文档的视频：

不过如果你翻不了墙也没关系，接下来我会把每一页PPT都截下来，并且说明其要点。由于文章很长，下面是整体目录：

• 游戏策划文档有必要吗？
• 文档是写给谁的？
• 写文档的阶段
  • 愿景陈述
  • 高概念
  • 游戏设计文档（GDD）
  • 产品模块分解（PBS）
  • 详细开发文档
• 如何写好一个详细开发文档？
  • 保证可读性
  • 可视化
  • 力求精准
  • 不惧怕改动
  • 及时更新
• 最佳实践
  • 边玩边做
  • 别怕砍功能
  • 管理好需求变更
  • Story Mapping
  • 其他策划工具推荐
  • 其他忠告
  • 扩展阅读

目录里面我认为重要的部分我都加粗了，感兴趣的同学可以跳着看。首先要说明的一点是，大佬分享的经验更类似于传统的单机开发流程，而我在整理的时候会将其整理为对我们以免费、长线、不断迭代的游戏更为合适的版本。

下面进入第一个话题，既然我们要讲如何写游戏策划文档，那么第一个问题是……

游戏策划文档有必要吗？

一提到策划文档（或者按英文的说法叫游戏设计文档，Game Design Document，缩写GDD），很多人都会蹦出来说这玩意没必要，无外乎以下几种说辞：

• 就算你写了也没人看
• 写文档花的时间太多了，有这时间不如去实际开发功能
• 我们是敏捷迭代，不需要文档
• 变化太快了，文档只要你写了就是过期的
• 我们慢慢迭代就好，不需要文档

在大佬看来，这些都是很差劲的说辞，而我也很认同这个观点，我们不妨一条一条驳斥上面的说法：

写了没人看？

并不是文档没用，而是策划的锅，说明你写的烂！

写的烂的文档的几大特点：

• 洋洋洒洒的大段文本
• 用的工具不对
• 文档没做到时刻保持最新
• 无关紧要的内容
• 相应内容很难找到
• 写的受众不对

这些具体怎么办，下面会说。接下来驳斥第二条：

变化太快了，文档总是跟不上需求变更？/既然我们不确定最终做出来的是什么，为什么要为中间品写文档？

不要害怕文档发生变化，文档发生变化是正常的，一开始的时候不知道最终做出来的东西是什么样的并不是不需要文档的借口。

正确的做法是每一步都有扎实的文档，并且当发现不对的时候就改变，并且时刻将改变更新到文档中去。

所以一不要怕变化，二变化之后要及时更新。

最后第三条：

敏捷迭代不需要文档？/有空写文档不如去实际开发功能？

大佬驳斥这一点的时候给出了一个例子：敏捷迭代中也是有计划的，这个东西叫Backlog（也就是待做事项列表），里面会有所有要做的内容以及任务的分配，整个团队要持续对这个待做事项列表进行维护，确保任何时点团队成员都知道完成整个项目还有多少内容要做。这个东西其实就是游戏设计文档。

在视频将近结尾的地方大佬又把敏捷迭代拿出来说了一遍，因此我把这段提前了也整理在了这里。

首先大佬表示，所谓的敏捷迭代在游戏行业中并不是什么新鲜东西，最早的雅达利的游戏基本都是靠敏捷迭代搞出来的。另外敏捷迭代和非敏捷迭代其实也没有特别大的区别，都要有功能的说明、功能的优先级、都注重于如何尽快实装、并且也都一直在用User Story（从玩家角度出发详细的描述一个玩家玩这个游戏的各种过程）或者Epic（从玩家的角度来出发描述如果能怎么样这个游戏会很牛逼）来提需求。而且，敏捷迭代还有一系列问题：

• Backlog（待做事项列表）只有一大堆功能，但没有任何结构、图片说明和索引。
• 上下文和链接都不容易理解。
• 同时要维护待做事项列表、游戏设计文档是很累人的
• 产品到底谁说了算？制作人？策划？老板？还是谁？

其实上面说的这四点我不太懂，因为我不太清楚真正的敏捷迭代是啥样的，但从过亲身经历我可以举个栗子说明一下，没有文档的日子过起来是什么样的：

---

• 你要盖一栋10层的楼，你觉得很简单，盖完了。
• 接下来接到了需求，要加盖10层。好，这没啥难的，因为你对1-10层熟悉得不得了，11-20层盖的很顺利。
• 接下来的几个月你去做别的东西了，半年后老板要你回来，跟你说1-5层要改成商铺。你花了很大代价想起来了当年1-10层是怎么盖的，终于把1-5层改成商铺了。
• 接下来要在房顶上加个游泳池。
• 接下来要粉刷外部墙壁。
• 接下来要在8层打通一个天桥连接到隔壁楼。
• 接下来要给1-20层加装电梯，整个楼层都要打通一个电梯井。
• 接下来要在房顶的游泳池下面做一个餐厅，屋顶要是透明的可以看见拥有池中的水。
• 接下来要盖地下停车场。
• 接下来要给1-20层加装空调，这会破坏你之前粉刷的墙壁。
• 接下来要加盖21-30层，然后你才想起来现在20层的楼顶上还有个游泳池，并且下面还有个透明房顶的餐厅。
• 并且21-30层都要有粉刷后的墙壁、电梯以及空调。

---

如果你没有一个时刻更新的最新文档的话，你觉得你能活到第几步？

讨论完了文档的必要性后进入第二话题：

文档是给谁写的？

这分为对内和对外两部分。对内：

• 程序员
• 其他策划
• 美术（视觉与听觉）
• QA

对外：

• 老板或项目负责人，反正是你需要给个交代的大佬
• 外包
• 外部QA
• 有的时候还包括媒体、品宣、市场等

那么我们给他们写文档看是为了达到什么目的？

• 对要做什么样的东西达成共识（不管是对内还是对外）
• 帮助团队聚焦（不管是对内还是对外）
• 是预估工数、排优先级以及功能依赖性的基础
• 是QA团队测试计划的基础，定义了什么样叫“做完了”
• 是需求变更的基础

写文档的阶段

大佬讲一个文档的生命周期分为了五个阶段：

• 愿景陈述
• 高概念
• 游戏设计文档（GDD）
• 产品模块分解（PBS）
• 详细开发文档

如文章开始所说，大佬的这个阶段划分也是按照典型的传统单机开发流程来写的，因此我会按照我的理解来将其转换为更接近与免费、长线游戏的版本。

愿景陈述和高概念两个阶段我会简单带过，重点在后面三个阶段。

愿景陈述阶段

愿景陈述的目的：

• 与开发组达成共识
• 一切所有后续文档的基础
• 用来检验所有后续的文档是否偏离初衷
• 永远是一篇游戏设计文档（GDD）的第一段或第一页
• 定义整个游戏的核心精华体验

具体内容：

• 最多1-2页
• 从体验开始说
• 核心玩法
• 主要与次要游戏主题

《帝国时代》是一款历史题材的PC即时战略游戏，通过结合《魔兽争霸2》的RTS玩法与《文明》系列的历史与经济元素，体验地球上最初的文明的崛起。

我想说的是，上面这段例子写的非常牛逼，能写出这种例子的人，已经不是普通策划了。

愿景陈述这东西对于我们从业者来说其实很难经历到，因为我们一般都没有从头立项的资格与能力，但是我们可以吸收这一段的精华，将其转换为每一篇策划文档开头的设计目的，通过提纲挈领的方式快速写清整个文档要达成一种什么样的效果，可以让阅读的人判断后续的内容写的是否有偏离。

总之，任何一篇涉及到稍微大一点的功能的文档，都应该以这个作为开篇，即这篇文档说描述的功能要达成一种什么样的效果。

按照我的 【需求 -> 思路 -> 设计】三步来走的话，这步是第一步：确定目的。

• 需求：我们要达到什么目的
• 思路：我们通过哪些功能模块达到这个目的
• 设计：这些功能模块具体是怎么运作的

当然如果拆的更细的话可以分为四步：

• 需求：我们要达到什么目的
• 思路：我们通过什么方式达到这个目的
• 设计：我们通过提供哪些功能模块来实现上述思路
• 实现：我们通过具体完成哪些工作可以完成上述设计

总之很灵活，但是要做的事情都是一样的。

高概念

高概念的目的：

• 又叫设计草案、概念稿或提案圣经
• 把产品卖出去的工具
• 把你的点子展现给感兴趣的发行商
• 为需要开发的内容定下目标
• 定义目标群体、年龄、性别等
• 最好和第一版原型同时提交

具体内容：

• 最多10-20页
• 核心特色与卖点
• 核心玩法，早起、中期、后期玩法的展现
• 线框图，原型与竞品
• 目标受众群体，性别，市场信息，盈利手段
• 研发团队说明

最后说明：

• 什么时候来做高概念？——愿景陈述之后，提交给感兴趣的发行商之前。
• 高概念是给谁看的？——对外给发行商，制作人或各种大佬看，对内给开发团队成员看。

我想说的是，能够把高概念阶段搞定的人已经不是一般的策划了，而是有立项能力的制作人了，关于制作人需要什么能力以我的水平来探讨有点力不从心，因此这段就简单略过了。

下面进入重头戏，第三部分：

游戏设计文档（GDD）

GDD的目的：

• 描述所有主要的功能，愿景，质量，这样团队的开发成员能够大致判断各个模块的复杂度。
• 游戏玩法与循环的说明，并列出游戏功能的优先级。
• 规模要根据团队的开发能力来规定。
• 量力而行，别贪多。
• 保持简单、清晰。

具体内容：

• 所有相关的游戏功能与玩法循环
• 定义规模与品质要求
• 说明美术风格需求
• 关卡、世界观或主线剧情需求
• 盈利手段，如果是免费游戏的话还有玩家分层规划
• 一般不包括：具体公式、数值、设定、配表等等等等

最后说明：

• 什么时候做GDD文档？——预生产阶段，就是规划项目计划、时间估算以及预算的时候。
• GDD是给谁看的？——内部团队，要能确定时间估算，要生产的资产列表，以及进行风险评估等等。外部团队大佬以及主要的相关利益者也要能看到。

这部分内容对于我们的实际工作就有意义的多了，因为GDD已经描述了多有主要功能模块，而我们日常的工作其实就是在打磨一个个的工作模块。

按照我的【需求 -> 思路 -> 设计 】三步来走，这一步其实就是思路阶段。它不包含详细的开发用文档，但已经可以说明白每一个功能模块具体都要做什么了，因为开发团队已经可以拿着它来预估工数了。并且我们可以回头根据需求来判断，这个思路是否是解决需求的最好思路，或者说这个解决思路的代价我们能否接受。只有当我们确定了需求和思路都没问题的时候，进入详细设计阶段才有意义。

下面是第四个阶段：

产品模块分解（PBS）

PBS的目的：

• 能够整体总览所有功能模块与资产
• 包括敏捷迭代的全部内容
• 后续计划与进度估算的根本
• 有助于排优先级

具体做法：

• 用脑图
• 列出功能点
• 列出资产
• 列出技术
• 不分解具体的任务，只写详细的功能描述
• 不包括资源分配和依赖关系

最后说明：

• 什么时候做PBS？——与GDD同步做，GDD开始的时候做，结束的时候一并结束
• 给谁看的？——设计游戏的主要系统，PM，产品负责人

显然，PBS的作用是从宏观上辅助GDD的，因此当我们并不需要从宏观的角度出发，项目已经进入后续稳定的迭代阶段的时候，就不需要PBS了。

但是当我们制作一个复杂的大功能的时候，将其分解为各个模块是非常有必要的。由于在我们的策划团队中PM也是由策划担当的，但功能拆分并不是由策划来做的，而是策划给出详细设计文档后由程序和美术各自估算工数的，所以PBS在实践层面意义不大，或者说它本身就是GDD的一部分。

当我们功能过大的时候，学会用类似PBS的方式拆解功能是很关键的，也是PM的核心能力。

最后是第五部分：

详细开发文档

详细开发文档的目的：

• 所有下次迭代相关的功能的非常详细的设计文档
• 详细到什么程度算合适？要详细到可以拆解任务并且按照人时来分配任务的地步
• 详细到会明确的列出所有要完成的内容的列表，因此完成全部列表里面的项目后就可以认为开发完成了
• 包括所有的详细的公式、数值、配表等等
• 应该与技术组或程序员紧密合作

具体内容：

• 功能优先级（哪些是必做的，哪些是要做的，哪些是最好能做的）
• 每个功能模块的竞争力（简单做做就好，还是要有一定竞争力，还是要另辟蹊径，甚至大幅革新）
• 每个功能模块的大致目的
• 实装一个功能的具体要完成的内容，用列表、用例甚至伪代码的方式来详细说明
• 策划说明
• 风险
• 变动记录

最后说明：

• 什么时候做？——正式开发阶段，每个迭代开始前
• 给谁看的？——程序员与QA，大佬，以及外部QA

显然这段是非常干货的，就是【需求 -> 思路 -> 设计 -> 实现】阶段的最后一个阶段：实现了。因为前面说的一大堆都是前期设计阶段，这部分终于到了撰写用于实际开发的文档的阶段了，也就是大部分策划实际工作面临的内容，毕竟做一个游戏有创意的部分只占10%，剩下90%都是苦力活儿，而干好了这90%才有机会去做那10%。

那么如何才能写好一个详细开发文档？

分为几个方面：

• 保证可读性
• 可视化
• 力求精准
• 不惧怕改动
• 及时更新

保证可读性

简短是高端的体现：

• 保持简短，不要罗里吧嗦
• 用列表写内容，不要写大段文本
• 如果一个功能比较大，拆分成数个比较小的子功能
• 避免冗余
• 使用超链接，交叉引用，以及表格
• 自己发明一套模板，并且坚持用下去

---

功能总览：

• 这个小游戏会在屏幕上方显示4个不同颜色的容器。它们分别代表千，百，十与一（十进制）。
• 容器上方会显示一道数学题。下方的触摸屏上会显示一条传送带，上面有不同颜色的圆球在运动。
• 玩家必须用控制唱针“抓住”对应的球并把它们扔到对应对应的正确的容器中。
• 玩家必须根据数学题的正确答案来为每个容器装入正确的数量的球。每个容器只能保存0至9个球。

功能实现：

• 为了把正确的球放入正确的容器中，玩家必须用唱针指向被选中的球，并且持续按住唱针。
• 然后圆球就“扎”在了唱针上，离开传送带随着唱针移动。
• 玩家必须把唱针移动到正确的容器上然后“抖”一下唱针，这样球就会落入玩家的NDS的上面一块屏幕中的容器中。
• 如果玩家在“抖”唱针之前就松开了唱针，圆球会掉落回传送带上。
• 玩家必须持续的抓球放球，直到数学问题得到正确解答。当所有容器都被填上了正确的球的时候，程序要能自动判断已经回答正确了。
• 在这种情况下屏幕上会播放一种视觉反馈，以及一个积极的音效，来告诉玩家他赢了。

---

可视化

一图胜千言：

• 尽可能的通过可视化的方式来说明功能，做原型也好，做界面迁移图也好
• 找其他游戏或电影或各种媒体的例子来说明你的功能
• 可视化的工具：PPT，Visio
• 注意：不要抢UI设计师或美术的活儿，你做的东西只是用来说明功能的
• 不要越俎代庖告诉别人怎么做他们的工作

几种可视化的例子：

力求精准

你的陈述应该要么是“YES”要么是“NO”：

• 别用“可能”，“也许”这种词
• 别用“我们”这个词
• 别光顾着说玩家能做什么，同时也要说清楚玩家不能做什么
• 别假设你的读者精通各种缩写（如DOT、AOE啥的）

不惧怕改动

好产品都是改出来的：

• 记住，允许计划变动不是你不写文档的借口
• 拥抱改变：根据反馈来强化、迭代你的设计
• 只有通过清晰的文档，才能评估方案改变的工数影响
• 所有功能都要写好变更记录
• 每次修改的时候都写明白修改的原因，否则半年之后又会有人把这个问题拉出来讨论一遍

及时更新

• 时刻保证文档是最新的
• 别用离线的文本管理方式，那样每个人手里都会有一份不同的文档，并且没人知道最新的是什么
• 所有文档都必须纳入版本管理中
• 用好Wiki，谷歌文档之类的工具

最佳实践

到上面就说完了如何写游戏详细设计文档，最后一个环节是大佬分享了自己的其他建议，分为七个部分：

• 边玩边做
• 别怕砍功能
• 管理好需求变更
• Story Mapping
• 其他策划工具推荐
• 其他忠告
• 扩展阅读

边玩边做

• 和团队成员定期玩自己做的游戏
• 当游戏进入可玩阶段后，至少一周一次勇于批评，勇于接受批评
• 时刻保持接受外部反馈

别怕砍功能

• 做的玩意不行——砍掉！
• 德国设计师（做加法）vs美国设计师（做减法），做后者！
• 小心功能膨胀
• “没东西可加了不是完美，没东西可减了才是完美”

管理好需求变更

• 确保工作流程中有对应的环节是允许需求变更的
• 确保需求变更针对于你游戏的核心特色是有益的
• 确保需求变更是通过一个正式的流程来通过或被否决的
• 所有需求变更都做好变更日志，不管是通过了的还是否决了的

Story Mapping

大佬丢了个链接来说明啥叫Story Mapping：

http://www.thoughtworks.com/de/insights/blog/story-mapping-visual-way-building-product-backlog

并且还配了个例子的图：

但我还是没看懂。不过我觉得Story Mapping归根结底是管理需求的一种手段，具体咋用我没看懂，所以这段跳过。

其他策划工具推荐

• 脑图工具，比如Xmind或者Mind Manager
• Trello（用来跟踪美术资产开发进度比较有用）
• PPT，Visio，Balsamiq，甚至铅笔来做线框图
• 用来放设计文档的Wiki（比如Confluence）
• 谷歌文档（国内就别想了）

其他忠告

• 在预开发阶段做多迭代，而不是已经开发了频繁改动
• 设计原型越早、越多越好，能运行的原型永远比纸面上的文档强
• 先做最重要也是最有风险的部分
• 勿忘初心：你是最终为体验是否有趣负责的人
• 如果确定要改动内容，在交付实际开发之前，先跟大佬打好招呼……说白了就是不要私自改动设计！

扩展阅读

• 如何写游戏设计文档：

http://www.zenofdesign.com/wp-content/uploads/2014/12/Writing_Design_Docs_2008.pdf

• Story Mapping：链接我前面贴过了这里不重复了
• 400 Project（需科学上网）：

http://www.finitearts.com/pages/400page.html

• 游戏策划的五个规则：

http://www.gamesauce.biz/2010/09/07/bruce-shelleys-five-rulessteps-for-a-game-design%E2%80%99s-first-draft/

• 游戏怎样才能屌（我试了没打开，科学上网也没用）：

http://pixelpaton.com/?p=3385