作者：命运Sniper (独立观点)
https://zhuanlan.zhihu.com/p/684909430
如果你是一名游戏策划，你一定遇到过，甚至经常遇到这样的情况：
自己构思了一个非常精妙的玩法或者功能，兴冲冲地写好策划案、提好需求，结果开发评审中被告知，A太复杂了做不了，B和另外一个功能有冲突不能做，C的开发周期很长一个版本做不完，一通减肥瘦身，最后玩家玩到的就是个半成品，然后被疯狂吐槽。
更有甚者，还会出现D漏了与另一个模块有关联的部分，临近封版才发现，E这里没考虑到和另外一个功能的兼容性问题，上线了被发现有bug，那就不仅仅是被吐槽这么简单的事情了。
实际上，游戏本质上是一种十分复杂的软件，尤其是体量大、功能多、玩法丰富的游戏，最典型的就是开放世界游戏。如果你是这样复杂游戏的策划，那么写策划案、提需求就不仅仅是要管好自己的一亩三分地就行，否则就会出现上述ABCDE这样的问题。
那么本期《游门弄斧》，就让我们以原神里的寻宝罗盘为例，聊聊我觉得一个优秀的游戏策划应该如何写案子、提需求。
如何写出完备、可落地的游戏功能需求
www.bilibili.com/video/BV1Rx4y1r7zM/
模块化构思——先感性，再理性，再感性
首先我想问下大家，你觉得原神里的寻宝罗盘好用么？
其实游戏功能做出来不好用甚至有bug，90%的原因本质上都是在需求构思阶段就出了问题，只是策划不知道，等到后面被开发指出做不了，只能被砍得面目全非，甚至开发都没看出问题，最后产生更大的问题。
因此为了避免这种情况，最有效的方法，一定是在构思需求、写策划案的阶段，就要尽量完备。而为了完备，策划就得知道自己这个可能看起来很简单的设计，到底与哪些模块有关，要和谁沟通收集信息。这个过程我称之为先感性、再理性、在感性。
首先要感性地想一想，自己想要一个什么效果，实现什么目的。
例如我想给玩家一个工具，按一下就可以帮玩家指出距离自己最近的还没有开启的宝箱，一方面可以获得宝箱里的奖励，同时也是将区域探索度刷到100%的途径。
这个过程是十分感性的，设计出发点就是为了解决玩家游戏中找宝箱时烦躁、迷茫的“感觉”，预期的道具效果也非常模糊，并不存在客观上“最好”的方案。
但我必须要根据对这种“感觉”的体会和思考，给这个功能确定预期效果，以及边界条件，例如：
如何帮玩家标记这个宝箱？是地图标记，还是3D场景中标记，还是指向一个方向的一条线
需要区分宝箱类型么？宝箱有战斗的、解谜的、探索的，都要标记么
对宝箱的奖励有要求么？例如必须是和探索度/原石相关的宝箱，还是说只要他是一个宝箱，甚至不是宝箱，只要是一次性奖励就行？
这些问题我都需要在第一次感性思考中想清楚，别人是无法替我做决定的，因为他们并不知道我的设计目的，即使知道了，对于这种感性的问题每个人都有自己的看法，可能另一个人从感性上会觉得只要是奖励都应该提示，而我作为负责人得有自己的意见，这是我的工作职责，也是体现设计能力的地方。
实际上我也碰到过没想好这些就去找其他人“对需求”的情况，于是别人一个反问，自己一下就蒙住了，因为开始没想过，此时临时思考或者下意识的反应就很容易给出并不正确的结论。
然后需要再理性、客观地想一下，这个功能涉及到哪些模块，后续要跟谁沟通。
宝箱在场景里，由关卡策划负责摆放，那肯定和关卡策划有关我确定了只和地图探索度、原石相关的宝箱，那需要和系统策划中负责地图探索度设计、原石投放相关的人聊聊这个东西以一个随身小道具的形式提供给玩家使用，这种物品的使用方式和表现效果需要3C/道具策划参与还要和负责道具逻辑实现的开发聊聊实现方案
你看，看起来只是一个做寻宝工具的需求，现在就已经牵扯到至少4类不同的人了，只有和这些人都聊过之后，我才有可能知道我的需求能不能做、怎么做、做出来会是一个什么效果。
到这里依然没有结束，我还得感性地脑补一下整个流程，把自己带入到玩家视角去使用这个道具，看看会不会有“完美情况”以外的“意外情况”。
首先是玩家拿到这个道具，这一上来就发现漏了一个点，这东西怎么给玩家？肯定不能是活动，那么是常驻的世界任务？还是玩家锻造合成？如果是锻造合成，那么配方如何获取，合成材料怎么定，这些需要再和系统策划聊一聊然后玩家用了一下这个道具，此时有没有可能附近已经没有宝箱了？这样引出了一个问题，这个道具能搜索多远范围内的宝箱呢？这个问题需要再后续跟开发大哥聊一下玩家用了这个道具，道具给出了一个方向，这个方向足够明确么？会不会指向地下或者天上这种一眼不知道如何前进的地方呢？而无论是地图标记还是3D场景标记都会遇到同样的问题，因此我得再问下开发大哥，这种情况下有什么可能的方案
总结一下，需求构思阶段，需要明确需求涉及到的功能模块和相关人员，并通过尽量完整全面的“脑补流程”，把可能存在的问题都罗列清楚，方便后续的沟通。
善于沟通——先小聊，再大聊，再小聊
经过前面的步骤，我已经尽可能把我自己能够想到的问题都罗列出来了，接下来就到了沟通的时间。
首先我要“小聊”，找到前面提到的每个模块的相关策划、开发，去确定有疑问的地方。
问关卡策划，宝箱的放置有没有什么说法，天上地下这种需要找到正确入口的宝箱有没有定位入口的方式
问系统策划，和探索度、原石相关的宝箱有哪些，有没有什么区分方法问道具策划，这样的罗盘在使用过程有没有什么坑点问道具开发能搜索到多远范围内的宝箱
小聊的目的是为了找到专业的人，补充我的知识盲区。
对于大型游戏项目来说，没有谁能做到完全熟悉每一个游戏细节，因此当一个需求和某个模块相关时，就得找到对应的人去确定细节有没有问题，不能自己想当然。
例如在“小聊”中我就可能被告知。
关卡策划在配置过程中，不存在宝箱与出入口关联关系，只能知道宝箱在A洞穴中，但并不知道A洞穴的出入口在哪里系统策划的设计是，所有以宝箱为外形的奖励，都是包含原石的，可以用这个方法区分
开发表示，“找宝箱”这个过程最简单的方案，只能找到玩家附近一定距离内已经加载的宝箱，玩家设备越差，这个范围越小，而且无法找到本来不存在，需要通过解谜或者任务才会刷出来的宝箱。
这些信息都是在沟通前仅凭我自己的知识无法知道的，而这些信息又会影响我对整个功能的设计。
不过幸好我提前进行了“小聊”，提前知道了这些信息，还有修改设计的余地，例如：
知道无法提供关于入口的提示，那么从引导性上，常驻3D场景标记>地图标记>方向指示线，可以考虑将标记宝箱的方式从指示线改为场景标记
知道简单版本的找宝箱方案无法找到解谜后才会刷出来的宝箱，那么找宝箱的方案就得替换，不能直接在已加载的场景里找，得从地图数据中找
然后是“大聊”，也就是开需求评审会。
需求评审会上所有与需求相关的人都会被召集，于是有的策划会认为这是聊细节的好时机，不需要自己跑上跑下，可以“一站式”解决问题，就把前面提到的所有问题都留到需求评审会的时候才确定。
但这就会带来3个问题：
1是大量时间都是在1对1沟通，其他人干坐着，浪费大家时间2是一旦需求复杂，细节一多，大家的耐心被消耗完了，越到后面的内容越容易出错，因为大家都不想聊了3是如果会上发现之前的设计有问题，就只能靠下意识的反应修改需求，设计质量无法保证
所以，就和表白一样，需求评审会应该是胜利的仪式，而非冲锋的号角。
大家聚在一起，是为了处理不聚在一起就无法解决的问题，为了发现那些多个模块、多个功能之间互相耦合产生的隐藏问题。
例如：
关卡策划和系统策划聚一起之后才发现，虽然确实所有宝箱都提供原石，但是有的宝箱需要完成了某个任务才具备解锁条件，这种宝箱需要提示么？
关卡策划和开发聚在一起之后才发现，有的宝箱虽然只有1个，但解锁这个1个宝箱需要去N个地方还隔得老远，这种情况下要如何提示玩家？
道具策划听着听着说，有的宝箱解谜是依赖小道具的，而这个罗盘也是个小道具，岂不是玩家要一直来回切换？
实际上，复杂、大型的游戏里设计新功能最难的并不是设计功能本身，而是这个功能与太多其他功能有关联，且随着游戏内容越来越多，游戏复杂性越来越高，这种耦合性带来的麻烦也会越来越多。
因此，开发评审会的“大聊”就是为了尽量在进入开发阶段前，就把所有可能的问题、麻烦全都暴露出来，尽早进行评估、评审，避免做到一半，甚至功能上线了才发现，那时候就真的骑虎难下了。
其中有的问题和麻烦是当下无法解决的，例如小道具的切换，当前无法做到快速切换，但未来是可以增加相关功能的。
而有的问题甚至可能完全无法解决，例如宝箱的解锁条件太复杂，不是一个“寻宝罗盘”就能提示的，那么就需要用别的方式，例如通过支线任务引导，或者将其不计入探索度统计里。
但无论如何，只有知道了这些问题的存在，才有可能修正前面的设计。如果真的存在无法调和的矛盾或者困难，那需求该砍就得砍，不做了。
如果经过“大聊”确定可以做，那么就到了最后的“小聊”，也就是和每个部分相关的具体负责人聊实现细节。
道具怎么给到玩家，打造材料如何设计怎么搜索宝箱，解谜后才生成的宝箱要通过什么方式查询，是否要增加配套的功能逻辑发现宝箱后的提示方式是什么，找到和找不到的表现细节分别是什么…………
总结一下，对于游戏策划来说，沟通是非常重要的一项技能，能不能高效地通过“小聊”“大聊”把功能需求相关的问题都搞清楚，是非常体现策划能力的。
另一方面，大家的时间都很宝贵，不要把一大堆人拉上，结果讨论的全是2个人就能对清楚的内容，甚至是因为“觉得”某人“可能”相关就拉进群里/拉进会里，这些都是懒惰的表现。
知其所以然——拆分需求，了解原理，预留后手
沟通结束，就进入开发阶段了……吗？
其实不然，一些策划喜欢直接把复杂需求作为一个整体扔给开发，然后坐等开发完之后验收。但实际上，复杂的需求往往是可以拆分的，策划可以，也应当参与到拆分工作中。
这会有3方面的好处
第一、不再需要整个功能全部做好了才能验收，给优化、修改提供了时间
例如，找宝箱的功能做好了，但提示宝箱位置的功能还没做好，怎么办？
没关系，找宝箱功能在提需求时可以单独拆分成一个需求，要求能通过调试功能直接显示找到的宝箱的ID、坐标，这样就能单独验收这一个功能。
然后就可能发现，由于有的任务会影响场景，在某些任务进行的过程中，有的宝箱并不会显示出来。
由于发现及时，那么还有修改的空间，可以赶紧联系开发看看怎么处理这个问题。如果等到提示宝箱位置的功能也做好了才开始验收，很可能就来不及改了。
第二，验收和测试时有更多手段测bug，提升测试效率
测试时我们往往希望针对某一种特殊情况进行单独的测试，但实际游戏中的环境是十分复杂的，想通过正常途径或者已有的调试工具凑出这种情况并不容易，此时就需要我们在拆分需求时预留好测试手段。
例如我想测试一个特殊地点的宝箱被标记在地图上时是什么效果，玩家在不同位置触发这个标记时是否都很容易找到过去的路。但搜索宝箱本身是找最近的宝箱，我换个位置可能就锁定到另一个宝箱上了。
以右下角为起点时，锁定到了右下角宝箱，而非想测试的宝箱
此时我就需要在拆分“标记宝箱位置”的功能时额外指出，我还需要一个接口，通过输入宝箱ID的方式来测试标记效果，避免“搜索”功能干扰我测试“标记”功能。
第三，当出现bug时，有更多的Debug手段定位问题
复杂、耦合功能的Debug往往是非常麻烦的，经常是出了问题不知道是哪个步骤错了，拉上一大堆人查来查去。
正常情况下查bug的工作确实与策划无关，合格的开发应当在代码中预埋相关的log用于查bug，但作为整个需求的发起者，策划也并非不能为此做贡献。
如果提前进行了功能拆分，也约定了调试接口和相关的log信息，当游戏中的实际表现与预期不符时，策划自己就能通过调试接口和log定位到是哪个步骤出了问题，直接cue对应的开发。
例如测试提了个bug，说在某个位置使用罗盘没有任何反应，我在同样的位置先用“搜索最近宝箱”的接口，发现确实找到了宝箱信息，ID是114514，但用“标记宝箱位置”的接口无法标记出114514号宝箱的位置，那么显然问题就出在标记的部分，可以直接通知做这个功能的开发。
总结一下，一个复杂的需求在写策划案时，就应当拆分为若干个相对独立的子需求提出，并约定好验收、测试的接口和log信息，这会极大地提升整个需求的开发、验收、测试效率，是项目管理中非常常见的技巧。
结语
综上所述，在大型游戏项目中设计一个需求，不仅仅只是设计需求本身，而是一项包含了设计、沟通、实现、项目管理等多个方面的工作。
很多策划会在工作中抱怨，自己精妙的游戏设计总是在实现的过程中受挫，甚至与开发大哥产生矛盾，觉得是开发的水平不行、不重视。
但实际上，游戏作为一种非常复杂的软件系统，设计与实现本身就是密不可分的，再好的设计，不考虑实现导致难以落地或者落地后出了问题，那也等于0。
而一名优秀的游戏策划，在提需求、写策划案时，就得多想、多聊、多思考，而不是事后因为忘了A、不知道B、没考虑到C、做不了D、没测到E，最后交给玩家一个阉割的不好用的甚至有bug的功能。
发表评论