GMGC—腾讯如何打造一款实时对战手游

最近公众号停更了一段时间,因为一直忙于GMGC2016全球移动游戏大会的腾讯游戏服务展位工作,负责演讲:腾讯游戏开发者训练营—腾讯如何打造实时对战手游。这篇推送便是此次GMGC的演讲内容。

从2015年以来,手机游戏的市场偏好,渐渐从早期的休闲、卡牌为主,转向更重度,操作性更强的玩法中来。因此实时对战这一游戏形式,也渐渐成为了手机游戏畅销榜上常见的一个特性。《王者荣耀》《热血传奇》《火影忍者》《穿越火线·手游》《六龙争霸》等等曾站上收入前十的游戏,都支持玩家实时的PK或者合作攻关。这些游戏里的玩家,由于有强互动的玩法,活跃度和社交强度都是比较高,为游戏收入的提高奠定了坚实的基础。同时,由于实时对战的玩法深度和互动强度远比休闲游戏高,所以用户的忠诚度也比较高,游戏的生命周期从而变得更长。

腾讯的游戏开发团队,很早就看到实时对战这一个重要的趋势,因此在自研产品方面,加大了开发这种玩法的力度。诞生了《王者荣耀》《全民超神》《穿越火线·手游》《全面突击》《天天炫斗》等一大批优秀的作品,早期的《全民飞机大战》也加入了实时双打的功能。这些带实时对战玩法的游戏,普遍的用户活跃度都很高。其中《王者荣耀》的DAU一度超过千万。既然实时对战玩法是一个非常重要的特性,为什么我们现在看到的游戏,带有这个玩法的还是不算很多呢?其中一个重要原因,就是开发实时对战的功能,在技术上有一定的门槛,本文希望能向大家展现腾讯是如何跨过这些门槛,解决实时对战游戏开发的一系列技术难题的。

实时对战游戏开发的技术难点,有三个主要的方面:一个是版本兼容问题,大家知道,不同版本的程序如果通过网络进行通信互动,很容易出现问题。而手机上的游戏客户端,往往比较难以推动用户去更新,从而出现大量不同的历史版本同时运营的情况。要解决这种问题才能为大量用户共同游戏提供基础。第二个方面是游戏状态同步的问题。由于多个玩家在一起实时对战,游戏程序就要保障玩家的客户端上,表现出相同的效果,否则很难提供公平的游戏机制,也难以保障玩家的游戏体验。实时同步游戏状态,需要转发大量的数据包,这和回合制的同步数据量不在一个数量级上,然而手机游戏的网络环境又异常的复杂,2G、3G、4G、WIFI多种网络并存,这些网络的延迟都不一样,更要命的是,手机会在这些网络中切换,底层的网络连接常常会断线或者丢包,这是以前的PC游戏不曾碰到的问题。第三个方面是对于服务器稳定性方面的挑战。

由于实时对战游戏有大量的消息需要转发,大部分游戏还需要在服务器上运行各种游戏逻辑如奖励、AI、验证等等程序,这些都造成了对服务器的超高负载。面对海量计算要求的同时,实时游戏对于计算延时还非常敏感,要求服务器在非常短的时间内给出响应。这造成了服务器性能和稳定性的巨大挑战。对于这三个方面的挑战,腾讯游戏结合在PC端游时代的技术经验,加上努力在手游环境下的探索,总结出一系列符合实际的解决方案。

首先我们来说说网络同步问题。这是实时对战手游中技术问题最困难,对用户体验影响最大的部分。我们经过测试,可以发现2G网络的延迟在400ms左右,而3G/4G/WIFI下的延迟平均在100ms,50ms,30ms,由于手机可能会在延迟相差如此大的网络中切换,所以我们不能简单的以某一个网络延迟作为方案设计的唯一着眼点。另外移动网络的还有质量不稳定的特点,网速快慢变化非常频繁,这也让我们需要注意不能单单依赖网络本身的质量来保障体验。在非WIFI下,很多移动网络都是按流量收费,这也是需要考虑的问题。手机在网络间的切换,会造成底层网络断线、地址变化等问题,都是常见的情况。以上的几个问题,在网络同步程序设计的时候,都必须要同时考虑到。这些问题的统一解决手段,最重要的是选择一个合理的游戏状态同步模型。在同步模型中通盘考虑各种需求,而不是头痛医头脚痛医脚,是解决实时同步问题最基本的方法。

游戏同步方案

腾讯在大量游戏开发的实践中,总结出三种游戏的同步模型:

第一种叫MMOG模式。这种同步模型,在端游时代就使用的非常广泛,特别是MMORPG里面。它的主要实现要点是:服务器负责计算全部的游戏逻辑,并且广播这些计算的结果;客户端仅仅负责发送玩家的操作,以及表现收到的游戏结果。

一般来说,玩家发送一个操作到服务器上,服务器根据玩家操作去修改内存中的游戏世界模型,同时运算游戏世界对这个操作的反应,然后把这些反应都广播给相关的多个客户端,每个客户端负责把这些数据表现出来给玩家看。这种法的优点是非常安全,由于整个游戏逻辑都在服务器上,客户端可以作弊的范围非常少,服务器只接受合法的玩家操作,一切都经过既定逻辑的运算。另外一个优点是游戏的逻辑更新很方便,因为主要逻辑都在服务器端,一般的游戏玩法挑战,游戏开发团队自己更新重启服务器就可以了,无需让千万个手机去下载更新包。

但是这种做法的缺点也很明显,首先就是用户的体验非常依赖网络质量,如果一个用户的网速慢,其他玩家都会发现他在游戏中明显的变卡,所以一般要求网络延迟在100毫秒以内,才能保证基本的流畅。另外一个缺点就是服务器负责了太多的游戏逻辑运算,特别是动作游戏里,服务器往往需要针对二维或者三维空间进行运算,这样导致服务器的负载非常高。

最后,如果使用这种同步方案,可能会导致网络通讯的数据量非常大,因为每个游戏表现都要以数据包发往客户端,如果一起玩的用户数量较多,这种广播的数据包量就会非常大,大量的数据包除了占用带宽造成延迟上升、丢包增加外,还可能给用户造成很多流量费用。因此根据以上的特点,腾讯一般会在那些同局游戏人数不太多,但讲求玩法变化快和安全性高的游戏中采用这种同步方案。由于腾讯在端游中大量使用这种方案的,有一定的技术积累,所以也会影响较多的游戏使用这个方案。腾讯自研手游中比较著名的《穿越火线·手游》《全民超神》《炫斗之王》都是使用这种方案的。

第二种方案叫主机模式。这种同步方案的做法是:以参与对战的一个客户端为“主机”,其他的客户端为“副机”。游戏逻辑的主要运算由“主机”完成,所有的“副机”把操作指令,通过服务器中转,集中发送给“主机”;“主机”完成游戏运算后,把结果指令再通过服务器中转,广播给所有的“副机”。

这个方案看起来有点奇怪,但是却有很明显的优点:首先是大量的实时动作游戏,其游戏过程的逻辑代码,都是在客户端上开发和运行的。客户端的游戏引擎对于二维、三维空间中的位置运算、碰撞检测等功能,都有很好的支持。因此把整个游戏逻辑由客户端负责,就能让服务器端无需再开发这部分功能,同时也显著减轻了服务器的复杂。因为服务器只负责做转发、广播的操作,因此能承载的人数和第一种方案有数量级上的差别。另外由于“主机”客户端运行游戏逻辑,所以其体验是最好的,就算有些“副机”由于网络延迟丢包造成体验下降,对于“主机”来说,只是发现“副机”动作有点迟缓而已。

在一些特定游戏玩法下,比如“双打”的动作游戏来看,“主机”的运算量也是很小的,完全可以承担多一个副机。如果实时对战的玩法以PVE为主,用户更关注的是自己的体验,所以不会太在意同伴的准确动作,只要同伴能帮上忙,就会觉得满意了。这种主机模式在PVE和少量玩家共同游戏的情况下,是一种不错的同步方案。它在400毫秒延迟下还能提供不错的游戏体验,这是其他方案都比较难达到的。当然,这种方案要占用的网络带宽和流量也是不少的,和第一种MMOG方案基本相当。腾讯的《全民飞机大战》的双打模式就是采用这种方式,效果相当不错。

第三种方案叫帧同步模式,又叫“锁步模式”。这种模式用形象的比喻来说,就是把所有参与对战的客户端,看成是排成一列的囚犯。这些囚犯们的左脚都被链子所在一起,因此他们如果要往前走,就只能同时迈步,如果其中某个人走快了,或者走慢了,都会让整队人停下来。在实现上,一般是以服务器按固定的帧率,来搜集每个客户端的收入,然后把这些输入广播给所有的客户端;由于每个操作指令到达所有客户端的时间(帧)都是一样的,所以每个客户端运算的结果也是一样的,同样的输入就会得到同样的结果,就好像其他玩家通过网络,把操作手柄接到你的手机上一样。

这种同步方案,是传统单机-局域网游戏中最常用的,比如我们熟悉的星际争霸。这种同步模型的最大有点是强一致性,每个客户端的表现是完全一样的,非常适合高度要求操作技巧的游戏。而且,由于网络上广播的只是玩家的操作,所以数据量很少,不管游戏中的角色数、状态量有多大、多复杂,都不会影响广播的数据量,这也为自然创造游戏内容提供了基础,在手机网络下,更少的数据包带来更低的流量费用、更好的网络表现。

但是这个方案也有很大的缺点,就是对所有王家的延迟都有要求,一般来说要求在50毫秒以内。如果有一个客户端网络卡了,所有的客户端都要停下来等,大家在玩星际争霸的时候,就见识过一家断线,全部人游戏暂停的样子了。腾讯游戏中的《王者荣耀》《全民突击》由于竞技性非常强,所以采用了这种方案。

玩家实时沟通

在传统的端游中,玩家在游戏过程中往往会通过键盘打字沟通。后来有一些语音聊天软件,比如YY,充当了游戏过程中实时沟通的工具。在实时对战的游戏中,和队友的配合往往是游戏的重要乐趣来源,因此实时的沟通非常重要。所谓的“开黑”,就是表示一个沟通良好的游戏伙伴小组,一起和其他玩家对战,顺畅的沟通能带给玩家巨大的竞技优势。然而,在手机游戏中,屏幕一般都比较小,不可能有空间来让玩家打字输入,况且如此激烈的实时战斗,也没有时间去慢慢的打字。因此自然很多人想到像PC上一样,运行一些实时聊天的语音软件,来辅助游戏沟通。但是手机操作系统和Windows不一样,在手机上运行的后台软件,除了会严重降低手机运行性能外,还可能被操作系统暂停和关闭。所以游戏+语音工具的路子是走不通的。这时,就需要游戏开发团队,为玩家在游戏中,直接提供实时语音的服务。

腾讯由于率先大规模进入实时对战领域,所以很早就发现了语音的需求。因此首先开始在游戏中集成语音服务,除了实时的聊天能力外,还提供了语音转文字、语音留言等多种功能,让玩家能在手机上也实时顺畅的沟通。随着实时对战的规模越来越大,腾讯还实现了高达十万人的语音聊天房间,如此大规模的聊天房间,有赖于语音服务的低码率、低功耗、低崩溃特性。现在除了游戏领域,在其他的领域,如体育视频转播、在线教育,都开始使用这个产自游戏的语音服务了。

从游戏语音服务的市场效果来看,腾讯大力开发这个服务是非常值得的。因为我们统计在MOBA类游戏中,有30%的玩家会主动说话,每人单局的语音会超过30秒,累计用过语言的玩家超过85%——这些数据都说明了语音服务是实时对战游戏的必备特性。所以腾讯在所有32款对战游戏中,都加入了语音服务。

版本更新问题

手机游戏的版本更新问题由来已久,大家都知道要推用户升级手机上的程序是不容易的。由于手机内存小,更新的过程很容易崩溃;移动设备的网络很不稳定,经常下载到一半,用户走出了wifi范围或者进了电梯,网络中断了。iOS的版本审核也是一个很大的问题,什么时候能审核通过往往不能预测,对于紧急的BUG来说更是远水救不了近火。然而,实时对战游戏由于强调竞技性,所以玩法逻辑常常需要调整优化;并且实时对战的玩法内容需要持续更新,所以经常都需要更新很多程序,在现有的条件下,如果只是简单的按部就班发版本,估计玩家早就跑光了。

我们发现,如果在游戏内进行资源更新,是可以做到99.5%以上的成功率的。但是,如果要发布一个程序包版本的更新,成功率往往就会跌至90%以下。所以每次发布版本,几乎在线人数都要下降10%,这对于游戏运营来说,是一个巨大而持久的损失。因此,我们就想,能不能把程序版本更新,变成游戏资源更新呢?答案是可以的,只要把程序代码,以脚本来编写,然后使用一个优秀的脚本解析器来运行,就能让程序代码以文本资源的形式,和图片、声音等其他游戏资源一样更新下载了。于是我们开发了xLua执行库,这个库能在Unity3D引擎中运行lua脚本,并且其执行的效率非常高,还能无缝的在脚本中调用游戏引擎的API。这样,我们就可以尽量少的发布新的程序版本,大部分的游戏内容玩法调整,都使用lua脚本更新来实现。由于使用了资源更新的方式来更新游戏,现在腾讯的程序更新率已经达到99.8%左右。

验证问题

游戏的外挂和破解,一直是国内游戏市场的痼疾。在实时对战的游戏中,这种破坏性的程序,更是创造出各种花样。比如有穿墙、加速的外挂,还有通过协议破解刷奖励的代理,以及自动机器人反复刷战斗。对此,我们花了很大力气,从游戏的内部结构上,对抗这些破坏游戏性的行为。现在比较常用的手段有四种:

一是服务器驱动。在传统的端游项目中,大部分的游戏逻辑,都是由服务器控制的,所以外挂能攻击的空间比较小。在实时对战的同步模型中,服务器驱动的MMOG模型,也是最好的对抗外挂的方法。这种方案由于逻辑全部在服务器上运算,所以外挂几乎无法从游戏逻辑中得到任何好处,只能在降低玩家操作难度上想办法。但是这种服务器驱动的方案,代价也是高昂的,服务器需要保存整个游戏世界的模型,并且演算所有的AI逻辑,这让服务器所消耗的硬件资源很多,也增加了服务器架构的复杂性和维护难度。这种模型还会降低玩家的实时性感受,因为总是要等待服务器的结果。

第二种是MonoSvr抽查回放。这种方法是在第一种服务器驱动方案上的一种简化,也就是说客户端还是会上传所有的游戏操作,但服务器并不完全的演算整个战斗逻辑,仅仅是对容易被外挂攻击的部分进行验证,这种做法让服务器上仅保留部分世界模型即可,降低了服务器的运算量。更重要的,客户端并不需要等待服务器的命令回复,就可以先按自己的逻辑去运行,体验上有更好的表现,如果服务器发现了作弊,再惩罚相关的帐号就可以了。这种做法实际上也是有漏洞的,因为那些没有被抽查到的客户端,或者没有被验证的逻辑,都可能是外挂攻击的漏洞,但是付出了这种代价后,得到的是服务器性能消耗和体验上的好处。

第三种是柔性反外挂。这种方法的校验更加简单,仅仅在服务器上保留了一批预设的校验规则,这些规则可能仅仅是核算玩家的收益和付出是否合理,一些重点操作是否符合规则。这种方案服务器的压力非常的轻,玩家的体验也会很好,因为验算的过程大大的加快了,验证的位置也往往被减少到玩家收益的时候。不过这种方法的漏洞更加多,一旦外挂熟悉了这些预设的校验规则,就很容易进行针对性的攻击,这种对抗可能会延续很久。

第四种是举报系统。这种方法简单来说就是人民战争,让玩家发起举报请求,然后服务器再搜集模拟被举报者的行为证据,进行针对性的验证和惩罚。这种民不举官不究的做法,很容易被有意识的互刷所利用。但是从对抗的角度来说,发动玩家一起来做验证举报,实际上也是一个程序运行机制的扩展。这种方案有一定的漏报几率,因此往往是作为其他几种验证机制的后备机制,一起使用。

以上四种,在腾讯的游戏中,往往都是结合起来使用。在实时对战游戏中,我们除了要关注验证的准确性外,同时还需要平衡游戏体验。因此往往需要在很多地方做妥协,但是只要我们有足够多的手段复合使用,真正的漏网之鱼还是很少的。

实时对战游戏的开发,一般需要涉及大量的技术开发工作。除了上面说的几个重点问题外,还有其他很多技术问题需要解决。腾讯的自研游戏,一般都会使用历史积累下来的大量基础服务、框架和组件。这些经过长期考验的基础服务,能大大的减少游戏的开发工作量,提供稳定的技术支持。为了让所有的游戏开发者,都能享受腾讯工作室使用的这些优秀基础服务,腾讯IEG研发部把这些基础框架和服务,整合成“腾讯游戏服务”,在http://gcloud.qq.com/上公开提供给业界共享。这些服务分为“接入服务”“逻辑服务”“数据服务”“运营平台”四大类型,分别解决游戏开发中大量共性问题。

感谢大家的阅读,如觉得此文对你有那么一丁点的作用,麻烦动动手指转发或分享至朋友圈。如有不同意见,欢迎后台留言探讨。

原文发布于微信公众号 - 韩大(handa1740168)

原文发表时间:2016-03-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏人称T客

MDM(移动设备管理)国内和国外厂商技术比较差距明显

最近总有人说国内的MDM和国外MDM差距不大,两者功能半斤八两,实则不然,国内MDM厂商起步较晚,在技术上还无法与国外厂商相媲美,从黑莓时代国外就开始专注MDM...

3207
来自专栏互联网数据官iCDO

109个提高App下载量的营销策略(上)

引言:本文介绍了如何提高APP下载量的109个适用的营销策略中的前36个策略,本系列全长共109个策略。

1055
来自专栏程序你好

DevSecOps的三种解读

771
来自专栏人称T客

APP终结者 誓言还是谎言?

“未来是重前端轻后端的天下”,你没有听错,这是云适配CEO陈本峰给企业移动化的重新定义,但对于这个说法T哥还是持保留意见,因为一直被大家宣贯的轻前端重后端在云适...

3598
来自专栏企鹅号快讯

初识java

一、JAVA的由来 Java的发展历程充满了传奇色彩。最初,Java是由Sun公司的一个研究小组开发出来的,该小组起先的目标是想用软件实现对家用电器进行集成控制...

18010
来自专栏后端技术探索

漫谈大型网站架构

作者介绍:陈康贤(花名龙隆),淘宝技术部技术专家,著有《大型分布式网站架构设计与实践》一书,在分布式系统架构设计、高并发系统设计、系统稳定性保障等领域积累了较为...

551
来自专栏TechBox

一篇文章汇总WWDC2016(图文详解)声明前言一、眼花缭乱的iOS 10二、名正言顺的macOS三、深度呼吸的watchOS四、语音遥控的tvOS总结图文详解

992
来自专栏知晓程序

对小程序有意见?这一次,腾讯爸爸给你一次吐槽的机会 | 亲儿子 #29

知晓程序在过去一年,收到了许多用户对推荐过的小程序的不少反馈,其中很多反馈都会加一句「找不到哪里跟开发者说,就在文章里给你们留言吧」。

1034
来自专栏Golang语言社区

技术干货分享:如何选择 HTML5 游戏引擎

原生手游市场已是红海,腾讯、网易等寡头独霸天下,H5游戏市场或将成为下一个风口。据笔者所知,很多H5游戏开发团队由于选择引擎不慎导致项目甚至团队夭折。如何选择适...

2859
来自专栏华章科技

大数据除了Hadoop,还有Scrapy

互联网+概念的兴起,中国的创业者几乎把互联网+这趟车开进了所有领域,传统领域的商家人心惶惶,言必谈互联网+,仿佛不套点互联网的概念都不好意思宣传自家产品;而赶在...

642

扫码关注云+社区