不是策划不知其苦。
最近自己最近深陷与策划设计沟通之苦，我只是作一点感想记录。
游戏制作本身属于软件工程范畴：
从故事剧情设计、游戏时长设计、数值设计等几个方面确定游戏制作的偏重方向，这个我觉得我们没有做好，开发过程虽然也实时有在保持在大方向上，但有时候一些人提出了一些针对性问题，团队内部就好像有点怀疑侧重方向是否应该这样或那样。我所说的这个方向并不是没有方向的意思，举个例子来讲就是：现在市面上有许多生存类游戏，但是其设计的侧重点不一样，有偏策略生存-这是我的战争、偏数值向生存-overland(怎么苟怎么玩)、偏沙盒类生存-饥荒。
对于游戏设计我虽然没多少经验也不敢指手画脚，但是从工程角度来讲这个也是非常重要：兵马未动，设计先行。主方向定好了，程序才能有的放矢。这就涉及到如何在有限的时间里完成原型设计验证，那主方向就非常关键了。策划同学的原型设计都得必须基于这个大方向框架之内发挥才智，设计游戏玩法，然后交予程序同学编码验证。这个必须也是相当关键的了，每一个人每一天的工作都是制作成本。
还有一个点我也想记录一下，就是文案的问题。现在一直都在流行一个段子：提需求前先扫码，我TM直接甩你一个策划案，还扫码？。不管段子怎么样，现在我们也确实存在这个现状：口述提需求
。详细的策划案是一切工作的交接支点，一是设计成案且详细记录的文案，是玩法迭代的基础，没有人能一次性想清楚整个设计或问题；二是方便交接，对美术、对程序的工作支持都是相当的大。人的脑子容量有限，口述的需求基本第二天都给忘记了，还得不停询问需求是啥，谈何工作效率呢。三是验收关键，对程序验收第一是时间进度验收，第二是完成质量验收。时间进度好说，直接量化。而质量验收的关键就得靠文案了：需求文案编码实现还原度；QA验收依据，都得用文案量化。口述需求基本都是靠感觉验收，容易蒙混过关：程序不想写了、或者策划不想想了。
我有时候也在想统筹，它其实也是一门学问。我在项目中的与同事沟通的时候，发现我们每一个人关注点不一样总是会遗漏某些方面的问题，自己梳理的时候就会不停的与策划沟通。我之前对策划文案梳理都有画流程图和UML的习惯，可以帮助我更好的理解策划的意图，理清自己的实现思路。只要我给技术总监看看我画的图，他总能在某些点上指出我的存在的问题，在我有疏忽的时候也能来保证这一块没有问题，他能做到面面俱到，这一点我非常佩服，这也是我需要学习的地方。很多时候需要对接的工作有非常多，对接各个策划设计以及他们的设计与现有系统的衔接性、自洽性，这个时候更加需要这种能力。不得不说，我之前也是太小看统筹管理这方面的技能了，特别是在中大型项目中。这种经验的积累，其实就是对工作流程、方法论的总结，把所有流程放在一起看上去很多余或者很臃肿，但是它确实在一定程度上确保了工作的准确性和提高了工作的质量。好比现在生产手机都在提良品率一词，工作质量上不去，进度再超前都是成本的浪费。不得不承认，统筹管理技能也是必须掌握的一门学问。