游戏后台开发九问(腾讯技术分享实录)

[导读]腾讯游戏讯,7月30日消息,第九届中国游戏商务大会网页游戏论坛30日在上海浦东嘉里大酒店展进行相关主题论坛活动。

30日,在上海chinajoy嘉里酒店进行了游戏开发者大会,腾讯游戏的研发部助力总经理聂志明进行了演讲。

>

他为大家演讲的题目是“游戏后台开发中的九个选择”,他解释,使用这个标题的原因,是因为我们在生活中总会遇到很多选择,这个道理同样适用在游戏开发中。

>

这九个选择分别是:

第一,选择什么样的架构。

第二,选择单线程还是多线程。

第三,如何在游戏中使用脚本。

第四,如何处理网络通讯。

第五,如何处理游戏通信协议。

第六,如何设计存储结构。

第七,如何设计网络同步。

第八,如何定义性能基准。

第九,如何在不同项目间进行代码复用。

聂志明先生在他的PPT里详细地为大家讲解了这九个问题,具体情况请参看演讲实录。

以下是演讲实录:

聂志明:大家好!我们现在开始演讲,我先自我介绍,我是腾讯游戏研发部助理总经理。我今天的题目是“游戏后台开发中的九个选择”,为什么用这个题目?在生活中我们
有很多选择,对这些选择的不同处理方式会决定不同的品质,我们在游戏开发里面会遇到很多选择,我今天说九个,但不一定每个人都碰得到,我在这里会把一些经验给大家分享
一下。

>

首先介绍一下在腾讯开发跟别的公司会有不同,在我内部遵从两个岗位,每个公司里面是按照不同模块来分。为什么会这样分?前台是通过便,后台讲究的是不便,我们不是
追求新的技术,而是解决问题。

>

下面我开始演讲,这是北京最盛名的一座桥,每次都不知道怎么走,越来越复杂。我们每天都会遇到很多选择,所以导致人也不是很愉快。

>

我现在来讲九个选择,从Q1到Q9,后面一一按照这个顺序做个阐述。


第一,选择什么样的架构?

其实是SNS特点决定的,不同的特点决定不同的架构。玩发围绕的是玩家之间偏真实的关系链,位置对玩家是不重要的,玩家之间没有物理上的距离概念,SNSGame
是大世界的模式,通用大世界方案的系统必须平行发展。MMO的特点,前几年是一个发展重点,很多人了解也不是很多,它的特点是存在世界地图,位置很重要,有地形概念,
每个玩家都有自己的物理坐标。交互频繁,逻辑复杂,交互的实时性要求高,严重依赖于预先设计的游戏内容。小世界有小世界的好处。第一易于就近部署及,减轻国内网络复杂
与MMO对网络要求高的矛盾。大家知道网络有很多问题,大家知道问题也解决不了。对MMO来讲,是一个很高的类型,所以会用小世界。

>

通过分区服务,降低了因为架构导致的运营问题的严重性,小世界的内部在架构上也需要有一定的可伸缩性,这取决于游戏的设计。并不是所有的小世界只有一台服务器搞定
,因为它的元素、它的特点对它也会有不同的要求。

>

在我选择这种架构的时候,我们会有原则,选择什么样的架构取决于游戏自身的设计,这取决于某些特点,并不是所有服务都有同样的需求,并不是大世界就好,小世界就不
行。我们不从纯技术角度追求大世界的架构,大世界需要游戏内容的支持,通常美术策划无法支撑百万在线的世界,这是最根本的原因。大世界在架构上有困难,但这是部分不可
克服的。

>

我讲大家非常熟悉的一个例子,通常最复杂的大区概念,大区通常是做帐号,服务器在服务器里面按角色区分。线,就是有的游戏有,有的游戏没有,在这些线里面只是为了
扩展这个世界的流量上线,线目前来说只是一个方便,这是一个样对复杂的示意部署视图(PPT)。

>

我们看一个架构,如果展开来讲,左边是一些辅助服务,右边的Worldsvr像公会的那种会放在这个里面,加在服务器上面,不同的游戏会有不同的处理。这是一个简
单的示意图,在不同的游戏里面会有不同的区分。


第二,选择单线程还是多线程?

不同的公司会有不同的做法,这个问题并不是所有人都碰到,也有个概率,但是大家也会有争论。争论的原因,通常是双方关注的重点不同,单线程程序的执行只有一条主线
,容易跟踪、调试和定位。我们腾讯也不是一定说要这样选择,我们理由非常理由,单线程加异步模式可以提供更好的性能,我们会选择单线程模式。现在我们游戏开发周期很长
,在漫长的运行周期里面每周都会更新,交接过程中会有问题的,使用多线程容易导致问题。这个时候我们会进行一些处理,我们对里面的要求角度来看,运行的周期很长、节奏
很快,为了达到要求我们可以想更简便的方式。

>

新形势,对我们也是有一些影响,现在有一些四核以上的CPU出现,这个时候我们会尝试把一些通用的服务,把相对固定的进程变成简单化,这是一个新趋势。

>

这是适应新趋势的原则,只在必须的时候才使用多多线程,如果使用了多线程,尽量减少线程间的交互需求,这样我们就好把握。


第三,如何在游戏中使用脚本?

在游戏开发中通常大家都会使用一些脚本。客户端对脚本的需求非常明显,这里主要讨论服务器端。两种使用脚本的方式:一种是C/C++的框架,主要逻辑用C/++编
写,脚本用来做一些局部扩展。C/C++的框架,主要逻辑用脚本来编写,耗性能的地方用C/C++决定的。

>

使用脚本的原则,脚本是一种胶水语言,通常用来隔离变化,易变化的逻辑用脚本实现,快速响应。一般情况下是说这个性能高,那个性能低,上面两种方法没有对错之分,
取决于两点,开发团队成员的能力,对不同语言的掌握程度;公司或者项目组的导向,偏重性能还是偏重开发速度,如果是创业型的团队,对性能方面要求多一些,怎么样把游戏
做好才是最重要的。


第四,如何处理网络通讯?

其实网络通信本身是非常复杂的事情,目前的开发环境已经提供了相对来讲简单得多的编程接口,但是网络程序还是需要处理很多的问题。

>

两种处理方式:一种是跟游戏服务器耦合带一起,游戏服务器既处理问落接入相关的逻辑,也处理游戏逻辑。一种是把网络通信部分剥离住来,向游戏服务器提供一种以消息
为单位的、非阻塞的、有Qos能力的中间服务,游戏服务器看不到网络的细节。

>

我们选择第二种好处,是基于这样的考虑,首先简化了游戏服务器的处理逻辑,降低了编程的难度。更易于提升后台整体的处理性能,不同部分可以独立的优化,因为它可以
不断的优化和在不同项目里面去继承的。

>

这是非常简单的一张示意图,我们会有一个界面,在客户端和服务器端给它不同的接口,会有不同的形式,看不到网络的问题,而且都是非阻塞的形式,面向消息的服务,类
似于有保障的、可持续的服务。


第五,如何处理游戏通信协议?

协议分两大类:文本协议和二进制协议,这是两个非常典型的例子,左边是UDP,非常高兴。右边是文本的协议,都是文字。文本协议直观,版本兼容性好,但是效率低。
其实对于游戏来讲,我们最好能够做到不同的版本都可以玩,不强调所有的客户端都去升级,这对运营商有非常强的周期,这对运营商来说有很大的挑战。版本兼容性问题其实是
我们在通信协议的时候,都需要重点考虑的。二进制协议效率高,但是不直观,版本兼容性处理相对复杂。

>

Web相关的游戏根据与浏览器交互的方式可能采用文本协议,基于效率原因,C/S类型的游戏通常采用二进制协议。

>

下面我会介绍腾讯的经验,游戏服务器是时钟消息和网络消息驱动的,大部分代码都是接受消息,或者接纳,其实有很多的解码、编码、代码占了相当大的比例。我们可以把
协议做一个区分,就变成一个消息的协议描述,然后生成工具,然后得到网络协议处理代码。

>

这是我们的做法,我们自己定义了一套协议描述方法,并实现了相应了工具集。我们这个协议重点会有所不同,在于高性能、与C/C++的无缝结合以及多协议版本共存能
力。利用我们这个版本来描述协议,不断在上面添加新的内容,但是其实可以进入到所有的低版本的客户端协议,不需要开发者做任何处理,它会自动生成。类似的方式大家可以
看Google protobuf orFacebook thrift。


第六,如何设计存储结构。

从游戏来讲,所有的在线游戏通常使用数据库来存储用户数据。通常MMO使用关系型数据库来存储数据,后面主要针对MMO进行存储方式的讨论。会有两种方式:一种是
把游戏的每一个数据对象的属性看成一个单独字段,遵循RDBMS的要求来设计数据库表和索引,尽量符合3NF。以MMO为例,有帐号表、角色基本信息表、物品表、装备
表等等,这是一种方式。

>

还有一种方式更具体,角色的列表类数据尽量采用blob来存储而不是另一个表。原则是这些列表数据只被角色自身所拥有,就是这个玩家所拥有,其他玩家不会拥有个数
据,它的生命周期跟玩家是一致的,不存在其他的交叉拥有情况,技能、物品、装备、任务、好友等等都属于这种情况。

>

优点是存储表结构简单,通常几张表就可以玩一个游戏,不超过10个。存取交互简单,角色登录或者推出时通常只需要存取一到二条记录。同一个角色的数据易于保持一致
,易于多版本数据共存。我们把这些数据存到数据库的时候,会把编码存到数据库里面。所以在数据库里面做完的数据可能会不一样,不过不会影响,它会共存。

>

这种方式也会有缺点,数据维护工具、客服工具实现相对复杂,需要提供特殊的API来操作数据。如果手上工具是通用的,可能比以前要直白一点。某些类型的统计相对要
麻烦一些,有些常用的数据,比如说角色的等级,在这方面可以用一些方式解决你的问题。

>

>
举个例子,在MMOG这块,存储角色的概要信息,包括名字、基本属性等,用于显示角色列表和防止重名。还有存储角色的详细信息,存储帐号的仓库信息,存储公会的信息。

>

新趋势的影响,就是Nosql数据库,性能高,存在好的开源实现,游戏的数据访问多为唯一键访问,很少复杂的Query,符合Nosql数据库的特点。后面在游戏
应用上,可能也会涉及到。


第七,如何设计网络同步?

网络同步面临的主要问题:第一如何减少网络波动对同步的影响;第二如何减少外挂对同步的破坏。如果没有外挂,网络几大问题没有服务器去运行。这两个问题单独都好解
决,但是在一起比较难解决。我们解决这两个问题,会遵循几个原则:第一网络条件好的玩家获得好的体验;第二网络条件差的玩家尽可能获得好一些的体验,但不能拖累其他玩
家的体验;第三外挂不能在网络同步方面获得持续的好处。对外挂方面,玩一个游戏是一个人,或者说非人类不清楚,所以说外挂不能在网络同步获得持续的好处。

>

为了解决问题我们有一些基本方法:首先要探测玩家的网络质量;第二在玩家机器与服务器之间进行时钟同步;第三基于游戏特点,设计合理的同步机制。像竞技类的游戏,
都是根据它的某些特点决定的,这是需要我们权衡考虑的。这里强调一点,在外挂获得好处,跟玩家体验时间做一个折中,你要保证外挂持续得到源源不断的好处,这样外挂就会
上去。对于探测、时钟同步都需要控制好。


第八,如何定义性能基准?

做游戏开发通常不太注重事先对于性能的规划,多以结果作为目标,基本上是看后来测试出来的性能,能优化则优化。性能基准包括客户端和服务器,客户端的性能基准与游
戏的目标市场有关。在服务器当中我们可以分析出来服务器能支撑多少用户?我们分解一下,制约性能的因素,网络IO/磁盘IO/内存/CPU。

>

具体的方法,可以通过经验的方式,或者计算的方式来确确定理论上限。网络IO,可以分析,取悦于由游戏类型、游戏设计所形成的业务模型,可估算。内存,相对来讲更
简单,取决于用到的主要数据结构,相对来讲更聚焦,更能估算出来支撑多少人。CPU计算能力,其实也不是计算,需要更多对CPU的支撑,简单的方式,这个游戏取决于游
戏类型导致的逻辑复杂性。推过这三点,可以有一个目标,大概需要多少人。

>

我们的数据,以实时列MMOG来讲,单一物理服务器1CPU,2核心,支撑3000-4000在线。平均每用户流量12-20Kbps。


第九,如何在不同项目间进行代码复用?

当一个公司内在不止一个项目在开发、运营时,复用的想法的产生是自然而然的。简单的把上一个心目的可用代码拷贝过来自行维护是最简单的方式,但是会导致同一个功能
有N种实现变体,每个变体都解决一部分问题。把共用的代码收归一个杜立德组织来开发和维护,形成公共组件,能够解决上述的问题,但是又会带来新的问题。要解决这些问题
,也很难有一些具体的方法,有几个原则,以服务、进程、库来提供。提供充分的工具,满足调试、验证、部署、运营等需求,如果推广好对你有很大的关系。最后还有充分的提
供扩展能力,可以降低组件开发的压力。

我这边就讲到这里,九个问题,并不一定所有问题都会碰到,但希望这些问题对大家有所帮助。谢谢!

请赐予我钱进的动力吧~
0%