游戏策划职位面面观04：系统策划
写在前面
这次拖更的有点久了啊，因为最近在研究拍摄vlog的事，看着知乎上每天都在增长的关注人数。突然觉得再不写点什么就太多不过去了。所以这里将之间回答的一个问题整理成这篇游戏策划职位面面观中的完结篇——系统策划（假装忘记了还有一篇数值策划的没有写）
这篇文章我和大家深入的聊一聊系统策划的核心竞争力，以及系统策划的进阶之路。
前言
我跟做互联网程序员的朋友这么介绍自己：“我就是游戏行业的产品经理”。
我们在说游戏策划的时候，如果没有特殊介绍，通常说的就是系统策划。
我对于系统策划有不同的看法，正如我看好关卡策划在未来的发展一样，我也看衰系统策划，因为现在的系统策划，往往是找不到更细分的领域的情况下最终选择的职业方向。就像我在上文中说的，用产品经理来作为类比，人人都是产品经理，每个玩家都是系统策划。
前几天我在知乎上回答了系统策划如何提升自己的专业技能？，一位热心的朋友在我的回答下反驳了我的观点，我觉得很有意思。这里结合他的观点整理出来和大家分享一下。
级别划分
我了解到的系统策划，主要的工作内容当然就是写系统文档了。然后就是围绕着系统文档的实时跟进。最终落实到游戏中。
初级系统策划，通常是写通用性较强的、非核心的，与其他系统耦合性低的系统策划案，比如：背包系统、签到系统等；
进阶的系统策划，开始撰写针对性强的，核心的GamePlay系统，这就开始要求系统策划本人对于项目有一定的认知；
高级的系统策划，或者说游戏项目的主策划，就是游戏核心玩法的制定者，这需要策划人员对于某类游戏有独到的见解和认知，清楚项目方向。
不靠谱系统策划
可能是因为我是做数值策划的，平时和各种系统策划多有交集，遇到的几类不靠谱的系统策划都是什么样的呢？这里和大家分享一下，作为系统策划的小伙伴引以为戒。
- 知其然不知其所以然的
比较有代表性的话就是：“具体我也不清楚，反正大部分游戏（常规游戏）都是这么做的”
怎么说呢，有点儿无力吐槽了。这种和你讨论问题时，永远停留在“某某游戏就是这么做的”层面的系统策划，大概是还没入门的，也就别和他太过计较了，能打发的就打发了吧。我还真就遇到过，和你说某某游戏就是如何如何，然后我解释说某某游戏如此的原因是什么什么时候，这位仁兄先是一愣，然后眼神发直了一会儿后，说了句“你先别说那个，反正人家是这么做的。”
所以我说这种仁兄基本上就别和他过多交流了，能打发就打发了吧。 - 写出设计不知道如何实现的
知乎上之前有人邀请我回答“游戏策划要不要懂一些编程知识”的问题，我其实觉得这个问题没有必要回答，甚至不应该问。因为不知道实现方式的设计通常一文不值，我在工作中遇到太多将感性描述记录下来就称其为“策划案”的同事了，在和程序沟通前我通常都会先从数据表结构上反推一下其设计的不合理之处，但是有个别固执的，就只能让程序哥哥去调教了。要是程序同事碰巧也缺乏经验，最后制作出来的东西，单纯表结构都是一场灾难。 - 只会规划却不知道细节的
有一类系统策划很容易掉入“假大空”的陷阱中，设计一个系统必定要上升到整个游戏架构的高度上，否则就举步维艰。然后整个系统案只能写出一个空泛的壳子，对于其中具体细节的设计，只有在对策划案（设置是程序实现时）才能逐步补充完善。
这种策划通常是最危险的，因为很可能陷入在自嗨的陷阱中，以为自己已经进阶到核心玩法制定者的地步，殊不知只不过是因为缺乏将问题细化的能力，而凡事都不得不提高到整个游戏系统架构的高度而已。大家要格外的引以为戒。
以上说的三种不靠谱的系统策划，虽然听起来挺不可思议的，但实际上在工作中确实那么的常见。
进阶之路
上面和大家吐槽了一些我接触过的不靠谱的系统策划，这里在和大家分享一些我认为作为系统策划在职业生涯中必须具备的素质。有助于大家在系统策划的道路上更好更快的进阶。把那些大混子赶出游戏圈。
- 清楚设计目的
设计目的是一个系统策划案的中心思想。很多小伙伴可能不重视这一块，只是不得不写一行应付了事。实际上这一块才是一个系统策划案最核心的部分，我在看策划案的时候，通常看下设计目的就至少清楚这个策划案有没有“跑偏”。
不仅是写策划案，实际上在大家平时工作过程中不妨多思考这样的问题，就是某个游戏的某个系统的设计目的是怎样的。 - 细节决定成败
拒绝“假大空”从我做起，这里所说的细节决定成败，是呼吁大家关注细节。要知道一个系统就是由很多微小的但就是能够提高用户体验的设计堆砌起来的。系统的完成度，可能就决定了玩家的留存。只有从足够基层的细节设计中摸爬滚打，才能做好之后的宏观架构设计。这其实也是一个系统策划的核心竞争力。 - 功能的验收
其实这方面也是我比较欠缺的，这里提出来和大家共勉吧。要知道一个游戏最终是要面向玩家的，玩家不能玩策划案。所以即使我们的策划案写的再棒，最后也要看实际游戏中的完成情况，而能够对一个系统负责的只有我们系统策划，我们系统策划要跟进功能的实现，确保功能彻底的验收完成。
这一步很关键，却也是最容易忽略的，很多人有这样的观点：系统策划案写完了我的任务就算是完成了。这种想法是不对的，游戏是策划的，功能模块的负责人要有负责人该有的亚子。
记住：玩家不能玩策划案（我也想跟部分程序哥哥说：玩家不能玩儿代码） - 了解系统的核心控制参数及含义
我本来想说具备设计数据表结构的能力，想了想这部分不是刚需的，毕竟可以通过数值或者程序的配合完成。但是有一点是系统策划不可替代的能力：能够抽象出系统的核心控制参数及含义。
这个可能有点抽象了，我这里给大家解释一下。
抽象出系统的核心控制参数，任何一个GamePlay都是有参数的，这些参数就是你们在写策划案时候随手写的可配置的那些数值。这个不是直接丢给数值同学就完事了！这个是做系统的你要给出更详细的含义解释的。甚至是做出最初版的数值
比如说，某款游戏中的背包系统，一行有4个格子，初始解锁4行，之后每升一级解锁一行，玩家也可以通过消费解锁行，费用 = 解锁行数* 参数A，其中参数A为10，货币类型为可配置的，暂定为元宝。
类似我在之前讲述关卡策划的文章中提到的，关卡策划应该是一个关卡的总负责人；一个系统策划，同样应该是一个Gameplay模组的总负责人，这个系统想要达到怎样的体验是需要准确的和数值策划进行沟通的，而数值策划只是在理解了你这个系统的核心控制参数的同事辅助你达到这个体验预期的角色而已。
后记
现在将近零点了，最近很忙。这篇文章写得可能也多少有些零散，这里先给各位读者说声对不起了。我会在之后不那么忙了的时候优化一下这个系列的文章。
下一期就迎来了游戏策划职位面面观的真正完结篇，也是我的本职工作——数值策划了！希望大家到时候还能捧场啊。
我是一个普普通通做游戏的，除了游戏不会别的。
感谢各位的关注！
