游戏运营之营销技术引擎

发表于2017-07-17
评论3 1.5k浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯游戏学院游戏程序行业精英群

711501594

      从事游戏运营开发工作已十余年,算算从第一款网游凯旋做起,到今日共支持过200多款游戏的运营开发工作,也算涵盖了从游戏的运营的各个领域。本文主要回顾了游戏运营平台的建设历程,希望能够给到新入行的战友们一些启示。


 先回忆下游戏运营平台建设的几个阶段:

一、运营技术原始积累时期:

      记得08年页游刚兴起,我们分成了ACT、MMO、WEBgame个团队来支撑游戏的运营及活动。围绕这些游戏类型,进行了基础运营体系搭建,和运营活动的建设。

 

     那会,每天都有N多的风格迥异的需求需要承接。你不得不先磨练出自己的“砍”功(不是砍人,是砍需求),再去和自己的小伙伴们讨论如何开发。

 

     为什么有那么多不一样的需求呢?原因很简单,游戏需要创新营销。创新就意味着无数种可能,每个游戏需要自己的个性,谁愿意我的运营案和别人的是一个模子?

 

      那为什么又要去砍呢?也很简单,我们每次做出来的运营程序,都希望下一次能复用,满足一下C 程序员对于程序抽象带来效率提升的快感。。。

 

      例如,我们以为众多需求在有了分享抽奖后,就可以给玩家发奖励了,从而封装了一个统一的此类活动程序。谁知道某一天策划找来说,我们希望分享后先给玩家积分,积分够了再来抽奖。。。       

      类似的情况不甚枚举,在被策划虐了无数遍之后,终于有一天,爆发了下图。。。

 

      痛定思痛,作为一帮牛逼闪闪的高级程序员,我们以为靠抽象、靠封装就能解决需求多样性的问题,但现实的残酷,将我们的自信心打击的一败涂地,人力也是持续在过渡紧张的边缘。看起来求变是必须的了,简单的抽象已难以适应游戏运营开发的需要。

 

 

二、快速化工具支撑多业务时期:

      10年左右的时期,游戏业务数量膨胀的更加急剧,已经到了数百款的地步,而且更要命的是,有些游戏一夜之间成了高富帅,访问量大的惊人,DNF、CF、7X。。。抱大腿的同时,也暗暗幻想,需求少一点,需求简单一点,阿门。。。

 

      我们在扛业务需求压力,绞尽脑汁想开发模式的时候,后台架构和性能问题又不容分说的,要我们提升日程同步考虑。

 

      游戏运营系统开发,别人眼中的高富帅职业,实际上成了每天纠结在这种开发模式和质量提升的轮回圈里的屌丝。在一次长达3天的会议之后,屌丝们决定要逆袭~~~~

 

      先介绍下如何革新开发模式的。我们在不断的功能抽象后,终于发现,运营需求最主要的脉络是,获得资格->设置概率->抽奖发道具,如果我们把这复用率最高的原子系统设计出来,然后再让大家逐个的补全其他营销行为程序,就能大大提升开发效率! 事实上,这套系统出来之后,我们的运营需求建设效率提升了起码30%以上。

 

      同时在架构性能方面,我们引入了memcached、TTC等组件,一定程度上缓解了性能压力。

 

      但是,由于各个游戏并不拘泥于简单的发下资格,判断下条件即发奖,而需要更多的秒杀类型、先抽奖再扣积分、更多的营销行为堆叠组合。这种原子系统也逐渐无法适应实际的多变性了。

 

      虽然不管作为一个玩家,还是一个运营人员而言,并不认为这样复杂的营销是否适合游戏本身。但既然业务有需要,作为一个技术人员,当时并没有特别的分析手段,基本上报着“以技术改变世界”的勇气准备再一次的技术革新征程。

 

三、集成化平台精细化时期:

      这个阶段在12年2月之后,首先感谢老板允许我们这一小撮人,能潜心去做游戏运营平台相关的事。这个时期的方法,可以用两个词形容:积木 轴承。如何形容有轴承的积木呢?还是以我们面临的运营需求举例形象点。

 

      例如,很多游戏业务需要在玩家进行分享行为后,去获得一个积分;或者进行VIP充值一段时间后,获得两个积分;或者游戏内杀满多少人后,获得N个积分;然后拿这些积分来换取抽奖资格。(晕没?。。。)

 

       还没完,实际需求还需要,如果已经从VIP充值渠道拿到了积分进行抽奖,游戏里杀人就不能再抽奖了。。。 这显然已经不是简单的线性逻辑结构就能解决了,除非你case by case开发,但谁也不想回到08年前。

 

       而且以后会不会积分又会和更多条件、营销行为交互?小伙伴们憋闷至极,不知道前走还是后移。

 

      在一次看到游戏内的任务系统设计时,突然想到,我们也可以设计一套全新的引擎,来使玩家把条件、资格、动作按照配置化,上报给这个引擎,然后由这个引擎来调用下一组条件、资格、动作的组合体,这样各类不可预见的营销顺序,就都能覆盖到了。

 

      说起来比较复杂,但一图胜千言,其实所有的运营需求,都可以用营销引擎这张图来解决。(示意图如下。。。)

这也是目前一直在运行的营销引擎模式,凭借这个突破,我们也获得了腾讯的公司级卓越研发奖,同时我们也将过半的需求交付了外包人员开发,进一步提升了效率。

      同时,在解决了开发模式后,我们还引入了内存化组件、云化扩容组件、流控过载防护组件、流水号打通重发及日志、全流程效果数据展现等,解决后台的大部分性能问题,和活动效果评估问题。这也终于能让我们能拿着历次活动报表,相对从容的和策划评估业务的需求了。

 

      当然目前这样的平台还不完善,30多个营销模块,全部是HTTP调用 动态生成进程的方式,单机运行能力比较低,之后我们开展了常驻进程及后台加速的研究。

 

      这应该也是tony经常讲的,先扛住,再优化的核心思路吧。

 

四、第四次跨越。

      如果你耐心读到了这里,或许你会产生一个疑问,难道游戏运营全部都是后台的事情,好似没有前端的事情?

 

      非也。游戏运营系统发展至今日,除了承载在HTML或H5网页上,甚至还跑到了公众号、客户端中,亲爱的策划伙伴们不止要求营销逻辑的千变万化,也需要页面交互上的一枝独秀。加上现在众多手游的出炉,发现我们的平台,越来越在前端页面整合能力上,无法适应目前前端的需要了。JS不兼容、模版应用低、前端流程零散、前端异常查错慢。


       我们在14年推出了前端自助化、和前端引擎的版本,将典型的运营需求变为策划自己去配置实现,同时实现与移动端手机游戏深度耦合。

      

      最后总结两点觉得比较关键的:

1、问题就是机会。这是游戏运营开发这行会经常碰到的,因为游戏本身是一个日新月异的行业,更何况你是在为所有的游戏做运营开发。面对问题,如果你没有OPEN的心态,将其转化为生产力,游戏运营这行我们就无法乐在其中。

 

2、技术驱动发展。简单的设计多游戏流程,希望套遍所有游戏,这样简单的线性封装切切是不够的。一个新游戏轻而易举的会break掉你昨天半夜想到的完美构造,而且这势必会让你在运营开发工作中相当的痛苦。设计一套耦合度低、易扩展、兼容多种数据结构、多种模块的系统才是王道。


以上就是四个阶段的建设经历,希望能对从事互联网运营营销的技术同学们有用。特别赞一下一起日夜摸爬滚打的产品/开发/测试/运维XD们,共同的理想使我们凝聚在了一起。 ✿

 

 

     


如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台