为啥游戏的版本迭代都是作死

文/陈廷泽

1

想好了再做，还是做好了再迭代？

想法总是那么单纯可爱，特别是在手游行业，什么是迭代？

但凡参加某些成功项目的分享会，总会听到核心战斗改了5次，玩法循环改了8次，UI当然也是改了10多次，经过5次测试，上线次留过80%，月留20%，流水过亿。

当一件事不确定的时候就需要不停的去试错，试错是对“不确定性”的数据化，产品化的过程，我们拿不准，不知道，才会去做测试，做迭代，但凡涉及到核心战斗的迭代，已经属于伤筋动骨的范畴，属于是大手术，心脏搭桥。

经历过5次整容的产品总算成功，取得了市场极大认可，那么我试着问了另外一个问题

“你们研发团队有多少个人呢？”“我们研发团队，包括美术外包的人合起来200人左右吧”

很好，版本迭代实实在在的涉及到工作量，也是人数的问题，我相信，200人做的版本迭代内容，绝不是20多个人能够完成的，这还不包括对项目总体的把控能力，人家是用一个公司的人做一款项目的迭代，而你话只听了一半，准备用20个人对同样级别的项目，同样的工作量，死扛？这难道不是属于痴人说梦么?

2

百发百中，指哪打哪

国外的3A级别游戏公司普通标配会有以下三个Director

不止如此，他们上面还有位Producer（制作人）

制作人更多职责倾向于各个环节之间的资源调配，确保游戏制作环节资源充沛并对游戏最终正常上线做好充分的资源准备

之前在国内某知名外包公司面试助理制作人的时候，面试官说他们Producer能做到把下个月的需求开发进度，精确的控制在以小时的单位。

（四次面试均通过，但最后由于项目搁浅，岗位被取消）

非常震撼，入行这几年版本需求的规划不是随时都在变的么？怎么可能精确到以小时为单位呢？

以至于从细枝末节之间，便能感受到中外游戏研发管理上的巨大区别。

现在我们回到迭代这个问题上，策划出案子，程序一次性搞定，之后再也不用修改迭代。

那几乎是不可能完成的任务，大佬们总是认为“想好再做，免得返工”是不是看起来无法反驳？

问题的焦点在时间维度上，世界上唯一可以确定不变的事情就是，“变化”

我看待这个问题

市场在变，所以想法和方法在变，你不可能在用户还没体验你的游戏之前，就做到完全知道用户在想什么，当然有些牛逼的大佬会说，我当然知道啊，不行我核心战斗全改啊，美术风格全换啊！UI老子也换啊！

“预算上限就是产品的生命线”

而游戏的制作的预算都会花在研发的人力成本上，最终还是决定你有多少人，有多少钱，愿意花多长的时间。

所以抛开时间，抛开人力，抛开成本谈迭代都是在耍流氓

3

迭代迭代，叠着叠着就Go die

我看来，如果核心玩法，核心战斗，甚至UI出现严重问题，需要反复迭代，那么就是制作管理上出现了严重问题，如果按照国外研发公司的标准模板来说，就是主策的重大失误，

当然国内的公司通常和主策关系不太强，上有公司的老板，只需要一句话

“次留必须过60%”主策就得按照这个KPI去把他分了，这时已经不存在什么游戏性了，首先得完成任务啊！

“这个玩法加两个内容，就和哪个XXOO一样，已经是验证过的，我们搬过来就可以直接用，不要想那么多”

“UE的反馈特效太弱了，这是升级呢！必须让玩家感到自己很牛逼啊，特效要覆盖全屏啊”

挺好，这就是从需求变成了迭代，迭代变成了Go die

4

迭代没啥卵用，那可未必。

首先我中心观点，为迭代而迭代，那必定狗代，为什么呢？

短期类，你这帮研发的人，制作人，策划，程序，美术水平并不会得到极大的提高，做的人一样，没有结构性改变的前提下，还能把汤圆做成小笼包么？

显然是不可能的，凡是都有个方法，不可能无中生有啊，

如果能考虑到时间维度，以及方法维度，那么迭代的思路就对了一半

我们花多长的时间，要达到什么目标？从准备迭代伊始就需要有明确的里程碑，人员安排，自然而然的在制作过程当中，就会出现方法。

我相信方法总会比问题多，解决问题才是项目迭代的核心。

而为了迭代而去迭代，那么真的是得不偿失

另外一半是什么，“止损点”，在金融行业中经常被提到到一个词，

亏到什么时候，我收手，避免收益雪崩，对一款游戏来说，我再三强调，就是时间，如果想20个人去拼200人，那么在什么时间点，做什么事情就非常非常重要，

我拿UI的迭代举个例子，如果你看人家做了8个版本的UI，那么我们也做8个版本，那只会被美术爸爸喷SB，正确的姿势是

我们最多做3个版本，最次从这三个版本中选一作为CBT的测试UI

为什么？因为UI的工作量占到总体工作量的15%，需要在1个月内搞定，超过这个时间范围，超过这个工作量，势必挤压日后的美术需求，得不偿失。

您看这样理解容易多了吧。

专栏地址：

https://zhuanlan.zhihu.com/p/87547389