游戏运营之营销技术引擎

      从事游戏运营开发工作已十余年，算算从第一款网游凯旋做起，到今日共支持过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们，共同的理想使我们凝聚在了一起。 ✿✿✿