一种基于相关性的游戏数据流媒体化方法与流程

1.本发明涉及游戏数据技术领域，具体是指一种基于相关性的游戏数据流媒体化方法。


背景技术：

2.随着计算机技术的高速发展，图像处理技术的发展，游戏的容量爆炸式增长，一些大型游戏的容量往往已经超过200gb，一些手机游戏容量也超过10gb。更为重要的是，随着开放世界游戏和元宇宙的到来，游戏容量的增长速度会越来越快。因此，在现有分发技术(线下光盘，硬盘，闪存等存储介质，线上下载安装)条件下，这些大容量的游戏分发，安装和存储就成了问题，所以如何降低用户的获取成本和获取时间，成为当务之急。
3.因此，如果能够将游戏数据的访问(大部分是随机访问模式，也存在顺序访问模式)变成可串行化的，就可以使用类似流媒体的方式来服务数据访问，完美解决游戏分发和访问。


技术实现要素：

4.本发明要解决的技术问题是，克服现有技术缺点，提供一种基于相关性的游戏数据流媒体化方法，极大地降低了游戏开发中的容量限制，极大地降低了游戏的开发难度。
5.为解决上述技术问题，本发明提供的技术方案为：一种基于相关性的游戏数据流媒体化方法，建立一套游戏逻辑和游戏文件关联关系扫描子系统，即unity游戏引擎的插件，用来扫描和记录游戏中多个层次的关联，建立流媒体化所需的关联关系模型，关联性扫描的流程为：
6.1)扫描游戏各个场景之间的依赖关系，并记录下来，可以接受人工修改；
7.2)扫描场景和场景内资源文件的关联关系，如果场景内引用的资源文件小于10个或者资源文件的总长度小于1mb，则停止扫描，将场景内所有资源记录为一个聚类，同时记录下这些资源和场景的关联；
8.3)扫描场景内各个部分之间的依赖关系，将场景内的地图按照四叉树的方式进行分块：先将场景划分成5*5个子地图块，记录下各个子地图块的世界坐标系中坐标范围，然后依次扫描各子地图块。
9.进一步的，为了支持流式传输，将最小的资源文件聚类限制在1mb。
10.进一步的，所述步骤3)中，如果子地图块内引用的资源文件小于10个或者资源文件总长度小于1mb，则停止扫描，记录下子地图块的坐标范围，将子地图块内所有资源记录为一个聚类，同时记录下这些资源和子地图块的关联；否则，将子地图块划分成2*2个子地图块，依次扫描和拆分这些子地图块，直到所有子地图块引用的资源文件小于10个或者资源文件总长度小于1mb。
11.进一步的，游戏数据流服务端子系统，负责处理用户端资源预测和下载请求：将资源文件映射到最终打包或文件系统的结构，并记录对应关系；处理用户端的资源预测请求，
用户端传入屏幕分辨率，最近访问资源文件列表，用户输入序列信息，对于已经接入了运行时sdk的游戏，用户端还会传入当前所在场景、世界坐标、相机视角的信息；处理用户下载请求：使用压缩格式返回用户请求的文件或者部分文件。
12.进一步的，计算当前所在的场景，服务端资源预测流程包括：
13.1)如果用户端请求中没有场景信息，根据请求中的最近使用资源文件列表，结合场景和资源文件的对应关系，计算出当前可能的场景；
14.2)如果场景引用的资源文件小于10个或者资源文件总长度小于1mb，则直接开始计算资源文件的使用概率打分；否则，计算当前的子地图块；
15.3)计算出当前的子地图块；
16.4)计算下一阶段可能需要的资源文件；
17.5)按照资源接下来被使用的概率进行打分：根据资源文件被引用的次数，和当前坐标的距离，和相机视角的夹角大小，聚类中其他文件的打分信息，计算出资源文件的分数；
18.6)将预测的资源文件和打分返回给用户端。
19.进一步的，计算出当前的子地图块时，如果用户端发送的请求中不包含游戏当前的世界坐标，根据请求中的最近使用的资源文件列表，结合关联关系扫描子系统输出的文件和子地图块之间的关联关系，以及当前的场景，计算出当前可能的子地图块；如果用户端发送的请求中包含当前的世界坐标，结合关联关系扫描子系统输出的文件和子地图块之间的关联关系，计算出当前所在的子地图块。
20.进一步的，计算下一阶段可能需要的资源文件时，预测资源文件候选集：根据用户端屏幕分辨率和游戏中单位像素设置计算出用户视野范围，然后以当前子地图块为中心，找出视野大小4倍范围内的子地图块列表；如果有相机视角信息，沿着相机视角找出距离当前坐标4倍视野高度的所有子地图块，加入到子地图块列表中；然后查找出这些子地图块对应的资源文件。
21.进一步的，关联关系扫描子系统产生的关联关系模型，通过打包到游戏程序中或者游戏运行时分发到客户端，由客户端sdk根据游戏当前的上下文，包括场景、世界坐标、相机视角的信息，来预测接下来被使用的资源，然后从服务端请求对应资源。
22.本发明具有如下优点：本发明在运行时支持下设计和实现了一套游戏逻辑和游戏文件关联关系扫描子系统(具体来说，是unity游戏引擎的插件)，用来扫描和记录游戏中多个层次的关联，建立流媒体化所需的关联关系模型。
23.本发明不侵入游戏开发过程，只需要在游戏发布之前扫描游戏数据的相关关系，即可完成游戏流媒体化建模。以流媒体的方式提供游戏服务。而且各游戏引擎，和各游戏平台通用。
24.建模过程基于静态扫描，没有使用到机器学习等方法，因此无需收集用户数据，没有模型训练过程，可以直接冷启动。
25.解决了游戏特别是大容量游戏的分发问题，在运行时支持下，用户无需下载，无需安装，即点即玩。
26.和现存云游戏方案比，无需服务端渲染，而且极大降低了流量成本。
27.极大地降低了游戏(程序)对用户端(手机或电脑)存储容量的要求，之前一个128g
的手机也只能存储10 个大型游戏(程序)，在本发明的技术支持下，用户理论上可以拥有无限个游戏。
28.本发明极大地降低了游戏开发中的容量限制，而且对用户和开发者都是透明的。游戏开发者可以使用访问本地文件的方式访问任意容量的游戏资源，天然支持元宇宙游戏等开放式游戏。也极大地降低了游戏的开发难度(以往游戏开发者为了动态加载资源而不得不在游戏逻辑中加入的资源下载和加载的逻辑，不再需要了，一切资源都是“本地文件”。)
29.本发明也支持可交互视频(ar/vr等)的流式传输。
30.本发明融合了云端数据和本地数据的访问接口，以往只有专业程序员可以实现的云存储 本地计算模式的技术门槛大大降低，真正盘活云端存储更加便捷。
31.本发明中的关联关系模型还可以存储在客户端，由客户端负责根据游戏运行时的上下文预测接下来需要的资源，可以进一步降低网络延时和服务端的计算成本。
附图说明
32.图1是本发明的关联性扫描流程示意图。
33.图2是本发明的服务端资源预测流程示意图。
34.图3是本发明的用户端运行时数据访问流程示意图。
具体实施方式
35.下面结合实施例对本发明做进一步的详细说明。
36.概念：
37.游戏数据指的是游戏厂商分发的游戏运行中使用的程序代码，纹理，模型，音频，视频等数据，通常以安装包或者iso等方式发布，在游戏运行的时候时为目录和文件，或者iso等打包格式。
38.游戏文件：游戏数据在非打包状态的文件形式，比如单个的纹理文件，音频文件。
39.场景：游戏情节的单位，比如关卡游戏的一个关卡可以是一个场景。对于开放世界类游戏没有明显的场景划分，但是可以根据地图的位置划分成若干逻辑场景。
40.资源：指的是游戏中使用的纹理，模型，音频，视频，代码等数据。
41.在公司开发游戏的过程中发现，虽然游戏容量很大，虽然游戏对数据的访问大都是随机访问，但是游戏运行时使用的数据是有局部性和关联性的。
42.局部性在于在任意时刻，游戏只会使用一小部分数据，而且，这些数据通常表现出一定的聚集性。
43.关联性在于，由于游戏逻辑的确定性，数据和游戏场景之间，数据和数据之间是互相关联的。
44.本发明在具体实施时，本发明在运行时支持下设计和实现了一套游戏逻辑和游戏文件关联关系扫描子系统(具体来说，是unity游戏引擎的插件)，用来扫描和记录游戏中多个层次的关联，建立流媒体化所需的关联关系模型。为了支持流式传输，会将最小的资源文件聚类限制在1mb。流程如下：
45.1)扫描游戏各个场景之间的依赖关系，并记录下来，可以接受人工修改。
46.2)扫描场景和场景内资源文件的关联关系，如果场景内引用的资源文件小于10个或者资源文件的总长度小于1mb，则停止扫描，将场景内所有资源记录为一个聚类，同时记录下这些资源和场景的关联。
47.3)扫描场景内各个部分之间的依赖关系，将场景内的地图按照四叉树的方式进行分块，具体来说，先将场景划分成5*5个子地图块，记录下各个子地图块的世界坐标系中坐标范围，然后依次扫描各子地图块：
48.如果子地图块内引用的资源文件小于10个或者资源文件总长度小于1mb，则停止扫描，记录下子地图块的坐标范围，将子地图块内所有资源记录为一个聚类，同时记录下这些资源和子地图块的关联。
49.否则，将子地图块划分成2*2个子地图块，依次扫描和拆分这些子地图块，直到所有子地图块引用的资源文件小于10个或者资源文件总长度小于1mb。
50.游戏数据流服务端子系统，负责处理用户端资源预测和下载请求。其功能如下：
51.将资源文件映射到最终打包(或文件系统)的结构，并记录对应关系。
52.处理用户端的资源预测请求，用户端会传入屏幕分辨率，最近访问资源文件列表，用户输入序列等信息，对于已经接入了本发明运行时sdk的游戏，用户端还会传入当前所在场景，世界坐标，相机视角等信息。
53.1)计算当前所在的场景：如果用户端请求中没有场景信息，根据请求中的最近使用资源文件列表，结合场景和资源文件的对应关系，计算出当前可能的场景。
54.2)如果场景引用的资源文件小于10个或者资源文件总长度小于1m，则直接开始计算资源文件的使用概率打分。否则，计算当前的子地图块。
55.3)计算出当前的子地图块：
56.如果用户端发送的请求中不包含游戏当前的世界坐标，根据请求中的最近使用的资源文件列表，结合关联关系扫描子系统输出的文件和子地图块之间的关联关系，以及当前的场景，计算出当前可能的子地图块。
57.如果用户端发送的请求中包含当前的世界坐标，结合关联关系扫描子系统输出的文件和子地图块之间的关联关系，计算出当前所在的子地图块。
58.4)计算下一阶段可能需要的资源文件：
59.预测资源文件候选集：根据用户端屏幕分辨率和游戏中单位像素设置计算出用户视野范围，然后以当前子地图块为中心，找出视野大小4倍范围内的子地图块列表。如果有相机视角信息，沿着相机视角找出距离当前坐标4倍视野高度的所有子地图块，加入到子地图块列表中。然后查找出这些子地图块对应的资源文件。
60.5)按照资源接下来被使用的概率进行打分：根据资源文件被引用的次数，和当前坐标的距离，和相机视角的夹角大小，聚类中其他文件的打分等信息，计算出资源文件的分数。
61.6)将预测的资源文件和打分返回给用户端。
62.处理用户下载请求：使用压缩格式返回用户请求的文件或者部分文件。
63.本发明在用户端建立了一套运行时子系统，接管游戏运行的文件访问请求并映射成本地文件系统或服务端访问，满足数据访问需求，对用户和游戏开发者透明。因此，游戏可以无需下载安装，即点即玩。其主要功能如下：
64.对每次数据请求，本地文件系统命中则直接返回数据，否则和服务端通信，请求当前需要的数据。
65.后台预测线程周期性向服务端通信，上传本地设备信息，最近使用的文件列表，用户输入序列等信息，请求预测资源文件列表和打分。如果游戏使用了本发明的游戏sdk，则获取当前的场景，世界坐标，相机视角等信息，加入到预测请求中。
66.本地维护下载队列，当服务端返回预测资源文件列表和打分信息时，更新下载队列，降低原有文件的权重，并将新的文件列表和打分加入到队列中。
67.后台下载线程从下载队列拿出需要下载的文件，如果本地文件系统没有，则向服务端请求下载，解压并写入本地文件系统。
68.为了实现更加精准的资源预测，本发明设计了一套游戏sdk，具体为unity游戏插件。如果游戏开发者在开发过程中引入了该sdk，游戏运行时用户端运行时子系统可以通过该sdk获取当前的场景，世界坐标，相机视角等信息。
69.本发明中关联关系扫描子系统产生的关联关系模型也可以打包到游戏程序中或者游戏运行时分发到客户端，由客户端sdk根据游戏当前的上下文(如场景，世界坐标，相机视角等信息)来预测接下来被使用的资源，然后从服务端请求对应资源。
70.本发明从游戏逻辑出发，通过分析游戏场景和场景之间，场景和资源之间，资源和资源之间，可执行代码和场景、资源之间，代码和代码之间的关联关系，构建出多层次的聚类和依赖关系，从而将游戏对数据的访问转化成流媒体的方式。基于此，我们在unity游戏引擎中实现了一个关联关系扫描插件，扫描出场景和资源之间的依赖关系，以及资源之间的聚类关系，并构建了一个游戏数据的流媒体化系统，解决了大容量游戏的分发问题：让游戏即点即玩，不用等待下载。
71.虽然，上文中已经用一般性说明及具体实施方案对本发明作了详尽的描述，但在本发明基础上，可以对之作一些修改或改进，这对本领域技术人员而言是显而易见的。因此，在不偏离本发明精神的基础上所做的这些修改或改进，均属于本发明要求保护的范围。