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