作者：jfy19771224
前文回顾：
本章节主要讲解策划的工作准则，无论我们做什么工作，保持一个良好的心态和正确的思维方式是非常重要的。
无论你能力有多强，心态和思维方式错了，最终也会给你带来沟通失效，同事厌恶，进度缓慢等不好的工作体验，下面我们就来看看如何建议个良好思维方式。
一 需求的建立
首先是用户的理解，当我们接到某个需求时，可能来自领导，也可能是自己的想法，那么我们首先要从用户的角度去看待这个需求，站在用户的角度的来看待这个设计是否符合了我们展现给用户的目的。
举个例子：玩家在攻击怪物时会显示攻击伤害，比如10，1000，那么如果随着玩家的装备提升，伤害一定会越来越大，如果当玩家的伤害一刀可以砍出100000000之后，这个伤害怎么显示呢？看不懂？那我再换个数字，玩家一刀砍出了983410023，感受一下，你能记住几个数字。
图片来源：网络
现在问题就来了，首先我们要明确，伤害数字的显示目标是什么，是希望让玩家清楚的看到自己的伤害值，通过这个伤害值可以体现出玩家的成长感。
当数据长度太长之后，玩家是否还能很好的记住这个数值呢，显然是有困难的，这还是一个，如果来个多段伤害，我相信屏幕上一定是被数字占满了。
那么解决这个问题我们可以用万为单位，省略后面的数值，比如9834万，看一下，是不是好记很多了，如果上亿，我们则可以9.8亿，更好记了，那么玩家的成长感只需要关注前面4位数就可以了，当玩家的数值真的大到这个程度，实际上后面的数值他也不需要记了，而且提升的效果也几乎可以忽略不计。
看两组数据就明白了，10级玩家打了9.8万伤害，20级玩家打了12万，而不是983420和126280，那么请问现在你有多少存款？你能说出所有的数字吗？还是只能说一个大概？对于数字的记忆长度我们通常只能记忆到前3~4位，数字长度越小，玩家记忆力越方便，并且伤害数字是在游戏内是移动显示的，所以你需要让玩家记住一个在移动的很长的一串数字很明显是违背常理的。
仅仅一个小技巧就可以解决这个问题，所以这就是站在用户的角度去考虑这个需求，但是现在仍然还有很多游戏，做伤害数字只是为了效果，甚至有的游戏伤害数字移动很快，哪怕是3位数也没来记得看清楚，这就是典型的为了做效果而做，完全不考虑用户的体验和感受。
所以设计需求时，一定要降低一个维度，去考虑这个设计原本的意图，绝对不能因为别人做了，你就照做，要明白设计意图才能去做。
接着就是，开发角度，一个需求设计时，不仅考虑了用户角度，也要站在开发的角度考虑研发成本，其中对研发成本的预估，需要对技术和美术有一定的了解，不过没关系，本书后面的章节都会全部讲到。
在中国做游戏，通常情况下不会给你太多的时间和金钱去做一个你认为的完美游戏，如何用最少的时间做出最大的收益是当下需要考虑的。
下面我再举一个例子：现在我们12张地图，每10级为一个阶段，每个地图上都有小怪，那么我们就需要设计12个种类的小怪，如果12个种类小怪每个都不一样，无疑设计成本是很高的，哪怕就算你设计出12个种类的小怪，那么你就需要考虑你游戏本身小怪的种类不同是否对游戏玩法产生影响，比如每个小怪都有自己的攻击方式，有对应的方式。
如果不是，则小怪的种类只是外观视觉上的变化而已，并没有机制上的不同，那我们继续分析，我们现在只设计1种小怪，12张地图都用上它，显然这也不行的，玩家会觉得你完全不走心，敷衍，那么我们就可以简化设计，只设计4种小怪，每3个地图用一种小怪，接着，我们对这3种小怪进行颜色，部位上的修改，就可以形成种类相似，外观不同的小怪了。
这样的设计成本远比完全设计12种小怪要低很多，如果是生物型的怪物，美术可能需要在建模上修改，如果是人形怪物，则还可以穿不同的装备形成不同的小怪。
无论哪种做法都可以，其核心原则就是尽量复用设计，而玩游戏小怪只是战斗体系下的消耗品，除了前期会对怪物的外形有一定的认知，到中后期，怪物的外形并不会对游戏产生本质的变化，玩家更多关注的是如何更加有效率的打死它，而不是它长得好看不好看。
所以，我们在建立一个需求时，除了考虑它本身的玩法之外，还需要从用户的理解和开发成本上新考虑。
方法有很多，如何选择除最有效的放大达到目的，是每一个策划都需要去磨练的，策划并不是照本宣科的东西，一定要分析设计的内在目的，很多情况，分析完内在目的，那么问题反而非常好解决。
二 深度思考
为什么说现在策划浮躁，因为缺少的思考太多了，策划体系没有一个标准，不像技术一样，有先后循序。
作为一个策划，你只要能给出一个合理的理由就可以上需求，所以很难有一个标准，那么现在，我们就说说策划建立需求是应该需要哪些思考。
这个需求的目的是什么，我们拿到一个需求开始完善时，可能是你领导的一句话，也可能是你自己的想法，现在你第一时间考虑得就是这个系统得需求目的是什么。
举个例子，接到通知，我们要做排行榜，排行榜都会做，把某个数据列出来，进行排序就可以了，我们继续往下走，分析一下，究竟排行榜的目的是什么。
排行榜，是所有的玩家某个数据单独提取出来，比如战斗力，等级，关卡数等等，放在一起比较，形成玩家和玩家之间攀比的效果，以达到刺激消费的目的，最终结论就是，排行榜的需求目标是通过玩家的数据进行对比而刺激消费。
所以你接到这个需求时，第一原则就是考虑设计有没有满足这个要求，比如很多游戏，喜欢列出一大堆的排行榜，并且在玩家新手阶段就弹出排行榜，这样做的意义是什么呢，玩家新手阶段，对游戏还处于懵逼阶段，你让它攀比什么，而且大量的排行榜反而会劝退玩家。
再比如根据排行榜名次给与奖励，这些不是不能做，而是要看放在什么时机去做，当我们了解到排行榜本身设计目的后，这样就能很方便的对其进行控制，有效的可以做，无效的则不做。
有时候我们在设计需求时，会陷入到一个惯性思维，因为都这么做了，我也这么做，实际上绝大部分游戏还没有上线就已经资金链断裂了，就算上线了，也以惨淡收入立场，大部分都是失败的案例。
所以大多数不代表就一定是正确的，跟随大流做产品，究竟是这个设计确实好，还是你自己根本不知道怎么做，这个问题可能只有你自己知道了。
所以我们接着来说说，我们设计的功能当玩家看到时，应该是一个什么样子的反馈，我们用首充礼包举一个例子，首充礼包的作用是什么呢，我们根据上面的结论分析一下，首充礼包其作用是在玩家前期阶段，给一个比较大的折扣帮助玩家进行成长，而体验到游戏的成长乐趣。
这里面就关系到一个词，成长，成长是什么，成长是玩家数值的提升，数值的提升是需要依靠游戏物资的消耗，那么问题来了，玩家在新手阶段，对游戏一无所知，物资也不认识几个，什么女娲石，强化石，龙魂，这种东西必须建立在玩家对游戏有一定的了解情况下才有可能刺激玩家的消费。
所以，在新手阶段，我们首要做的就是让玩家对游戏系统的认知，了解道具提升的情况，新手礼包才会起到作用。
我看到很多游戏，玩家一进来，还是1级的情况下，就弹出一个首充礼包，各种看不懂得物资，还有折扣，这是什么意思？你难道希望玩家看到这华丽的界面和你夸张的广告词就充钱吗？希望通过曝光率来提升付费率吗？
这是对游戏的不尊重，本末倒置，在1级就弹出首充礼包，难道你希望玩家的反馈是，“哇，好漂亮的界面，我要充钱。”，我只能说两个，幼稚。
所以新手礼包应该是在你认为游戏系统教育得差不多得时候，出现，最好是和游戏得卡点进行一个绑定，甚至可以利用收集强迫症来处理。
新手阶段会送9个升星碎片，每个升星碎片可以提升1级，现在已经教育玩家9次了，第10次升级可以突破，突破之后可以改变外观，但是碎片副本很难获得，这时候首充礼包里就有1个，这样，首充礼包和新手教育就进行了一个绑定。
出一个题目，你来回答看看，现在我们需要设计一个挂机系统，每天玩家可固定挂机1小时，这1小时可掉落1000个金币，最终数值算下来，每个小怪可以掉落1.12个金币。
当你得到1.12这个数值后，出问题了，系统跟你说，金币最小单位是1,小数点没法掉，而且用户也不好理解，美术做出来效果也不好，这时候你怎么办？
这个问题我问过一些策划，直接回答，小数点可以抹去，直接掉落1金币就好了，这是非常典型得错误，首先我们要明确一点，数值得计算，是根据整个系统来定得，最终计算得结果可能是任何数，而最终把整个总数分摊到比如小怪上，副本上，玩法上，很难保证是一个整数。
看是0.12个金币很少，但是直接省略掉就会出现计算上的漏洞，那么有两种做法，一种做法是扩充货币体系，1小时可掉落10000金币，每个小怪可掉落112个金币，这样可以忽略小数点，但不是完美，而且整个货币价值都要改动，成本非常高。
那么还有一种做法是，小怪必然会掉落1个金币，但是有12%的概率，再掉落一个金币，看懂了吗？用概率去把后面的小数点补上，在挂机的一小时里，最终我们击*的小怪掉落金币会接近我们预算的值。
别小看12%，如果是1.95个金币呢，直接省略掉小数点，那么你掉落的金币数量和原本设计的数值相差接近一倍，这是疯狂的，所以，正确的做法是用概率。
而实际上你反过来算一下，比如击*892只小怪，省略小数点最终的收益是1*892=892，加上概率就是1.12*892=999，而这个结果，才能对应上数值给我们的数据。
所以，当我们在面对一个设计时，一定要考虑这样做会有什么后果，有没有解决问题，而不只是一切从简，上面的问题你看懂之后发现是小学数学题目，但往往就这样的水平，在我认知的策划里很多都回答不上来，可悲可叹。
三 策划会议
当我们写出了一份文档之后，必然要去和其他部门的同事进行开会，讨论，那什么样子的会议才是最高效的。
图片来源：网络
首先，我们在开会时，需要把设计的目的完全的列举出来，并且列出可能会出现的问题，再列出解决办法。
有一个词，叫深度思考，如果一个方案没有深度思考半小时以上，这个方案必然是无效漏洞百出的，而我们在会议上很难让所有人深度思考，因为深度思考是不能被外界打扰的，是一个很隐私的时间空间，这个在会议上是不可能完成的。
那么问题就来了，我们再会议上讨论的问题基本上都是没有怎么经过大脑的，甚至只是一瞬间的灵感，所以为什么很多人讨厌会议，就是这个原因。
所以在开会之前，作为一个策划，必须要尽快的让参会人员了解这次会议的上下文，并且引导到自己的思路上，帮助自己去解决这个问题，而不是大范围的猜测，在多人会议上，根据我十多年的工作经验，多数的讨论都项目无关，只是为了证明自己的参与感的瞎讨论而已，没有经过深度思考的讨论，参杂了太多的个人因素。
所以，在这个会议上，尽量的要还原自己深度思考的过程，我这么想的理由是什么，他会有什么问题，而这个问题是否已经得到了解决，如果还没想到解决办法，那么可以把被自己否掉的解决办法先出来，并且说出为什么否掉，这样也可以给大家做一个参考。
在会议上，尽量避免无关人员的参加，如果让大家感知到你的所想，是一个策划必须要熟练掌握的沟通技巧，通常情况下，一个经过了深度思考的会议，都是非常高效和果断的。
如果在会议上出现了不同的意见，那么把可以这两个意见写下来，分别列出他们的优势和劣势，其实很多意见矛盾都是因为不了解双方的意图，并且没有对问题深究，如果可以的话，可以一直深究到最底层。
很多创业公司喜欢头脑风暴，喜欢团队成员的争吵，认为这是一个碰撞和磨合的过程，这里我并不赞同，争吵一定会出现情绪矛盾，别说人不记丑，没那么伟大，争吵一定是没双方能力欠佳，无法和对方沟通好自己的论点，也无法说服对方，如果你连你的团队都说服不了，那如何说服玩家为你的游戏充钱呢，难道和玩家吵一架吗？
最后，在会议结束是，一定要让参与人员都了解的情况，毕竟功能是需要开发人员来做，开发人员就是策划的第一批玩家，如果连开发人员都搞不定，那这游戏就可以停止开发了，有的人会认为，程序，美术不懂策划，跟他们讲不明白，但是玩家懂吗？开发人员怎么也算是业内人士，玩家是各种和互联网不相关的人群，他们懂吗？如果连业内的人都无法懂你，玩家更不懂了。
