风控做不好,游戏毁于一旦

作者:黒い羊 2021-01-11 36.4k

如果有人问我,什么是一个游戏运营最基本,最重要,但是又最难做好的部分,那我的答案一定是【风险控制】。众所周知,在大多数情况下,游戏运营是很难提升一个项目的上限的;相反,游戏运营在很多时候都是一个项目的软肋。我们很少看到一个游戏因为运营得优秀而成功,但可以看到有很多游戏因为运营没做好而爆炸,成为同行和玩家的笑柄。


我知道很多玩家一出问题可能就在骂“狗策划”,但是我还是想为策划正名一下,很多游戏事故其实都应该是游戏运营背锅。而面对游戏事故,处理游戏事故,甚至是预防游戏事故,本身就应该是运营的重要工作。

但可能现在行业内的风气是,运营的工作重心都放在了项目数据和市场上了。并不是说关注数据、活动、市场的运营就不对,我只是想说那些都是一个运营的上限,而真正一个运营的下限其实是风控运营。

我所见过的大多数游戏运营,也包括我自己在内,都是缺少风控思维的。都是背负着流水压力,在繁重的、杂乱的工作中,做一些我认为的【高危操作】。当项目用户体量小,或者是运气好的时候,这些高危操作的问题可能暴露不出。一旦运营在没有风控运营的能力时,接手了一个重大项目,那么这个项目也会因为这个运营个人而承担极大的风险。


运营的第一原则应该是风控

如果不想运营成为一个项目的软肋,那么运营应该在处理任何对玩家有影响的事情的时候,都保持风险意识。

项目的每个问题,都会因为用户体量的放大而指数放大的,有可能运营在做小项目的时候,遇到小问题,没有关注,敷衍解决,一路走过来,直到接手大项目,在原本就遇到过的小问题上栽个大跟头。同样的运营事故,放日活3K的游戏里,可能都没有玩家感知到,放日活300W的游戏里,可能直接导致整个项目凉凉。

产品调整风险

产品调整的目的是为了让游戏与玩家、市场、以及现阶段的运营策略更贴合,但是产品调整的放出,本身也是会带来运营风险的。其中包括了:角色/系统的重做或改版,游戏数值的调整,商业化的调整,这里简单举例。


为了更好的描述产品调整具体会带来多大的麻烦,下面我会用我自己的真实经历说明

案例

在大多数游戏中,都有一个战斗力系统,把玩家当前的实力数据化,提供一个具象的实力参考标准


有时这个战力数值还会与PVP玩法关联,这些PVP玩法也通常是后端通过定时器自动发送结算奖励的


这里要先简单说明一下,统计玩家战力的设计思路:通常是,当玩家进行升级、换高级装备这种行为的时候,后端会执行一次重新算战斗力的方法,如果算出的战斗力大于数据库里玩家的【最大战力】,那么这个新算出的结果就会被更新记录到数据库中。


你一定注意到了,这个程序的整套逻辑,都是基于【最大战力】这个关键数值,而这个数值又是一个通过计算获得的结果,不是游戏内的自然数值。

然而,随着游戏的版本迭代,最初的战力算法已经不再适合于当前的游戏版本了。也就是说,按照老版本的战力算法,已经无法正确描述新版本的玩家实力了,这个系统成了摆设不说,还有可能对玩家产生误导。同时关联的PVP玩法,也会因为战力不准,引发大量的玩家投诉。

这个时候,系统或者数值策划会出一个【重算战力】的方案,让后端去改写战力算法,从而使战斗力描述能够更符合当前的版本。

你可能会产生疑问了,这里哪里有风险点,改战力算法就改战力算法咯,哪里有运营需要关注的地方?

首先,大多数开发是不了解业务的,也是没有玩家思维的,很多时候策划案过了,他们按照要求去写就完事了,是不会意识到战力调整对游戏的影响的。

而此时,如果策划与运营都只看到了:战力算法不合适了需要调整,这一个表面问题。而没有去考虑新的算法是会导致玩家的战力整体【上升】,还是整体【下降】的问题,再结合我上面介绍的,只有当重算的战力大于数据库里记录的数值时,玩家的最大战力才会更新,那么更新后的场景我们可以设想一下:

  • 策划写的新算法会导致所有玩家的战斗力整体上升,更新后,战力计算更准确了,玩家、策划、运营、开发皆大欢喜
  • 策划写的新算法会导致所有玩家的战斗力整体下降,运营、策划都没想到要先让开发停服,用新算法,重算所有玩家战力,并写库后再对外。更新后,所有玩家升级、买装备都不提升战力,pvp玩法没进度,最后玩家炸了,社群炸了,客服炸了,一路炸到策划和运营这来,最后又是紧急停服,开发赶紧写脚本,一个个给玩家重算战力补救
  • 策划写的新算法会导致部分玩家的战斗力下降,部分玩家的战斗力提升。开服后,部分玩家升级买装备有战力提升,pvp有进度,甚至已经领了奖励。而部分玩家死活没进度,战力也不动。

我曾经遇到的就是第三种情况,可以说是最坏的一种,并且那部分没有进度的,恰好是游戏中最核心的那一批大R,最后由于距离更新的时间已经太久,只能玩家找过来一个个再给他修改补偿。可以说如果情况3出现,已经算是重大运营事故了,如果是体量大的项目,又会是一场舆论风波。

其实这个问题要解决很简单,只要在业务流程上规定:如果有涉及到玩家数值的调整,都一律先停服修改完所有玩家的数据后,再对外开服。这个问题看起来好像是策划在执行的时候没有考虑周全,实际上策划通常是一个不用去面对运营一线的职位,有时候可能真的考虑不到,如果这个时候运营和策划有充分沟通过了,同时运营也具备风控思维的情况下,事故本该是可以被规避的。

因此我认为,大多数运营事故在上线前是可以被运营拦下来的,项目出现运营事故,无论是不是运营引起的,运营都应当并且有责任关注问题的原因,找到规避的方法

总结

诚然,要掌握把控产品风险的能力,需要运营本身有丰富的经验,并且对业务线上的每一环节都相当熟悉。但更重要的是,运营是否拥有对每次遇到的运营事故都追根溯源的精神,这些运营事故甚至可以不来自于自己的项目,可以是竞品的,是你玩的游戏里的,是你从哪里听说某某游戏的某某调整又炸了的……总而言之,产品风险问题,最好的解决思路就是关注。运营不关注,不排查,风险就永远在那里,等待一个合适的时间爆发。



相关推荐