主程出身的主策，有一种不能被人理解的孤独

很多时候一个主程出身的主策比如我，是不能被人理解的，所以更多的体验是一种孤独。

程序出身的策划，才能做到一些基本的工作，比如前面很多人说了，可以抽象一些“普通策划”想不到的需求、提出一些可扩展的执行方式之类，这个在我看来再基础不过了，因为一个策划，本身的职责就是分析出用户最真实的需求，根据这个需求去设计产品，设计产品一方面是用户体验，另一方面就是如何实现。

什么叫会编程？很多时候我们理解的会编程，就是会写一段代码，然后实现一些小的功能，就叫做编程，这在我看来只能算是coder，如果你说这样的人做游戏策划，我觉得他只要够谦虚，培养一下能行，如果你说他作为专业程序员，对不起，在我看来只是会写代码的玩家而已（想一想，WoW里面能写个宏的是不是也就这样了？）。所谓的编程，是分领域来定义的，在游戏领域，编程就是开发出完整的游戏框架，并且在这个框架的基础上，任何人根据自己的想法设计轻易地实现出游戏的任何设计需求（因为游戏的设计需求总是在改变的）。简单来说，游戏编程，最核心的就是完成游戏的业务，完成业务，包括了业务本身的运作（就是对玩家来说，游戏玩起来没问题），以及后续的可扩展性（就是对设计师来说，我要功能什么的不是那么的吃力，不是总在妥协的感觉），游戏编程与众不同的是面向了2层用户（游戏玩家和游戏设计师）。当然顺带讽刺一下某些所谓的程序员——如果你整天只想着搞渲染，认为渲染=游戏程序，那何苦做游戏呢？哦，原来是其他行业比如影视动画行业你已经进不去啦？所以被排泄了才来做游戏的！啧啧啧！

但是也正是因为程序出身的策划，才会感觉现在主流的研发方式非常的别扭：

1，为什么要出策划案呢？而且策划案居然还能用中文？！在这个混沌的行业，有一套非常糟糕，但却又成为公论的研发模式，就是策划写需求，程序去执行。但是，中文策划案又确实有很多说不清楚的地方“中国队，谁也赢不了”，同样这几个字，语境不同效果就很不同，放在中国乒乓队，那是说他们无敌，放在中国足球队，那是说他们无能。游戏中有太多的语境，即使是策划和策划之间，玩家和玩家之间都能产生歧义的，一份策划案就能说清楚了吗？不能！换一个角度来说，我写一份策划案，说清楚这件事情的时候，背后实现的逻辑可能还不如策划案这么冗长，我直接coding是不是效果更好，而别人的理解代价更小？（事实是，专业程序员阅读代码的理解能力远高于阅读“策划案”，只是游戏行业渣渣太多了，既没能力又没耐心阅读别人代码的渣渣，做不了别的行业全来游戏行业了而已）

2，游戏是谁在设计？这个问题讲道理，个个都会说“是策划”，所以延伸出来一套说法就是“游戏做完了，但是数据不好，那就是策划的责任”。但是真是如此吗？真正的问题是，你把一半的设计和全部的开发交给了程序，最后程序“设计”的游戏当然不咋的，能成功那真是运气了。在我看来，一个项目里，只要程序开发的东西，有过任何一丝“你策划就（“只要”，“应该”等等词汇）这么用就行了”的思想，就会做出一个看似灵活实际上是牢笼的东西，最后策划真要做什么都做不了，也就只能、必须这么做（妥协），最后出来的东西不是任何人想要的，能成功了不奇怪么？最简单直白的一个问题，策划在一个动作游戏中设计了一个翻滚，程序实现（为什么却不是策划实现，这才是行业问题的根本）的时候却依赖于美术视觉，认为美术设计了这个动作多久翻滚多远，那么策划对应填表、填写数据就好了，很多“普通策划”只能妥协，但是这却是有致命问题的，首先设计游戏的是策划，那么翻滚的时间和长度就应该依赖于策划数据，而不应该美术和策划去做一个耦合（通常我们认为，你要这样的效果么，你叫美术吧翻滚的时间做的跟你做的一样长好了，这就是策划依赖美术的制作，美术依赖于策划的设计，工作耦合！），所以真正的实现方式是，翻滚的时间、距离读取策划的数据，翻滚的tween（好的翻滚动作不应该是匀速的）和美术资源由美术提供（没错，我是说如果你用Unity Root Motion，让美术来设计这样一个翻滚，并且依赖他，那就是错的，你要用到的只是美术资源和Tween）。很多时候游戏程序员在开发的都是牢笼（你要用一个功能，必须接受这个功能附带的内容），因为游戏程序员不像其他行业的程序员那样会去理解自己做的行业的业务（事实上也没法去理解游戏业务，因为游戏设计本身太简单也太困难了），什么是通用的、可扩展的？想用了拿来，不想用丢掉，不是非得妥协点什么才能拿来用的。

3，为什么游戏策划不是一个垂直职业呢？Growth Hacker = 营销 + 程序，为什么游戏策划不能 = 游戏设计师 + 程序？为什么很多实现要去交给别人写？事实上在你实现和调试的过程中，难免会发现一些设计上的小问题，也会因为实现，产生一些新的灵感和用法，都是很常见的现象。当然这只是一方面，最重要的是，真正能够理解好游戏业务，并且将之实现好的很多时候真的只有你自己，同时如其他楼提到过的，可扩展性，也只有游戏设计师才最了解游戏要怎么扩展。我们就说最常见的一个扩展点，这个帖子如何设计一个易扩展的游戏技能系统？ - 知乎，是一个好问题，但是我们总觉得自己能硬编码出来，可事实是什么？很多时候策划真的要一个技能的时候，程序员甚至说“这么复杂，玩家能不能理解”之类，反正意思就是不乐意做的话，那么问题来了，设计阶段你不提任何问题，到了实现阶段，你非但不去思考如何实现好，还一个劲的反对是什么鬼呢？最后有趣的东西做不出来，游戏不行了，怪策划，全是策划不好，锅全都是策划的，所以这个死了的游戏就能成功了？所以甩锅还是没用，怎么做好才是关键，怎么才能做好呢？游戏策划（或者说现在被称为“游戏程序员”的），就应该是垂直领域的，游戏设计垂直程序。

我们很多时候看到成功的项目，他们的开发模式都是程序策划分工明确的，因此我们觉得开发就是如此，但我们却看不到失败的项目也是如此（幸存者偏差导致这个现象），所以动脑筋想想，成功的项目之所以能成功，离得开项目中那些游走在程序和策划中间的人（通常在国内是制作人或者项目经理）吗？

所以说，你问我一个会编程的策划是个什么体验？这就是我的体验，孤独，满满的负能量为主！但是也并不总是那么无奈，游戏行业里还是有顶尖的人的（只是大多数、应该说95%以上都是渣渣），至少还有人能懂我的好就足够了。