掌桥专利:专业的专利平台
掌桥专利
首页

游戏中虚拟角色的数据处理方法、装置以及电子设备

文献发布时间:2023-06-19 16:06:26



技术领域

本公开涉及游戏技术领域,尤其是涉及一种游戏中虚拟角色的数据处理方法、装置以及电子设备。

背景技术

目前,帧同步是一种游戏中常用的同步方式,多用于虚拟角色少、单局时间短,但对公平性与一致性要求高的游戏,例如格斗、第一人称射击(First-person shooting,FPS)、多人在线战术竞技(Multiplayer Online Battle Arena,MOBA)等。它与传统状态同步最大的区别是将战斗逻辑放到了客户端。例如,客户端需要根据收到的指令进行一系列技能、攻击、移动、碰撞、人工智能(Artificial Intelligence,AI)等的计算。

但是,对于现有的这种虚拟角色的数据处理方法,客户端进行各种计算使数据处理量较大,导致客户端的运行压力较大。

发明内容

本公开的目的在于提供一种游戏中虚拟角色的数据处理方法、装置以及电子设备,以缓解客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

第一方面,本公开实施例提供了一种游戏中虚拟角色的数据处理方法,所述游戏的游戏场景中包含通过第一客户端控制的第一虚拟角色,所述方法包括:

基于所述第一客户端对所述第一虚拟角色的控制指令,确定所述第一虚拟角色执行所述控制指令过程中生成的游戏状态数据;

将所述游戏状态数据封装为状态帧;

将所述状态帧发送至服务端,以使所述服务端将所述状态帧发送至第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可能的实现中,所述游戏状态数据包括下述任意一项或多项:

所述第一虚拟角色的状态数据、所述游戏场景中除所述第一虚拟角色以外的其他虚拟角色的状态数据以及其他虚拟物体的状态数据。

在一个可能的实现中,所述服务端对应有多个所述游戏场景;还包括:

确定所述第一虚拟角色所处的目标游戏场景;

将所述目标游戏场景的数据发送至所述服务端,以使所述服务端将所述状态帧发送至所述第二客户端;其中,所述第二客户端控制的第二虚拟角色为处于所述目标游戏场景中除所述第一虚拟角色之外的其他虚拟角色。

在一个可能的实现中,所述游戏场景中包含多个场景区域,每个所述场景区域对应有区域标识;

所述将所述目标游戏场景的数据发送至所述服务端,以使所述服务端将所述状态帧发送至所述第二客户端的步骤,包括:

将所述目标游戏场景的数据以及目标场景区域对应的目标区域标识发送至所述服务端,以使所述服务端根据所述目标游戏场景的数据确定所述第一虚拟角色所处的所述目标游戏场景以及根据所述目标区域标识确定所述目标场景区域,并将所述目标场景区域对应的目标状态帧发送至所述第二客户端。

在一个可能的实现中,所述状态帧以数据包的形式被发送至所述服务端;所述将所述状态帧发送至服务端的步骤之前,还包括:

确定所述状态帧中发生变化的数据;

将所述状态帧中发生变化的数据打入所述数据包的包体。

在一个可能的实现中,所述状态帧以数据包的形式被发送至所述服务端;每个所述数据包中包含指定帧数的状态帧;

所述游戏画面在所述第二客户端上以指定帧率显示;其中,所述指定帧率为每秒所述指定帧数。

在一个可能的实现中,所述游戏状态数据包括下述任意一项或多项:

所述游戏中的移动状态数据、碰撞状态数据、位置状态数据。

第二方面,本公开实施例提供了一种游戏中虚拟角色的数据处理方法,应用于服务端,所述游戏的游戏场景中包含通过第一客户端控制的第一虚拟角色;所述方法包括:

获取所述第一客户端发送的状态帧;其中,所述状态帧为所述第一客户端对游戏状态数据进行封装而得到,所述游戏状态数据为所述第一虚拟角色执行所述第一客户端的控制指令过程中生成的游戏状态数据;

确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色;

将所述状态帧发送至所述第二虚拟角色对应的第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可能的实现中,所述确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色的步骤,包括:

获取各个客户端发送的场景标识;其中,所述场景标识用于表示所述客户端控制的虚拟角色在所述游戏中所处的至少一个所述游戏场景;

基于多个所述虚拟角色所处的所述游戏场景确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色。

在一个可能的实现中,所述服务端对应有多个所述游戏场景,每个所述虚拟角色对应有多个游戏场景分配维度;

所述确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色的步骤,包括:

通过遍历所有所述游戏场景,确定所述多个游戏场景分配维度中每个所述游戏场景分配维度最优的游戏场景;

基于每个所述游戏场景分配维度的优先级,从所述游戏场景分配维度最优的游戏场景中确定所述第一虚拟角色所分配至的游戏场景以及与所述第一虚拟角色分配至相同游戏场景的第二虚拟角色。

在一个可能的实现中,所述游戏场景分配维度包括下述任意一项或多项:

所述虚拟角色的游戏习惯、角色等级以及角色活跃度。

在一个可能的实现中,所述第二虚拟角色的数量为多个,每个所述第二虚拟角色对应有游戏角色划分维度;

所述将所述状态帧发送至所述第二虚拟角色对应的第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面的步骤,包括:

通过所述游戏角色划分维度从多个所述第二虚拟角色中确定与所述第一虚拟角色划分为同类的目标第二虚拟角色;

将所述状态帧发送至所述目标第二虚拟角色对应的目标第二客户端,以在所述目标第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可能的实现中,所述游戏角色划分维度包括下述任意一项或多项:

所述虚拟角色的游戏习惯、角色等级以及角色活跃度。

第三方面,本公开实施例提供了一种游戏中虚拟角色的数据处理方法,所述游戏的同一游戏场景中包含通过第一客户端控制的第一虚拟角色以及通过第二客户端控制的第二虚拟角色,通过所述第二客户端提供图形用户界面;所述方法包括:

接收服务端发送的状态帧;其中,所述状态帧为所述第一客户端对游戏状态数据进行封装而得到,所述游戏状态数据为所述第一虚拟角色执行所述第一客户端的控制指令过程中生成的游戏状态数据;

在所述图形用户界面中显示所述游戏状态数据对应的游戏画面。

在一个可能的实现中,所述在所述图形用户界面中显示所述游戏状态数据对应的游戏画面的步骤,包括:

将所述游戏状态数据对应的游戏画面覆盖显示于所述图形用户界面中。

第四方面,提供了一种游戏中虚拟角色的数据处理装置,所述游戏的游戏场景中包含通过第一客户端控制的第一虚拟角色,所述装置包括:

确定模块,用于基于所述第一客户端对所述第一虚拟角色的控制指令,确定所述第一虚拟角色执行所述控制指令过程中生成的游戏状态数据;

封装模块,用于将所述游戏状态数据封装为状态帧;

发送模块,用于将所述状态帧发送至服务端,以使所述服务端将所述状态帧发送至第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面。

第五方面,提供了一种游戏中虚拟角色的数据处理装置,应用于服务端,所述游戏的游戏场景中包含通过第一客户端控制的第一虚拟角色;所述装置包括:

获取模块,用于获取所述第一客户端发送的状态帧;其中,所述状态帧为所述第一客户端对游戏状态数据进行封装而得到,所述游戏状态数据为所述第一虚拟角色执行所述第一客户端的控制指令过程中生成的游戏状态数据;

确定模块,用于确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色;

发送模块,用于将所述状态帧发送至所述第二虚拟角色对应的第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面。

第六方面,提供了一种游戏中虚拟角色的数据处理装置,所述游戏的同一游戏场景中包含通过第一客户端控制的第一虚拟角色以及通过第二客户端控制的第二虚拟角色,通过所述第二客户端提供图形用户界面;所述装置包括:

接收模块,用于接收服务端发送的状态帧;其中,所述状态帧为所述第一客户端对游戏状态数据进行封装而得到,所述游戏状态数据为所述第一虚拟角色执行所述第一客户端的控制指令过程中生成的游戏状态数据;

显示模块,用于在所述图形用户界面中显示所述游戏状态数据对应的游戏画面。

第七方面,本公开实施例又提供了一种电子设备,包括存储器、处理器,所述存储器中存储有可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述第一方面、第二方面以及第三方面所述的方法的步骤。

第八方面,本公开实施例又提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机可运行指令,所述计算机可运行指令在被处理器调用和运行时,所述计算机可运行指令促使所述处理器运行上述第一方面、第二方面以及第三方面所述的方法。

本公开实施例带来了以下有益效果:

本公开实施例提供的一种游戏中虚拟角色的数据处理方法、装置以及电子设备,首先基于第一客户端对第一虚拟角色的控制指令,确定第一虚拟角色执行控制指令过程中生成的游戏状态数据,之后将状态数据封装为状态帧,进而将状态帧发送至服务端,以使服务端将状态帧发送至第二客户端,以在第二客户端上显示游戏状态数据对应的游戏画面。本方案中,第一客户端可以将与其控制的第一虚拟角色相关的游戏状态数据封装为状态帧,再将该状态帧发送至服务端,进而通过服务端将状态帧同步至第二客户端,各个第二客户端便可以从服务端处获取并基于该状态帧直接显示出对应的游戏画面,状态帧解决了帧同步服务端没有任何游戏数据的问题,依然将计算交给客户端来处理,同时由于每个客户端只处理并上传服务器自身控制的虚拟角色相关的游戏状态数据,所以在收到其他客户端的数据时可直接绘图,使各客户端无需再进行一系列关于其他客户端控制的虚拟角色相关的游戏状态数据计算,有效降低了客户端的数据处理量和运行压力,缓解了客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

附图说明

为了更清楚地说明本公开具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本公开的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1为本公开实施例提供的应用场景示意图;

图2示出了本公开实施例提供的一种电子设备的结构示意图;

图3为本公开实施例提供的一种触控终端的使用场景示意图;

图4为本公开实施例提供的一种游戏中虚拟角色的数据处理方法的流程示意图;

图5为本公开实施例提供的一种帧同步效果示意图;

图6为本公开实施例提供的一种游戏场景划分示意图;

图7为本公开实施例提供的另一种游戏中虚拟角色的数据处理方法的流程示意图;

图8为本公开实施例提供的一种微服务设计示意图;

图9为本公开实施例提供的另一种游戏中虚拟角色的数据处理方法的流程示意图;

图10为本公开实施例提供的一种游戏中虚拟角色的数据处理装置的结构意图;

图11为本公开实施例提供的另一种游戏中虚拟角色的数据处理装置的结构意图;

图12为本公开实施例提供的另一种游戏中虚拟角色的数据处理装置的结构意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合附图对本公开的技术方案进行清楚、完整地描述,显然,所描述的实施例是本公开一部分实施例,而不是全部的实施例。基于本公开中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本公开保护的范围。

本公开实施例中所提到的术语“包括”和“具有”以及它们的任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括其他没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

目前的帧同步游戏一般都可以提供比较简单的社交系统,除了世界聊天、战队聊天、好友聊天外很少有一些特殊设计。而窗口聊天又有很多局限性,人数过多导致窗口滚动过快,很难找到自己感兴趣的话题,人数过少又可能非常冷清。假设存在一种社交广场,每个人都是一个可操作角色,可以在广场内随意走动、聊天。而聊天信息除了显示在聊天窗口中,也可以以泡泡的形式出现在人物头向上,让其他人一眼就能看到。玩家可以快速找到自己感兴趣的话题或者人,然后通过头顶泡泡聊天。用帧同步方案可以在一定程度上实现社交广场。例如,客户端按照每秒传输帧数(Frames Per Second,FPS)15帧的固定频率上传操作指令,服务端也按照FPS15的频率将数据广播给所有广场中的角色。客户端在收到自己或他人的指令后进行计算,并将结果绘制出来。这套方案与战斗内完全一致,其实就是在战斗的基础上增加聊天等社交功能。但这种方式需要消耗客户端大量计算力,原来人数控制在1-5个时还能承受,一旦超过10人客户端就将出现严重卡顿甚至闪退的情况。所以单纯使用帧同步无法支持大量同时在线。

帧同步是一种将计算压力分发给客户端的技术,计算压力将随着人数增加而成倍增加。而客户端能承载的压力上限是未知的,无法量化出一个游戏场景最多可以承载多少人。即使能量化出来,这个值也是很小的,无法满足大型多人社交的需求。由于使用这项技术,大量数据都在客户端本地缓存,服务端无法得知玩家操作角色的位置、状态,非玩家角色(Non-Player Character,NPC)状态和地图状态。所以若想以状态同步的方式实现社交广场,又需要客户端、服务端同时实现两种同步框架,不仅需要双倍的开发人力,又使得代码量翻倍,这对一个项目来说是非常不现实的。同时不管用什么技术,只要同时在线人数多,就无法避免流量大的问题。状态同步下有非常成熟的感兴趣区域(Area of Interest,AOI)方案,那么如何在帧同步下实现一种特殊AOI也是个问题。

基于此,本公开实施例提供了一种游戏中虚拟角色的数据处理方法、装置以及电子设备,通过本公开实施例提供的方法,每个客户端只需计算自己的数据,收到其他客户端的状态帧时可以直接绘图,服务端只负责转发。同时引入AOI技术,基于地图标签(Tag)的AOI设计可以在服务端没有数据的情况下得到客户端的感兴趣区域,从而分组下发状态帧,减少不必要的流量和计算消耗,进而缓解客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

在本公开其中一种实施例中,游戏中虚拟角色的数据处理方法可以运行于本地终端设备或者是服务器。当游戏中虚拟角色的数据处理方法运行于服务器时,该方法则可以基于云交互系统来实现与执行,其中,云交互系统包括服务器和客户端设备。

在一可选的实施方式中,云交互系统下可以运行各种云应用,例如:云游戏。以云游戏为例,云游戏是指以云计算为基础的游戏方式。在云游戏的运行模式下,游戏程序的运行主体和游戏画面呈现主体是分离的,游戏中虚拟角色的数据处理方法的储存与运行是在云游戏服务器上完成的,客户端设备的作用用于数据的接收、发送以及游戏画面的呈现,举例而言,客户端设备可以是靠近用户侧的具有数据传输功能的显示设备,如,移动终端、电视机、计算机、掌上电脑等;但是进行信息处理的为云端的云游戏服务器。在进行游戏时,玩家操作客户端设备向云游戏服务器发送操作指令,云游戏服务器根据操作指令运行游戏,将游戏画面等数据进行编码压缩,通过网络返回客户端设备,最后,通过客户端设备进行解码并输出游戏画面。

在一可选的实施方式中,以游戏为例,本地终端设备存储有游戏程序并用于呈现游戏画面。本地终端设备用于通过图形用户界面与玩家进行交互,即,常规的通过电子设备下载安装游戏程序并运行。该本地终端设备将图形用户界面提供给玩家的方式可以包括多种,例如,可以渲染显示在终端的显示屏上,或者,通过全息投影提供给玩家。举例而言,本地终端设备可以包括显示屏和处理器,该显示屏用于呈现图形用户界面,该图形用户界面包括游戏画面,该处理器用于运行该游戏、生成图形用户界面以及控制图形用户界面在显示屏上的显示。

在一种可能的实施方式中,本公开实施例提供了一种游戏中虚拟角色的数据处理方法,通过终端设备提供图形用户界面,其中,终端设备可以是前述提到的本地终端设备,也可以是前述提到的云交互系统中的客户端设备。

例如,如图1所示,图1为本公开实施例提供的应用场景示意图。该应用场景可以包括电子终端(例如,手机102)和服务器101,该电子终端可以通过有线网络或无线网络与服务器101进行通信。其中电子终端用于运行虚拟桌面,通过该虚拟桌面,可以与服务器101进行交互,以实现对服务器101中的虚拟角色进行控制。

本实施例的电子终端以手机102为例进行说明。手机102包括射频(RadioFrequency,RF)电路210、存储器220、触摸屏230、处理器240等部件。本领域技术人员可以理解,图2中示出的手机结构并不构成对手机的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。本领领域技术人员可以理解触摸屏230属于用户界面(User Interface,UI),且手机102可以包括比图示或者更少的用户界面。

RF电路210还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议,包括但不限于全球移动通讯系统(Global System of Mobilecommunication,GSM)、通用分组无线服务(General Packet Radio Service,GPRS)、码分多址(Code Division Multiple Access,CDMA)、宽带码分多址(Wideband Code DivisionMultiple Access,WCDMA)、长期演进(Long Term Evolution,LTE)、电子邮件、短消息服务(Short Messaging Service,SMS)等。

存储器220可用于存储软件程序以及模块,处理器240通过运行存储在存储器220的软件程序以及模块,从而执行手机102的各种功能应用以及数据处理。存储器220可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据手机102的使用所创建的数据等。此外,存储器220可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

触摸屏230可用于显示图形用户界面和接收用户针对图形用户界面的操作。具体的触摸屏230可包括显示面板和触控面板。其中显示面板可以采用液晶显示器(LiquidCrystal Display,LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置。触控面板可收集用户在其上或附近的接触或者非接触操作(例如,如图3所示,用户使用手指301、触笔等任何适合的物体或附件在触控面板上或在触控面板附近的操作),并生成预先设定的操作指令。另外,触控面板可包括触摸检测装置和触摸控制器两个部分。其中,触摸检测装置检测用户的触摸方位、姿势,并检测触摸操作带来的信号,将信号传送给触摸控制器;触摸控制器从触摸检测装置上接收触摸信息,并将它转换成处理器能够处理的信息,再送给处理器240,并能接收处理器240发来的命令并加以执行。此外,可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板,也可以采用未来发展的任何技术实现触控面板。进一步的,触控面板可覆盖显示面板,用户可以根据显示面板显示的图形用户界面,在显示面板上覆盖的触控面板上或者附近进行操作,触控面板检测到在其上或附近的操作后,传送给处理器240以确定用户输入,随后处理器240响应于用户输入在显示面板上提供相应的视觉输出。另外,触控面板与显示面板可以作为两个独立的部件来实现也可以集成而来实现。

处理器240是手机102的控制中心,利用各种接口和线路连接整个手机的各个部分,通过运行或执行存储在存储器220内的软件程序和/或模块,以及调用存储在存储器220内的数据,执行手机102的各种功能和处理数据,从而对手机进行整体监控。

下面结合附图对本公开实施例进行进一步地介绍。

图4为本公开实施例提供的一种游戏中虚拟角色的数据处理方法的流程示意图。其中,该方法可以应用于第一客户端(例如图2所示的手机102),游戏的游戏场景中包含通过第一客户端控制的第一虚拟角色。如图4所示,该方法包括:

步骤S410,基于第一客户端对第一虚拟角色的控制指令,确定第一虚拟角色执行控制指令过程中生成的游戏状态数据。

在实际应用中,第一客户端可以基于玩家通过第一客户端下达的针对第一虚拟角色的控制指令,确定第一虚拟角色执行控制指令过程中生成的游戏状态数据。

作为一种示例,游戏状态数据可以为第一虚拟角色的状态数据,例如,玩家通过第一客户端控制第一虚拟角色在游戏场景中进行移动、跳跃等动作,第一客户端可以将这些移动的距离、位置、跳跃高度以及是否与游戏场景中的地形发生碰撞等数据确定为游戏状态数据。

作为另一种示例,游戏状态数据可以为第一虚拟角色执行控制指令过程中导致的其他虚拟角色的状态数据,例如,玩家通过第一客户端控制第一虚拟角色对其他虚拟角色进行攻击,导致其他虚拟角色的生命值降低,第一客户端可以将这些数据确定为游戏状态数据。

作为另一种示例,游戏状态数据可以为第一虚拟角色执行控制指令过程中导致的其他虚拟物体的状态数据,例如,玩家通过第一客户端控制第一虚拟角色对虚拟建筑物进行攻击、对虚拟树木进行砍伐、打开游戏场景中的宝箱等等,第一客户端可以将这些数据确定为游戏状态数据。

步骤S420,将游戏状态数据封装为状态帧。

示例性的,如图5所示,第一客户端可以将第一虚拟角色在游戏场景中移动的距离位置、跳跃高度以及是否与游戏场景中的地形发生碰撞等状态数据封装为状态帧。例如,第一虚拟角色在第1单位时间的时候向右移动了1米,在第2单位时间的时候向右前方跳了一下,则第一客户端可以将这些动作记为游戏状态数据,并封装为状态帧。其中状态帧有别于帧同步和状态同步,服务端只转发不计算,通过帧同步的形式下发客户端状态信息。

步骤S430,将状态帧发送至服务端,以使服务端将状态帧发送至第二客户端,以在第二客户端上显示游戏状态数据对应的游戏画面。

示例性的,如图5所示,第一客户端将封装好的状态帧发送至服务端,通过服务端进行转发,将封装好的状态帧转发至第二客户端,使第二客户端基于状态帧中的内容进行绘图,进而对第一虚拟角色进行显示,即在第二客户端的图形用户界面中显示第一虚拟角色在第1单位时间的时候向右移动了1米,在第2单位时间的时候向右前方跳了一下。每个客户端只计算自己的移动、跳跃、碰撞等数据,并把最终计算结果封装成状态帧发给服务端。

本公开实施例中,第一客户端可以将与其控制的第一虚拟角色相关的游戏状态数据封装为状态帧,再将该状态帧发送至服务端,进而通过服务端将状态帧同步至第二客户端,各个第二客户端便可以从服务端处获取并基于该状态帧直接显示出对应的游戏画面,状态帧解决了帧同步服务端没有任何游戏数据的问题,依然将计算交给客户端来处理,同时由于每个客户端只处理并上传服务器自身控制的虚拟角色相关的游戏状态数据,所以在收到其他客户端的数据时可直接绘图,使各客户端无需再进行一系列关于其他客户端控制的虚拟角色相关的游戏状态数据计算,有效降低了客户端的数据处理量和运行压力,缓解了客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

下面对上述步骤进行详细介绍。

在一些实施例中,游戏状态数据可以包括多种类型,通过使游戏状态数据的类型包括多种,从而使第一客户端可以较为灵活的将多种游戏状态数据封装为状态帧,提高了可上传内容的丰富性,进而可以有效降低客户端的数据处理量和运行压力。示例性的,游戏状态数据包括下述任意一项或多项:

第一虚拟角色的状态数据、游戏场景中除第一虚拟角色以外的其他虚拟角色的状态数据以及其他虚拟物体的状态数据。

作为一种示例,游戏状态数据可以为第一虚拟角色的状态数据,例如,玩家通过第一客户端控制第一虚拟角色在游戏场景中进行移动、跳跃等动作,第一客户端可以将这些移动的距离、位置、跳跃高度以及是否与游戏场景中的地形发生碰撞等数据确定为游戏状态数据。

作为另一种示例,游戏状态数据可以为游戏场景中除第一虚拟角色以外的其他虚拟角色的状态数据,例如,玩家通过第一客户端控制第一虚拟角色对其他虚拟角色进行攻击,导致其他虚拟角色的生命值降低,第一客户端可以将这些数据确定为游戏状态数据。

作为另一种示例,游戏状态数据可以为其他虚拟物体的状态数据,例如,玩家通过第一客户端控制第一虚拟角色对虚拟建筑物进行攻击、对虚拟树木进行砍伐、打开游戏场景中的宝箱等等,第一客户端可以将这些数据确定为游戏状态数据。

通过使游戏状态数据的类型包括多种,从而使第一客户端可以较为灵活的将多种游戏状态数据封装为状态帧,提高了可上传内容的丰富性,进而可以有效降低客户端的数据处理量和运行压力。

在一些实施例中,客户端只显示一定范围内的场景区域中的虚拟角色,因此只需从服务端获取这些虚拟角色的状态帧,从而减少客户端的数据处理量,通过较为灵活的方式减轻客户端的运行压力,例如,游戏场景一般都远大于客户端屏幕,所以玩家的视野非常有限,服务端发送那些在玩家视野外的游戏数据是一种浪费,若能去掉这一部分数据则可以节省很多流量,可以通过将第一虚拟角色所处的目标场景区域的数据通过服务端发送至同一场景区域中对应的第二客户端,以使第二客户端可以接收到同区域内第一虚拟角色对应的状态帧,使其他场景区域对应的其他客户端无法接收到状态帧,减轻服务端的数据传输压力,减轻其他客户端的工作压力。作为一个示例,服务端对应有多个游戏场景;方法还包括:

步骤a),确定第一虚拟角色所处的目标游戏场景。

步骤b),将目标游戏场景的数据发送至服务端,以使服务端将状态帧发送至第二客户端。

对于上述步骤b),其中的第二客户端控制的第二虚拟角色为处于目标游戏场景中除第一虚拟角色之外的其他虚拟角色。

示例性的,如图6所示,游戏场景中可以包含多个场景区域,如虚线划分的9个不同的场景区域,第一客户端可以首先确定第一虚拟角色601在游戏场景中所处的目标场景区域,即中部偏左的场景区域。之后将中部偏左的场景区域的数据发送至服务端,使服务端将该场景区域对应的状态帧发送至所有同处于中部偏左的场景区域的,目标虚拟角色所对应的客户端。可以理解为,玩家只能看见同处于同一场景中的游戏内容,即玩家控制第一虚拟角色在中部偏左的场景区域中移动,则玩家只能看到中部偏左的场景区域中的游戏内容,同处于中部偏左的场景区域的其他玩家也只能看到中部偏左的场景区域中的游戏内容。

通过使第一客户端确定第一虚拟角色所处的目标游戏场景,之后将目标游戏场景的数据发送至服务端,以使服务端将状态帧发送至第二客户端,可以避免服务端发送多余无用的游戏数据。通过使客户端只上传以及绘制当前游戏场景下的游戏内容,避免无效的数据传输,减轻服务端的数据传输压力,减轻客户端的工作压力。

基于上述步骤a)和步骤b),可以通过区域标识的方式使服务端确定各个客户端对应的上述场景区域中的虚拟角色,例如,可以通过添加标识的方式对场景区域进行精准划分,从而准确的为对应的第二客户端发送状态帧,以使第二客户端可以接收到同区域内第一虚拟角色对应的状态帧,使场景标识不同的其他场景区域对应的其他客户端无法接收到状态帧,减轻服务端的数据传输压力,减轻其他客户端的工作压力。作为一个示例,游戏场景中包含多个场景区域,每个场景区域对应有区域标识;上述步骤b)可以具体包括如下步骤:

步骤c),将目标游戏场景的数据以及目标场景区域对应的目标区域标识发送至服务端,以使服务端根据目标游戏场景的数据确定第一虚拟角色所处的目标游戏场景以及根据目标区域标识确定目标场景区域,并将目标场景区域对应的目标状态帧发送至第二客户端。

示例性的,如图6所示,游戏中每个场景区域都对应有独特的区域标识,例如将中部偏左的场景区域标识为00001,将中部的场景区域标识为00010,将中部偏右的场景区域标识为00100等等。第一虚拟角色601处于标识为00001的场景区域,则第一客户端可以将目标场景的数据以及目标场景区域对应的目标区域标识00001发送至服务端,以使服务端根据目标区域标识00001确定第一虚拟角色所处的目标场景区域并将状态帧发送至同处于同一场景下的第二客户端,即目标区域标识00001对应的场景区域中其他虚拟角色对应的客户端。

在实际应用中,可以理解为目标区域标识是一个Tag(标签)值,通过维护Tag值,用它来表示整个地图。然后再根据视野或者游戏场景等条件将整个地图划分为一个个小区域,每个区域占总Tag的一位。客户端在上传状态帧时,需要将所控制的虚拟角色能看到的区域标记在Tag上并上传。服务端在接收到状态帧后,将根据Tag值将虚拟角色分组,即Tag有一位相同的在一组。如果某个虚拟角色在某些区域的边缘可能同时在多个组内。如图6所示,每个场景区域对应整型数据中的一个数位,例如将中部偏左的场景区域标识为00001,即用第五位标识中部偏左的场景区域;将中部的场景区域标识为00010,即用第四位标识中部的场景区域;将中部偏右的场景区域标识为00100;将左下的场景区域标识为01000;将中部偏下的场景区域标识为10000。第一虚拟角色601处于场景标识为00001的场景区域,因此可以上传场景标识00001至服务端,第一虚拟角色只可以观察到标识为00001的场景区域中的其他虚拟角色,而所有场景标识第五位为1(XXXX1)的游戏场景中的虚拟角色都可以观察到第一虚拟角色601。第二虚拟角色602同时处于场景标识为00010和10000的场景区域,即第四位为1以及第一位为1的场景区域,因此可以上传场景标识10010至服务端,第二虚拟角色602可以同时看到两个场景区域中的其他虚拟角色,同时所有场景标识第四位和第一位为1(1XX1X,也包含1XXXX和XXX1X)的游戏场景中的虚拟角色都可以观察到第二虚拟角色602。

需要说明的是,第一客户端上传的目标场景区域可以是第一客户端所控制的第一虚拟角色所观看的视野内的场景,即第一客户端的图形用户界面当前所显示的游戏场景;第一客户端上传的目标场景区域也可以是第一虚拟角色所观看的视野内的场景中的部分范围,例如,只上传第一客户端的图形用户界面左上角的游戏场景。

通过将目标游戏场景的数据以及目标场景区域对应的目标区域标识发送至服务端,以使服务端根据目标游戏场景的数据确定第一虚拟角色所处的目标游戏场景以及根据目标区域标识确定目标场景区域,并将目标场景区域对应的目标状态帧发送至第二客户端,可以使得第二客户端可以精准的接收到同区域内第一虚拟角色对应的状态帧,使标识不同的其他场景区域对应的其他客户端无法接收到状态帧,减轻服务端的数据传输压力,减轻其他客户端的工作压力。

在一些实施例中,可以通过较为灵活的方式减少需要传输的数据量,从而有效的减轻客户端的数据处理压力,例如,省略状态帧中重复或不变数据,只将状态帧中发生变化的数据进行封装处理,得到对应的数据包,有效的减少了需要传输的数据量。作为一个示例,状态帧以数据包的形式被发送至服务端;在上述步骤S430之前,该方法还可以包括如下步骤:

步骤d),确定状态帧中发生变化的数据。

步骤e),将状态帧中发生变化的数据打入数据包的包体。

在实际应用中,Protobuf即是一种支持多平台、多语言、可扩展的数据序列化机制。通过将结构化的数据进行序列化(串行化)实现高效存储,用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式,支持自定义的数据结构。以横版2维(2-Dimension,2D)游戏为例,由于游戏只有两个维度,即X轴和Y轴,虚拟角色只能左右、上下移动,因此除了虚拟角色坐标、角虚拟色状态和地图状态等必要参数,其余状态通过一个值的不同位来表示。另外根据Protobuf不将默认值打入包体的特性,可以省略掉一些不变值,比如虚拟角色只在平台上(X轴方向)移动时,Y轴坐标、虚拟角色状态和地图状态都没有变化,那么就不将它们打入包体。在实际应用中这样压缩后,一个状态帧的大小将控制在2~19字节内。这个压缩量非常可观,能有效减少流量。在实际应用中同样的方法也同样适用于3维(3-Dimension,3D)游戏,只需做些扩展例如增加Z轴坐标,游戏场景字段等等,但数据流量也将相应提升。

示例性的,第一客户端可以进行实时刷新或按预设帧率进行刷新,例如,按照预设的15FPS的帧率绘制图像,绘制图像的过程中通过Protobuf的特性省略掉一些不变值,虽然每个数据包的包体中的状态帧的数量不变,但是每个数据包所占的存储空间变小,缓解了客户端和服务端的数据处理压力。

通过使第一客户端首先确定状态帧中发生变化的数据,之后将状态帧中发生变化的数据打入数据包的包体。通过只将状态帧中发生变化的数据进行封装处理,有效的减少了需要传输的数据量,减轻了客户端的数据处理压力。

在一些实施例中,可以通过较为灵活的方式减少需要传输的数据量,从而有效的减轻客户端的数据处理压力,例如,可以在保证画面稳定连续的前提下,通过限制每个数据包中状态帧的帧数来减少数据量,既有效的减少了客户端的数据处理压力,又不影响玩家的游戏体验。作为一个示例,状态帧以数据包的形式被发送至服务端;每个数据包中包含指定帧数的状态帧;游戏画面在第二客户端上以指定帧率显示;其中,指定帧率为每秒指定帧数。

示例性的,客户端还是按照15FPS的帧率绘制图像,但上传数据从15帧一包压缩成了7帧一包。即收集自己的7帧数据,将其打包成一个数据包发给服务端,这样做能减少所有客户端每秒上传包数量,减少服务端序列化、反序列化协议的次数,有效减轻服务端压力。所以同一时刻,如图5所示,实际第一虚拟角色(实线小人)的运动情况在其他玩家眼里(虚线小人)将延后0.5秒。这在以社交为主的游戏场景下是可被接受的,玩家对这种现象也基本无感,即不知道别人提前0.5秒已经跳起。

需要说明的是,每个数据包中所包含的帧数可以替换,但对玩家体验影响较大。如果15帧缩小一半,那么在玩家眼中其他虚拟角色的动作可能有较明显的卡顿感。若7帧缩小一半,那么第一虚拟角色在其他玩家眼中将延后1秒。

通过使状态帧以数据包的形式被发送至服务端;每个数据包中包含指定帧数的状态帧;游戏画面在第二客户端上以指定帧率显示。实现了通过较为灵活的方式减少需要传输的数据量,从而有效的减轻客户端的数据处理压力,既有效的减少了客户端的数据处理压力,又不影响玩家的游戏体验。

在一些实施例中,游戏状态数据的数据类型可以包括多种,通过使游戏状态数据包括多种类型,从而可以使数据包中包含的数据可以充分记录下第一虚拟角色的行为状态及其他相关内容,进而使其他客户端可以确切的表现出第一虚拟角色的行为状态及其他相关内容,提高玩家的游戏体验。作为一个示例,游戏状态数据包括下述任意一项或多项:

游戏中的移动状态数据、碰撞状态数据、位置状态数据。

示例性的,状态数据可以包括第一虚拟角色的移动状态,例如第一虚拟角色向哪个方向移动、是否进行跳跃等等;状态数据还可以包括第一虚拟角色的碰撞状态,例如是否和其他虚拟角色发生碰撞、是否和游戏场景区域中的道具模型发生碰撞等等;状态数据还可以包括第一虚拟角色的位置状态,例如第一虚拟角色当前处于哪一个标识所对应的游戏场景区域。

通过使游戏状态数据包括多种类型,从而可以使数据包中包含的数据可以充分记录下第一虚拟角色的行为状态及其他相关内容,进而使其他客户端可以确切的表现出第一虚拟角色的行为状态及其他相关内容,提高玩家的游戏体验。

图7为本公开实施例提供的一种游戏中虚拟角色的数据处理方法的流程示意图。其中,该方法可以应用于服务端,游戏的游戏场景中包含通过第一客户端控制的第一虚拟角色。如图7所示,该方法包括:

步骤S710,获取第一客户端发送的状态帧。

其中,状态帧为第一客户端对游戏状态数据进行封装而得到,游戏状态数据为第一虚拟角色执行第一客户端的控制指令过程中生成的游戏状态数据。

示例性的,服务端可以获取第一客户端发送的状态帧,状态帧为第一客户端对状态数据进行封装而得到,状态数据为基于第一客户端对第一虚拟角色的控制指令而生成的游戏状态数据。例如玩家通过第一客户端控制第一虚拟角色在游戏场景中进行移动、跳跃等动作,第一客户端可以将这些移动的距离位置、跳跃高度以及是否与游戏场景中的地形发生碰撞等数据确定为游戏状态数据,之后将其进行封装得到状态帧。

步骤S720,确定与第一虚拟角色处于相同游戏场景的第二虚拟角色。

示例性的,服务端可以基于第一客户端所发送的目标游戏场景的数据、目标场景区域对应的目标区域标识等,确定出与第一虚拟角色处于相同房间(游戏场景)的第二虚拟角色,进而使服务端的转发具有筛选功能,从而可以筛选出与第一虚拟角色处于相同房间(游戏场景)的第二虚拟角色。

步骤S730,将状态帧发送至第二虚拟角色对应的第二客户端,以在第二客户端上显示游戏状态数据对应的游戏画面。

示例性的,服务端将封装好的状态帧发送至第二客户端,使第二客户端无需重新计算,而是基于状态帧中的内容直接进行绘图,进而对第一虚拟角色进行显示,即在第二客户端的图形用户界面中显示第一虚拟角色在游戏场景中进行移动、跳跃等动作。

本公开实施例中,当玩家通过第一客户端对第一虚拟角色进行控制时,系统可以获取第一虚拟角色的状态数据,之后将状态数据封装为状态帧,进而通过服务端将状态帧同步至第二客户端,使第二客户端基于状态帧在图形用户界面上对第一虚拟角色进行显示。状态帧解决了帧同步服务端没有任何游戏数据的问题,依然将计算交给客户端来处理,同时由于每个客户端只处理并上传自己的数据,所以在收到其他客户端的数据时可直接绘图,有效减小了客户端压力,缓解了客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

下面对上述步骤进行详细介绍。

在一些实施例中,在一些实施例中,可以通过使客户端只显示对应场景区域中的内容,从而减少客户端的数据处理量,通过较为灵活的方式减轻客户端的压力,例如,通过服务端的筛选,使第二客户端仅可以接收并显示相同区域内的游戏画面,从而有效的减轻第二客户端的工作压力。作为一个示例,上述步骤S720具体可以包括如下步骤:

步骤f),获取各个客户端发送的场景标识。

步骤g),基于多个虚拟角色所处的游戏场景确定与第一虚拟角色处于相同游戏场景的第二虚拟角色。

对于上述步骤f),其中的场景标识用于表示客户端控制的虚拟角色在游戏中所处的至少一个游戏场景。

示例性的,如图6所示,可以理解为场景标识是一个Tag(标签)值,通过维护Tag值,用它来表示整个地图。然后再根据视野或者游戏场景等条件将整个地图划分为一个个小区域,每个区域占总Tag的一位。客户端在上传状态帧时,需要将所控制的虚拟角色能看到的区域标记在Tag上并上传。服务端在接收到各个客户端发送的场景标识后,将根据Tag值将虚拟角色分组,即Tag有一位相同的在一组。第一客户端系统将第一虚拟角色601所处的场景区域中的场景标识00001发送至服务端,服务端获取后来自多个客户端的场景标识后,可以确定都有哪些虚拟角色与第一虚拟角色601同时处于相同的场景区域中,之后针对相同的场景区域,将每个虚拟角色对应的状态帧广播至处于相同场景区域的所有虚拟角色,从而使得其他玩家可以观察到其他虚拟角色的状态。又例如,第二虚拟角色602同时处于场景区域00010以及场景区域10000中,则服务端可以获取两个场景区域的场景标识,之后针对相同的场景区域00010以及场景区域10000,将每个虚拟角色对应的状态帧广播至处于相同场景区域的所有虚拟角色,即处于场景区域00010和场景区域10000中的其他虚拟角色都可以观察到第二虚拟角色602。

通过使服务端获取各个客户端发送的场景标识,之后基于多个虚拟角色所处的场景区域,确定处于相同场景区域的虚拟角色,进而针对每个相同场景区域,将每个虚拟角色对应的状态帧广播至处于相同场景区域的所有虚拟角色,使客户端仅仅显示同处于同一游戏场景下的游戏内容,既保证了玩家可以看到视野范围之内所需求的游戏内容,又省略了不必要、不需要进行数据传输的内容,减轻了服务端、客户端的工作压力。

在一些实施例中,服务端对应多个游戏场景,可以通过遍历所有游戏场景,从而根据遍历结果得到与虚拟角色对应的优先级最高的游戏场景,并将其分配给虚拟角色,可以使虚拟角色与其相似度较高的其他虚拟角色同处于同一游戏场景,提高玩家的游戏体验。作为一个示例,服务端对应有多个游戏场景,每个虚拟角色对应有多个游戏场景分配维度;上述步骤S720具体可以包括如下步骤:

步骤h),通过遍历所有游戏场景,确定多个游戏场景分配维度中每个游戏场景分配维度最优的游戏场景。

步骤i),基于每个游戏场景分配维度的优先级,从游戏场景分配维度最优的游戏场景中确定第一虚拟角色所分配至的游戏场景以及与第一虚拟角色分配至相同游戏场景的第二虚拟角色。

示例性的,如图8所示,本公开实施例可以应用于游戏中的社交广场,社交广场是一个分布式的微服务架构,与其他服务集群相对独立,集群与集群内部都支持横向扩容和缩容。集群间通过客户端随机访问不同网关来做到不同集群人数相对平等。集群内部有多个负载均衡服,将根据各个广场进程上一次负载值加预测值实时计算出当前负载,并挑选出一个最优进程分配给虚拟角色。广场的集群、进程都是基于平等原则分配的,虚拟角色进入每个广场服的概率相同。每个进程里有几百个游戏场景,这些游戏场景的分配又是以策划定义的属性优先级来分配,属性相似或相吸引的虚拟更容易分配在一起。比如希望给第一虚拟角色优先匹配游戏习惯相似的其它虚拟角色,若没有则匹配等级相近的,若还是没有则放弃条件,则匹配一个相对活跃的游戏场景。所以可以将所有游戏场景插入到四个队列中,分别根据活跃程度定义为:满负载、高负载、活跃、空闲四个等级。并将游戏习惯定为第一优先级,角色等级定为第二优先级,每个虚拟角色的进出都将更新游戏场景属性。这样从寻找合适的虚拟角色就变成了寻找合适的游戏场景。另外由于每个优先级都需要根据活跃程度遍历一遍所有游戏场景,非常浪费性能,所以需要额外维护一个遍历备忘表,遍历一次后就能得到所有符合各种条件的游戏场景,其中如果某个游戏场景符合最高优先级则可以马上退出遍历。

在实际应用中,服务端中一开始有个如表1所示的空列表,遍历一次后将每个维度最优的游戏场景填入其中,最后再从这个列表中得到结果。

表1

因为优先级、游戏场景数都是可以根据策划需求成长的。假如游戏场景一共有N个,优先级有M种,那么优化前每次遍历次数是N*M,优化后遍历次数就是N+M。因为是基于优先级的设计,即如果游戏习惯相似,就不再考虑匹配等级是否相近。也可以考虑增加权重的设计,每个游戏场景都有个习惯占比、等级占比,以最终相加结果作为筛选条件。

通过使服务端遍历所有游戏场景,确定多个游戏场景分配维度中每个游戏场景分配维度最优的目标游戏场景,之后基于每个游戏场景分配维度的优先级,从目标游戏场景中确定虚拟角色所分配至的最终游戏场景,可以使虚拟角色与其相似度较高的其他虚拟角色同处于同一游戏场景,让玩家找到兴趣相投的其他玩家,提高玩家的游戏体验。

基于上述步骤h)和步骤i),游戏场景分配维度可以包括多种,通过使游戏场景分配维度可以包括多种,可以较为灵活、详细的实现对于最终游戏场景的确定,使虚拟角色可以分配到匹配度最高的游戏场景,提高玩家的游戏体验。作为一个示例,游戏场景分配维度包括下述任意一项或多项:

虚拟角色的游戏习惯、角色等级以及角色活跃度。

示例性的,游戏场景分配维度可以包括多种,例如虚拟角色的游戏习惯、角色等级以及角色活跃度等等。可以将不同的维度设置为不同的优先级,进而为虚拟角色进行合适的分配。如上文提到的,可以将虚拟角色的游戏习惯定为第一优先级,玩家角色等级定为第二优先级,每个玩家的进出都将更新游戏场景属性。这样从寻找合适的玩家就变成了寻找合适的游戏场景。而且一个遍历备忘表遍历一次后就能得到所有符合各种条件的游戏场景,其中如果某个游戏场景符合最高优先级则可以马上退出遍历。

通过使游戏场景分配维度包括多种,可以较为灵活、详细的实现对于最终游戏场景的确定,使虚拟角色可以分配到匹配度最高的游戏场景,可以使虚拟角色与其相似度很高的其他虚拟角色同处于同一游戏场景,让玩家找到兴趣相投的其他玩家,提高玩家的游戏体验。

在一些实施例中,服务端可以根据第二虚拟角色对应的划分维度对多个第二虚拟角色进行进一步的划分,确定与第一虚拟角色划分为同类的目标第二虚拟角色,通过筛选将状态帧发送至目标第二虚拟角色对应的目标第二客户端,实现了趣味相投的玩家彼此可见的效果,进一步提高玩家的游戏体验。作为一个示例,第二虚拟角色的数量为多个,每个第二虚拟角色对应有游戏角色划分维度;上述步骤S730具体可以包括如下步骤:

步骤j),通过游戏角色划分维度从多个第二虚拟角色中确定与第一虚拟角色划分为同类的目标第二虚拟角色。

步骤k),将状态帧发送至目标第二虚拟角色对应的目标第二客户端,以在目标第二客户端上显示游戏状态数据对应的游戏画面。

示例性的,与游戏场景的分配相似,可以将虚拟角色游戏习惯定为第一优先级,将虚拟角色等级定为第二优先级,将虚拟角色的活跃度定为第三优先级,根据上述游戏角色划分维度对多个第二虚拟角色进行进一步划分筛选,确定出一批与第一虚拟角色最相似的同类玩家。之后服务端将第一客户端的状态帧发送至对应的目标第二客户端,使第二客户端可以对游戏状态数据对应的游戏画面进行显示。

通过首先将游戏角色划分维度从多个第二虚拟角色中确定与第一虚拟角色划分为同类的目标第二虚拟角色,之后将状态帧发送至目标第二虚拟角色对应的目标第二客户端,以在目标第二客户端上显示游戏状态数据对应的游戏画面。实现了服务端对于多个第二虚拟角色的进一步的划分,筛选出与第一虚拟角色划分为同类的目标第二虚拟角色,通过筛选将状态帧发送至目标第二虚拟角色对应的目标第二客户端,实现了仅趣味相投的玩家彼此可见的效果,进一步降低了客户端的运行压力,提高了玩家的游戏体验。

基于上述步骤j)和步骤k),游戏角色划分维度可以包括多种,通过使游戏角色划分维度可以包括多种,可以较为灵活、详细的实现对于同一类虚拟角色的确定,使第一虚拟角色可以分配到匹配度最高的第二虚拟角色,提高玩家的游戏体验。作为一个示例,游戏角色划分维度包括下述任意一项或多项:

虚拟角色的游戏习惯、角色等级以及角色活跃度。

示例性的,游戏角色划分维度可以包括多种,例如虚拟角色的游戏习惯、角色等级以及角色活跃度等等。可以将不同的维度设置为不同的优先级,进而为虚拟角色进行合适的分配。如上文提到的,可以将虚拟角色的游戏习惯定为第一优先级,虚拟角色等级定为第二优先级,每个虚拟角色的进出都将更新游戏场景属性。同样可以通过类似上文表1所示的遍历备忘表实现,遍历一次后就能得到所有属于同一类别的第二虚拟角色。

通过使游戏角色划分维度可以包括多种,可以较为灵活、详细的实现对于同一类虚拟角色的确定,使第一虚拟角色可以分配到匹配度最高的第二虚拟角色,提高玩家的游戏体验。

图9为本公开实施例提供的一种游戏中虚拟角色的数据处理方法的流程示意图。其中,该方法可以应用于第二客户端(例如图2所示的手机102),游戏的同一游戏场景中包含通过第一客户端控制的第一虚拟角色以及通过第二客户端控制的第二虚拟角色,通过第二客户端提供图形用户界面。如图9所示,该方法包括:

步骤S910,接收服务端发送的状态帧。

其中,状态帧为第一客户端对游戏状态数据进行封装而得到,游戏状态数据为第一虚拟角色执行第一客户端的控制指令过程中生成的游戏状态数据。

示例性的,基于服务端的筛选分配,部分与第一客户端相对应的目标第二客户端将接收到服务端发送的状态帧。

步骤S920,在图形用户界面中显示游戏状态数据对应的游戏画面。

示例性的,第二客户端在接收到服务端发送的状态帧后,可以基于状态帧中的内容进行绘图,进而在图形用户界面中显示游戏状态数据对应的游戏画面。

本公开实施例中,第一客户端可以将与其控制的第一虚拟角色相关的游戏状态数据封装为状态帧,再将该状态帧发送至服务端,进而通过服务端将状态帧同步至第二客户端,各个第二客户端便可以从服务端处获取并基于该状态帧直接显示出对应的游戏画面,状态帧解决了帧同步服务端没有任何游戏数据的问题,依然将计算交给客户端来处理,同时由于每个客户端只处理并上传服务器自身控制的虚拟角色相关的游戏状态数据,所以在收到其他客户端的数据时可直接绘图,使各客户端无需再进行一系列关于其他客户端控制的虚拟角色相关的游戏状态数据计算,有效降低了客户端的数据处理量和运行压力,缓解了客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

在一些实施例中,第二客户端可以通过较为灵活方式的在图形用户界面中显示游戏状态数据对应的游戏画面,例如,用状态帧中的游戏状态数据对应的游戏画面对现有游戏画面进行覆盖,进而可以实时的为玩家显示游戏画面。作为一个示例,上述步骤S920具体可以包括如下步骤:

步骤l),将游戏状态数据对应的游戏画面覆盖显示于图形用户界面中。

示例性的,第二客户端在接收到服务端发送的状态帧后,可以基于状态帧中的游戏状态数据进行绘图,得到对应的游戏画面,之后可以通过覆盖的方式对当前图形用户界面中的显示内容进行覆盖,以实现游戏内容的实时更新。

通过将游戏状态数据对应的游戏画面覆盖显示于图形用户界面中,可以较为快捷的更新游戏显示内容,可以实时的为玩家显示游戏画面,提高玩家的游戏体验。

图10为本公开实施例提供的一种游戏中虚拟角色的数据处理装置的结构示意图。其中,该装置可以应用于第一客户端,游戏的游戏场景中包含通过第一客户端控制的第一虚拟角色。如图10所示,游戏中虚拟角色的数据处理装置1000包括:

确定模块1001,用于基于第一客户端对第一虚拟角色的控制指令,确定第一虚拟角色执行控制指令过程中生成的游戏状态数据。

封装模块1002,用于将游戏状态数据封装为状态帧。

发送模块1003,用于将状态帧发送至服务端,以使服务端将状态帧发送至第二客户端,以在第二客户端上显示游戏状态数据对应的游戏画面。

在一些实施例中,游戏状态数据包括下述任意一项或多项:

第一虚拟角色的状态数据、游戏场景中除第一虚拟角色以外的其他虚拟角色的状态数据以及其他虚拟物体的状态数据。

在一些实施例中,服务端对应有多个游戏场景;该装置还可以包括:

第二确定模块,用于确定第一虚拟角色所处的目标游戏场景;

将目标游戏场景的数据发送至服务端,以使服务端将状态帧发送至第二客户端,其中,第二客户端控制的第二虚拟角色为处于目标游戏场景中除第一虚拟角色之外的其他虚拟角色。

在一些实施例中,游戏场景中包含多个场景区域,每个场景区域对应有区域标识;发送模块1003具体用于:

将目标游戏场景的数据以及目标场景区域对应的目标区域标识发送至服务端,以使服务端根据目标游戏场景的数据确定第一虚拟角色所处的目标游戏场景以及根据目标区域标识确定目标场景区域,并将目标场景区域对应的目标状态帧发送至第二客户端。

在一些实施例中,状态帧以数据包的形式被发送至服务端;该装置还可以包括:

第三确定模块,用于将状态帧发送至服务端之前,确定状态帧中发生变化的数据;

将状态帧中发生变化的数据打入数据包的包体。

在一些实施例中,状态帧以数据包的形式被发送至服务端;每个数据包中包含指定帧数的状态帧;

游戏画面在第二客户端上以指定帧率显示;其中,指定帧率为每秒指定帧数。

在一些实施例中,游戏状态数据包括下述任意一项或多项:

游戏中的移动状态数据、碰撞状态数据、位置状态数据。

图11为本公开实施例提供的一种游戏中虚拟角色的数据处理装置的结构示意图。其中,该装置可以应用于服务端,游戏的游戏场景中包含通过第一客户端控制的第一虚拟角色。如图11所示,游戏中虚拟角色的数据处理装置1100包括:

获取模块1101,用于获取第一客户端发送的状态帧;其中,状态帧为第一客户端对游戏状态数据进行封装而得到,游戏状态数据为第一虚拟角色执行第一客户端的控制指令过程中生成的游戏状态数据。

确定模块1102,用于确定与第一虚拟角色处于相同游戏场景的第二虚拟角色。

发送模块1103,用于将状态帧发送至第二虚拟角色对应的第二客户端,以在第二客户端上显示游戏状态数据对应的游戏画面。

在一些实施例中,确定模块1102具体用于:

获取各个客户端发送的场景标识;其中,场景标识用于表示客户端控制的虚拟角色在游戏中所处的至少一个游戏场景;

基于多个虚拟角色所处的游戏场景确定与第一虚拟角色处于相同游戏场景的第二虚拟角色。

在一些实施例中,服务端对应有多个游戏场景,每个虚拟角色对应有多个游戏场景分配维度;确定模块1102具体用于:

通过遍历所有游戏场景,确定多个游戏场景分配维度中每个游戏场景分配维度最优的游戏场景;

基于每个游戏场景分配维度的优先级,从游戏场景分配维度最优的游戏场景中确定第一虚拟角色所分配至的游戏场景以及与第一虚拟角色分配至相同游戏场景的第二虚拟角色。

在一些实施例中,游戏场景分配维度包括下述任意一项或多项:

虚拟角色的游戏习惯、角色等级以及角色活跃度。

在一些实施例中,第二虚拟角色的数量为多个,每个第二虚拟角色对应有游戏角色划分维度;发送模块1103具体用于:

通过游戏角色划分维度从多个第二虚拟角色中确定与第一虚拟角色划分为同类的目标第二虚拟角色;

将状态帧发送至目标第二虚拟角色对应的目标第二客户端,以在目标第二客户端上显示游戏状态数据对应的游戏画面。

在一些实施例中,游戏角色划分维度包括下述任意一项或多项:

虚拟角色的游戏习惯、角色等级以及角色活跃度。

图12为本公开实施例提供的一种游戏中虚拟角色的数据处理装置的结构示意图。其中,该装置可以应用于第二客户端,游戏的同一游戏场景中包含通过第一客户端控制的第一虚拟角色以及通过第二客户端控制的第二虚拟角色,通过第二客户端提供图形用户界面。如图12所示,游戏中虚拟角色的数据处理装置1200包括:

接收模块1201,用于接收服务端发送的状态帧;其中,状态帧为第一客户端对游戏状态数据进行封装而得到,游戏状态数据为第一虚拟角色执行第一客户端的控制指令过程中生成的游戏状态数据。

显示模块1202,用于在图形用户界面中显示游戏状态数据对应的游戏画面。

在一些实施例中,显示模块1202具体用于:

将游戏状态数据对应的游戏画面覆盖显示于图形用户界面中。

本公开实施例提供的一种游戏中虚拟角色的数据处理装置,与上述实施例提供的一种游戏中虚拟角色的数据处理方法具有相同的技术特征,所以也能解决相同的技术问题,达到相同的技术效果。第一客户端可以将与其控制的第一虚拟角色相关的游戏状态数据封装为状态帧,再将该状态帧发送至服务端,进而通过服务端将状态帧同步至第二客户端,各个第二客户端便可以从服务端处获取并基于该状态帧直接显示出对应的游戏画面,状态帧解决了帧同步服务端没有任何游戏数据的问题,依然将计算交给客户端来处理,同时由于每个客户端只处理并上传服务器自身控制的虚拟角色相关的游戏状态数据,所以在收到其他客户端的数据时可直接绘图,使各客户端无需再进行一系列关于其他客户端控制的虚拟角色相关的游戏状态数据计算,有效降低了客户端的数据处理量和运行压力,缓解了客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

本申请实施例还提供了一种电子设备,包括:处理器、存储介质和总线,所述存储介质存储有所述处理器可执行的机器可读指令,当电子设备运行如实施例中的一种游戏中虚拟角色的数据处理方法时,所述处理器与所述存储介质之间通过总线通信,所述处理器执行所述机器可读指令,所述处理器方法项的前序部分,以执行以下步骤:

基于所述第一客户端对所述第一虚拟角色的控制指令,确定所述第一虚拟角色执行所述控制指令过程中生成的游戏状态数据;

将所述游戏状态数据封装为状态帧;

将所述状态帧发送至服务端,以使所述服务端将所述状态帧发送至第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可行的实施方案中,所述游戏状态数据包括下述任意一项或多项:

所述第一虚拟角色的状态数据、所述游戏场景中除所述第一虚拟角色以外的其他虚拟角色的状态数据以及其他虚拟物体的状态数据。

在一个可行的实施方案中,所述服务端对应有多个所述游戏场景;还包括:

确定所述第一虚拟角色所处的目标游戏场景;

将所述目标游戏场景的数据发送至所述服务端,以使所述服务端将所述状态帧发送至所述第二客户端,其中,所述第二客户端控制的第二虚拟角色为处于所述目标游戏场景中除所述第一虚拟角色之外的其他虚拟角色。

在一个可行的实施方案中,所述游戏场景中包含多个场景区域,每个所述场景区域对应有区域标识;

所述将所述目标游戏场景的数据发送至所述服务端,以使所述服务端将所述状态帧发送至所述第二客户端的步骤,包括:

将所述目标游戏场景的数据以及目标场景区域对应的目标区域标识发送至所述服务端,以使所述服务端根据所述目标游戏场景的数据确定所述第一虚拟角色所处的所述目标游戏场景以及根据所述目标区域标识确定所述目标场景区域,并将所述目标场景区域对应的目标状态帧发送至所述第二客户端。

在一个可行的实施方案中,所述状态帧以数据包的形式被发送至所述服务端;所述将所述状态帧发送至服务端的步骤之前,还包括:

确定所述状态帧中发生变化的数据;

将所述状态帧中发生变化的数据打入所述数据包的包体。

在一个可行的实施方案中,所述状态帧以数据包的形式被发送至所述服务端;每个所述数据包中包含指定帧数的状态帧;

所述游戏画面在所述第二客户端上以指定帧率显示;其中,所述指定帧率为每秒所述指定帧数。

在一个可行的实施方案中,所述游戏状态数据包括下述任意一项或多项:

所述游戏中的移动状态数据、碰撞状态数据、位置状态数据。

当上述电子设备运行如实施例中的一种游戏中虚拟角色的数据处理方法时,所述处理器与所述存储介质之间通过总线通信,所述处理器执行所述机器可读指令,所述处理器方法项的前序部分,以执行以下步骤:

获取所述第一客户端发送的状态帧;其中,所述状态帧为所述第一客户端对游戏状态数据进行封装而得到,所述游戏状态数据为所述第一虚拟角色执行所述第一客户端的控制指令过程中生成的游戏状态数据;

确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色;

将所述状态帧发送至所述第二虚拟角色对应的第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可行的实施方案中,所述确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色的步骤,包括:

获取各个客户端发送的场景标识;其中,所述场景标识用于表示所述客户端控制的虚拟角色在所述游戏中所处的至少一个所述游戏场景;

基于多个所述虚拟角色所处的所述游戏场景确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色。

在一个可行的实施方案中,所述服务端对应有多个所述游戏场景,每个所述虚拟角色对应有多个游戏场景分配维度;

所述确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色的步骤,包括:

通过遍历所有所述游戏场景,确定所述多个游戏场景分配维度中每个所述游戏场景分配维度最优的游戏场景;

基于每个所述游戏场景分配维度的优先级,从所述游戏场景分配维度最优的游戏场景中确定所述第一虚拟角色所分配至的游戏场景以及与所述第一虚拟角色分配至相同游戏场景的第二虚拟角色。

在一个可行的实施方案中,所述游戏场景分配维度包括下述任意一项或多项:

所述虚拟角色的游戏习惯、角色等级以及角色活跃度。

在一个可行的实施方案中,所述第二虚拟角色的数量为多个,每个所述第二虚拟角色对应有游戏角色划分维度;

所述将所述状态帧发送至所述第二虚拟角色对应的第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面的步骤,包括:

通过所述游戏角色划分维度从多个所述第二虚拟角色中确定与所述第一虚拟角色划分为同类的目标第二虚拟角色;

将所述状态帧发送至所述目标第二虚拟角色对应的目标第二客户端,以在所述目标第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可行的实施方案中,所述游戏角色划分维度包括下述任意一项或多项:

所述虚拟角色的游戏习惯、角色等级以及角色活跃度。

当上述电子设备运行如实施例中的一种游戏中虚拟角色的数据处理方法时,所述处理器与所述存储介质之间通过总线通信,所述处理器执行所述机器可读指令,所述处理器方法项的前序部分,以执行以下步骤:

接收服务端发送的状态帧;其中,所述状态帧为所述第一客户端对游戏状态数据进行封装而得到,所述游戏状态数据为所述第一虚拟角色执行所述第一客户端的控制指令过程中生成的游戏状态数据;

在所述图形用户界面中显示所述游戏状态数据对应的游戏画面。

在一个可行的实施方案中,所述在所述图形用户界面中显示所述游戏状态数据对应的游戏画面的步骤,包括:

将所述游戏状态数据对应的游戏画面覆盖显示于所述图形用户界面中。

上述电子设备所执行步骤的具体实施例和具体工作过程,均可以参考上述方法实施例中的对应过程,在此不再赘述。

通过上述方式,第一客户端可以将与其控制的第一虚拟角色相关的游戏状态数据封装为状态帧,再将该状态帧发送至服务端,进而通过服务端将状态帧同步至第二客户端,各个第二客户端便可以从服务端处获取并基于该状态帧直接显示出对应的游戏画面,状态帧解决了帧同步服务端没有任何游戏数据的问题,依然将计算交给客户端来处理,同时由于每个客户端只处理并上传服务器自身控制的虚拟角色相关的游戏状态数据,所以在收到其他客户端的数据时可直接绘图,使各客户端无需再进行一系列关于其他客户端控制的虚拟角色相关的游戏状态数据计算,有效降低了客户端的数据处理量和运行压力,缓解了客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

对应于上述游戏中虚拟角色的数据处理方法,本公开实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质储存有计算机可运行指令,所述计算机可运行指令在被处理器调用和运行时,所述计算机可运行指令促使所述处理器执行以下步骤:

基于所述第一客户端对所述第一虚拟角色的控制指令,确定所述第一虚拟角色执行所述控制指令过程中生成的游戏状态数据;

将所述游戏状态数据封装为状态帧;

将所述状态帧发送至服务端,以使所述服务端将所述状态帧发送至第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可行的实施方案中,所述游戏状态数据包括下述任意一项或多项:

所述第一虚拟角色的状态数据、所述游戏场景中除所述第一虚拟角色以外的其他虚拟角色的状态数据以及其他虚拟物体的状态数据。

在一个可行的实施方案中,所述服务端对应有多个所述游戏场景;还包括:

确定所述第一虚拟角色所处的目标游戏场景;

将所述目标游戏场景的数据发送至所述服务端,以使所述服务端将所述状态帧发送至所述第二客户端,其中,所述第二客户端控制的第二虚拟角色为处于所述目标游戏场景中除所述第一虚拟角色之外的其他虚拟角色。

在一个可行的实施方案中,所述游戏场景中包含多个场景区域,每个所述场景区域对应有区域标识;

所述将所述目标游戏场景的数据发送至所述服务端,以使所述服务端将所述状态帧发送至所述第二客户端的步骤,包括:

将所述目标游戏场景的数据以及目标场景区域对应的目标区域标识发送至所述服务端,以使所述服务端根据所述目标游戏场景的数据确定所述第一虚拟角色所处的所述目标游戏场景以及根据所述目标区域标识确定所述目标场景区域,并将所述目标场景区域对应的目标状态帧发送至所述第二客户端。

在一个可行的实施方案中,所述状态帧以数据包的形式被发送至所述服务端;所述将所述状态帧发送至服务端的步骤之前,还包括:

确定所述状态帧中发生变化的数据;

将所述状态帧中发生变化的数据打入所述数据包的包体。

在一个可行的实施方案中,所述状态帧以数据包的形式被发送至所述服务端;每个所述数据包中包含指定帧数的状态帧;

所述游戏画面在所述第二客户端上以指定帧率显示;其中,所述指定帧率为每秒所述指定帧数。

在一个可行的实施方案中,所述游戏状态数据包括下述任意一项或多项:

所述游戏中的移动状态数据、碰撞状态数据、位置状态数据。

上述计算机可读存储介质储存有计算机可运行指令,所述计算机可运行指令在被处理器调用和运行时,所述计算机可运行指令还可以促使所述处理器执行以下步骤:

获取所述第一客户端发送的状态帧;其中,所述状态帧为所述第一客户端对游戏状态数据进行封装而得到,所述游戏状态数据为所述第一虚拟角色执行所述第一客户端的控制指令过程中生成的游戏状态数据;

确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色;

将所述状态帧发送至所述第二虚拟角色对应的第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可行的实施方案中,所述确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色的步骤,包括:

获取各个客户端发送的场景标识;其中,所述场景标识用于表示所述客户端控制的虚拟角色在所述游戏中所处的至少一个所述游戏场景;

基于多个所述虚拟角色所处的所述游戏场景确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色。

在一个可行的实施方案中,所述服务端对应有多个所述游戏场景,每个所述虚拟角色对应有多个游戏场景分配维度;

所述确定与所述第一虚拟角色处于相同游戏场景的第二虚拟角色的步骤,包括:

通过遍历所有所述游戏场景,确定所述多个游戏场景分配维度中每个所述游戏场景分配维度最优的游戏场景;

基于每个所述游戏场景分配维度的优先级,从所述游戏场景分配维度最优的游戏场景中确定所述第一虚拟角色所分配至的游戏场景以及与所述第一虚拟角色分配至相同游戏场景的第二虚拟角色。

在一个可行的实施方案中,所述游戏场景分配维度包括下述任意一项或多项:

所述虚拟角色的游戏习惯、角色等级以及角色活跃度。

在一个可行的实施方案中,所述第二虚拟角色的数量为多个,每个所述第二虚拟角色对应有游戏角色划分维度;

所述将所述状态帧发送至所述第二虚拟角色对应的第二客户端,以在所述第二客户端上显示所述游戏状态数据对应的游戏画面的步骤,包括:

通过所述游戏角色划分维度从多个所述第二虚拟角色中确定与所述第一虚拟角色划分为同类的目标第二虚拟角色;

将所述状态帧发送至所述目标第二虚拟角色对应的目标第二客户端,以在所述目标第二客户端上显示所述游戏状态数据对应的游戏画面。

在一个可行的实施方案中,所述游戏角色划分维度包括下述任意一项或多项:

所述虚拟角色的游戏习惯、角色等级以及角色活跃度。

上述计算机可读存储介质储存有计算机可运行指令,所述计算机可运行指令在被处理器调用和运行时,所述计算机可运行指令还可以促使所述处理器执行以下步骤:

接收服务端发送的状态帧;其中,所述状态帧为所述第一客户端对游戏状态数据进行封装而得到,所述游戏状态数据为所述第一虚拟角色执行所述第一客户端的控制指令过程中生成的游戏状态数据;

在所述图形用户界面中显示所述游戏状态数据对应的游戏画面。

在一个可行的实施方案中,所述在所述图形用户界面中显示所述游戏状态数据对应的游戏画面的步骤,包括:

将所述游戏状态数据对应的游戏画面覆盖显示于所述图形用户界面中。

上述计算机可读存储介质储中的计算机可运行指令在被处理器调用和运行时,所述处理器所执行步骤的具体实施例和具体工作过程,均可以参考上述方法实施例中的对应过程,在此不再赘述。

通过上述方式,第一客户端可以将与其控制的第一虚拟角色相关的游戏状态数据封装为状态帧,再将该状态帧发送至服务端,进而通过服务端将状态帧同步至第二客户端,各个第二客户端便可以从服务端处获取并基于该状态帧直接显示出对应的游戏画面,状态帧解决了帧同步服务端没有任何游戏数据的问题,依然将计算交给客户端来处理,同时由于每个客户端只处理并上传服务器自身控制的虚拟角色相关的游戏状态数据,所以在收到其他客户端的数据时可直接绘图,使各客户端无需再进行一系列关于其他客户端控制的虚拟角色相关的游戏状态数据计算,有效降低了客户端的数据处理量和运行压力,缓解了客户端的数据处理量较大导致客户端的运行压力较大的技术问题。

本公开实施例所提供的游戏中虚拟角色的数据处理装置可以为设备上的特定硬件或者安装于设备上的软件或固件等。本公开实施例所提供的装置,其实现原理及产生的技术效果和前述方法实施例相同,为简要描述,装置实施例部分未提及之处,可参考前述方法实施例中相应内容。所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,前述描述的系统、装置和单元的具体工作过程,均可以参考上述方法实施例中的对应过程,在此不再赘述。

在本公开所提供的实施例中,应该理解到,所揭露装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。

再例如,附图中的流程图和框图显示了根据本公开的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外,在本公开提供的实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述游戏中虚拟角色的数据处理方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释,此外,术语“第一”、“第二”、“第三”等仅用于区分描述,而不能理解为指示或暗示相对重要性。

最后应说明的是:以上所述实施例,仅为本公开的具体实施方式,用以说明本公开的技术方案,而非对其限制,本公开的保护范围并不局限于此,尽管参照前述实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本公开实施例技术方案的范围。都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应以权利要求的保护范围为准。

技术分类

06120114703351