懂≠做，懂代码的游戏策划更受开发喜欢吗？

我相信很多朋友（尤其是游戏开发大哥）对于游戏策划的印象之一就是：“啥也不懂，只会脑洞，根本不管功能好不好实现，还明天就要”。

那么：

• 如果游戏策划懂代码，甚至能自己上手写代码做功能，就能得到开发的认可吗？
• 如果我想当游戏策划，学编程懂代码对我找工作有帮助吗？
  

那么本期《游志竟成》我们就来聊一聊懂代码、会编程对于游戏策划的意义。


专业的人做专业的事，懂≠做

首先我们要明确一点，只要不是在非常小的团队，就是那种只有3-5个人，一个成员往往又是策划又是开发甚至还是美术的团队。


只要不是在这样的团队中，“专业的事交给专业的人做”就一定是一条永恒的定律，不同类型的工作交给对应负责的人去做，既能提升事情的完成效率，毕竟不同的人擅长不同的工作，同样也是一种职责划分，是团队合作的基础，往坏了说也能避免甩锅、分锅问题。

那既然“专业的事交给专业的人做”，那么“写代码”这样专业的事，就应该交给专业的人去做，也就是游戏开发。

可能有的朋友会觉得，我懂代码，还能自己上手写代码，那我就能承担一部分开发的工作，开发大哥的工作量少了，肯定会感谢我吧。

其实不然，这也是一个“会代码的策划”常常陷入的误区，因为“会写代码”的目的不是为了“写代码”。

一方面，策划会的那点“代码”和真正专业的开发比起来，还是太少了。我当初应聘策划时就被问到过，说我作为一个计算机方向的博士，自然是会编程的，还能自己写游戏，为啥不应聘游戏开发，而是来应聘游戏策划呢？

我当时回答到，会编程对于我来说，无论是科研里，还是在游戏设计中，都只是一种“工具”，帮助做研究和验证想法，程序能跑起来，功能能实现就行，这距离真正商用软件和游戏的开发还有不小的距离，例如没有遵守编程时的各种代码规范，还有一些复杂算法、底层机制等等都不了解。用这种“半吊子”水平去给开发“帮忙”，那大概率就是帮倒忙，还得开发大哥来擦屁股。

另一方面，就像我之前在《游志竟成2》里所说，虽然同样是“懂技术”的人，但不同人的兴趣点差异其实很大。对有的人来说，他们喜欢的是分析、设计游戏，能够写出嵌套推箱子游戏是为了验证这个玩法是否好玩，他们适合当策划。而对于有的人来说，他们喜欢的是琢磨技术，写出嵌套推箱子是为“场景嵌套循环”找一个可能的应用场景，他们则适合当开发。

因此，对于适合当策划的前者来说，“会写代码”的目的并不是“写代码”本身，”写代码“不是，也不应该是策划关注的焦点、工作重点。

可以更有效率地沟通、描述需求

既然策划“会写代码”的目的不是为了“写代码”，那么到底有什么用，能为策划自己带来什么优势呢？

我认为最明显的优势有两点：

第一个优势是可以更有效率地描述需求。

由于我们不是三体人能直接用脑电波传递信息，只能通过语言来描述，而只要是描述，就必定存在信息损耗的情况，而且效率也不高。

这里有一个我常用的例子，“一个比划一个猜”这个游戏相信大家都很熟悉，应该没有人会觉得这个游戏易如反掌，尤其是在和另一个完全陌生的人合作时。

因为要求你在不提及一个东西的情况下，向另一个人描述它，让对方理解自己要描述的东西是什么，这本身就是一件很困难的事情。而双方的“共有知识”越少，这种描述就越困难，这也是为什么“一个比划一个猜”非常考验双方的“默契”。

显然，游戏策划会经常需要向开发描述自己想要的东西，而游戏策划与游戏开发之间，“共有知识”在很多方面都是空白的，例如游戏策划知道很多游戏，往往非常自然地说出吃鸡、MOBA、摇杆、辅助瞄准等等词汇，但游戏开发往往不会有策划那样多的游戏阅历，此时策划想要描述自己想要实现的效果时，就会开始“一个比划一个猜”的游戏。

反过来，游戏开发会关注算法、代码等等方面的问题，非常自然地说出数组、排序、内存空间、查表等等词汇，那此时就换游戏策划懵逼了，当开发想要描述一个需求为什么不好做时，也会开始“一个比划一个猜”的游戏。

从这个分析中我们就能看出来，如果双方的“共有知识”能多一些，这个沟通的过程显然就会更加顺畅。

因此，如果一个游戏策划懂代码、会编程，那么他在与开发沟通需求时的效率显然会更高。

更进一步的，如果一个游戏策划会代码，知道一个需求大概的实现方式，那么他甚至可以在描述完想要的效果之后，再描述一下可能的实现方式。

例如，我希望有一个功能，让AI在面对视野外的敌人时，可以“预判”敌人出现的位置，提前防备这个位置。


那我可以在普通描述后，再描述一个可能的实现方式：

从敌人当前位置向AI所在位置寻路，在路径上每隔50厘米向AI所在位置打一条射线，第一次射线没有被挡住的位置就是敌人可能出现的位置。


通过增加这个实现方式的描述，开发对我想要的效果就能理解得更加清楚。

能自己消除需求中模糊、不确定的部分

除此之外，增加的这段实现方式描述还有另一个好处，也就是策划“会写代码”的另一个优势——能够自己消除需求中模糊、不确定的部分。

策划最让开发讨厌的一点，就是反反复复地修改需求。其中有的是策划自己水平问题导致的无意义的反复横跳，但即使是优秀的策划，也不能保证自己提的需求能一步到位。

而一方面的原因就是，任何“想法”在代码实现的步骤中都是会有偏差的，因为策划想要的效果可能并不能100%完美实现，比如我想做个时光倒流，难道开发大哥给你从口袋里掏一个时光机出来？


如果策划不懂实现逻辑，不知道开发在实现功能的过程中可能会产生什么偏差，等到功能真做完了才发现细节和自己想要的效果不符，那自然免不了要改需求，加逻辑。

但如果策划懂代码，就能大概知道可能的坑点，例如前面提到的“预判敌人出现位置”的需求，如果按照我所提供的寻路+隔一段距离进行一次检测的方案，可能的坑点就包括：

1）检测间隔短了会消耗过多的性能，检测间隔长了就可能错过正确答案，那么检测间隔多少合适呢？


2）检测高度怎么定，寻路的路径是贴地的，那么射线检测的高度要从地面往上多少呢？


3）射线检测用什么类型？如果是LineTrace，可能会出现刚好有一条缝隙让射线通过了，但没人会觉得这里是一个进攻位置，如果用SphereTrace性能消耗又太大，同时Sphere半径多少合适又是另一个坑。


这些可能的坑点在需求实现前没人知道正确答案是什么，但因为预判到了这些可能的坑点，就可以在提需求时提前做好预案，例如将这些不确定的地方通过参数暴露给策划，让策划可以调整修改，而不是真出问题之后再让开发去改。

需求修改的另一方面原因是，游戏中很多的设计是十分感性的，只有做出来真正玩过了才知道好不好玩，这在设计新玩法、新机制时十分常见，只能不断试错才能找到真正好玩的“正确答案”。

显然这个试错的过程必定伴随着反复修改，但这个过程中并不需要考虑正式版本才需要关注的一些要素，例如游戏稳定性、运行效率等等，甚至各种画面表现力都可以不用考虑，通俗地说就是——能跑就行。

这时候还记不记得前面我说过的一段话：


那么如果游戏策划懂代码，能自己将设计出的玩法用非常粗糙的形式搓出来，不考虑稳定、不考虑性能、不考虑表现力，只是为了验证到底好不好玩，等确定一个玩法真的好玩之后再提需求让开发按照规范和标准去实现，这样就能避免需求反复修改调整的问题了，开发省心，同时试错阶段策划想修改也不用等开发有空了才行，极大地提升玩法设计的迭代效率。

那么，如果你正在准备进入游戏行业，也觉得自己想做一个懂代码策划，或者想让懂代码、能自己搓游戏成为自己应聘时的优势，就一定要注意不要让“懂代码”喧宾夺主，不要陷入实现功能的细节中，游戏设计能力才是策划的立足之本。

要牢记会做弹反不是为了做一个弹反，而是为了测试和验证“有没有弹反”“不同弹反效果”“不同弹反参数”对于游戏的意义。

结语

总结一下，中型、大型游戏开发团队中是有明确的分工的，策划懂代码、能写代码的目的不是为了真的去干开发的活、去写代码，这么做并不能让开发更加喜欢你。

真正的目的是为了更加有效率地进行沟通、描述需求，还能提升游戏设计的迭代速度、避免将开发人力浪费在“试错”上。

试问，哪个开发不喜欢一个交流起来轻松，提出的需求明确直观，还不怎么改需求的策划呢？


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