你朋友没吃过榴莲也没吃过臭豆腐，这周你们要一起做榴莲臭豆腐，他是主厨。你如何让他理解这个需求呢？ 对这类问题，我的解决方法总结起来很简单，并且容易执行： 1. 请他玩要参考的游戏的要参考部分（吃榴莲和臭豆腐） 2. 给他一份“以图为骨，以文字为触手”的策划文档（绘制榴莲臭豆腐食谱） 3. 开会以正确的提问确认需求（请他复述，一起解决疑问） 本文中： 游戏策划 = 游戏设计师 知识的诅咒 = 你一旦知道榴莲的味道，就难以想象没吃过榴莲的人心理状态。假设知识是一种病毒，大脑被感染后就很难以未被感染前的状态运作。 01、请他玩游戏 为什么要请他玩游戏？口头直接说、文字描述出来不行么？ 这个问题涉及到人类大脑的运作方式。 长久以来，我一直在思考这些问题： 理解的本质是什么？ 理解和学习是什么关系？ 理解和记忆又是什么关系？ 同时每个人都在说： “用类比让别人理解”、 “运用基模”、 “要具象化形象化”、 “说人话”…… 实际上，理解的本质非常简单：新旧概念关联。 进一步说，我们只能用对方已有的概念，通过联系、排序、重构，在对方脑中构建新事物，从而完成理解、增加新认知的过程。 这其中又引出一个新的问题： 是否存在一种小概念（元概念），无法再被其他概念所重构？ 说得通俗一点： 有没有什么概念，是无法很好解释清楚的？ 《失控》中有这么一段话： “网络数学不像古典数学，其共同要素是由数千个相互作用的函数所形成的横向因果关系，仅靠研究方程本身很难一窥其特性。各部分间的关联纠缠在一起，试图用数学来描述清楚的话无异于给自己添堵。要想知道方程能产生什么效果的话，唯一的方法就是让方程运行起来，或者用计算机的行话，就是‘执行’方程。” 人类的意识、感觉显然是一个复杂的非线性的网络数学系统。 所以，当要人们用“线性逻辑”解释 “为什么你觉得她美？”， “为什么你觉得甜粽子好吃？”， 经常是语焉不详，终会推给同样虚无缥缈的欲望、本性——兜兜转转，又回到了乱麻中。 简而言之： 基于感觉的概念通常是非常底层的、难以被重构的元概念。 如果反过来看，元概念也就是我们常说的“直观”。 直观的潜台词是“不需要解释就能理解”。 在我看来，直观不仅不需要解释，也很难很好解释。 比如： ”榴莲”吃起来像加厚版的奶油——这显然无法传递榴莲臭之精髓。 因为这个臭是“120多种化合物与我们的神经系统所引发的化学风暴”，已经是逻辑语言力所不逮之处，因而很难解释好。 而对于吃过榴莲的人而言，“榴莲味”是一个不需要解释的直观概念。 因此我的结论是： 与其通过“概念的联系”让别人理解一个感官概念，不如直接让他体验。 因此，每次当我想和程序员说：“目标体验就像XXX的X系统那样！” 我都得想一想：他是否玩过XXX的X系统？ 事实上他有很大概率没有对应的游戏体验——并且这种“元概念”无法通过纯粹的概念联系来理解。 所以，解决方案很简单： “翠花，上游戏！” 我们通过“让程序员体验过XXX游戏的X系统（吃过榴莲）”解决了底层概念的构建问题，接下来的交流和需求理解就会容易很多。 例如之前要描述一个按钮“Q弹十足的缩放动画”，你可能需要：
而现在你可能只要说“做得和‘打造’按钮的动画一样”——程序员便会立即理解你想要的效果，并发挥自己函数表达的专长为你挑选合适函数。 然而，想通过让程序员玩玩游戏就能理解需求还是太Naïve。 用上面的话说：感觉的理解是一个网络数学问题，而系统的开发则更接近经典数学问题——换句话说，游戏中某个系统的开发是一个具体的工程问题。 那么，如何解决这个具体的工程问题呢？ 02、提供一份图文相济的策划文档 （1）游戏，物种，建筑 游戏本身就是一个物种。 从自然中物种演变的角度去研究游戏，会给我们带来许多启发。 例如自然界中稳定是常态，剧变是偶然——虽然游戏行业一直有人标榜创新，但我认为这是被宣传放大的事实。 经历了上个世纪末到本世纪初的生命大爆发后，各大游戏物种基本成型，后面出现新游戏物种的速度在放慢（例如十年前的MOBA、五年前的COC，都被大众归为新物种，称为类XX游戏）——正如地球近五亿年也很少有新的物种出现。 虽然游戏物种本身也在经历市场环境的选择：不受欢迎的濒临灭绝，适应市场的大行其道，也因适应环境的需要，其本身也在不断发生变异，但仍改变不了游戏类型特征稳定的事实 次世代全自由MMO？ 二次元绿色MOBA？ 基于LBS的真实社交手游？ 这些设计师引以为傲的（微）创新，通常只是稳态下的一朵浪花罢了，哪里是什么新物种。 但是，游戏形态的稳定没有好的一面吗？ 《失控》中有这么一段话： …对生物进化的束缚也正是人工进化的希望所在。进化动力学中的每一个负面约束都可以从正面来看待。用来维持旧传统的束缚力可以用来创造新事物。将生物限制在自己的形态内，防止其随意漂移到其他形态的力量，也正是初使得生物成形的力量。而当某个物种奋力一跃，挣脱原有的稳定态时，同样的内敛性会诱使它进入一个新的内稳态。乍一看这有些奇怪，但的的确确，束缚即创造。 实际上，对于大部分游戏设计师而言，游戏形态的稳定是重大利好。 这至少允许我们做以下几件事：
当然，每个游戏设计者对游戏的定义不会完全一样， 有人认为自己是艺术家，做的是艺术品； 有人认为自己是商人，做游戏就为赚钱； 我对它的定义则是“工艺品”。 它既非纯粹的没有审美功能的工程项目，也不是没有实用价值的艺术品。 这种特性，使得游戏设计师和许多方面和建筑师非常相像。 作为一个年轻的行业，电子游戏有太多智慧可以从建筑学汲取。 在这里我尝试借助建筑工程解决工艺品中“工”的部分： 我们能否参考建筑施工图文件写出一份类似的游戏施工图文件？ 我经常在对策划的要求中看到以下关键词： 结构化，清晰，严谨，完整，逻辑 这些词形容的肯定是策划的产出：要么是口头语言，要么是书面文档。 令我惊讶的是，苦苦追寻的答案直接就浮现在建筑施工图中——在看到这些建筑图纸时，我脑中一下就想到了这些关键词。
长期的发展使得建筑学在解决建筑工程时精准而优雅； 例如数字会标得很清楚。这点许多策划并不能做到 我从建筑图中得到的重要启发是： 图，图，图。 有一句话这么说：能动手，就别逼逼。 在这里，我这么说：能画图，就别逼逼。 好的演讲应该有一个主线， 好的需求文档，应该以某个图为主线，让图来完成大部分信息传达工作； 再辅以文字说明，让文字完成细枝末节、极值、容错等情况的处理，成为文档的边界。 我认为，这是一个非常好的包容性的策划案架构。 多年的游戏开发经验告诉我，手机游戏开发和建筑施工大的区别在于灵活度（本质上来源于项目不确定性程度的差别）。 因此手游很难彻底的工程化——用几个月时间给你出一个详尽标准的策划“施工图”，然后给程序员做——传统的瀑布式开发正被边缘化，敏捷或者迭代式开发已成为行业主流。 与之对应的，策划案也必须能适应这种开发节奏，并能包容需求的变化。 在这里，我假定游戏开发中： 大的需求变化出现的频率很低。也即前面提及的“物种成型”； 小的需求变化在频繁、持久地发生（有人称为“微创新”）； 游戏既不处于一成不变的均衡态，也不处于无法定型的失衡态，而是一直在永不停歇、永不衰落的边缘上冲浪。 所以，在我这策划案中， 图形继承了系统的主体架构和灵魂，让它的精髓能被读者理解并记忆； 文字则像是无所不及的分布式触手，行走在广度和深度的边界上，一方面提供足够让程序员得以开展工作的信息具体度，另一方面也在随时承接可能发生的微小变革。 （2）示例：一个宠物系统策划文档 为了让读者更好理解，下面以我曾写过的一个宠物系统为例进行说明。 PS：这里只解决“信息传达和沟通问题”。不解决诸如“这个系统有没有必要做？”“具体怎么设计？”“要多少人做多久啥时上线？”“数值怎么投？”“UI怎么画？”等问题。 策划案背景：
关键词：横向对比，超链接，结构化。 两张图可以说明： Excel基本结构：SheetxSheet
对比Word的串行结构：
我们可以直观地感受到区别： Sheet天然构成了回溯按钮，再加上可以精确到单元格的超链接——你可以快速从某个层级的节点跳转到任意节点。 Word虽然提供了交叉引用，但我更享受在Excel中一个个模块化的数据库之间穿梭。 2) 章： 大纲、综述、概述、总览，无论怎么称呼，都要保证： 1. 用几句话说出你想说的，有助于别人理解、且别人需要知道的文档关键句； （例如我就喜欢一遍遍说目标，并希望程序员能理解并认同这个目标） 2. 一个高层级的目录（目录层级是否向下展开看具体需求）； 如下图：
在此我们就可以学习施工图的信息组织方式，这里我以属性界面为例：
3 小时前 上传 和做施工图一样，这里主要的工作是：制（画）图。 制图的过程本身也是我们进行信息组织和设计的过程，用什么工具好？ 工具服务于目的。 在这里我选择使用Photoshop而不用Axure有两个原因：
当然，如果有时间和人手，Axure会是非常好的选择。
梦幻西游手游的UI设计大量使用Axure 再次强调，Photoshop、Axure都服务于制图这个目的。 实际工作中策划可以用到的图的种类非常多，因而用来制（静态）图的工具也非常广，这里做个简单列举：
需要记住的一点是：读者只关心你的图，不关心你用什么工具做出了图。
我们依然先看下图：
这些文字有什么要点？ 是走马观花，还是事无巨细？ 项目管理中推崇“渐进明细”，但同时我们也经常听到有人抱怨“策划需求不清晰”，两者如何平衡？ 用上文的话回答： 这些文字的具体深入程度，就是我这个文档流动的边界。 它足够具体，具体到能保证程序和测试能据此信息进行工作； 它足够概括，概括到能够随项目进展、可能的变更而不断“进、细”。 也正因如此，我不看好“施工图式、事无巨细”的策划案，因为无法应对变化； 也不赞成“不加维护与修订、过于简略”的策划案，因为这让工作难以进行。 如果说图是大部分人都能看懂的话，这些文字则被我称为“面向读者的信息”。 回忆一下我们的读者：前端程序员、后端程序员、测试员（当然可能三个角色是同一个人）, 不同角色关注的点不一样，但这不意味着我们一定要进一步拆解工作包为更细碎的文字。 为了保证我们的文字信息已经足够详细到能让读者开展工作，我们要进行后一步： 03、开会以正确提问确认需求 开会这个话题是一个巨大的坑，形形色色的话题都可以往里填。 这里我将这个步骤简化为一个情景： 当你给开发人员玩过游戏，看过文档并开会讲解后，通常会问他们一句： 还有什么不懂的吗？ 然而，这个问题一点都不高效。 想象你去参加一个课程或演讲，如果演讲水平不高（通常如此），演讲后通常会进入提问环节——此时，你会经常看到尴尬的冷场。 ”还有什么不懂的吗？“ 这个问题每个策划都会问，甚至谁都可以问，如此常见又如此平庸，以至很少有人会去思考： 有没有更好的提问方式？ 我认为更高效的提问方式是： XXX(指代人)，你给我讲下你怎么理解这个需求的？ 我发明（也许不是个）的这个提问方式，融合了以下几个心理学原理：
会议作为工作的一部分，必然是以结果为导向并讲求效率的。 什么是好的会议结果？——大家理解了参加会议之前没理解的需求，同时需求作为思想得到传播、完善，并在大家心理达成共识。 所以，这也决定了我们向谁提问：谁不理解需求？谁常问策划这个要怎么做？——让这个问题来帮助他更好地理解吧。 04、结语 游戏策划（游戏设计师）有大量的工作要和其他成员配合完成，需求的沟通非常重要。 然而游戏策划通常比常人拥有更多游戏经验，也因而陷入“知识的诅咒”。 如何让不玩游戏的程序员理解开发需求？ 答： 1. 请他玩要参考的游戏的要参考部分 2. 给他一份“以图为骨，以文字为触手”的策划文档 3. 开会以正确提问确认需求 希望这答案能对项目组和平做出贡献 *~(￣▽￣)~[] []~(￣▽￣)~*
（蛤？你说你们策划不玩游戏？——能动手就别逼逼了，上，打他……） via：GAD |
北京开源纵横网络科技有限公司 版权所有 © 2011-2017 94hwan.com All Rights Reserved 京ICP备15000695号- 3
北京市科委认定的高新技术企业，致力于互联网游戏开发与运营、游戏行业大数据分析、互联网软件开发等业务，拥有强大的设计力量和技术开发力量，在同行中处于国内绝对领先地位。
