TGDC | 手游研发运营2.0 ——潘多拉解决方案的技术实践

8月11日，由腾讯游戏学院举办的第二届腾讯游戏开发者大会（TGDC）在深圳举行。大会技术论坛中，腾讯互动娱乐营销应用与服务中心技术副总监庞巍伟带来了《手游研发运营2.0——潘多拉解决方案的技术实践》的主题演讲。演讲中，庞巍伟和大家讲解了“潘多拉”如何建设各项能力来支持游戏运营，提升游戏的营收、留存和用户活跃指标，并提出了改变产业分工的美好愿景。

以下是演讲实录：

大家下午好！非常高兴和大家分享我们基于移动游戏的智能营销、运营解决方案“潘多拉”，正式演讲前我想问一个问题，大家不用回答我，可以心里默默思考。大家所在的游戏团队规模是多大？有多少开发人员，其中多少在设计周边系统，而这些周边系统大概占用我们多少开发时间和资源？我过往参与、服务过的项目，这些周边系统所占用的时间是超过1/3的，我不知道大家的团队是不是这样的现状。今天所有的分享会围绕这几个问题展开，向大家介绍我们思考的不同的方案或是不同的团队模式，看能不能更好的解决这个问题。

今天我分享的主要内容会分为三个部分：一是简单介绍“潘多拉”是什么？二是“潘多拉”的技术架构和遇到的挑战；三是“潘多拉”起到什么样的效果，对我们的项目有什么样的价值。

“潘多拉”介绍

大家看一下这个图，我们思考一下游戏在最早期的时候，我们所谓的单机游戏就是纯粹的游戏体验，比如说我们玩《马里奥》、《赛尔达》、《仙剑奇侠传》，就是战斗、剧情、道具的升级。早期的单机游戏里不存在周边系统，我们一般把周边系统定义为在线的运营、商城、玩家互动的系统，这些系统和游戏的核心玩法关系没那么紧密。我们可以把网络游戏拆分成核心玩法+周边系统的设计，拆分出来以后我们就开始思考周边系统能不能单独建设，跟游戏的核心玩法独立开来，使得游戏的团队能专注在核心玩法，把有限的时间和有限的资源都投入到核心玩法，提高游戏的可玩性、游戏的核心乐趣，周边系统单独拆出来、单独做沉淀，使得最后能达到产业的分工，并且这个东西还可以独立的优化、独立的迭代。

如果我们拆开以后，核心玩法就是现在大家普通团队花最多时间做的，比如说RPG、ACT、MOBA、商城、任务系统、运营的玩家回流、玩家之间战队的匹配，独立的拆分出来。也许我们就达到了设计的目标，我们简单看一下设计目标，其实就是为了能不能使我们的团队和游戏核心开发团队的分工分开，让我们的“潘多拉”团队或是在座各位所在的公司都可以做这样的尝试，把游戏的核心开发团队和周边运营的团队单独拆分出来，让整个产业分工变成游戏、周边系统独立建设。

第一个例子是《QQ飞车》的商城，我们看到这样的商城，不管是道具的展示、交互的效果、支付购买，其实都是通过“潘多拉”完成的，并没有造成玩家的割裂体验。

第二个例子是《QQ飞车》做的视频直播，这个视频直播也是嵌入到游戏里的原生体验，具备完善的开播、交互、弹幕功能，和虎牙、斗鱼、熊猫的直播源都打通了。通过游戏内嵌入的系统可以观看到外部关于《QQ飞车》所有直播内容，这样一个方案可以在所有的游戏里进行上线、集成，开发商可以大大降低开发成本。

第三个例子是《QQ飞车》做的好友和战队的匹配系统，可以帮玩家快速找到合适自己玩家，我们会分析玩家的地理信息、地理的聚群，让玩家可以相互匹配在一起。这样的一套社交系统在《王者荣耀》、《天天酷跑》都上线了。

通过三个例子，相信大家已经有非常直观地认识到，周边系统可以单独拿出来放在游戏建设中，可以重复应用到不同的游戏里，其实做这样的系统可能并不是游戏核心乐趣所在，但又不可或缺，这些系统影响到玩家的留存、活跃等指标，这三个系统很好了展示了“潘多拉”到底要做什么样的事情。

“潘多拉”技术架构与挑战

技术层面上怎么做？“潘多拉”的系统结构就是上图，最底层是基于腾讯互娱，集合了PaaS系统，包括数据的挖掘、数据的分析、道具的售卖等系统，上面提供一套总线，能够调动下面丰富的系统，为上面的“潘多拉”前端做服务，中间会有一些运营系统和开发者工具链，最上层是游戏适配层，对所有的引擎提供一套适配层，能让适配层嵌入到游戏的引擎，原生呈现游戏系统的UI。适配层之上我们构建丰富的商业化服务，大家在里面可以看到关于营销、数据的应用、关系链的社交、商城等。

整个一套服务，放在游戏里就可以大大降低游戏的开发成本，取得非常好的运营效率和效果的收益。这里先重点看一下关于移动前端，引擎适配层技术的探索、演进的过程。我们来看这张图，底下两个红色三角是游戏的引擎，大家做游戏还会在上面做一些封装，它会有一些分层和嵌入的关系。“潘多拉”的前端适配层，它并不是完全分层的结构，这套适配层和游戏的引擎、Game Framework是嵌入的关系，而不是看起来分层的结构。因为“潘多拉”还要解决引擎原生不具备的能力，举个例子，关于音频、直播、K歌的能力，引擎是不提供的。

我们看到“潘多拉”的嵌入适配层和游戏引擎之间不是分层的关系，是类似于相互嵌入的关系。在“潘多拉”的适配层之上才是周边应用的服务层，在服务层之上我们可以构建商业化应用，对于我们迁入这层在技术上有一些要求，必须具备非常好的跨平台特性，同时要具备跨引擎的能力，它都能很好的嵌入进去。最后他要易于调试、易于开发，最后还要非常方便的测试。

最开始的第一版是非常简单的想法，就是用H5的浏览器嵌进去，这是市面上我们看到一些所谓的具有社交能力的组件会用到的方案，游戏里嵌入H5的浏览器，基于H5的浏览器在上面做一些应用，与游戏之间会有数据的交互。这样的解决方案最开始是在三年前，也是这么尝试的，它有非常明显的优势，它的开发成本非常低，整个的工具链是非常成熟的，现有的开发人员能快速地进入到开发环境里实际的上线开发，它也是易于在线更新的。

劣势是什么？他对游戏内存有非常明显的影响，特别是在安卓系统上，开了一个浏览器，安卓有80甚至100M的内存是无法回收的，这是安卓、Java的内存回收机制和安卓进程统计的问题，还有浏览器组件本身就很大，使得这部分内存无法被回收。我们做游戏的时候，内存跑在系统的临界点上，我们做一个组件使得游戏打开一个简单的页面占掉50、80、100M的内存，这是完全不能接受的。

完成V0的版本后，我们尝试了V1版本，V1版本也有很多游戏上线，V0和V1 的区别是我们使用原生系统进行封装，用IOS和安卓原生的UI系统，市面上有很多比较流行的技术，比如说早期的wax，现在阿里开源的weex，上层用一些Lua或者H5方式抽象原生系统UI，达到在一个开发环境下对于不同系统的UI进行抽象。它的优势与上面v0相似。

它的劣势，是安卓和IOS还是有一些系统性的差异，包括UI的局部表现也不是很一致，系统功能表现不一致，性能和内存也不是理想的。

做完V1版本以后我们开始考虑V2版本，针对不同的游戏引擎提供游戏引擎原生的解决方案，包括对于Unity提供Unity的方案、对于Cocos提供Cocos的解决方案、对于Unreal提供Unreal的解决方案，基于游戏引擎各自的特点来做。

我们做完V2以后，和开发人员讨论的时候，我们的开发语言、开发环境、开发术语是一致的，他们就能理解，你们也是这么做的，你们做的快和慢，哪里遇到了挑战，他们非常容易理解，这样他们慢慢觉得我们做这件事情非常专业，对我们产生足够的信任。

V2版本已经应用到腾讯基本所有的五星到六星的业务。

做完V2版本之后，我们显然觉得这样的方式还是有不足的，我们就去思考，刚才我们是针对不同引擎进行了抽象，我们能不能对于所有引擎都提供一个统一的抽象层，将统一的抽象层应用到所有的游戏引擎里，使得我们整个的开发环境最后也是统一的。V2版本是我们针对不同的引擎做了抽象以后，用的是引擎自己的一套开发方式，包括可能用到自己的工具链，Unity在Unity上开发，Unreal在Unreal上开发，能不能提供一套统一的工具链，可以把不同的东西在不同的引擎里统一的进行渲染？我们正在解决这个问题。

刚刚我们讲到关于前端的技术演进和迭代，现在我们来看看运营这套系统解决了什么样的问题，这是我们为什么要坚定的把这件事情做下去，不仅仅是产业分工，更为了解决一些游戏产品设计的一些问题。

我们做这件事情的目标是为了做到“千人千面，帮助游戏再设计”。

我们怎么做到时候这一点？我们来看快速运营迭代系统，一般运营的方案都会是这样的闭环设计，首先拿到一个策划案分析我们的策划案到底适应于什么样的环境，它的目标用户是什么样的，我们希望达到什么样的效果，这个东西有没有不同的版本，针对于不同的平台。比如在小米平台、华为平台最后的运营系统不太一样，甚至可能送的礼品或是新品的礼包也不太一样，方案在设计出来后，针对方案设计的过程会筛选用户，用户从哪里来，到底是什么渠道的，灰度的测试、部分的测试还是全量的测试？基于用户筛选过程之后我们会把方案投放到对应的平台上，我们会对投放出来的方案做实时的数据跟踪，分析效果是不是达到设计预期，如果达到设计预期就可以更大范围的推广这个方案，如果没有达到设计预期，就要把方案重新拿回去再设计，大概是这样的闭环。

我们的运营系统需要解决内容的差异化、版本的差异化，包括可能多语言、不同渠道的管理和用户的触达，我们需要思考每个用户来自于哪里，他是不是基于广州、深圳这样的聚群的玩家测试，还是基于什么样的特性测试，这些用户颗粒度到达单一的QQ号、微信号的方式去测试我们的方案力度，最后是基于方案有一套完善的效果分析系统，这套分析系统会自动生成效果分析，包括报表、包括我们感兴趣的数据。帮助到我们的运营人员可以把这个东西快速的投放到市场上，让我们的方案可以快速地试错、迭代、推送给玩家，让这个方案可以真正地帮助到运营人员，提高运营的效率和效果。

我们来具体看一下数据分析系统能为游戏提供什么样的帮助。假如说我们有一个正在研发的游戏，我们会匹配历史上跟他类似的游戏，通过数据匹配会分析他的玩家行为数据、购买数据，社交数据、对局数据和玩家的画像信息等，匹配完数据以后，会指导我们正在研发的游戏，为正在研发的游戏寻找可能更好商业化模式，更加适合玩家的节奏设计，包括社交的玩法，包括匹配的机制是什么样的，可能都会影响到实际研发的数据。

大家知道手游的生命周期已经越来越短，比如说上完线以后再去思考运营这件事情，很可能当你实际运营的时候你的游戏已经是属于衰退期了，可能已经没有这样的效果，所以我们一般都会把事情前置，在游戏研发的时候就已经开始思考这样的问题，使得数据对于游戏的分析、对于数据的应用都会前置，在上线前推送到玩家面前之前，就可以把这些东西影响到游戏的实际开发过程。

在整个的生命周期里，我们会根据玩家的所谓用户画像，这个游戏还没上线之前分析潜在的用户来自于哪里，对潜在用户做精准的拉新和精准的投放。在新手阶段，针对性的实时关怀，使他变为活跃用户，他成为活跃用户后我们希望他的活跃周期更长、活跃值变得更高。

最后到了用户生命周期的长尾的过程，我们会分析玩家的流失风险，包括实际流失以后，我们会对玩家做精准的挽留或是对玩家进行回流的推送等，会做这样数据化的服务。

“潘多拉”的效果和价值

一定会有人问，我们做的这件事情对游戏有什么样的帮助？这里给大家直观的数据，以《QQ飞车》来讲，我们通过分析玩家的潜在关系链，去做精准的拉新，拉新用户占新增用户量的68.27%；我们对于战队的推荐，使得玩家活跃程度平均提升了42.53%。

我把这个项目推到腾讯自己的团队和外面的团队，大家会问，游戏团队为什么自己不做，你做的东西我们自己都能做，我们做起来效率更高，为什么拆分出来让你们做？对我们来讲有什么好处？我跟大家总结一下。

1.我们发现，大多数游戏开发的团队在游戏即将上线的时候，周边系统还没开始开发，这件事情对他们的优先级并不高，开发团队优先做了游戏的乐趣和体验。

2.开发的资源、时间是有限的。

3.不擅长。一个游戏团队，应该非常擅长做游戏，但不一定擅长做看似和游戏不太相关，看上去更像是一些APP领域的技术。

4.做不了。数据挖掘、数据分析场景欠缺，他们不了解自己的游戏与其他游戏的数据相比是怎样的，玩家画像是否和预期相匹配。

5.缺乏沉淀和积累。这是非常现实的问题，一个游戏在做实际开发的过程中，如果项目成了，可能会比不成的时候更累、更辛苦，大家需要赶更多的玩法和更多的任务，如果项目不成，很有可能这个团队解散了，我们之前对这个项目开发的技术可能也就七零八落，技术也没什么沉淀，更别说周边系统怎么沉淀积累。

6.关于改变产业分工的问题。

在改变产业分工这里，我们简单看一个案例，简简单单的一个任务系统，这个任务系统我们会抽象规则平台、任务生产推荐模块、奖励模块和整个的管理后台，应用到不同的游戏里，一个游戏是《王者荣耀》、一个是《天龙八部》，前端表现不太一样，后端包括我们抽象出来的东西是完全一样的，接入到游戏里以后，游戏研发侧是没有任何投入的，我们给《王者荣耀》、《天龙八部》做的时候，会根据游戏的UI、UE需要，首次开发耗费两到三周，后续的开发、迭代和物品的更新、升级，包括任务的更新升级，仅仅需要产品人员配置，连程序都不需要介入。只需要产品人员配置0.5天，加上测试就可以快速地上线，这样一套系统的开发质量也是非常高的，故障率小于千分之一。