CN110705219A - 游戏数据处理方法、装置、存储介质与电子设备 - Google Patents

Abstract

本公开提供一种游戏数据处理方法、游戏数据处理装置、计算机可读存储介质与电子设备，涉及数据处理技术领域。该方法包括：获取第一格式的初始数据文件，所述第一格式为基于游戏引擎的数据格式；通过所述游戏引擎将所述初始数据文件由所述第一格式转换为第二格式，所述第二格式为基于办公软件的数据格式；将所述第二格式的初始数据文件发送至终端，使所述终端在所述办公软件中打开所述第二格式的初始数据文件。本公开可以方便产品人员使用办公软件对游戏数据进行处理，节省人力和时间成本，且无需在终端上运行游戏引擎，提高处理效率。

Description

游戏数据处理方法、装置、存储介质与电子设备

技术领域

本公开涉及数据处理技术领域，尤其涉及一种游戏数据处理方法、游戏数据处理装置、计算机可读存储介质与电子设备。

背景技术

在游戏开发项目中，通常需要产品人员(或策划人员)与技术人员(或开发人员、程序员)的相互配合，产品人员从前端应用、功能等角度对游戏提出修改需求和意见，技术人员从底层通过修改数据、代码、配置等实现这些需求和意见。

随着项目复杂性、长期性的提高，为了优化项目流程，上述两部分人员的职能也需要互相渗透，如产品人员应当负责一部分数据方面的工作。然而，游戏项目中的数据，如程序的静态数据等，大多是基于游戏引擎的数据格式保存和管理的，通过游戏引擎编辑这些数据，需要产品人员学习和掌握游戏引擎的相关操作，这无疑增加了人力和时间成本，实用性较低。

鉴于此，有必要提出一种有效的游戏数据处理方法，以解决上述技术问题。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供了一种游戏数据处理方法、游戏数据处理装置、计算机可读存储介质与电子设备，进而至少在一定程度上克服现有技术耗费人力和时间成本的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的第一方面，提供一种游戏数据处理方法，包括：获取第一格式的初始数据文件，所述第一格式为基于游戏引擎的数据格式；通过所述游戏引擎将所述初始数据文件由所述第一格式转换为第二格式，所述第二格式为基于办公软件的数据格式；将所述第二格式的初始数据文件发送至终端，使所述终端在所述办公软件中打开所述第二格式的初始数据文件。

可选的，所述获取第一格式的初始数据文件，包括：接收由所述终端发送的所述第一格式的初始数据文件。

可选的，在将所述第二格式的初始数据文件发送至终端后，所述方法还包括：从所述终端接收第二格式的目标数据文件，所述第二格式的目标数据文件由所述终端根据用户输入的指令编辑所述第二格式的初始数据文件而得到；将所述目标数据文件由所述第二格式转换为所述第一格式；将所述第一格式的目标数据文件发送至所述终端，使所述终端采用所述第一格式的目标数据文件覆盖所述第一格式的初始数据文件。

可选的，所述获取第一格式的初始数据文件，包括：接收由所述终端发送的所述初始数据文件的名称，根据所述初始数据文件的名称查找所述第一格式的初始数据文件。

可选的，所述根据所述初始数据文件的名称查找所述第一格式的初始数据文件，包括：载入索引目录，根据所述初始数据文件的名称在所述索引目录中查找对应的存储路径；从所述存储路径获取所述第一格式的初始数据文件。

可选的，所述接收由所述终端发送的所述初始数据文件的名称，包括：和所述终端建立连接，并通过所述连接接收由所述终端发送的数据获取请求，所述数据获取请求包括所述初始数据文件的名称；所述将所述第二格式的初始数据文件发送至终端，包括：向所述终端发送所述第二格式的初始数据文件的大小，再发送所述第二格式的初始数据文件；在所述终端反馈成功接收所述第二格式的初始数据文件后，断开所述连接。

可选的，在将所述第二格式的初始数据文件发送至终端后，所述方法还包括：从所述终端接收第二格式的目标数据文件，所述第二格式的目标数据文件由所述终端根据用户输入的指令编辑所述第二格式的初始数据文件而得到；将所述目标数据文件由所述第二格式转换为所述第一格式；存储所述第一格式的目标数据文件，以覆盖所述第一格式的初始数据文件。

可选的，所述从所述终端接收第二格式的目标数据文件，包括：从所述终端接收数据保存请求，所述数据保存请求包括所述初始数据文件的名称；当根据所述初始数据文件的名称查找到所述第一格式的初始数据文件，且所述第一格式的初始数据文件为未锁定状态时，通过所述数据保存请求，并将所述第一格式的初始数据文件锁定；从所述终端接收所述第二格式的目标数据文件的大小，再接收所述第二格式的目标数据文件；当接收成功时，向所述终端反馈成功接收的信息。

可选的，所述通过所述游戏引擎将所述初始数据文件由所述第一格式转换为第二格式，包括：通过所述游戏引擎加载所述第一格式的初始数据文件；利用所述游戏引擎中预先配置的接口对所述第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件；将所述中间格式的初始数据文件转换为所述第二格式的初始数据文件。

可选的，在对所述第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件后，还进行以下任意一种或多种后处理：删除所述中间格式的初始数据文件中的冗余信息；对所述中间格式的初始数据文件中的空白字段做规则化处理；调整所述中间格式的初始数据文件的浮点数。

根据本公开的第二方面，提供一种游戏数据处理装置，包括：获取模块，用于获取第一格式的初始数据文件，所述第一格式为基于游戏引擎的数据格式；转换模块，用于通过所述游戏引擎将所述初始数据文件由所述第一格式转换为第二格式，所述第二格式为基于办公软件的数据格式；发送模块，用于将所述第二格式的初始数据文件发送至终端，使所述终端在所述办公软件中打开所述第二格式的初始数据文件。

可选的，所述获取模块，用于接收由所述终端发送的所述第一格式的初始数据文件。

可选的，所述获取模块，还用于从所述终端接收第二格式的目标数据文件，所述第二格式的目标数据文件由所述终端根据用户输入的指令编辑所述第二格式的初始数据文件而得到；所述转换模块，还用于将所述目标数据文件由所述第二格式转换为所述第一格式；所述发送模块，还用于将所述第一格式的目标数据文件发送至所述终端，使所述终端采用所述第一格式的目标数据文件覆盖所述第一格式的初始数据文件。

可选的，所述获取模块，用于接收由所述终端发送的所述初始数据文件的名称，根据所述初始数据文件的名称查找所述第一格式的初始数据文件。

可选的，所述获取模块，用于载入索引目录，根据所述初始数据文件的名称在所述索引目录中查找对应的存储路径，并从所述存储路径获取所述第一格式的初始数据文件。

可选的，所述获取模块，还用于和所述终端建立连接，并通过所述连接接收由所述终端发送的数据获取请求，所述数据获取请求包括所述初始数据文件的名称；所述发送模块，还用于向所述终端发送所述第二格式的初始数据文件的大小，再发送所述第二格式的初始数据文件，以及在所述终端反馈成功接收所述第二格式的初始数据文件后，断开所述连接。

可选的，所述获取模块，还用于从所述终端接收第二格式的目标数据文件，所述第二格式的目标数据文件由所述终端根据用户输入的指令编辑所述第二格式的初始数据文件而得到；所述转换模块，还用于将所述目标数据文件由所述第二格式转换为所述第一格式；所述装置还包括：存储模块，用于存储所述第一格式的目标数据文件，以覆盖所述第一格式的初始数据文件。

可选的，所述获取模块包括：请求接收单元，用于从所述终端接收数据保存请求，所述数据保存请求包括所述初始数据文件的名称；数据查找单元，用于当根据所述初始数据文件的名称查找到所述第一格式的初始数据文件，且所述第一格式的初始数据文件为未锁定状态时，通过所述数据保存请求，并将所述第一格式的初始数据文件锁定；数据接收单元，用于从所述终端接收所述第二格式的目标数据文件的大小，再接收所述第二格式的目标数据文件；接收反馈单元，用于当接收成功时，向所述终端反馈成功接收的信息。

可选的，所述转换模块包括：数据加载单元，用于通过所述游戏引擎加载所述第一格式的初始数据文件；第一转换单元，用于利用所述游戏引擎中预先配置的接口对所述第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件；第二转换单元，用于将所述中间格式的初始数据文件转换为所述第二格式的初始数据文件。

可选的，所述转换模块还包括：后处理单元，用于在所述第一转换单元对所述第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件后，进行以下任意一种或多种后处理：删除所述中间格式的初始数据文件中的冗余信息；对所述中间格式的初始数据文件中的空白字段做规则化处理；调整所述中间格式的初始数据文件的浮点数。

根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一种游戏数据处理方法。

根据本公开的第四方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一种游戏数据处理方法。

本公开的技术方案具有以下有益效果：

根据上述游戏数据处理方法、游戏数据处理装置、计算机可读存储介质与电子设备，当终端上需要查阅或编辑游戏数据时，由服务器获取第一格式的初始数据文件，通过游戏引擎将其转换为第二格式，发送至终端，以在终端的办公软件中打开。一方面，在终端上以第二格式打开初始数据文件，以便于产品人员直接查阅或编辑其中的数据，可以借助办公软件实现更加便捷、高效的数据处理，且无需产品人员学习游戏引擎的数据操作方法，节省了人力和时间成本。另一方面，将打开和解析第一格式的初始数据文件部署在服务器端执行，无需在终端安装和运行游戏引擎，实现了终端的轻量化工作环境，特别是在实际应用中，服务器上持续运行游戏引擎，以满足多个终端的数据需求，从而提高了数据处理的效率。再一方面，游戏数据是以第一格式存储和管理的，第二格式的初始数据文件仅用于终端上的读写，在读写完成后不做额外的保存管理，因此无需保存游戏引擎外部的数据，也无需配置大量的导表脚本和打包脚本，减少了数据管理的工作量。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出UE4打开UDT数据表的界面；

图2示出UE4编辑UDT数据表中某一行的界面；

图3示出使用文本编辑器打开UDT数据表的界面；

图4示出本示例性实施例运行环境的系统架构图；

图5示出本示例性实施例中一种游戏数据处理方法的流程图；

图6示出本示例性实施例中一种游戏数据处理方法的子流程图；

图7示出本示例性实施例中一种游戏数据处理方法的交互流程图；

图8示出本示例性实施例中另一种游戏数据处理方法的交互流程图；

图9示出本示例性实施例中再一种游戏数据处理方法的交互流程图；

图10示出本示例性实施例中游戏数据管理的示意图；

图11示出本示例性实施例包含UE4宏功能的Excel界面；

图12示出本示例性实施例中一种游戏数据处理装置的结构框图；

图13示出本示例性实施例中一种用于实现上述方法的计算机可读存储介质；

图14示出本示例性实施例中一种用于实现上述方法的计算机可读存储介质。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

在游戏开发项目中，对于程序的静态数据，通常是直接通过游戏引擎做内部管理。以常用的UE4(Unreal Engine4，虚幻4引擎)为例，其将静态数据表存储为Uasset文件(UE4的资源文件)，并以UDT(UData Table，UE4自带的数据管理类)的形式打开或编辑。图1示出了UE4打开某个UDT数据表的界面，图2示出了UE4编辑UDT数据表中某一行的界面。尽管UE4提供了较为友好的数据编辑界面，但该界面所能实现的编辑功能大多较为基本，不支持批量操作、颜色标注、批注、公式计算等功能，对于产品人员来说，会降低个人工作效率。另外，Uasset文件是加密处理后以二进制形式存储的，只有UE4才可以解析。图3示出了使用文本编辑器打开UDT的结果，显示纯字节数据，不具有可读性。因此必须在UE4内打开UDT，而UE4的启动一般需要30秒以上，进一步影响了工作效率。

相关技术的一种方案中，可以在游戏引擎之外配置静态数据，以管理游戏数据。由于游戏程序本身就在处理数据，其中大量的初始数据是由产品人员定义的，这些数据具有静态管理的特质，可以在外部以数据文件的形式存储，便于产品人员编辑，然后通过导表脚本转换成代码可识别的格式，再通过打包脚本导入到游戏程序中，交由程序代码直接使用。然而，导表脚本和打包脚本根据数据格式和程序代码的开发需求不同而不同，形式和实现方式多种多样，需要技术人员根据实际情况进行编写，还需要进行测试，以保证脚本的正常功能，因此增加了大量的工作。另外，外部数据本身需要管理，则同一份游戏数据需要分别在游戏引擎内部和外部进行管理，其管理工作量增加了大约一倍，降低了效率。

鉴于上述一个或多个问题，本公开的示例性实施方式首先提供了一种游戏数据处理方法。图4示出了该方法运行环境的一种系统架构图。如图4所示，该系统架构400用于游戏开发，可以包括终端401、402、403，网络404和服务器405。其中，网络404用以在终端401、402、403和服务器405之间提供通信链路的介质，网络404可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端401、402、403可以是产品人员所使用的PC(Personal Computer，个人电脑)或智能手机等。服务器405可以是为了在游戏开发项目中进行数据处理而搭建的服务器，例如可以使用UE4提供的UCommandlet类进行二次开发，基于C++语言搭建远程服务端，基于Python在终端401、402、403上搭建对应的远程客户端。

应该理解，图4中的终端、网络和服务器的数目仅仅是示意性的。根据实际需求，可以设置任意数目的终端、网络和服务器。比如服务器405可以是多个服务器组成的服务器集群等。

本示例性实施方式的游戏数据处理方法可以以上述服务器405为执行主体，基于任一终端401、402、403和服务器405之间的交互实现数据处理，下面以终端401为例说明，其方法过程同样适用于402、403等其他终端。

图5示出了本示例性实施方式的一种方法流程，可以包括以下步骤S510至S530：

步骤S510，获取第一格式的初始数据文件。

其中，第一格式为基于游戏引擎的数据格式，通常仅能在游戏引擎中打开，例如采用游戏引擎UE4进行游戏开发时，第一格式可以是UDT格式。初始数据文件是指当前已存储的游戏数据文件，其可以包括游戏程序运行的静态数据、游戏人物的模型数据、游戏场景的渲染数据等等。

本示例性实施方式中，第一格式的初始数据文件是游戏开发项目中的内部数据，可以通过以下几种方式存储：

方式一、直接存储在服务器405上。基于此，当产品人员需要打开或编辑初始数据文件时，可以在终端401向服务器405发送相应的文件名，以进行查询。步骤S510可以包括：接收由终端发送的初始数据文件的名称，根据该初始数据文件的名称查找第一格式的初始数据文件。若未查找到该名称对应的初始数据文件，可以向终端401反馈未查找到文件的结果；若查找到对应的初始数据文件，可以从内存中读取该文件。

进一步的，服务器405可以通过具体执行以下步骤以查找初始数据文件：载入索引目录，根据初始数据文件的名称在索引目录中查找对应的存储路径；从存储路径获取第一格式的初始数据文件。以查找UDT数据为例说明：可以预先创建资源和UDT数据对应关系的索引目录，其中包括每个UDT数据对应的存储路径。要读取某个UDT数据时，在UE4引擎启动后，通过索引目录读取初始数据文件的名称对应的存储路径，然后在内存中找到对应的数据位置，再读取该位置的Uasset资源文件，在内存中保存为UDT数据类型即可，可以使用LoadObject方法载入对应的Uasset文件，获取到UDT数据。

方式二、额外部署服务器或数据库以存储初始数据文件，特别是有多个产品人员可能同时编辑同一数据文件时，可以部署SVN(Subversion，开放源代码的版本控制系统)服务器，可以通过采用分支管理系统实现高效管理，简而言之就是用于多个人共同开发同一个项目，控制并发请求，实现共享资源和集中式的管理。基于SVN服务器的架构，产品人员同样可以向服务器405查询文件名，服务器405在SVN服务器上查找该文件名对应的初始数据文件。

方式三、在上述方式一或方式二的基础上，还可以在终端401的本地存储配置数据副本，例如将服务器405或SVN服务器中存储的初始数据文件复制到每个终端上，并进行同步更新。基于此，步骤S510可以包括：接收由终端发送的第一格式的初始数据文件。即终端401将需要打开的初始数据文件发送到服务器405。

步骤S520，通过游戏引擎将上述初始数据文件由第一格式转换为第二格式。

其中，第二格式为基于办公软件的数据格式，例如Microsoft Excel所支持的各种数据表格式(如xls、xlsx等，以下简称为Excel格式)，可以在办公软件中直接打开，以便于产品人员使用。服务器405上可以部署游戏引擎，加载游戏引擎以打开第一格式的初始数据文件，再通过预先配置的接口或者游戏引擎自带的解析功能将其转换为第二格式。

在一种可选的实施方式中，参考图6所示，步骤S520可以具体包括以下步骤S610至S630：

步骤S610，通过游戏引擎加载第一格式的初始数据文件；

步骤S620，利用游戏引擎中预先配置的接口对第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件；

步骤S630，将中间格式的初始数据文件转换为第二格式的初始数据文件。

其中，中间格式是介于第一格式和第二格式之间的一种通用性格式，例如可以是JSON(JavaScript Object Notation，JS对象简谱)格式，其采用完全独立于编程语言的文本格式来存储和表示数据，易于人类读写和机器解析。例如，第一格式和第二格式采用不同的编程语言时，中间格式可以是基于伪代码的数据格式。

游戏引擎中预先配置的接口用于第一格式和中间格式之间的数据转换；在游戏引擎之外，也可以配置中间格式与第二格式之间的接口，以将数据文件在这两种格式之间互相转换。

上述通过中间格式实现第一格式和第二格式之间的转换，特别适用于第一格式和第二格式难以直接转换的情况，例如UDT格式和Excel格式之间，没有现成的数据转换接口，则需要技术人员编写配置大量的脚本代码；本发明人发现，UE4本身提供UDT序列化输出的接口，为编辑器提供一种数据导出的辅助功能，包括导出普通字符串、JSON字符串等的接口。通过该接口，可以对UDT进行序列化处理，输出普通字符串或JSON字符串。而Excel和JSON之间的数据转换也易于实现，无需特别编写脚本。

进一步的，在上述步骤S620之后，还可以进行以下任意一种或多种后处理：

(1)删除中间格式的初始数据文件中的冗余信息。冗余信息包括但不限于：表头信息，如资源路径、表名、大小等；格式控制字符，如各种换行、退格、回车等，连续出现时可能会导致数据传输错误，因此可以删除；部分字段的多语言本地化附加信息，可能增加一段本地化编码字段，对于产品人员编辑数据而言无意义，因此可以删除；其他的如自带的序列化信息等。

(2)对中间格式的初始数据文件中的空白字段做规则化处理。部分空白字段的默认值，比如字符串、浮点数、布尔值、结构体等，这些不同类型的单元格数据，在序列化时使用的空白默认值是不同的，进行统一的规则化处理后有利于系统识别。

(3)调整中间格式的初始数据文件的浮点数。通常在第一格式的数据文件中，浮点数的精度较长，对于不足精度的情况会自行添加内容，导致数据内容不可控，因此可以根据中间格式调整浮点数，通常可以降低其精度，以减少数据量，提升数值准确度。

步骤S530，将第二格式的初始数据文件发送至终端，使终端在办公软件中打开该第二格式的初始数据文件。

本示例性实施方式中，在产品人员使用的终端401上安装第二格式对应的办公软件，如Microsoft Excel等，可以直接打开第二格式的初始数据文件，以便于产品人员查阅或编辑其中的数据，例如批量新增或修改数据，快速修改错误，查验数据内容等。

基于上述内容，本示例性实施方式中，当终端上需要查阅或编辑游戏数据时，由服务器获取第一格式的初始数据文件，通过游戏引擎将其转换为第二格式，发送至终端，以在终端的办公软件中打开。一方面，在终端上以第二格式打开初始数据文件，以便于产品人员直接查阅或编辑其中的数据，可以借助办公软件实现更加便捷、高效的数据处理，且无需产品人员学习游戏引擎的数据操作方法，节省了人力和时间成本。另一方面，将打开和解析第一格式的初始数据文件部署在服务器端执行，无需在终端安装和运行游戏引擎，实现了终端的轻量化工作环境，特别是在实际应用中，服务器上持续运行游戏引擎，以满足多个终端的数据需求，从而提高了数据处理的效率。再一方面，游戏数据是以第一格式存储和管理的，第二格式的初始数据文件仅用于终端上的读写，在读写完成后不做额外的保存管理，因此无需保存游戏引擎外部的数据，也无需配置大量的导表脚本和打包脚本，减少了数据管理的工作量。

如果用户(产品人员)在终端401输入指令以编辑初始数据文件，编辑后的文件为第二格式的目标数据文件，目标数据文件和初始数据文件的名称通常相同，其数据内容不同。终端401可以将第二格式的目标数据文件发送至服务器405。

在一种实施方式中，基于终端401本地存储初始数据文件的方式(上述方式三)，服务器405还可以执行以下步骤：

从终端接收第二格式的目标数据文件；

将目标数据文件由第二格式转换为第一格式；

将第一格式的目标数据文件发送至终端，使终端采用第一格式的目标数据文件覆盖第一格式的初始数据文件。

换而言之，产品人员在终端401上编辑数据后，在服务器405端进行格式转换，再覆盖本地的原数据文件。其中，将目标数据文件由第二格式转换为第一格式可以通过数据接口实现，例如可以将Excel数据反向转换为JSON字符串，再通过UE4提供的用于反序列化的接口：CreateTableFromJSONString，将序列化后的JSON字符串格式化为UDT数据。并且，在序列化处理中进行的一系列后处理，UE4本身会完成部分特殊数据转换，因此不需要在反序列化之前针对后处理再逆行处理，这样的处理效率更高。

在另一种实施方式中，基于服务器405或SVN服务器远程存储初始数据文件的方式(上述方式一、二)，服务器405还可以执行以下步骤：

从终端接收第二格式的目标数据文件；

将目标数据文件由第二格式转换为第一格式；

存储第一格式的目标数据文件，以覆盖第一格式的初始数据文件。

可见，其处理方式和上述基于本地存储的处理方式基本相同，不同之处在于最后所覆盖的第一格式的初始数据文件为服务器405或SVN服务器上存储的数据文件，这样将修改后的数据文件保存到了远程端，可以使其他终端共享最新版本的数据文件。

通过上述两种方式，终端401或服务器405上始终以第一格式保存数据文件，以第二格式编辑数据文件，第一格式和第二格式的双向转换过程通过服务器405完成，这样的优点是：通过项目内部存储和管理游戏数据，无需管理第二格式的外部数据，成本更低；同时便于产品人员从外部编辑数据，操作方便。

在UE4中，保存UDT数据时，需要将其以Uasset形式保存到资源文件中。可以采用FAssetData类和UPackage类中的SavePackage方法，将已有的Uasset文件导入FAssetData中，再将资源文件打包成UPackage，通过调用SavePackage方法，即可把内存中已经反序列化后的UDT数据重新覆盖并保存。

图7示出了本示例性实施方式的一种交互流程。基于UE4的软件环境以及终端401本地存储数据文件的方式，在进行数据编辑时，如图7所示，由终端401首先执行步骤S710：在本地存储中获取待编辑的初始UDT数据，再执行步骤S720：将该初始UDT数据发送至服务器405；服务器405在接收到初始UDT数据后，执行步骤S730：将其转换为初始Excel数据，再执行步骤S740：将初始Excel数据发送至终端401；终端401在接收到初始Excel数据后，执行步骤S750：根据用户指令编辑数据内容，得到目标Excel数据，再执行步骤S760：将目标Excel数据发送至服务器405；服务器405在接收到目标Excel数据后，执行步骤S770：将其转换为目标UDT数据，再执行步骤S780：将目标UDT数据发送至终端401；终端401在接收到目标UDT数据后，执行步骤S790：将其保存到本地存储中，覆盖初始UDT数据，以完成数据更新。在上述流程中，核心功能在于服务器405对UDT数据进行一定程度的解析和转换，其实现过程简单，对系统资源要求较低，且无论是新建、新增、修改、删除数据表，还是更换数据结构，均不影响核心功能的使用，也无需进行相应的开发迭代。

在一种可选的实施方式中，服务器405可以通过以下步骤接收由终端401发送的初始数据文件的名称：

和终端建立连接，并通过该连接接收由终端发送的数据获取请求，该数据获取请求包括初始数据文件的名称。

相应的，服务器405还可以通过以下步骤发送第二格式的初始数据文件：

向终端发送第二格式的初始数据文件的大小，再发送第二格式的初始数据文件；

在终端反馈成功接收第二格式的初始数据文件后，断开连接。

其中，服务器405和终端401之间的双端交互可以通过基本的Socket(套接字，网络通信抽象层)开发实现。本示例性实施方式所涉及到的数据读、写交互操作，通常是由终端401侧单方面发起，且通过一次性双端交互即可解决。因此采用一次性短连接的方式，即终端401在发起请求时建立连接，在成功接收数据文件后断开连接，这样可以节省网络资源，且在实现上也更加简洁，无需做额外的连接管理和维护。在发送数据文件之前，先发送数据文件的大小，使接收方可以有效确认文件的完整性。并且，当数据较大时，无法通过一条协议发送完，TCP(Transmission Control Protocol，传输控制协议)可以自动分批发送，接收方根据数据包大小进行接收判断，因此服务器405先向终端401发送数据文件大小，使终端401在接收数据时可以进行分包判断。

进一步的，服务器405还可以通过以下步骤从终端401接收第二格式的目标数据文件：

从终端接收数据保存请求，该数据保存请求包括初始数据文件的名称；

当根据初始数据文件的名称查找到第一格式的初始数据文件，且第一格式的初始数据文件为未锁定状态时，通过数据保存请求，并将第一格式的初始数据文件锁定；

从终端接收第二格式的目标数据文件的大小，再接收第二格式的目标数据文件；

当接收成功时，向终端反馈成功接收的信息。

其中，上述交互过程也可以在一次短连接中完成。初始数据文件具有锁定或未锁定的状态，当有用户编辑该初始数据文件时，其状态为锁定，以防止其他用户同时编辑，反之则为未锁定，即允许用户编辑该文件。数据保存请求通常是终端401请求向服务器405写入修改过的数据文件，会覆盖掉服务器405上原有的文件，因此其必须在未锁定状态才能执行。当服务器405通过数据保存请求时，将对应的第一格式的初始数据文件锁定，以防止在保存过程中其他用户读取或修改该文件。终端401在向服务器405发送第二格式的目标数据文件时，也先发送文件大小，以便于服务器405确认接收文件的完整性，特别是在文件过大需要分包发送的情况。服务器405确认接收成功后，向终端401反馈相应的信息，终端401可以断开连接。

为了在实际应用中满足更加灵活的数据传输需求和处理，本示例性实施方式还可以设置较为全面的交互协议。表1示出了自定义交互协议的格式，表2示出了自定义交互协议的功能说明。实际情况根据数据源的不同，可以设置更多的协议类型，本公开对此不做限定。

表1

字段名称	数据类型	解释说明
			Header	Int32	协议号，区分功能
StrData	String、FString	所带数据

表2

Header	StrData	功能说明
			1001	表格名称、数据	打开表格
1002	表格名称、检查应答	保存表格
			1003	表格数据、保存结果	保存表格
9000	后续一条协议的数据包大小	数据大小
			9999	失败或断开原因	操作失败或主动断开连接

以UE4为例，采用UE4内的Fsocket(UE4封装的套接字抽象类)实现表1和表2所示的通信协议，可以实现以下几方面特点：在数据传输时发送后续一条协议的数据包大小，可以使接收方根据数据包大小进行数据的合并、完整性判断等处理；FSocket支持跨平台，可以通过ISocketSubsystem类进行创建和地址绑定；协议解析和分发处理逻辑，根据不同的协议号执行不同的数据处理；FSocket的数据流是uint8类型，除需使用UTF-8编码外，还需使用std::string作为中间数据类型，以保证中文的正常传输；确保服务端不会因为自身或终端错误而导致崩溃、死循环、不响应、错误响应、断开连接等异常情况，并且在发生这些异常情况时合理处置，不影响服务端的正常运行。

基于上述协议，下面结合图8和图9做进一步说明。

图8示出了终端810、引擎服务器820、SVN服务器830之间读取数据表(即第一格式的初始数据文件)的交互流程，其中终端810相当于图4中的终端401、402、403，引擎服务器820相当于图4中的服务器405，SVN服务器830用于存储和管理游戏数据文件(即第一格式的初始数据文件和目标数据文件)。

首先由终端810执行步骤S811：发送请求协议1001，包括需要读取的数据表名称。

引擎服务器820获取数据表名称后，在SVN服务器830处查找是否存在对应的数据表，若不存在，发送操作失败的9999协议给终端810，若存在，则执行步骤S822：获取对应的数据表(UDT格式)。

然后执行步骤S823：向终端810发送9000协议，告知数据大小；终端810获知数据大小后，准备接收数据表；引擎服务器820再执行步骤S824：通过1001协议分批发送数据表到终端810。

终端810在接收后检查数据的完整性，若数据有误，发送操作失败的9999协议到引擎服务器820，准备重新接收，若数据无误，则执行步骤S812：发送主动断开连接的9999协议到引擎服务器820，并断开连接。

图9示出了终端810远程修改数据表的交互流程。首先由终端810执行步骤S813：发送保存数据表的请求1002协议到引擎服务器820，附带数据表名称。

引擎服务器820获取数据表名称后，执行步骤S825：在SVN服务器830处查找是否存在对应的数据表以及数据表状态，若不存在数据表或数据表状态为锁定，则发送操作失败的9999协议给终端810，若存在数据表且状态为未锁定，则执行步骤S826：确认数据保存请求通过，并通知SVN服务器锁定该数据表。

接下来引擎服务器820可以执行步骤S827：发送1002协议到终端810，通知其可以修改数据表；然后终端810执行步骤S814：发送9000协议，告知引擎服务器820数据表的大小，使引擎服务器820准备接收数据表；再执行步骤S815：通过1001协议分批发送数据表到引擎服务器820。

引擎服务器820接收数据表后检查数据的完整性，若数据有误，发送操作失败的操作失败的9999协议到终端810，准备重新接收，若数据无误，则执行步骤S828：将数据表保存到SVN服务器830，以覆盖原数据表。

在保存数据表成功后，引擎服务器820可以继续执行步骤S829：向终端810发送1003协议，通知保存成功的结果；最后终端810执行步骤S816：发送主动断开连接的9999协议到引擎服务器820，并断开连接。

图10示出了本示例性实施方式管理游戏数据的示意图。一方面，通过终端和服务器的交互，可以使产品人员在本地通过Excel的格式读写游戏数据；另一方面，在服务器上可以通过UE4引擎对UDT数据进行直接的编辑；再一方面，UDT数据最终需要转换为可运行的游戏包体数据，也可以对这部分数据进行处理，以体现在游戏的逻辑代码中。由图可见，Excel编辑数据和UE4引擎内编辑器编辑UDT数据互不冲突，如果是开发调试，需要频繁修改少量数据，使用UE4编辑器更加快速方便，如果是大批量新增、修改数据，快速修改错误，查验数据内容等需求，使用Excel直接编辑更加高效。因此，本示例性实施方式提供的处理方式，可以满足不同用户(如产品人员和技术人员)不同工作需求，使用户自由灵活选择编辑方式，提高了工作自由度和效率。

下面从底层对UE4中的具体实现方式做进一步说明。

在UE4中对UDT数据的解析和读写可以通过UE4自带的Commandlet基类实现，其可通过命令行启动引擎，完成一定的预定义功能。其中，自定义可变参数示例如下：

FParse::Value(*CmdLineParams,TEXT("TableName＝"),TableName)；

基于Commandlet源码，可以通过以下方法实现UDT数据的解析和读写功能：

设置自定义类UMyTestCommandlet，并继承自Ucommandlet类；

在UMyTestCommandlet中开发Main函数，此为命令行的唯一入口，入口参数即为命令行的可变参数；

执行命令：>>UE4Editor-Cmd.exe YourProject.uproject–run＝MyTest[otherparams]；

上述命令中的各部分内容如下：

UE4Editor-Cmd.exe，是UE4引擎编辑器可执行文件位置；

YourProject.uproject，是开发项目的工程位置；

-run＝MyTest，是需要执行的Commandlet类，其参数对应自定义类的类名；

[other params]，表示其它自定义可变参数，以-开头，代码中自行提取即可，比如-TableName＝xxx.xls。

在上述图6中，数据文件在第一格式和第二格式之间的转换是通过中间格式实现的。在UE4中，如果采用UDT作为第一格式，Excel作为第二格式，JSON作为中间格式，中间格式可能存在不一致的情况。通常UDT序列化后的JSON数据(简称为UDT-JSON)和Excel可识别的JSON数据(简称为Excel-JSON)之间存在格式上的差异。下面以表3所示的数据表为例说明：

表3

对于表3所示的数据表，其对应的UDT-JSON数据格式可以如下所示(包含格式控制信息)：

表3中的数据表对应的Excel-JSON数据可以如下所示(包含格式控制信息)：

由上可见，UDT-JSON数据和Excel-JSON数据具有格式差异，主要表现在列组织方式上。基于此，需要在UDT-JSON和Excel-JSON之间进行双向转换，以统一JSON格式，具体方法如下：

一、UDT-JSON转换为Excel-JSON

使用json.loads将UDT-JSON数据解码为Python数据类型；

从任意行数据中提取所有的表格列头，即取key；

逐行处理每行数据，过滤key，按照顺序只保留value；

需要特别注意的是，结构体应为存在多层嵌套，因此需要整体转换成字符串数据，才可以正确的被Excel读取和编辑；结构体转换方法：判断每行数据中的value是否是list、dict等类型，如果是则直接通过dumps编码为字符串；

最终转换为一个嵌套的list，即Excel-JSON数据。

另外需要说明的是，部分字符需要特殊处理，比如false、true、null，需要转换为Python可识别的False、True、None，这部分字符通过预先配置的映射表可以直接转换。

二、Excel-JSON转换为UDT-JSON

从Excel中读取数据，先转为Python数据类型；

需要将字符串形式的结构体，使用eval重新解析为嵌套的list、dict等类型，使得后续UE4导入时，避免将结构体中嵌套的内容全部识别为字符串，导致出错；

将首行的表格列头，和其余各行的单元格内容按序配对为键值对使用json.dumps编码为JSON字符串数据；

最终转换为UDT-JSON数据。

在一种可选的实施方式中，可以在Excel中采用Xlwings(基于Python处理Excel的库)插件，读写Excel数据十分简便，通过以下几种操作组合即可实现：

获取活动工作簿：wb＝xlwings.books.active；

定位工作表：ws＝wb.sheets[sheet_pos]；

读取工作表数据：data＝ws.range('A1').expand().value；

保存工作表数据：ws.range('A1').value＝data；

此外，为了提供更好的操作体验，本示例性实施方式还可以结合Xlwings和VBA(Visual Basic for Applications，VB宏语言)对Excel进行功能拓展，增加快捷操作，包括：

客户端实现脚本通过在Excel宏中进行调用，例如新建任意启用宏的表格(.xlsm)，打开宏编辑器，新增宏模块，增加VBA脚本代码：

Sub PythonTest()

RunPython("import PyTest；PyTest.Client()")

End Sub

Excel打开所有宏功能，允许宏正常工作；

打开工具栏的自定义功能区，将打开文件和保存文件的宏，配置在工具栏，名称可自定义，也可以配置自定义的快捷键，参考图11所示，为带有UE4宏功能的选项卡；

将文件保存为启用宏的模板(.xlmt)文件，从该模板创建新的宏文件，即可正常运行，不需要在执行上述操作；

将客户端实现脚本和宏模板文件保存在同个目录下，这样更方便，无需自行搜索目录调用。

进一步的，为了保留产品人员使用办公软件的工作习惯以及其他有益的工作经验，本示例性实施方式提供配套的辅助工作方案，具体说明如下：

支持批注、着色、公式等辅助信息

对Excel数据进行更新时，并不清除表格的表格样式信息，仅刷新单元格数据，产品人员在编辑完成后，可以执行普通的保存操作来存储表格样式的修改，也可以执行本示例性实施方式的保存操作来存储UDT数据，这两个操作是不冲突的。数据页面不能出现公式，可以在工作簿中增加工作表，专门用来公式计算，从而满足产品人员使用公式计算的需求。

支持SVN协作、分支表

本示例性实施方式中，可以通过数据表名称来打开对应的UDT数据，因此，在用户本地和SVN服务器端，可以将UDT数据存储为对应的单个Excel表。用户个人调试在本地完成，操作完成后提交SVN服务器端更新同步，包括批注、着色等格式信息，也可以通过SVN服务器同步给其他用户。Excel的数据是否更新均可，这视实际需求而定，本公开不做限定。

分支表是应对复杂的开发环境和运营需求而诞生的，比如在开发中的版本和上线后的版本，就会有正式分支表和测试分支表；再比如国内分支表和国外分支表等。本示例性实施方式同样支持这种操作方式，在使用Excel打开UDT数据时，根据不同的开发和运营需求，打开不同SVN服务器的数据源即可，还可以提供不同功能的快捷按钮，方便用户使用。

支持拆表、子母表

拆表是为了防止数据表过大，将一份表格根据一定的编号规则拆分为几个表格，表头完全相同，只是数据不同而已。子母表是为了产品人员操作方便，针对数据中产品人员不关心或不需要编辑的内容，不存储在表格中，而是由程序导表时另行添加或修改，从而提升工作效率。

本示例性实施方式同样可以支持以上操作方式。对于拆表，创建带有固定规则的分表名称，在保存分表到UDT总数据时，通过名称规则分析，覆盖对应的数据即可。举例说明，Test总表有数据编号1001到2000，拆分为1001到1500、1501到2000两个分表，那么分表可以命名为Test_1001和Test_1501，保存时，将分表数据直接覆盖对应的数据段即可。对于子母表，在打开UDT数据显示时，将产品人员不关心的数据列隐藏不显示即可，具体隐藏哪些字段，可以事先配置。

上述功能拓展均是在核心功能的基础上，为了满足用户需求，提高用户操作体验和工作效率而进行的。由于核心功能的实现简单，独立性强，所以进行功能拓展的自由度高，除了上述几个方面以外，还可以进行其他方面的拓展，本公开对此不做限定。

本公开的示例性实施方式还提供了一种游戏数据处理装置。如图12所示，该游戏数据处理装置1200可以包括：获取模块1210，用于获取第一格式的初始数据文件，第一格式为基于游戏引擎的数据格式；转换模块1220，用于通过游戏引擎将初始数据文件由第一格式转换为第二格式，第二格式为基于办公软件的数据格式；发送模块1230，用于将第二格式的初始数据文件发送至终端，使终端在办公软件中打开第二格式的初始数据文件。

在一种可选的实施方式中，获取模块1210，可以用于接收由终端发送的第一格式的初始数据文件。

在一种可选的实施方式中，获取模块1210，还可以用于从终端接收第二格式的目标数据文件，该第二格式的目标数据文件由终端根据用户输入的指令编辑第二格式的初始数据文件而得到；转换模块1220，还可以用于将上述目标数据文件由第二格式转换为第一格式；发送模块1230，还可以用于将上述第一格式的目标数据文件发送至终端，使终端采用第一格式的目标数据文件覆盖第一格式的初始数据文件。

在一种可选的实施方式中，获取模块1210，可以用于接收由终端发送的初始数据文件的名称，根据初始数据文件的名称查找第一格式的初始数据文件。

在一种可选的实施方式中，获取模块1210，还可以用于载入索引目录，根据初始数据文件的名称在索引目录中查找对应的存储路径，并从存储路径获取第一格式的初始数据文件。

在一种可选的实施方式中，获取模块1210，还可以用于和终端建立连接，并通过连接接收由终端发送的数据获取请求，数据获取请求包括初始数据文件的名称；发送模块1230，还可以用于向终端发送第二格式的初始数据文件的大小，再发送第二格式的初始数据文件，以及在终端反馈成功接收第二格式的初始数据文件后，断开连接。

在一种可选的实施方式中，获取模块1210，还可以用于从终端接收第二格式的目标数据文件，该第二格式的目标数据文件由终端根据用户输入的指令编辑第二格式的初始数据文件而得到；转换模块1220，还可以用于将上述目标数据文件由第二格式转换为第一格式；游戏数据处理装置1200还可以包括：存储模块，用于存储第一格式的目标数据文件，以覆盖第一格式的初始数据文件。

在一种可选的实施方式中，获取模块1210可以包括：请求接收单元，用于从终端接收数据保存请求，该数据保存请求包括初始数据文件的名称；数据查找单元，用于当根据上述初始数据文件的名称查找到第一格式的初始数据文件，且该第一格式的初始数据文件为未锁定状态时，通过上述数据保存请求，并将该第一格式的初始数据文件锁定；数据接收单元，用于从终端接收第二格式的目标数据文件的大小，再接收第二格式的目标数据文件；接收反馈单元，用于当接收上述第二格式的目标数据文件成功时，向终端反馈成功接收的信息。

在一种可选的实施方式中，转换模块1220可以包括：数据加载单元，用于通过游戏引擎加载上述第一格式的初始数据文件；第一转换单元，用于利用游戏引擎中预先配置的接口对上述第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件；第二转换单元，用于将上述中间格式的初始数据文件转换为第二格式的初始数据文件。

在一种可选的实施方式中，转换模块1220还可以包括：后处理单元，用于在第一转换单元对第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件后，进行以下任意一种或多种后处理：删除中间格式的初始数据文件中的冗余信息；对中间格式的初始数据文件中的空白字段做规则化处理；调整中间格式的初始数据文件的浮点数。

上述装置中各模块/单元的具体细节在方法部分实施方式中已经详细说明，未披露的细节内容可以参见方法部分的实施方式内容，因而不再赘述。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

本公开的示例性实施方式还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在电子设备上运行时，程序代码用于使电子设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。

参考图13所示，描述了根据本公开的示例性实施方式的用于实现上述方法的程序产品1300，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在电子设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

本公开的示例性实施方式还提供了一种能够实现上述方法的电子设备。下面参照图14来描述根据本公开的这种示例性实施方式的电子设备1400。图14显示的电子设备1400仅仅是一个示例，不应对本公开实施方式的功能和使用范围带来任何限制。

如图14所示，电子设备1400可以以通用计算设备的形式表现。电子设备1400的组件可以包括但不限于：至少一个处理单元1410、至少一个存储单元1420、连接不同系统组件(包括存储单元1420和处理单元1410)的总线1430和显示单元1440。

存储单元1420存储有程序代码，程序代码可以被处理单元1410执行，使得处理单元1410执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。例如，处理单元1410可以执行图5至图9中任意一个或多个方法步骤。

存储单元1420可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)1421和/或高速缓存存储单元1422，还可以进一步包括只读存储单元(ROM)1423。

存储单元1420还可以包括具有一组(至少一个)程序模块1425的程序/实用工具1424，这样的程序模块1425包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线1430可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1400也可以与一个或多个外部设备1500(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1400交互的设备通信，和/或与使得该电子设备1400能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1450进行。并且，电子设备1400还可以通过网络适配器1460与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1460通过总线1430与电子设备1400的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1400使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开示例性实施方式的方法。

此外，上述附图仅是根据本公开示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的示例性实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施方式。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施方式仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限。

Claims (13)

1.一种游戏数据处理方法，其特征在于，包括：

获取第一格式的初始数据文件，所述第一格式为基于游戏引擎的数据格式；

通过所述游戏引擎将所述初始数据文件由所述第一格式转换为第二格式，所述第二格式为基于办公软件的数据格式；

将所述第二格式的初始数据文件发送至终端，使所述终端在所述办公软件中打开所述第二格式的初始数据文件。

2.根据权利要求1所述的方法，其特征在于，所述获取第一格式的初始数据文件，包括：

接收由所述终端发送的所述第一格式的初始数据文件。

3.根据权利要求2所述的方法，其特征在于，在将所述第二格式的初始数据文件发送至终端后，所述方法还包括：

从所述终端接收第二格式的目标数据文件，所述第二格式的目标数据文件由所述终端根据用户输入的指令编辑所述第二格式的初始数据文件而得到；

将所述目标数据文件由所述第二格式转换为所述第一格式；

将所述第一格式的目标数据文件发送至所述终端，使所述终端采用所述第一格式的目标数据文件覆盖所述第一格式的初始数据文件。

4.根据权利要求1所述的方法，其特征在于，所述获取第一格式的初始数据文件，包括：

接收由所述终端发送的所述初始数据文件的名称，根据所述初始数据文件的名称查找所述第一格式的初始数据文件。

5.根据权利要求4所述的方法，其特征在于，所述根据所述初始数据文件的名称查找所述第一格式的初始数据文件，包括：

载入索引目录，根据所述初始数据文件的名称在所述索引目录中查找对应的存储路径；

从所述存储路径获取所述第一格式的初始数据文件。

6.根据权利要求4所述的方法，其特征在于，所述接收由所述终端发送的所述初始数据文件的名称，包括：

和所述终端建立连接，并通过所述连接接收由所述终端发送的数据获取请求，所述数据获取请求包括所述初始数据文件的名称；

所述将所述第二格式的初始数据文件发送至终端，包括：

向所述终端发送所述第二格式的初始数据文件的大小，再发送所述第二格式的初始数据文件；

在所述终端反馈成功接收所述第二格式的初始数据文件后，断开所述连接。

7.根据权利要求4所述的方法，其特征在于，在将所述第二格式的初始数据文件发送至终端后，所述方法还包括：

从所述终端接收第二格式的目标数据文件，所述第二格式的目标数据文件由所述终端根据用户输入的指令编辑所述第二格式的初始数据文件而得到；

将所述目标数据文件由所述第二格式转换为所述第一格式；

存储所述第一格式的目标数据文件，以覆盖所述第一格式的初始数据文件。

8.根据权利要求7所述的方法，其特征在于，所述从所述终端接收第二格式的目标数据文件，包括：

从所述终端接收数据保存请求，所述数据保存请求包括所述初始数据文件的名称；

当根据所述初始数据文件的名称查找到所述第一格式的初始数据文件，且所述第一格式的初始数据文件为未锁定状态时，通过所述数据保存请求，并将所述第一格式的初始数据文件锁定；

从所述终端接收所述第二格式的目标数据文件的大小，再接收所述第二格式的目标数据文件；

当接收成功时，向所述终端反馈成功接收的信息。

9.根据权利要求1所述的方法，其特征在于，所述通过所述游戏引擎将所述初始数据文件由所述第一格式转换为第二格式，包括：

通过所述游戏引擎加载所述第一格式的初始数据文件；

利用所述游戏引擎中预先配置的接口对所述第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件；

将所述中间格式的初始数据文件转换为所述第二格式的初始数据文件。

10.根据权利要求9所述的方法，其特征在于，在对所述第一格式的初始数据文件进行序列化处理，得到中间格式的初始数据文件后，还进行以下任意一种或多种后处理：

删除所述中间格式的初始数据文件中的冗余信息；

对所述中间格式的初始数据文件中的空白字段做规则化处理；

调整所述中间格式的初始数据文件的浮点数。

11.一种游戏数据处理装置，其特征在于，包括：

获取模块，用于获取第一格式的初始数据文件，所述第一格式为基于游戏引擎的数据格式；

转换模块，用于通过所述游戏引擎将所述初始数据文件由所述第一格式转换为第二格式，所述第二格式为基于办公软件的数据格式；

发送模块，用于将所述第二格式的初始数据文件发送至终端，使所述终端在所述办公软件中打开所述第二格式的初始数据文件。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至10任一项所述的方法。

13.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至10任一项所述的方法。

Images