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

不过如果你翻不了墙也没关系，接下来我会把每一页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

这篇文章AT君一直想写，趁着这周双休来写一下（其实是因为八月只写了一篇博客，要抓住八月份的尾巴！）。

标题《干死玄学策划：Why与How》说明了文章的两部分：第一部分：为啥要干死玄学策划，第二部分：如何干死玄学策划。下面正式开始！

为啥要干死玄学策划

既然要反对玄学，那么首先就要说明一下什么是玄学，AT君由于并不喜欢讨论玄学内容，因此理解比较粗浅，在我的理解中，凡是出现过下面两个图的现象的策划，就是玄学策划：

这两个图总结下来就是两方面的问题：

• 感觉某个东西不对，但说不出来问题在哪。（上图）
• 知道某个东西好，但说不出来好在哪。（下图）

这两个问题在策划的工作中可以说是致命的，这个致命体现在两方面：

• 在策划的内部交流中，谁也无法说服谁，一个觉得主角叫张三好，一个觉得叫李四好，撕逼撕一宿也没有结果；
• 在和外部的交流的过程中，无法给出其他人（主要是美术，其次是程序）要删改某些功能的理由，只是强调“这么改绝对更好”，这句话的可信程度基本等于“我半藏玩的贼6”，在其他部门中的声望变成仇恨。

AT君认为，策划这个职业最重要的两个属性是能力（个人策划力）与魅力（团队靠谱力），想要走得远要两条腿抓两条腿都要粗。由于国内没啥像样的教育机构，因此几乎没有科班出身的策划，所有策划（AT君并不是针对某个人，而是指在座的各位，包括我自己）多多少少都有些玄学。玄学策划在能力方面一般都是值得肯定的，都有比较强的判断能力，自身的底子不会太薄，但玄学策划普遍无法说服别人，茶壶煮饺子，会被其它人恨，魅力约等于0，团队中人人都想弄死策划，所以玄学策划等于被打断了一条腿，另一条腿再粗也是个残疾。

AT君认为，玄学策划的问题的根本在于，缺乏把自己的判断力总结成规范化的原则与方法的能力。

缺乏这种能力的话，对内来说，玄学策划只能授人鱼不能授人渔，如果新人策划跟着玄学策划学本事，就真的只能“师傅领进门修行在个人”，只能靠自己的悟性从工作中总结经验，手把手的跟着学，从受到的“鱼”中自己领悟“渔”，而这种策划多了，就更会觉得策划本身就是这么一个特别有禅意、特别讲究顿悟的职业，有经验的老司机们都这么玄，那我自然也要尽快地变得更加玄才行，从而产生更多的玄学策划，陷入一种恶性循环；而实际上，策划和木匠、厨子没啥区别，并没有多少禅意在里面，一点都不玄。

对外来说，由于缺乏高屋建瓴的能力，往往其他部门的人（尤其是美术）做了很多工作了回头被一句“感觉不对”噎死，而更大的问题是改倒是不怕，但不知道要往什么方向改，玄学策划往往会丢出“要大气”，“要有《满江红》的感觉”，鬼他妈知道《满江红》什么感觉？一千人有一千个林黛玉，是不是也有一千个《满江红》？要求其他人也靠悟性和感性去理解自己的玄学需求，是一种极不负责任的做法，很容易做完了又被说“感觉不对”，浪费了大量的试错时间，美术要加班，策划要陪着，项目要延误。因此，玄学策划害人不浅。

最后一个问题是，玄学策划久而久之会陷入一个巨大的幻象中，就是自己总是怀才不遇的，为啥会这样呢？因为玄学无法向别人证明自己屌不屌，在无法证明的前提下人总是会觉得自己是屌的——没人愿意承认自己是个傻逼，心理防御机制就是这样的，人性弱点，所以策划普遍是骄傲的。你要问玄学策划们为啥干了这么多年工作还没有一个很屌的成果来证明自己，他们会说玩家都是傻逼，美术画的太他妈烂，程序代码一坨翔，投资人是煤老板，老板瞎鸡巴改等等理由，反正理由不在自己身上，因为老子特别的玄，你们这帮傻逼都不懂。

这就是AT君对玄学策划的理解，以及为啥要干死玄学策划的理由。

如何干死玄学策划

那么咋才能不玄学呢？也就是说，咋才能获得把自己的判断力总结成规范化的原则与方法的能力呢？由于AT君也是一个以玄起家的策划，并没有什么权威性的答案，只能说说自己的理解，一家之言仅供参考。

AT君认为策划要摆脱玄学，要做到以下三点：

1. 意识到自己的倾向性；
2. 懂基本的美术设计原理；
3. 懂编程的基本原理。

从下往上说，更容易一些。第三点，懂编程的基本原理，这个不难，学写代码就行了，如果不知道该学啥，就学VBA，总是没错的，一定能用上，能把VBA用的贼6，跟程序打交道就不成问题了，而且什么东西技术上能实现什么东西技术上实现不了，基本都能心里有数。

第二点，懂基本的美术和设计原理，这个看起来好像比起农代码更玄一些了，因为美术这东西你懂的，感性，艺术家，blahblahblah，其实都是扯淡，第二点的关键是以设计师的眼光去看待游戏，而不是以艺术家的眼光。艺术家很玄学，而设计师跟上面说的木匠厨子一样，一点都不玄。那么设计师咋入门？AT君的建议是看锤子设计师罗子雄的TED演讲（虽然最近网传他已经离职了），我经常把这个视频拿出来反复观看，因为这种直接告诉你可操作的方法的超级干货视频是非常少见的：

http://open.163.com/movie/2015/7/B/M/MATL76APV_MATL8FCBM.html

除了这个视频以外，AT君还建议多看各种为游戏美术从业人员提供的教学视频，作为策划不是去学技术的，而去学思想和方法的，这是非常关键的，能出来讲课的老师，基本都是脱离了玄学美术（是的，和策划一样，美术也有“玄学美术”）水平的，能达到这种水平的都是能授人渔的美术的，多看一些，能大幅提高和美术进行沟通的效率，封印自己的“感觉不对”大招。AT君最近就一直在看腾讯的GAD的美术讲座，感觉受益良多（妈的腾讯是不是该给我广告费）。总之，第二点一点都不玄，除了设计方面的基本常识以外，还要懂技术美术方面的常识，如序列帧动画的原理，骨骼动画的原理，法线贴图的原理，PBR材质的原理等等，玄吗？闹太套。

最后，第一点，意识到自己的倾向性，这个非常关键，但也是最玄的，因为这玩意等同于策划的心法。曾经有一本游戏设计书，把这一段描写成策划要进入一种冥想的状态，在玩游戏的时候，脑子里还有另外一个自己在观察自己的心路历程，什么时候自己感到好玩，什么时候感到无趣，也就是说，不再是以单纯的玩家在玩游戏，而是在以设计师的角度来品游戏。这个太玄了，因此AT君更建议用“干死玄学策划口诀”来代替这个神秘的冥想：

• 萝卜青菜，各有所爱；
• 萝卜青菜，各有所爱；
• 萝卜青菜，各有所爱。

重要的口诀念三遍。比如AT君非常不爱玩三消游戏，玩起来简直是味同嚼蜡，如果是Ego膨胀的没边的玄学AT君会认为这种游戏都是垃圾，爱玩的都是傻逼，从King公司离职去做《MineCraft》的Markus Persson才是具有Real Gamer Soul的Hardcore Indie Developer（为了装逼此处用英文），然而事实并不是如此——事实只是萝卜青菜各有所爱罢了。反过来讲也一样，比如暴雪脑残粉玄学AT君会觉得《魔兽世界》太他妈好玩了，玩起来觉得没意思的人都是傻逼，和他们说话简直会被传染上傻逼细菌，而事实也并不是如此——事实只是萝卜青菜各有所爱罢了。而对三消游戏恨之入骨的玄学AT君却发现《骑士故事》、《战神的挑战》这种三消居然很好玩，那么AT君就要接下来想是不是因为加入了战斗元素使自己这种不爱玩三消的人开始变得喜欢玩三消的？意识到自己爱玩什么类型的游戏，不爱玩什么类型的游戏，尤其是那些爱玩自己不爱玩的类型的游戏的玩家为什么爱玩这些游戏的原因，是“萝卜青菜”口诀的关键。

学会了第一段口诀后，再学“干死玄学策划口诀·其二”：

• 不要吹毛求疵，要去芜存菁；
• 不要吹毛求疵，要去芜存菁；
• 不要吹毛求疵，要去芜存菁。

具体一点来说就是，只盯着毛病看的人，成长的非常慢，而从差劲的作品中都能学习到的人，才是成长快的人。比如大喷子玄学AT君在玩一个非常垃圾的游戏（这个游戏真的很垃圾），觉得这个游戏太他妈烂了，简直就是一坨翔，从而直接枪毙了该游戏，觉得这个游戏没有任何值得学习的地方，但却没发现这个游戏的TIP是动态的，按屏幕的左半边TIP会在右面出现，按屏幕的右半边TIP会在左侧出现，总是不会挡住的，而自己做的游戏怎么按TIP都在屏幕中间经常被自己的手指挡住；

最后，“干死玄学策划口诀·其三”：

• 知其然没意义，知其所以然才有意义；
• 知其然没意义，知其所以然才有意义；
• 知其然没意义，知其所以然才有意义。

比如，面对着一个并不是很靠谱的策划案，暴乱狂策划玄学AT君咆哮着喊不行，这个案不好，而压根不想去理解提出这个案的背后的想法和动机是什么，要达到什么目的，是否达到了这个目的，是否会引出其他问题，是否解决了最初的需求等等，这些连想都没想就掀桌了，这还是在靠“棒喝”去让人顿悟的玄学做法，特别low。再比如，大喷子玄学AT君策划觉得首充界面放一个大美女实在是太他妈的low了，却没想想为啥要这么做，只是因为别人这么做自己也跟着这么做，典型的知其然不知其所以然。再比如，暴雪脑残黑AT君觉得《炉石传说》攻打暴风城的这个乱斗太他妈无聊了，简直是一坨屎，每回合变的数值更高的暴风城杂兵这也叫设计？却忽略了这个模式通过这个机制做到了菜鸡玩家必有一赢可以来随便刷钱，高手玩家可以来挑战自我的设计结果。如果暴雪脑残黑AT君能意识到这一点，并且尝试设计一个能达到同样设计结果的更优秀、更好玩的模式，那才是靠谱的策划，脱离了玄学的策划，一个有益于所有人的策划。

这篇文章所要探讨的是，在我们设计一款游戏的时候，我们到底如何判断各种idea是否符合我们的目的？或者说我们到底是如何产生这个目的的？

这是一个很抽象的东西，但举起例子来又很具体——大家都知道《口袋妖怪》中不会出现烟酒、脏话、暴力等元素，让任何一个人去做续作，他都会清楚出现这些东西就意味着砸招牌。那么到底是什么来决定了《口袋妖怪》之所以成为《口袋妖怪》的呢？

我们暂时抛下这个问题不管，先让AT君先解释一下本文标题的含义。所谓面向体验的含义就是，“我们要设计一款提供XXXXXX这种体验的游戏”，而面向用户的设计的含义就是，“我们要设计一个XXXXX用户群喜欢的游戏”。这两种设计思路并非完全对立，但大部分时候在面对项目组其他人的质疑的时候，你都必须要进行解释为什么做某些事情是必要的，而最根本的解释无非是以上两个中的某一个。

大家都知道，《口袋妖怪》之父田尻智的初衷是为了满足自己儿时森林冒险，捕捉昆虫，然后与同学交换昆虫的梦想。也就是说，这是一个典型的“面向体验的设计”。绝大多数游戏设计师们都有喜爱设计自己喜爱的游戏类型的倾向，因为他们往往自己就能代表目标群体，《口袋妖怪》显然就是这种设计思路下诞生的游戏。

但《游戏设计基础》一书的作者Ernest Adams认为，这种做法并不够专业，因为我们作为专业的游戏设计师，往往要设计一些并不是自己非常喜爱或擅长的类型的游戏，在这种情况下难道我们还能撂挑子不干了不成？

Ernest Adams还举出了一个看似非常有说服力的例子：儿童游戏。大家都知道，游戏设计师都是成年人，儿童是不可能自己为自己设计游戏的，因此儿童游戏的存在正说明了“面向用户的设计”的威力——成功的游戏设计师能够为自己绝对代表不了的目标群体来设计游戏。

但实际上，AT君认为这个例子站不住脚，那些成功的儿童游戏，实际上还是“面向体验的设计”所产生的结果，也就是说出色的儿童游戏设计师，要么是在基于自己的童年经历设计游戏，要么是自己已经是有很丰富育儿经验的父母，他们还是在基于个人的经历来判断这些体验是否是适合儿童的——说白了还是在为童年的自己或自己的孩子来设计游戏！

而当我们在很深的层面上理解了目标用户底层的心理需求的时候，我们就并不在是为了冷冰冰、抽象而又远在天边的用户群体来设计游戏，而是在基于体验设计游戏了。

抛离了体验的“面向用户的设计”很容易产生爆米花大片，用战术上的勤劳来掩盖战略上的懒惰，因为当主创人员并不知道到底要为目标用户提供什么体验的时候，就只能挑一些俗气的手段来提高品质。比如我们要制作一款以男性青年为目标群体的游戏，那么偷懒的做法就是放好多美女，因为男性青年必然是绝大多数都喜欢美女的，我的这个决策可以让所有抱有不满意见的同事闭嘴，但所有人内心深处都是鄙视这种做法的，并且知道这样做绝对产生不了最顶级的大作。这些游戏实际上并不是在提供体验，而是在利用人性弱点来让自己的游戏数据更好看而已，加美女，加赌博，加炫耀性内容，加各种让人产生虚假满足感的内容，这样的游戏会让人觉得空虚。AT君并不是在批评这种做法不好，人人都喜欢美女这不错，《守望先锋》中毕竟也都是屁股，但我们也都清楚，只靠屁股是诞生不了大作的。

也就是说，所谓的“面向用户的设计”，依然会分为两种，高级的一种是设计人员会把目标群体想要的体验内化然后再创作，就像那些深得人心的广告一样，明白什么能打动用户；而低级的一种就是以数据为指导的懒惰做法。SuperCell的主创人员认为，游戏数据只能用来证明你的改动是否成功，却永远无法作为改动设计的依据。AT君也在秉持着相同的观念。

再说回游戏设计师身上，一个好的游戏设计师必须要意识到自己的倾向性，意识到自己终究是有所擅长有所不擅长的。大家都知道席德梅尔擅长设计策略游戏和模拟游戏，那么如果让他去设计格斗游戏或者FPS游戏，失败的几率是非常高的。

因此，我反对Ernest Adams那种所谓的专业性论调，这种作品终究会由于缺乏灵魂而让人感到失望。让游戏设计师专注一个自己擅长的领域并且深钻下去，才是更靠谱的做法。比如笔者AT君完全不明白三消游戏有什么好玩的，因此显然我并不适合King这种专门做三消的公司。这并不是说三消这种游戏不好玩，只是我明确的意识到了自己的口味是完全无法代替目标用户的，就算赶鸭子上架让我拙劣的模仿一款三消游戏，最终做出来的东西也很有可能是东施效颦。

然而，这也并不是说游戏设计要上升到玄学的角度。《东京玩具箱》的主人公是一个游戏设计师，漫画中的他会经常说“我的灵魂感觉还不够”之类的脑残发言，并且在最终的加班关头靠灵光一闪想出来的绝妙点子让游戏的品质大幅提升——而那只是漫画而已。实际的游戏设计中，这种灵光一闪所占的比例实在是太少了，绝大多数实际上都是科学方法诞生出来的设计。希望各位策划新人们不要走了邪路，玄学害人！