一种在线游戏千人同屏的实现方法以及客户端与流程

本发明涉及在线游戏的客户端设计领域，尤其是大型多人在线网络游戏的客户端设计领域。具体说是涉及如何设计大型多人在线网络游戏的客户端，使其能够在硬件配置不高的计算机终端实现多用户在同一地图地点范围登录。游戏，即实现大型多人在线游戏的千人同屏。

背景技术：

大型多人在线角色扮演游戏(massivemulti-playeronlinerole-playinggame，简称mmorpg)是网络游戏的一种，玩家扮演一个虚构角色，控制该角色进行相应的游戏活动。mmorpg具有一个持续的虚拟世界，该虚拟世界由运营商提供的主机式服务器运行，并不断演进。mmorpg分为客户端和服务器两部分，玩家从客户端通过互联网连接，登陆服务端后才能进行游戏。大型多人在线网络游戏在运行时，用户在客户端地图上可以任意活动，运行人数会远远超过fps、moba等类型游戏，同城竞技时往往会集中在某个地点pk，比如限时活动时点击某个npc，或争夺某个固定的据点，此时有超过一千人同时存在一个屏幕的需求，cpu计算压力、内存容量压力、显存绘制压力可能达到饱和，如果客户端处理不完善，应用程序就会崩溃闪退。

现有技术将一个场景切分成矩形网格区域，玩家只与场景所处位置的九宫格范围内玩家进行消息同步，以减少交互对象个数、保证游戏流畅运行。但由于场景内的角色由玩家自由控制，大量的角色可能聚集在同一个九宫格范围内，角色显示的上限不可控，仍然有可能超客户端运算能力特别是对某些硬件配置不高的用户，可能直接闪退出客户端。

技术实现要素：

为了解决现存的大型多人在线网络游戏客户端存在的上述问题，本发明提供一种实现千人同屏的方法，其主要包括以下步骤：

步骤1：采用aop横切技术实时收集客户端压力点信息。由于当同城竞技时往往会集中在某个地点pk，比如限时活动时点击某个npc，或争夺某个固定的据点，此时有超过一千人同时存在一个屏幕，需要绘制大量的数据，对客户端显存，内存，显存和内存之间的带宽，cpu处理能力形成非常大的压力，一旦硬件的承压能力，就可能直接闪退出客户端。因此，用于收集内存、显存，内存到显卡的带宽、cpu等相关硬件资源的占用率等相关压力信息的aop横切模块需要优先启动，并在峰值时释放部分人物以外的资源。

步骤2：对资源进行分类加载，并按照策划对游戏的定义进行优先级分类，建立相关的分类号。游戏中的资源包括视频、音频、图片，配置文件等，可将各种资源分类为实时资源，延时加载资源、特效、界面，角色人物等，然后按照策划对游戏的定义做优先级分类，例如实时资源的优先级高于延时资源，特效的优先级低于延时加载资源等。若实时资源要在主线程中加载并加入缓存，可延时资源要在子线程中加载并在结束时回调通知主线程(界面窗口除外)。资源处理按队列顺序进行，所有操作都封装为自定义事件，不能直接调用函数。线程同步要根据业务环境选取互斥、事件、信号量、临界区。

步骤3：对具体分类号对应的资源建立文件加载缓存、并作引用计数，根据用户机器运行时实际内存容量做lifo处理。对相关分类资源的引用进行计数，对于从未被引用计数为0、或者长时间不用的资源进行清理，释放缓存，并在峰值时释放部分人物以外的资源。

步骤4：角色动画进行优化后按动作帧序列缓存，并按照方向做索引。实际客户端设计中可以采用九宫格ui图，采用镜像动作图片、例如左右共用一张图，影子图通过人物图斜拉压倒计算出来。最常用的角色动画要缓存动作帧，并在提交时打入队列，由绘制队列提交给显卡。角色上绑定的武器、头发、首饰、染色区等要同角色一起做动作帧缓存。

步骤5：综合产生组合的资源，按照层级划分后再按面积大小、声音时长再做细分。游戏里面我们看见的东西，其实都是有严格的层级划分的，比如人物站在场景上面，而ui又在人物上面，这就是底层，中层，上层这样一个层级关系。当将资源按照层级进行划分后，在根据面积大小、声音时长进行细分，例如后特效遮罩前特效。

步骤6：采用绘制队列对渲染对象进行排序，根据收集到的相关压力点信息筛选留下必要的部分，优化播放的层级，采用覆盖模式和丢弃模式提交显卡进行批量渲染。例如可以根据收集到的客户端显内、内存到显存之间的带宽信息等进行相关的筛选，优化处理。显卡的内存不同与内存，使用显存资源要平衡，注意从内存到显存的带宽限制，提交绘制时不要满载，注意选择覆盖模式和丢弃模式。最常用的角色动画要缓存动作帧，并在提交时打入队列，由绘制队列提交给显卡。角色上绑定的武器、头发、首饰、染色区等要同角色一起做动作帧缓存。同时采用绘制队列对渲染对象进行排序，下层的角色可适当不绘制。dipzone(底区)可以适当裁剪边缘区域，留下必要的区域信息进行绘制。特效部分，需要额外处理。当地图某个地点出现多个特效时，按提交顺序后者将覆盖前者，那么只提交后者若干次特效，前者就可以不提交不绘制，节省的内存和显存给其他缓存使用，而不影响视觉感官。灵活的绘制队列，要根据硬件环境设定的容量，当一个批次中绘制顶点达到限定后直接提交给显卡，或在未满情况下延迟30ms提交，这样采用队列进行批量提交绘制而不会影响视觉渐变。同时可以将同一角色放在同一图集(atlas)中，以减少调用接口进行绘制(drawcall)的次数。

附图说明

图1为本发明采用aop横切实现客户端的原理框图；

图2为本发明实现游戏客户端的组织架构图。

具体实施方式

为了使本发明所解决的技术问题、技术方案以及有益效果更加清楚明白，以下结合附图对本发明进行进一步详细说明。应该理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，本发明提供一种在线游戏千人同屏的实现方法以及客户端，如图1所示的本发明中的客户端的aop横切原理图。

其中对应于内存处理器的内存处理模块对资源进行分类加载，并按照策划对游戏的定义进行优先级分类，建立相关的分类号；对具体分类号对应的资源建立文件加载缓存、并作引用计数，根据用户机器运行时实际内存容量做lifo处理；角色动画进行优化后按动作帧序列缓存，并按照方向做索引；综合产生组合的资源，按照层级划分后再按面积大小、声音时长再做细分。如图1所述将资源分为实时资源、延时资源、角色，视频、图片等，实时资源要在主线程中加载并加入缓存，可延时资源要在子线程中加载并在结束时回调通知主线程(界面窗口除外)。资源处理按队列顺序进行，所有操作都封装为自定义事件，不能直接调用函数。线程同步要根据业务环境选取互斥、事件、信号量、临界区。并对相关资源的数量以及资源引用进行计数。根据运行中实际内存的消耗进行预警，对从来不曾引用计数为0或者长时间不用的资源进行清理，释放缓存，并在峰值时释放部分人物以外的资源。游戏里面我们看见的东西，其实都是有严格的层级划分的，比如人物站在场景上面，而ui又在人物上面，这就是底层，中层，上层这样一个层级关系。当将属于相关层级的资源进行划分后，在根据面积大小、声音时长进行细分，例如后特效遮罩前特效。

其中对应于cpu处理器的cpu处理模块执行代码实时收集客户端计算机的磁盘文件吞吐等压力点信息，执行多核多线程峰值处理，以及cpu预警。由于当同城竞技时往往会集中在某个地点pk，比如限时活动时点击某个npc，或争夺某个固定的据点，此时有超过一千人同时存在一个屏幕，需要绘制大量的数据，cpu需要将相关的绘制数据提交给显卡，此时对cpu处理能力形成非常大的压力，一旦超过硬件的承压能力，就可能直接闪退出客户端。因此，需要设置cpu处理模块对磁盘文件吞吐、多核多线程的峰值进行监测并做相关的处理，并当cpu的负荷达到/超过预设的阈值时进行峰值前预警。

其中对应于显卡处理器的显示处理模块采用渲染组、渲染队列对渲染对象进行排序，根据收集到的客户端显内、内存到显存之间的带宽信息筛选留下必要的部分，优化播放的层级，采用覆盖模式和丢弃模式提交显卡进行批量渲染。显卡的内存不同与内存，使用显存资源要平衡，注意从内存到显存的带宽限制，提交绘制时不要满载，注意选择覆盖模式和丢弃模式。最常用的角色动画要缓存动作帧，并在提交时打入队列，由绘制队列提交给显卡。角色上绑定的武器、头发、首饰、染色区等要同角色一起做动作帧缓存。同时采用绘制队列对渲染对象进行排序，下层的角色可适当不绘制。dipzone(底区)可以适当裁剪边缘区域，留下必要的区域信息进行绘制。特效部分，需要额外处理。当地图某个地点出现多个特效时，按提交顺序后者将覆盖前者，那么只提交后者若干次特效，前者就可以不提交不绘制，节省的内存和显存给其他缓存使用，而不影响视觉感官。灵活的绘制队列，要根据硬件环境设定的容量，当一个批次中绘制顶点达到限定后直接提交给显卡，或在未满情况下延迟30ms提交，这样采用队列进行批量提交绘制而不会影响视觉渐变。同时可以将同一角色放在同一图集(atlas)中，以减少调用接口进行绘制(drawcall)的次数。

值得注意的是当占用资源无可释放时，才在视觉上做局部优化，是短时间对内存和显存的妥协。在视觉允许范围内，在短时间内降低帧率，能跨过比较消耗资源的短时过程。图像资源色位的降低，高分辨率的资源会消耗更多资源，动态降低使内存能容纳更多纹理，这个操作交给显卡，类似自定义纹理采样级别。

如图2为本发明实现游戏客户端的组织架构图。如图所示客户端主要包括主线程模块(mainthread)，io线程模块(iothread)以及用于和服务器进行通信的通信线程模块(communicationthread)。其中线程之间根据业务环境选取互斥(mutex)、事件、信号量(semaphores)、临界区进行同步。

其中io线程模块主要读取io文件池(iofilespool)中的自定义操作文件对资源进行加载，对资源进行分类加载，并按照策划对游戏的定义进行优先级分类，建立相关的分类号；对具体分类号对应的资源建立文件加载缓存、并作引用计数，根据用户机器运行时实际内存容量做lifo处理；角色动画进行优化后按动作帧序列缓存，并按照方向做索引；综合产生组合的资源，按照层级划分后再按面积大小、声音时长再做细分。如图2中所述所述的资源分类包括ui资源(读取于uipool)、角色动作帧资源(角色上绑定的武器、头发、首饰、染色区等要同角色一起做动作帧缓存)(读取于roleframepool中)、以及特效资源(读取于effectspool)。

主线程模块(mainthread)主要执行各模块的管理(modulemanager)，对原始的绘图资源(drawprimitive)进行逻辑处理(logicprocess)以及其他的工作(others)，例如包括对实时资源进行加载，实时收集客户端内存、显存，内存到显卡的带宽、cpu占用率等压力点信息。

对磁盘文件吞吐、多核多线程的峰值进行监测并做相关的处理，并当cpu的负荷达到/超过预设的阈值时进行峰值前预警。逻辑处理部分(logicprocess)主要采用绘制队列对渲染对象进行排序，根据收集到的客户端显内、内存到显存之间的带宽信息筛选留下必要的部分，优化播放的层级，采用覆盖模式和丢弃模式提交显卡进行批量渲染。采用绘制队列对渲染对象进行排序，下层的角色可适当不绘制。dipzone(底区)可以适当裁剪边缘区域，留下必要的区域信息进行绘制。特效部分，需要额外处理。当地图某个地点出现多个特效时，按提交顺序后者将覆盖前者，那么只提交后者若干次特效，前者就可以不提交不绘制，节省的内存和显存给其他缓存使用，而不影响视觉感官。灵活的绘制队列，要根据硬件环境设定的容量，当一个批次中绘制顶点达到限定后直接提交给显卡，或在未满情况下延迟30ms提交，这样采用队列进行批量提交绘制而不会影响视觉渐变。同时可以将同一角色放在同一图集(atlas)中，以减少调用接口进行绘制(drawcall)的次数。

通信线程模块(communicationthread)主要通过网络实时获取服务器信息(severmessage)，包括游戏中其他玩家/其他角色的位置，动作，特效等其他需要显示在屏幕中游戏地图的信息，以便实现多人在线进行游戏。通信线程与游戏服务器可以通过用户协议进行通信，例如tcp、udp通信协议等。

本发明提供的客户端能够进行实时平衡负载处理，采用aop横切收集客户端压力点信息，并及时做出调整，牺牲冗余消耗资源的事件，架构设计使得结构清晰，运行时承载用户更多不会崩溃，能够更好地实现千人同屏。