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天,加上测试就可以快速地上线,这样一套系统的开发质量也是非常高的,故障率小于千分之一。

 

 

对于大多数游戏,商城系统基本上是没有积累的,而我们的积累包括了一套商城的管理后台,商城的道具销售分析,道具的自动上下架,折扣的管理、促销的管理、自动对帐和自动补发。

 

 

最后我们总结一下,我们通过跨引擎抽象有效提升了研发的效率,结合我们自己一套工具链,大幅度降低游戏开发成本和门槛,多年积累的PaaS层,整合数据和营销的能力、玩家的画像,提供增值价值,最后我们反复地锤炼升级我们的周边系统,提高业务的复用性,不断强化后台系统。

 

 

什么是“潘多拉”?是欧洲神话的一个盒子,盒子被打开可能有灾祸和希望,也会有邪恶和美好。我们做的“潘多拉”系统,是希望能把我们关于游戏设计的美好、有希望的东西沉淀下来,帮助到更多的游戏团队,让大家把更多的时间、精力花在游戏乐趣的建设上,让游戏的设计回归本来的乐趣,谢谢。

阅读与本文标签相同的文章