【策划篇】如何写出完备、可落地的游戏功能需求？

如果你是一名游戏策划，你一定遇到过，甚至经常遇到这样的情况：

自己构思了一个非常精妙的玩法或者功能，兴冲冲地写好策划案、提好需求，结果开发评审中被告知，A太复杂了做不了，B和另外一个功能有冲突不能做，C的开发周期很长一个版本做不完，一通减肥瘦身，最后玩家玩到的就是个半成品，然后被疯狂吐槽。

更有甚者，还会出现D漏了与另一个模块有关联的部分，临近封版才发现，E这里没考虑到和另外一个功能的兼容性问题，上线了被发现有bug，那就不仅仅是被吐槽这么简单的事情了。

实际上，游戏本质上是一种十分复杂的软件，尤其是体量大、功能多、玩法丰富的游戏，最典型的就是开放世界游戏。如果你是这样复杂游戏的策划，那么写策划案、提需求就不仅仅是要管好自己的一亩三分地就行，否则就会出现上述ABCDE这样的问题。

那么本期《游门弄斧》，就让我们以原神里的寻宝罗盘为例，聊聊我觉得一个优秀的游戏策划应该如何写案子、提需求。


模块化构思——先感性，再理性，再感性

首先我想问下大家，你觉得原神里的寻宝罗盘好用么？

其实游戏功能做出来不好用甚至有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的功能。


原文：https://zhuanlan.zhihu.com/p/684909430