首发于知乎
相信很多同学（尤其是游戏开发者）对于游戏策划的印象之一就是：“我什么都不会，只知道如何出创意。我不在乎功能能不能实现得好或者能不能实现。”不，我今天仍然需要它。”
所以：
那么本期《有志精诚》我们就来聊聊理解代码和编程对于游戏策划的意义。 【视频：】
专业的人做专业的事并且知道怎么做
首先，我们需要明确一点。 只要我们不是在一个特别小的团队，即只有3-5人的团队，往往有一个成员负责策划、开发，甚至美术。
只要你不在这样的团队中，“专业的事交给专业的人”一定是永恒的定理。 将不同类型的工作交给相应的负责人，不仅可以提高完成事情的效率，虽然不同的人擅长不同的工作，这也是一种职责界定，也是团队合作的基础。 最坏的情况下，也能避免出现推卸责任、分担责任的问题。
既然“专业的事情就交给专业人士”，那么“写代码”这样专业的事情就应该交给专业人士去做，那就是游戏开发。
有的同事可能会认为，如果我懂代码，能自己写代码，那么我还是可以承担一部分开发工作，开发工作量就会减少，所以他们一定会感谢我。
当然，这也是“会写代码的项目”经常陷入的误区，因为“会写代码”的目的并不是“写代码”。
一方面，规划会议上的那点“代码”与真正的专业发展相比还是太少了。 当我申请策划工作时，有人问我，说作为一名博士。 在计算机科学领域，我自然知道如何编程，并且可以编写自己的游戏。 为什么我应该申请游戏策划工作而不是游戏开发工作？
我当时回答说，对于我来说，能够编程，无论是科学研究还是游戏设计，都只是一个帮助我做研究、验证自己观点的“工具”。 只要程序能运行，功能能实现，那就不是那么遥远了。 真正的商业软件和游戏的开发还有很大的差距。 比如编程的各种代码规范没有遵循，一些复杂的算法、底层机制等不理解。 如果用这些“半生不熟”的技能来“帮助”开发，极有可能会惹出麻烦，还得被开发大妈抹脖子。
另一方面，就像我以前一样。 对于有些人来说，喜欢的是分析设计游戏，也可以写嵌套推包游戏来验证这个玩法是否好玩，是否适合做策划。 对于某些人来说，他们喜欢思考技术。 写嵌套包推送就是为“场景嵌套循环”寻找一个可能的应用场景，并且它们都适合开发。
因此，对于后者适合做规划的人来说，“会写代码”的目的并不是“写代码”本身。 “写代码”不是也不应该是规划和工作的重点。
能够更有效地沟通和描述需求
既然规划“会写代码”的目的不是“写代码”，那么它有什么用处，能给规划本身带来什么好处呢？
我认为最显着的优势有两个：
第一个优点是可以更有效地描述需求。
因为我们不是三体人，可以直接用脑电波传递信息，所以只能通过语言来描述。 只要我们描述一下，就会有信息丢失，但是效率不高。
这是我经常使用的一个例子。 相信大家都熟悉“一签一猜”这个游戏。 没有人会认为这款游戏很容易，尤其是在与另一个完全陌生的人一起工作时。
由于您被要求向另一个人描述某件事而不提及它游戏源码 泄露，因此其他人很难理解您想要描述的内容。 双方的“常识”越少，这些描述就越困难，这也是为什么“一举一猜”对于双方的“默契”是一个极大的考验。
事实上，游戏策划者经常需要向开发者描述他们想要什么。 然而，游戏策划者和游戏开发者之间的“共享知识”在很多方面都是空白。 例如，游戏策划者了解很多游戏，并且经常很自然地发言。 有斗鸡、MOBA、摇杆、辅助瞄准等词语，但游戏开发者往往没有策划那么多的游戏经验。 这个时候，当策划想要描述自己想要达到的效果时，就会开始“打手势猜”。 “游戏。
反过来，游戏开发会重点关注算法、代码等问题，很自然的就会讲到链表、排序、内存空间、查找表等词语，这时候游戏策划就会一头雾水。 当开发者想要描述一个需求难以满足时，一场“比划猜”的游戏也会开始。
从这个分析中我们可以看出，如果双方有更多的“共享知识”，沟通过程其实会变得更加顺畅。
因此，如果游戏策划人员懂代码、会编程，那么他在与开发者沟通需求时实际上会更加高效。
而且，如果一个游戏策划者懂得如何编码，知道一个大概的实现方法，他甚至可以在描述完想要的效果后，描述出可能的实现方法。
比如，我希望有一个功能，让AI在面对视野外的敌人时，能够“预测”敌人的位置，提前警惕这个位置。
那么我在大致描述之后就可以描述一个可能的实现方法：
找到一条从敌人当前位置到AI位置的路径，在路径上每隔50分米向AI位置发射一条射线。 第一道射线未被遮挡的位置就是敌人可能出现的位置。
通过减少这个实现方法的描述，开发可以更清楚的明白我想要的效果。
能够自行澄清需求中模糊、不确定的部分
此外，减少实现方法的描述还有另一个用处，这就是规划“会写代码”的另一个好处——能够自行消除需求中模糊、不确定的部分。
开发人员最讨厌规划的事情是一遍又一遍地改变需求。 有的是规划本身水平问题造成的无意义的重复跳跃，但再优秀的规划也不能保证一步到位地满足其提出的要求。
一方面，激励是任何“想法”在代码实现的步骤中都会出现错误，因为计划的预期效果可能无法100%完美实现。 比如我想要时光倒流，开发阿姨可以给我吗？ 你从口袋里掏出了时光机吗？
如果规划不了解实现逻辑，不知道在实现功能的过程中可能会出现什么错误，等到功能完成后发现细节与预期效果不符，那么就不可避免更改需求并添加逻辑。
但如果规划者看懂了代码，就能大致知道其中可能存在的陷阱，比如上面提到的需要“预测敌人的位置”。 如果按照一定距离提供的寻路+巡检计划，你可能会遇到的陷阱包括：
1）如果测量间隔短，会消耗过多的性能。 如果测量间隔较长，可能会错过正确答案。 那么合适的测量间隔是多少呢？
2）如何确定测量高度？ 寻路的路径接近地面。 那么射线测量高度距离地面应该多高呢？
3) 使用哪些类型的射线照相检查？ 如果是LineTrace，可能会有光线通过的间隙，但没有人会认为这是一个压着的位置。 如果使用 SphereTrace 太昂贵，并且适当的 Sphere 直径是另一个陷阱。
在需求实现之前，没有人知道这种可能的陷阱的正确答案，但是因为这种可能的陷阱是被预测到的，所以在需求提出的时候就可以提前做好计划，比如把这样的不确定性通过参数暴露给让规划能够调整、改变，而不是出了问题就要求开发商去改变。
需求变化的另一个原因是游戏中的很多设计都非常合理。 只有真正玩过才知道好玩不好玩。 这在设计新游戏玩法和新机制时很常见。 你只能通过反复试验来解决它。 找到“正确答案”真的很有趣。
其实这个试错的过程必然会伴随着反复的修改，但在这个过程中不需要考虑一些只需要在即将发布的版本中关注的因素，比如游戏稳定性、运行效率、等等，甚至各种屏幕表现都不需要考虑。 ，简单来说——只要你能跑。
这时，你还记得我后面说的话吗：
我当时回答说，对于我来说，能够编程，无论是科学研究还是游戏设计，都只是一个帮助我做研究、验证自己观点的“工具”。 只要程序能跑起来，功能能实现，也不算什么大的进步。 距离真正的商业软件和游戏的开发还有很长的路要走
这样，如果游戏策划者看懂了代码，他就可以极其粗略地设计玩法，不考虑稳定性、性能、表现力，只是为了验证好玩不好玩。 确认一个玩法确实好玩后，然后提出需求，让开发按照规范和标准去实现。 这样可以防止出现需求反复变更、调整的问题，让开发无忧。 同时，如果在试错阶段想要改变方案，不必等到开发空闲，这大大提高了玩法设计的效率。 迭代效率。
这样，如果你正打算进入游戏行业，并且你也认为自己想成为一名懂代码的程序员，或者你想懂代码并且能够自己制作游戏是你申请时的优势，你必须小心，不要让“代码知识”接管这项工作。 ，不要陷入实现功能的细节之中。 游戏设计能力是策划的基础。
请记住，篮板的目的不是为了篮板，而是为了测试和验证“是否有篮板”、“不同的篮板效果”和“不同的篮板参数”对于游戏的意义。
结语
综上所述，小型和大型游戏开发团队都有明确的分工。 计划理解代码、能够写代码的目的并不是为了真正做开发工作、写代码。 这样做并不会让开发者更喜欢你。 。
真正的目的是更高效地沟通和描述需求，这样可以提高游戏设计的迭代率游戏源码 泄露，避免在“试错”上浪费开发人力。
试问，哪个开发人员不喜欢沟通方便、需求清晰直观、需求无法更改的项目呢？
