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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tags：

转载请标注：SEO三人行——经验分享：游戏运营之营销技术引擎