游戏中的信息处理方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机应用技术领域，尤其涉及一种游戏中的信息处理方法、装置、电子设备及存储介质。

背景技术

多个玩家可以同时操作一份游戏数据进行游戏，且根据设定，玩家可以进行不同的操作，各玩家的操作实时互相可见。

以主城共享玩法为例：多个玩家共同使用角色数据来组成一个家族势力，起兵于同一座主城。多个玩家将一同享有该主城的领地、建筑、城内设施及内政效果等，共同完成配置部队、出征土地、升级设施、建造建筑等。

以针对创建部队中的确认环节为例，在一个玩家每次使用角色数据时，需确认所使用的角色数据是否为该玩家所有，针对多个玩家同时操作游戏数据的情况，以两个玩家共享武将组建部队为例：武将甲属于玩家A，玩家B使用武将甲组成部队1，由于武将甲不是玩家B所拥有的武将，在游戏过程中需要对上述确认环节做额外处理，即，不仅确定所使用的角色数据是否为该玩家B所有，还需要确定该角色数据是否为玩家A所有，以便通过确认环节。

在上述针对多个玩家同时操作游戏数据的确认环节中，需要通过额外的编码来修改原有的确认环节逻辑。并且该确认环节是在玩家每次使用游戏数据时均需要执行的，这也会增加针对代码改动的处理量。

发明内容

有鉴于此，本申请实施例至少提供一种游戏中的信息处理方法、装置、电子设备及存储介质，通过正向代理避免了对游戏运行逻辑中的现有环节的改动，减少了额外的编码。

第一方面，本申请示例性实施例提供一种游戏中的信息处理方法，所述方法包括：接收目标玩家在本次虚拟对战中针对目标虚拟元素的触发操作，所述目标玩家为关联组队中的一玩家，所述关联组队包括一主控玩家和至少一个从控玩家；响应于所述触发操作，执行针对所述目标虚拟元素的确认环节；在所述目标虚拟元素通过确认环节时，生成针对所述主控玩家的数据记录；将所生成的数据记录同步至所述关联组队内的每个玩家。

在一可能实施方式中，所述确认环节用于确定所述目标虚拟元素的归属。

在一可能实施方式中，执行针对所述目标虚拟元素的确认环节的步骤包括：确定所述目标虚拟元素是否为所述主控玩家所拥有。

在一可能实施方式中，所述目标虚拟元素通过确认环节包括所述目标虚拟元素为所述主控玩家所有。

在一可能实施方式中，所述主控玩家所拥有的虚拟元素包括所述关联组队所对应的虚拟元素集合中的所有虚拟元素，所述虚拟元素集合包括所述关联组队中的所有玩家所具备的虚拟元素，和/或，每个从控玩家所拥有的虚拟元素包括所述关联组队所对应的虚拟元素集合中的所有虚拟元素。

在一可能实施方式中，还包括：将关联组队中的每个从控玩家均代理为主控玩家，以使每个从控玩家在本次虚拟对战中以主控玩家的身份进行游戏。

在一可能实施方式中，在所述目标虚拟元素通过确认环节时，生成针对所述主控玩家的数据记录的步骤包括：在所述目标虚拟元素通过确认环节时，按照本次虚拟对战中的游戏运行逻辑，执行针对所述触发操作的游戏环节，以生成针对所述主控玩家的与各环节对应的数据记录。

在一可能实施方式中，所述游戏环节包括以下项中的至少一项：针对所述触发操作进行操作结算；针对所述触发操作发放任务奖励；确定是否满足本次虚拟对战的虚拟对局结算条件。

在一可能实施方式中，响应于所述触发操作，生成针对所述主控玩家的数据记录的步骤包括：响应于所述触发操作，在主表中插入所述数据记录，所述主表为用于记录所述主控玩家在本次虚拟对战中的游戏操作的数据表；其中，将所生成的数据记录同步至所述关联组队内的每个虚拟角色的步骤包括：针对每个从控玩家，创建一与该从控玩家对应的从表；在主表中插入所述数据记录的同时，在每个从表中插入对应的一条数据记录。

在一可能实施方式中，在主表中插入的数据记录用于表征的是主控玩家使用目标虚拟元素的记录，在每个从表中插入的数据记录用于表征的是与该从表对应的从控玩家使用目标虚拟元素的记录。

在一可能实施方式中，所述方法还包括：将在主表中插入的数据记录发送至所述主控玩家对应的第一游戏终端，以使第一游戏终端将接收的数据记录直接添加至所述主控玩家的角色数据表中。

在一可能实施方式中，所述方法还包括：针对每个从控玩家，将与该从控玩家对应的从表中插入的数据记录发送至该从控玩家对应的第二游戏终端，以使第二游戏终端根据接收的数据记录更新该从控玩家的角色数据表。

在一可能实施方式中，每个从控玩家对应的角色数据表由第二游戏终端通过以下方式来更新：确定该从控玩家对应的偏移数值；基于接收的数据记录中的键值和所确定的偏移数值，确定恢复键值；使用所确定的恢复键值来更新接收的数据记录中的键值，并将更新后的数据记录添加至该从控玩家的角色数据表中。

在一可能实施方式中，不同从控玩家对应的偏移数值是不同的，每个从控玩家对应的偏移数值是基于针对各从控玩家预先设置的存储区域来确定的。

在一可能实施方式中，所述主控玩家为从所述关联组队中随机选中的一玩家，或者，所述主控玩家为基于所述关联组队中各玩家的选择操作而确定出的玩家；所述至少一个从控玩家为所述关联组队中除所述主控玩家之外的其他玩家。

第二方面，本申请实施例还提供一种游戏中的信息处理装置，所述装置包括：接收模块，接收目标玩家在本次虚拟对战中针对目标虚拟元素的触发操作，所述目标玩家为关联组队中的一玩家，所述关联组队包括一主控玩家和至少一个从控玩家；确认模块，响应于所述触发操作，执行针对所述目标虚拟元素的确认环节；生成模块，在所述目标虚拟元素通过确认环节时，生成针对所述主控玩家的数据记录；同步模块，将所生成的数据记录同步至所述关联组队内的每个玩家。

第三方面，本申请实施例还提供一种电子设备，处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行上述方法的步骤。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述方法的步骤。

本申请实施例提供的游戏中的信息处理方法、装置、电子设备及存储介质，在游戏过程中无需对原有环节的逻辑进行修改，减少了额外的编码。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出本申请示例性实施例提供的游戏中的信息处理方法的流程图；

图2示出现有的确认环节的逻辑流程示意图；

图3示出本申请示例性实施例提供的数据交互流程图；

图4示出本申请示例性实施例提供的更新从控玩家对应的角色数据表的步骤的流程图；

图5示出本申请示例性实施例提供的游戏中的信息处理装置的结构示意图；

图6示出本申请示例性实施例提供的电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中的附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应当理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

本说明书中使用用语“一个”、“一”、“该”和“所述”用以表示存在一个或多个要素/组成部分/等；用语“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”和“第二”等仅作为标记使用，不是对其对象的数量限制。

应当理解，在本申请实施例中，“至少一个”是指一个或者多个，“多个”是指两个或者两个以上。“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“包含A、B和/或C”是指包含A、B、C三者中任1个或任2个或3个。

应当理解，在本申请实施例中，“与A对应的B”、“与A相对应的B”、“A与B相对应”或者“B与A相对应”，表示B与A相关联，根据A可以确定B。根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其他信息确定B。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的全部其他实施例，都属于本申请保护的范围。

在游戏中，多个玩家可以同时操作一份游戏数据进行游戏，且根据设定，玩家可以执行不同的操作，各玩家的操作实时互相可见。

下面以主城共享玩法为例进行介绍：多个玩家共同使用角色数据来组成一个家族势力，起兵于同一座主城，多个玩家将一同享有该主城的领地、建筑、城内设施及内政效果等，共同完成配置部队、出征土地、升级设施、建造建筑等。

以针对创建部队中的确认环节(Check环节)为例，每当一个玩家使用角色数据时，均需确认所使用的角色数据是否为该玩家所有。

针对多个玩家同时操作游戏数据的情况，以两个玩家共享武将组建部队为例：武将甲属于玩家A，玩家B使用武将甲组成部队1。由于武将甲不是玩家B所拥有的武将，在游戏过程中需要对上述确认环节做额外处理，即，不仅确定所使用的角色数据是否为该玩家B所有，还需要确定该角色数据是否为玩家A所有，以便通过Check环节。

在上述针对多个玩家同时操作游戏数据的确认环节中，需要通过额外的编码来修改原有的确认环节的逻辑。并且该确认环节是在玩家每次使用游戏数据时均需要执行的，这也会增加针对代码改动的处理量。

针对上述问题，本申请提出一种游戏中的信息处理方法、装置、电子设备及存储介质，能够通过正向代理，将从控玩家代理成主控玩家，避免了对游戏运行逻辑中的现有环节的改动，减少了额外的编码。

首先，对本申请实施例中涉及的名称进行简单介绍。

在本申请实施例中，可以通过终端设备提供图形用户界面，在图形用户界面中显示游戏场景，其中：

终端设备：

本申请实施例中涉及的终端设备主要是指用于提供游戏场景，并能够对虚拟角色进行控制操作的智能设备，终端设备可以包括但不限于以下设备中的任意一种：智能手机、平板电脑、便携式计算机、台式计算机、游戏机、个人数字助理(PDA)、电子书阅读器、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器等。该终端设备中安装和运行有支持游戏场景的应用程序，比如支持三维游戏场景的应用程序。该应用程序可以包括但不限于虚拟现实应用程序、三维地图程序、军事仿真程序、MOBA游戏、多人枪战类生存游戏、第三人称射击游戏(TPS，Third-Personal ShootingGame)中的任意一种。可选地，该应用程序可以是单机版的应用程序，比如单机版的3D游戏程序，也可以是网络联机版的应用程序。

图形用户界面：

是一种人与计算机通信的界面显示格式，允许用户使用鼠标或键盘等输入设备操纵屏幕上的图标、标识或菜单选项，也允许用户通过在触控终端的触控屏上执行触摸操作来操纵屏幕上的图标或菜单选项，以选择命令、启动程序或执行其它一些任务等。这里的图形用户界面中显示游戏场景。

虚拟场景：

是应用程序在终端或服务器上运行时显示(或提供)的虚拟场景。可选地，该虚拟场景是对真实世界的仿真环境，或者是半仿真半虚构的虚拟环境，或者是纯虚构的虚拟环境。虚拟场景是二维虚拟场景和三维虚拟场景中的任意一种，虚拟环境可以为天空、陆地、海洋等，其中，该陆地包括沙漠、城市等环境元素。其中，虚拟场景为用户控制虚拟对象等完整游戏逻辑的场景。

虚拟角色：

是指在虚拟环境中的虚拟角色，该虚拟角色可以是由玩家操控的虚拟角色，包括但不限于虚拟人物、虚拟动物、动漫人物中的至少一种，可以是非玩家操控的虚拟角色(NPC)，还可以是虚拟物体，指虚拟场景中的静态角色，例如，虚拟场景中的虚拟道具、虚拟任务、虚拟环境中的一个位置、地形、房屋、桥梁、植被等。静态角色往往不受玩家直接控制，但可以响应场景中虚拟角色的交互行为(如，攻击、拆除等)，而作出相应的表现，例如：虚拟角色可以对建筑物进行拆除、拾取、拖拽、建造等。可选地，虚拟物体也可以无法响应虚拟角色的交互行为，例如，虚拟物体同样可以为游戏场景中的建筑物、门、窗、植等，但是虚拟角色并不能与其进行交互，比如，虚拟角色不能对窗进行破坏或是拆除等。可选地，当虚拟环境为三维虚拟环境时，虚拟角色可以是三维虚拟模型，每个虚拟角色在三维虚拟环境中具有自身的形状和体积，占据三维虚拟环境中的一部分空间。可选地，虚拟角色是基于三维人体骨骼技术构建的三维角色，该虚拟角色通过穿戴不同的皮肤来实现不同的外在形象。在一些实现方式中，虚拟角色也可以采用2.5维或2维模型来实现，本申请实施例对此不加以限定。

在虚拟场景中可以存在有多个虚拟角色，该虚拟角色是玩家操控的虚拟角色(即，玩家通过输入设备进行控制的角色)、或者是通过训练设置在虚拟环境对战中的人工智能(Artificial Intelligence，AI)。可选地，该虚拟角色是在游戏场景中进行竞技的虚拟人物。可选地，该游戏场景对战中的虚拟角色的数量是预设设置的，或者是根据加入虚拟对战的终端设备的数量动态确定的，本申请实施例对此不作限定。在一种可能实现方式中，用户能够控制虚拟角色在该虚拟场景中进行移动，例如，控制拟角色跑动、跳动、爬行等，也能够控制虚拟角色使用应用程序所提供的技能、虚拟道具等与其他虚拟角色进行战斗。

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

对本申请可适用的应用场景进行介绍。本申请可应用于游戏技术领域，在游戏中，由参与游戏的多个玩家共同加入同一局虚拟对战中。

在进入虚拟对战之前，玩家可以为自己在虚拟对战中的虚拟角色选择不同的角色属性，例如，身份属性，通过分配不同的角色属性以确定不同阵营，使得玩家在本次虚拟对战的不同对局阶段通过执行游戏分配的任务，以赢得游戏比赛，例如，具有A角色属性的多个虚拟角色通过在对局阶段将具有B角色属性的虚拟角色进行“淘汰”，以获得游戏比赛的胜利。这里，还可以是在进入虚拟对战时，为参与本次虚拟对战的每个虚拟角色随机分配角色属性。

在本申请一个实施例提供的实施环境可以包括：第一终端设备、服务器和第二终端设备。第一终端设备和第二终端设备分别与服务器进行通信，以实现数据通信。在本实施方式中，第一终端设备和第二终端设备分别安装有执行本申请所提供的游戏中的信息处理方法的应用程序，服务器为执行本申请的提供的游戏中的信息处理方法的服务器端。通过应用程序，使得第一终端设备和第二终端设备分别可以与服务器进行通信。

以第一终端设备为例，第一终端设备通过运行应用程序与服务器建立通信。在一可选的实施方式中，服务器根据应用程序的游戏请求建立虚拟对战。其中，虚拟对战的参数可以根据接收到的游戏请求中的参数进行确定，例如，虚拟对战的参数可包括参与虚拟对战的人数，参与虚拟对战的角色级别等。当第一终端设备接收到游戏服务器的响应时，通过第一终端设备的图形用户界面显示虚拟对战所对应的游戏场景，第一终端设备为第一用户控制的设备，第一终端设备的图形用户界面中所显示的虚拟角色为该第一用户控制的玩家角色(即第一虚拟角色)，第一用户通过图形用户界面输入操作指令，以控制玩家角色在游戏场景中执行相应的操作。

以第二终端设备为例，第二终端设备通过运行应用程序与服务器建立通信。在一可选的实施方式中，服务器根据应用程序的游戏请求建立虚拟对战。其中，虚拟对战的参数可以根据接收到的游戏请求中的参数进行确定，例如，虚拟对战的参数可包括参与虚拟对战的人数，参与虚拟对战的角色级别等。当第二终端设备接收到服务器的响应时，通过第二终端设备的图形用户界面显示虚拟对战所对应的游戏场景。第二终端设备为第二用户控制的设备，第二终端设备的图形用户界面中所显示的虚拟角色为该第二用户控制的玩家角色(即第二虚拟角色)，第二用户通过图形用户界面输入操作指令，以控制玩家角色在虚拟场景中执行相应的操作。

服务器通过接收第一终端设备和第二终端设备上报的游戏数据，进行数据计算，并将计算后的游戏数据同步至第一终端设备和第二终端设备，使得第一终端设备和第二终端设备根据游戏服务器下发的同步数据控制图形用户界面渲染出对应的游戏场景和/或虚拟角色。

在本实施方式中，第一终端设备控制的第一虚拟角色和第二终端设备控制的第二虚拟角色为处于同一局虚拟对战中的虚拟角色。其中，第一终端设备控制的第一虚拟角色和第二终端设备控制的第二虚拟角色可以具有相同的角色属性，也可以具有不同的角色属性，第一终端设备控制的第一虚拟角色和第二终端设备控制的第二虚拟角色可以属于相同的阵营，也可以属于不同的阵营。

需要说明的是，虚拟对战中，可以包括两个或是两个以上的虚拟角色，不同的虚拟角色可以分别对应不同的终端设备，也就是说，在虚拟对战中，存在两个以上的终端设备分别与游戏服务器进行游戏数据的发送和同步。

为便于对本申请进行理解，下面对本申请实施例提供的游戏中的信息处理方法、装置、电子设备及存储介质进行详细介绍。

请参阅图1，为本申请示例性实施例提供的游戏中的信息处理方法的流程图，该信息处理方法具体包括：

步骤S101：接收目标玩家在本次虚拟对战中针对目标虚拟元素的触发操作。

在本申请示例性实施例中，目标玩家为关联组队中的一玩家，该关联组队包括一主控玩家和至少一个从控玩家。也就是说，上述目标玩家可以是主控玩家，也可以是从控玩家。

示例性的，上述关联组队可以是基于参与本次虚拟对战的每个虚拟角色的角色属性而形成的阵营，或者，还可以是玩家在进入本次虚拟对战之前或者在本次虚拟对战过程中通过主动选择而形成的队伍。

此外，在形成关联组队之后，可以先确定出一主控玩家，至少一个从控玩家为关联组队中除主控玩家之外的其他虚拟角色，在此情况下，可以将关联组队中的每个从控玩家均代理为主控玩家，以使每个从控玩家在本次虚拟对战中以主控玩家的身份进行游戏。

下面介绍从关联组队中确定主控玩家的方式，但应理解，本申请不限于此，还可以通过其他方式来从关联组队中确定出主控玩家。

一种情况，主控玩家为从关联组队中随机选中的一玩家。

例如，在每个关联组队中，主控玩家的数量为1，可以在形成关联组队之后，从关联组队内的多个玩家中随机选中一玩家，确定为主控玩家，将多个玩家中除随机选中的玩家之外的其他玩家，确定为从控玩家。

类似地，针对上述情况，也可以只允许一个玩家通过终端设备选择其在关联组队内的身份，例如，可以从关联组队中随机选中一玩家，被选中的玩家具备身份选择资格，或者，该玩家也可以指第一个选择主控玩家的玩家。

通过上述方式，关联组队内的多个玩家被划分为一主控玩家和至少一个从控玩家，关联组队内的各玩家可以同时操作一份游戏数据进行游戏，各玩家的操作实时互相可见。

另一种情况，主控玩家为基于关联组队中各玩家的选择操作而确定出的玩家。

例如，在形成关联组队之后，属于该关联组队的各玩家需通过终端设备选择在该关联组队内的身份。

在一可选示例中，主控玩家可以为关联组队内的多个玩家通过投票被选举出的玩家。示例性的，可以通过以下方式确定主控玩家：根据对关联组队内的各玩家的投票结果，确定出主控玩家。这里，该主控玩家为关联组队内获得票数最多的玩家。

例如，统计针对每个玩家的投票结果的过程可以如下：针对关联组队内的每个玩家对应的玩家标识，在该玩家标识的关联区域显示针对该玩家标识所指示的玩家的投票控件。响应于关联组队内的各玩家对投票控件的投票操作，执行对应的投票指令，统计针对每个玩家的投票结果。

这里，可以在预设显示界面中显示各玩家对应的玩家标识，示例性的，该预设显示界面可以是静态显示界面，例如，用于设置/修改游戏参数的相关属性的配置界面，还可以是动态显示界面，例如，用于呈现实时游戏场景的游戏画面。

在一示例中，可以针对玩家所对应的投票控件进行操作，来完成投票操作。

在另一示例中，还可以基于邀请请求来完成投票。

例如，接收终端设备对应的玩家对自身的投票控件的投票操作，根据对自身的投票控件的投票操作，执行对应的投票指令，并产生邀请请求，发送至关联组队内的其他玩家对应的其他终端设备，以使其他终端设备基于针对邀请请求的反馈来进行投票。

应理解，在上述实施例中，是基于投票控件来执行投票操作的，但本申请不限于此，也可以通过直接点击玩家的玩家标识，来执行投票操作。

在本申请一实施例中，目标虚拟元素可以是关联组队所对应的虚拟元素集合中的虚拟元素，虚拟元素可以游戏中的虚拟资源。例如，虚拟元素可以包括但不限于以下项中的至少一项：虚拟角色、虚拟物品、组建的队伍、获得的任务奖励、虚拟模型。

示例性的，虚拟角色可以包括各玩家在本次虚拟对战中所使用的虚拟角色，或者各玩家在游戏中所拥有的虚拟角色，在游戏中可以将相同类型或不同类型的虚拟角色组建成编队以执行游戏作战任务。虚拟物品可以指用于提升虚拟角色的战斗能力的虚拟物品，例如，游戏中的虚拟道具、虚拟武器。作为示例，虚拟物品可以包括但不限于以下项中的至少一项：虚拟角色所持有的虚拟武器、装备在虚拟角色身上或者附加在虚拟武器上的虚拟配件。作为示例，虚拟配件可指宝石、枪托等可以附加在武器上的配件。虚拟模型可以游戏中的各类虚拟建筑，如虚拟城池，玩家在游戏中通过作战争夺各个虚拟城池的控制权。

在本申请一实施例中，触发操作可以为目标玩家对目标虚拟元素的控制操作，例如，对虚拟角色进行编队、对虚拟物品进行使用/分配、对虚拟建筑进行管理等。该触发操作的类型可以多种，既可以是在触摸显示屏中执行的触控式操作，也可以是通过鼠标、手柄等外设设备执行的非触控式操作。

步骤S102：响应于触发操作，执行针对目标虚拟元素的确认环节。

在本申请实施例中，确认环节可以用于确定目标虚拟元素的归属，即，确定目标虚拟元素是否为关联组队共享的虚拟元素。示例性的，可以确定目标虚拟元素是否为主控玩家所拥有。

这里，主控玩家所拥有的虚拟元素包括关联组队所对应的虚拟元素集合中的所有虚拟元素，该虚拟元素集合包括关联组队中的所有玩家所具备的虚拟元素。此外，每个从控玩家所拥有的虚拟元素也包括关联组队所对应的虚拟元素集合中的所有虚拟元素。也就是说，关联组队内的各玩家所拥有的虚拟元素可以由各玩家共享使用。

下面结合图2来阐述本申请与现有技术在多个玩家协调操作一份游戏数据的过程中的差异。

图2示出现有的确认环节的逻辑流程示意图。

在本示例中，假设玩家B未组成关联组队、且武将甲归玩家B所有，此时，如图2所示，当玩家B在本次虚拟对战中使用武将甲创建部队一时，需执行Check环节，即，确认武将甲的归属，是否为玩家B所有，若武将甲为玩家B在该游戏中(或者本次虚拟对战中)所拥有的虚拟角色，则生成一数据记录，该数据记录中的键值(army_id)为1，用户(user)为玩家B，所使用的虚拟角色(hero)为武将甲。

若在本次虚拟对战中玩家B与玩家A开启共享玩法，两个玩家可以共享对方的游戏数据。例如，假设玩家A具有武将甲，玩家B使用玩家A的武将甲来创建部队一，由于武将甲不是玩家B所拥有的武将，在游戏过程中需要对上述确认环节做额外处理，即，不仅确定所使用的角色数据是否为该玩家B所有，还需要确定该角色数据是否为玩家A所有，以便通过Check环节。

在本申请实施例中，将关联组队中的各玩家的操作均代理为主控玩家，在此情况下，确认环节仅需确认所使用的目标虚拟元素是否为主控玩家所有即可，避免了对代码的改动。

步骤S103：在目标虚拟元素通过确认环节时，生成针对主控玩家的数据记录。

示例性的，目标虚拟元素通过确认环节可以指目标虚拟元素为主控玩家所有，目标虚拟元素未通过确认环节可以指目标虚拟元素不属于主控玩家所拥有。

这里，上述触发操作可以由关联组队中的任一玩家来执行，即，可以由关联组队中的主控玩家或者从控玩家来针对目标虚拟元素执行触发操作，但所生成的数据记录仅指向主控玩家。

也就是说，关联组队中的从控玩家在本次虚拟对战中的操作，通过正向代理，代理成主控玩家来操作游戏。在本申请实施例中，通过对从控玩家的正向代理，减少了现有技术中多个玩家同时操作游戏数据情况下的Check环节，还避免了对Check环节代码的改动。

在目标虚拟元素通过确认环节时，按照本次虚拟对战中的游戏运行逻辑，执行针对触发操作的游戏环节，以生成针对主控玩家的与各环节对应的数据记录。

示例性的，游戏环节可以包括但不限于以下项中的至少一项：针对触发操作进行操作结算(如，结算虚拟角色在该触发操作后的虚拟战斗力、血量值、伤害值)；针对触发操作发放任务奖励；确定是否满足本次虚拟对战的虚拟对局结算条件。也就是说，可以针对确认环节、至少一个游戏环节，分别生成对应的一条的数据记录。

返回图1，步骤S104：将所生成的数据记录同步至关联组队内的每个玩家。

在现有技术中，以上述两个玩家共享武将组建部队为例，在玩家B使用武将甲组成部队1之后，直接生成玩家B的数据记录，如图2中所示的数据记录。但由于武将甲是玩家A所拥有的武将，此时，还需要通过额外的协议将数据记录同步给玩家A。

并且，在将数据记录同步给玩家A时，需要对数据记录进行修改，以玩家B使用玩家A的武将甲来组建部队1为例，在生成如图2所示的一条数据记录之后，在同步给玩家A时，需将user(用户)由B修改为A，即，需要对玩家的数据记录做拼接处理，导致不够直观。

在本申请实施例中，关联组队中所有需要同步的数据记录，依赖于主控玩家(Master)的变动，并将每次Master的数据记录的修改同步给从控玩家(Slave)，从而保证从控玩家的数据记录的正确性和及时性。并且从控玩家的数据记录仅仅用于客户端读取，具体的游戏逻辑部分全部使用Master的数据记录。

下面介绍本申请实施例中具体的数据记录同步过程。

在本申请实施例中，可以针对Master创建主表，针对各Slave分别创建从表，例如，在上述步骤S103中，可以在目标虚拟元素通过确认环节时，在主表中插入数据记录。这里，主表为用于记录主控玩家在本次虚拟对战中的游戏操作的数据表。

在此情况下，针对每个从控玩家，创建一与该从控玩家对应的从表，在主表中插入数据记录的同时，在每个从表中插入对应的一条数据记录。

下面结合图3来介绍数据记录同步的过程以及客户端进行数据记录读取的过程。

图3示出本申请示例性实施例提供的数据交互流程图。

在本示例中，以两个玩家共享武将组建部队为例：玩家A、玩家B、武将甲、部队1，其中，武将甲属于玩家A，选取玩家A作为Master，玩家B为Slave，玩家B使用武将甲组成部队1。

在此情况下，可以将玩家B代理为Master玩家A，玩家B使用Master数据进行游戏。

玩家B使用玩家A的武将甲组成了一支属于玩家A的部队1(该部队1也属于玩家B)，这样就可以避免现有方案中，对Check环节的额外处理。且保证了所有的数据操作都是在主表上进行，便于后续同步数据。

在组成部队1之后，为玩家B生成Army_Slave(从表)。如图3所示，Army为主表，Army_Slave为从表。关联组队所有的数据操作均在主表上进行，再通过逻辑Hook同步给从表。逻辑Hook的作用是屏蔽数据修改的原因，让数据同步变得简单。

下面以主表Army和从表Army_Salve为例介绍逻辑Hook：在玩家B使用武将甲组成部队1之后，以生成与确认环节对应的数据记录为例，在Army表中为玩家A插入一条数据记录，该数据记录中的键值(army_id)为1，用户(user)为玩家A，所使用的虚拟角色(hero)为武将甲。通过逻辑Hook，为玩家B在从表中也插入一条数据记录，该数据记录中的键值(army_id)为1，用户(user)为玩家B，所使用的虚拟角色(hero)为武将甲。在上述同步的过程中，并不关心为何插入这条数据记录，只需要在同步过程中为对应玩家添加数据记录和修改id即可。

从上述示例可以看出，在主表中插入的数据记录用于表征的是主控玩家使用目标虚拟元素的记录，在每个从表中插入的数据记录用于表征的是与该从表对应的从控玩家使用目标虚拟元素的记录。

在一优选示例中，上述执行的正向代理环节、确认环节(还有其他与游戏功能相关的环节)以及数据同步的过程可以在游戏的服务器中执行。在此情况下，在本申请示例性实施例中，还可以将在主表中插入的数据记录发送至主控玩家对应的第一游戏终端，以使第一游戏终端将接收的数据记录直接添加至主控玩家的角色数据表中。

也就是说，主控玩家对应的第一游戏终端可以读取主表中的数据记录，直接添加至主控玩家的角色数据表中，无需进行转换、修改。

此外，针对每个从控玩家，还可以将与该从控玩家对应的从表中插入的数据记录发送至该从控玩家对应的第二游戏终端，以使第二游戏终端根据接收的数据记录更新该从控玩家的角色数据表。也就是说，从控玩家对应的第二游戏终端在接收到从表Army_Slave中的数据记录，需进行转换，以添加到该从控玩家的角色数据表中。

图4示出本申请示例性实施例提供的更新从控玩家对应的角色数据表的步骤的流程图。

如图4所示，在步骤S201中，确定从控玩家对应的偏移数值。

这里，不同从控玩家对应的偏移数值是不同的，每个从控玩家对应的偏移数值是基于针对各从控玩家预先设置的存储区域来确定的。

例如，可以预先对存储区间进行划分，在所划分的不同存储区域中分别存储各玩家对应的游戏数据，然后基于从控玩家所对应的存储区域与主控玩家所对应的存储区域之间的地址差值(如编号差值)来确定该从控玩家对应的偏移数值。

在步骤S202中，基于接收的数据记录中的键值和所确定的偏移数值，确定恢复键值。

这里，该从控玩家的从表中的army_id表示该数据记录的键值，将该键值与从控玩家对应的偏移数值之和，确定为恢复键值。

在步骤S203中，使用所确定的恢复键值来更新接收的数据记录中的键值，并将更新后的数据记录添加至该从控玩家的角色数据表中。

也就是说，通过上述过程仅需对从表中的键值进行偏移，避免了对玩家的数据记录做拼接处理。

在本申请实施例中，通过逻辑Hook，做到不新增协议去同步玩家数据，也解决了玩家数据不直观的问题。

基于同一申请构思，本申请实施例中还提供了与上述实施例提供的方法对应的游戏中的信息处理装置，由于本申请实施例中的装置解决问题的原理与本申请上述实施例的游戏中的信息处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

图5为本申请示例性实施例提供的游戏中的信息处理装置的结构示意图。如图5所示，该游戏中的信息处理装置300包括：

接收模块310，接收目标玩家在本次虚拟对战中针对目标虚拟元素的触发操作，所述目标玩家为关联组队中的一玩家，所述关联组队包括一主控玩家和至少一个从控玩家；

确认模块320，响应于所述触发操作，执行针对所述目标虚拟元素的确认环节；

生成模块330，在所述目标虚拟元素通过确认环节时，生成针对所述主控玩家的数据记录；

同步模块340，将所生成的数据记录同步至所述关联组队内的每个玩家。

在本申请的一种可能实施方式中，所述确认环节用于确定所述目标虚拟元素的归属。

在本申请的一种可能实施方式中，确认模块330还用于：确定所述目标虚拟元素是否为所述主控玩家所拥有。

在本申请的一种可能实施方式中，所述目标虚拟元素通过确认环节包括所述目标虚拟元素为所述主控玩家所拥有。

在本申请的一种可能实施方式中，所述主控玩家所拥有的虚拟元素包括所述关联组队所对应的虚拟元素集合中的所有虚拟元素，所述虚拟元素集合包括所述关联组队中的所有玩家所具备的虚拟元素，和/或，每个从控玩家所拥有的虚拟元素包括所述关联组队所对应的虚拟元素集合中的所有虚拟元素。

在本申请的一种可能实施方式中，接收模块310还用于：将关联组队中的每个从控玩家均代理为主控玩家，以使每个从控玩家在本次虚拟对战中以主控玩家的身份进行游戏。

在本申请的一种可能实施方式中，生成模块330还用于：在所述目标虚拟元素通过确认环节时，按照本次虚拟对战中的游戏运行逻辑，执行针对所述触发操作的游戏环节，以生成针对所述主控玩家的与各环节对应的数据记录。

在本申请的一种可能实施方式中，所述游戏环节包括以下项中的至少一项：针对所述触发操作进行操作结算；针对所述触发操作发放任务奖励；确定是否满足本次虚拟对战的虚拟对局结算条件。

在本申请的一种可能实施方式中，生成模块320还用于：响应于所述触发操作，在主表中插入所述数据记录，所述主表为用于记录所述主控玩家在本次虚拟对战中的游戏操作的数据表；其中，同步模块340还用于：针对每个从控玩家，创建一与该从控玩家对应的从表；在主表中插入所述数据记录的同时，在每个从表中插入对应的一条数据记录。

在本申请的一种可能实施方式中，在主表中插入的数据记录用于表征的是主控玩家使用目标虚拟元素的记录，在每个从表中插入的数据记录用于表征的是与该从表对应的从控玩家使用目标虚拟元素的记录。

在本申请的一种可能实施方式中，还包括：发送模块，将在主表中插入的数据记录发送至所述主控玩家对应的第一游戏终端，以使第一游戏终端将接收的数据记录直接添加至所述主控玩家的角色数据表中。

在本申请的一种可能实施方式中，发送模块还用于：针对每个从控玩家，将与该从控玩家对应的从表中插入的数据记录发送至该从控玩家对应的第二游戏终端，以使第二游戏终端根据接收的数据记录更新该从控玩家的角色数据表。

在本申请的一种可能实施方式中，每个从控玩家对应的角色数据表由第二游戏终端通过以下方式来更新：确定该从控玩家对应的偏移数值；基于接收的数据记录中的键值和所确定的偏移数值，确定恢复键值；使用所确定的恢复键值来更新接收的数据记录中的键值，并将更新后的数据记录添加至该从控玩家的角色数据表中。

在本申请的一种可能实施方式中，不同从控玩家对应的偏移数值是不同的，每个从控玩家对应的偏移数值是基于针对各从控玩家预先设置的存储区域来确定的。

在本申请的一种可能实施方式中，所述主控玩家为从所述关联组队中随机选中的一玩家，或者，所述主控玩家为基于所述关联组队中各玩家的选择操作而确定出的玩家；所述至少一个从控玩家为所述关联组队中除所述主控玩家之外的其他玩家。

通过上述信息处理装置，在游戏过程中无需对原有的确认环节的逻辑进行修改，减少了额外的编码。此外，通过逻辑Hook，在不新增协议的情况下实现同步玩家数据。

请参阅图6，图6为本申请示例性实施例提供的电子设备的结构示意图。如图6所示，该电子设备400包括处理器410、存储器420和总线430。

所述存储器420存储有所述处理器410可执行的机器可读指令，当电子设备400运行时，所述处理器410与所述存储器420之间通过总线430通信，所述机器可读指令被所述处理器410执行时，可以执行如上述任一实施例中游戏中的信息处理方法的步骤，具体如下：

接收目标玩家在本次虚拟对战中针对目标虚拟元素的触发操作，所述目标玩家为关联组队中的一玩家，所述关联组队包括一主控玩家和至少一个从控玩家；响应于所述触发操作，生成针对所述主控玩家的数据记录；执行针对所述目标虚拟元素的确认环节；若所述目标虚拟元素通过确认环节，则将所生成的数据记录同步至所述关联组队内的每个玩家。

本申请实施例还提供一种计算机可读存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时可以执行如上述任一实施例中游戏中的信息处理方法的步骤，具体如下：

接收目标玩家在本次虚拟对战中针对目标虚拟元素的触发操作，所述目标玩家为关联组队中的一玩家，所述关联组队包括一主控玩家和至少一个从控玩家；响应于所述触发操作，生成针对所述主控玩家的数据记录；执行针对所述目标虚拟元素的确认环节；若所述目标虚拟元素通过确认环节，则将所生成的数据记录同步至所述关联组队内的每个玩家。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应所述理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。