CN112691365A - 云游戏加载方法、系统、装置、存储介质和云游戏系统 - Google Patents

Abstract

本申请公开了一种云游戏加载方法、系统、装置、存储介质和云游戏系统，涉及云计算领域，所述方法包括获取加载指令；根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；加载所述第一存档，以使所述云游戏加载至第一画面；通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面。本方案结合存档和指令集，可以快速将游戏加载到游戏中的任意场景，提升了云游戏系统的预加载效率。

Description

云游戏加载方法、系统、装置、存储介质和云游戏系统

技术领域

本申请涉及云游戏领域，尤其是一种云游戏加载方法、系统、装置、存储介质和云游戏系统。

背景技术

随着云计算技术的成熟，用户可以通过云计算来实现终端难以完成的任务。例如，在云游戏的领域，用户通过云服务可以游玩终端本来无法流畅运行的游戏、可以游玩终端本身没有安装的游戏或者可以游玩终端安装的操作系统所不能运行的游戏。终端只需要接收来自云端的画面，并通过终端的输入装置来与云端实现交互。

云服务商利用资源池中的资源向终端提供虚拟机，这些虚拟机上预先安装有一些游戏，云服务商会在将虚拟机分配给用户之前，对软件进行预加载，使得用户分配到虚拟机时看到的是游戏中的一个特定画面，这样用户看到画面后可以直接进行游戏，减少了用户等待的时间。相关技术中，通过录制剧本的方式来模拟用户的操作，在后台进行预加载，这样的方式存在缺点，当预加载指定的游戏关卡或者游戏场景比较深入(例如，第10关)的时候，该剧本需要从第1关操作到第10关。这样的加载时间比较长，导致服务器被长时间占用，进而导致用户难以分配到游戏服务器，或者增加了等待的时间。

发明内容

为解决上述技术问题的至少之一，本申请提供了一种云游戏加载方法、系统、装置、存储介质和云游戏系统，以缩短云游戏预加载的时间。

根据本申请的一方面，提供了一种云游戏加载方法，所述云游戏在服务器中运行，所述服务器用于向终端传输所述云游戏的视频流，以及接收所述终端针对所述云游戏的第三指令，所述方法包括以下步骤：获取加载指令；根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；加载所述第一存档，以使所述云游戏加载至第一画面；通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面。

根据本申请的另一方面，提供了一种云游戏加载系统，所述云游戏在服务器中运行，所述服务器用于向终端传输所述云游戏的视频流，以及接收所述终端针对所述云游戏的第三指令，所述系统包括：第一获取单元，用于获取加载指令；第二获取单元，用于根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；加载单元，用于加载所述第一存档，以使所述云游戏加载至第一画面；执行单元，用于通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面。

根据本申请的另一方面，提供了一种云游戏加载装置，包括：程序；存储器，用于存储所述程序；处理器，用于加载所述程序所述的云游戏加载方法。根据本申请的另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有程序，所述程序被处理器执行时实现所述的云游戏加载方法。

根据本申请的另一方面，提供了一种云游戏系统，包括：

第一服务器，用于获取分配请求，根据所述分配请求向终端分配一个第二服务器，并向所述第二服务器发送所述云游戏的加载指令；第二服务器，用于获取加载指令；根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；加载所述第一存档，以使所述云游戏加载至第一画面；通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面；以及向所述终端传输所述云游戏的视频流，以及接收所述终端针对所述云游戏的第三指令。

本申请实施例的有益效果是，根据加载指令获取云游戏的第一存档和第一指令集，然后通过加载第一存档的方式直接将云游戏加载到第一画面，接着执行包括可以对云游戏进行操作的第一指令集对云游戏进行操作，使得云游戏从第一画面加载至第二画面；通过第一存档的加载，可以快速将游戏加载到游戏保存的场景，即第一画面，并在第一画面的基础上通过执行第一指令集对云游戏进行操作，使得云游戏的场景加载到第二画面，这样的方式相对于相关技术缩短了预加载的时间，同时又可以预加载到云游戏不能保存的场景，这样可以缩短游戏服务器预加载云游戏的时间，减少服务器的压力，一定程度上缓解用户分配不到游戏服务器或者分配等待时间长的问题。

附图说明

图1为根据本申请实施例提供的一种云游戏加载方法的流程图；

图2为根据本申请实施例提供的云游戏系统的架构图；

图3为根据本申请实施例提供的一种云游戏系统的模块框图；

图4为根据本申请实施例提供的一种OSS服务器的存储结构示意图；

图5为根据本申请实施例提供的一种游戏保存存档的过程示意图；

图6为根据本申请实施例提供的一种游戏的存档保存机制的示意图；

图7为根据本申请实施例提供的一种剧本的截图；

图8为根据本申请实施例提供的执行图7的剧本的示意图；

图9为根据本申请实施例提供的另一种云游戏加载方法中部分步骤的流程图；

图10为根据本申请实施例提供的一种异常画面的示意图；

图11为根据本申请实施例提供的步骤920的一种子步骤流程图；

图12为根据本申请实施例提供的步骤1120的一种子步骤流程图；

图13为根据本申请实施例提供的步骤1210的一种子步骤流程图；

图14为根据本申请实施例提供的步骤1210的另一种子步骤流程图；

图15为根据本申请实施例提供的步骤130的子步骤流程图；

图16为根据本申请实施例提供的存档复制过程的示意图；

图17为根据本申请实施例提供的一种存档读取过程的示意图；

图18为根据本申请实施例提供的第一指令集的获取过程的流程图；

图19为根据本申请实施例提供的一种剧本代码的截图。

图20为根据本申请实施例提供的第一存档的获取过程的流程图；

图21为根据本申请实施例提供的从内存中获取存档信息的示意图；

图22为根据本申请实施例提供的一种云游戏系统的交互流程图；

图23为根据本申请实施例提供的切片编辑界面示意图；

图24为根据本申请实施例提供的OSS服务器生成异常处理子剧本的示意图；

图25为根据本申请实施例提供的一种云游戏加载系统的模块框图。

具体实施方式

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或装置不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或装置固有的其它步骤或单元。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

云游戏(Cloud gaming)又可称为游戏点播(gaming on demand)，是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thin client)能运行高品质游戏。在云游戏场景下，云游戏软件并不在玩家游戏终端运行，而是在云端服务器中运行。玩家游戏终端无需拥有强大的图形运算与数据处理能力，仅需拥有基本的流媒体播放能力与获取玩家输入指令并发送给云端服务器的能力即可。云游戏可以通过如图2所示的架构实现，在图2中的架构示出云游戏服务器和游戏客户端之间的关系，其中，用户选择的云游戏在云游戏服务器中运行。云游戏服务器通过音视频获取器获取云游戏软件的音视频流，然后经由音视频编码器编码，再通过实时流传输协议(RealTime Streaming Protocol RTSP)等互联网通信协议将经过编码的音视频流发送至游戏客户端。游戏客户端收到经过编码的音视频流后，通过音视频解码器对音视频流进行解码，再由音视频播放器播放游戏的画面和声音，那么用户就可以在终端看到游戏画面以及听到游戏的声音。游戏客户端监听用户的输入指令(包括来自鼠标、键盘和触摸屏等输入设备的输入指令)，会根据用户输入的指令进行事件编码，然后经过自定义通信协议，将编码后的输入事件发送到云游戏服务器。云游戏服务器在接收到这些经过编码的输入事件后，将其进行解码，然后再重现用户的输入。

预加载：为了让玩家启动云游戏即可试玩指定场景下的游戏，那么，在玩家玩云游戏之前，图像识别程序会预先自动控制游戏登录，且通过模拟点击，让游戏进入到指定场景，这个预先加载到游戏指定场景的阶段被称为预加载。

OSS(Object Storage Service)：一种云游戏管理系统，用于维护云游戏数据，处理云游戏所有配置、参数相关的逻辑。本申请将部署有OSS的服务器称作OSS服务器。

剧本，又称作脚本，一种软件自动控制的描述性语言，其可以看作是由多个具有逻辑关系的指令组成的指令集，剧本中通常包括图像匹配、点击、滑屏等指令。剧本被执行时，对软件模拟剧本所描述的操作。

主剧本：云游戏预加载时的剧本，一个云游戏可以拥有多个主剧本，不同的主剧本包含不同的逻辑，可以加载到不同的场景。

异常处理剧本：当主剧本无法正常执行完毕，发生异常时，被调用来处理异常画面的剧本。

异常子剧本：异常处理剧本中处理某个异常的剧本，多个异常子剧本集合则为异常处理剧本，比如：更新处理剧本就是异常子剧本。

静图，即静态画面，是指：云游戏预加载过程中，软件一直停留的一个画面。比如：云游戏的更新画面就是一个静图。可见，静态画面是一种根据主剧本无法处理的画面，是一种异常的画面。

云游戏服务器，是指用于向用户终端提供云游戏服务的设备，其可以是诸如服务器或者安卓板卡等硬件设备，也可以是由硬件设备通过资源划分的方式虚拟出来的虚拟设备，即虚拟机。

存档，是指游戏保存时留下的文件，其记录了关于游戏进度的各种数据。通过游戏存档，可以备份和恢复游戏的各种数据。一般情况下游戏存档中保存的数据是根据玩家的游戏进度而改变的关键参数。在游戏运行过程中，通过读取存档中的关键参数来恢复玩家上一次保存的节点。现存的很大一部分游戏，虽然带有存档功能，但是其存档功能只能在某些特定的节点发挥作用。

切片，在本申请中一个切片是指一个存档和一个主剧本组成的单元，其可以以文件夹的形式存在，或者以压缩包的形式存在，一个切片中的主剧本用于对云游戏进行操作，并且使得云游戏从画面A加载到画面B，其中，画面A是云游戏加载切片中存档后所加载到的画面。

参照图1，本方案提出一种云游戏加载方法，将云游戏加载至存档所保存的场景，即第一画面，然后在第一画面的基础上执行第一指令集对云游戏进行操作，使得云游戏的场景加载到第二画面，这样可以缩短游戏服务器预加载云游戏的时间，减少服务器的压力，一定程度上缓解用户分配不到游戏服务器或者分配等待时间长的问题。

在该实施例中，云游戏在服务器中运行，服务器用于向终端传输云游戏的视频流，以及接收终端针对云游戏的第三指令，具体地，本实施例中第三指令是指用户在进行云游戏时的操作指令，这些操作指令可以是单击、双击、划动或者长按等。参照图2，可知终端作为用户的输入设备和输出设备，云游戏在服务器上运行，服务器通过互联网与终端通信，服务器根据用户在终端输入的操作指令对云游戏进行操作，同时向终端传输游戏画面。

当然，图2中仅示出了终端和游戏服务器之间的关系，但实际上，云游戏服务所采用的系统更为复杂，参照图3，本实施例提供云游戏服务的系统由后台服务器310、OSS服务器320和云游戏服务器330组成。其中，后台服务器310主要用于响应终端340的请求，为终端340分配云游戏服务器330中的安卓服务器331，其中，游戏服务器可以理解成一种配置有多个安卓板卡的设备，其中，安卓板卡是指安装有安卓系统且接入网络的计算机设备，其不包含显示屏和喇叭等输出设备，也不包含如触屏或者键盘等输入设备，安卓板卡通过诸如USB接口或者网络接口等通信接口接入网络。云游戏服务器330用于响应后台服务器的请求，将空闲的安卓板卡分配给终端340。OSS服务器320，则用于管理游戏服务器中各安卓服务器331中的游戏软件，包括执行更新、安装新游戏、卸载游戏、录制游戏的剧本、管理存档和生成切片等。需要理解的是，上述多种服务器的功能也可以集成在一个服务器中实现，上述的任一种服务器也可以由多个分布式服务器组成。本实施例中的安卓板卡亦可以替换成IOS板卡、windows板卡或者linux板卡等。可以理解的图1所示的方法可以由安卓服务器331执行，亦可以由多种服务器配合完成，因此，亦可以将后台服务器310、OSS服务器320和云游戏服务器330看作是一个服务器，即看成一个执行的主体。

本实施例以图1中方法由安卓服务器331执行为例进行说明，本实施例包括步骤110-步骤140。

步骤110、获取加载指令。

在本实施例中，OSS服务器320通过后台服务器310向云游戏服务器330请求分配100台安卓服务器331来加载游戏A的第三关。后台服务器310向云游戏服务器330发送请求，要求分配100台安卓服务器331来加载游戏A的第三关。云游戏服务器330向100台空闲的安卓服务器331发送加载指令，安卓服务器331在本步骤中获取加载指令。其中，该指令中包含了游戏的信息(例如，游戏ID，其中ID是指唯一标识)、存档信息(例如，存档ID)和剧本的信息(例如，剧本ID)。通过该游戏指令，安卓服务器331可以确定需要加载哪个游戏的加载以及加载到何种场景。

步骤120、根据加载指令获取云游戏的第一存档和第一指令集，其中，第一指令集包括至少一个用于对云游戏进行操作的指令。

需要理解的是，加载指令中包含游戏的信息可以是游戏的ID，而存档和剧本的信息可以包括存档ID和剧本ID，其中，本实施例所指的存档即步骤120中的第一存档，剧本即步骤120中的第一指令集，在一些例子中，为了方便管理存档和剧本，将剧本和存档打包成切片，并通过一个切片ID来索引切片中的存档ID和剧本ID。在本步骤中，安卓服务器331可以通过加载指令中包含的游戏的ID、存档ID和剧本ID，查找到对应的第一存档和第一指令集，其中，查找过程是通过游戏ID查找游戏的存档索引表和剧本索引表，然后基于存档ID通过存档索引表在数据库中查找到第一存档，基于剧本ID通过存档索引表在数据库中查找到第一指令集。其中，在本实施例中，第一存档和第一指令集存储在OSS服务器320之中。OSS服务器320中的存储结构如图4所示，每个游戏都设有自己的切片存储空间，切片包括一个存档和一个主剧本。在另一些例子中，游戏的存档和剧本(即第一指令集)也可以由云游戏服务器330或者安卓服务器331进行存储。

在本实施例中的存档，是在用户或者运营人员在正常进行游戏的情况下触发保存的。如图5所示，运营人员在游戏画面500中点击保存按钮510，触发游戏程序保存存档，其中，保存的过程是从内存520(视运行环境而定，例如可以是安卓服务器331的内存)中，将特定的参数的数值(通常是一些随着游戏进行发生变化的参数，例如人物等级、人物属性、道具、关卡、积分等数值)保存到一个游戏指定格式的文档中，形成存档530。例如，在该例子中将Data2～Data6存到存档530中。其中，存档的文件格式可以是txt。可以理解的是，当游戏读取这个存档的时候，将存档中各参数的数值读取到内存中，即可以还原出存档保存的游戏进度。在现在流行的游戏中，一般不支持用户在任意场景保存进度，而是只允许用户将进度保存在时间上最接近的保存节点(该节点一般是用户已经通过的节点)。参照图6，在游戏进度轴上包括节点A和节点B，其中节点A为用户已经通过，且可以保存存档的节点，而节点B则是用户触发保存动作的节点，由于该游戏不支持任意场景的节点保存，故用户在节点B触发游戏保存动作的时候，存档中保存的是节点A的游戏参数值。可以理解的是，如果需要将该游戏直接加载到节点B，除了通过加载存档到节点A以外，还需要一个剧本，从画面1(即节点A)，将游戏操作到画面B(即节点B)。

在部分实施例中，剧本是由运营人员根据加载场景的需要，从存档起点的画面开始进行录制的。例如从画面1录制到画面2。剧本录制的时候，会将用户的操作指令，以及检测到用户的操作指令时的画面进行截图保存，关联成一组具有逻辑关系的指令，这一组指令的执行逻辑是识别到该画面，就执行该动作。例如，在录制剧本的时候，用户在执行点击坐标(x，y)的时候，截图的画面是画面1，则对应地生成的指令是，识别到画面1的时候，执行对坐标(x，y)的点击，在本实施例中，将画面1称作这组指令的例图。如果没有识别到一组指令对应的画面时，则会不断重复执行图像识别直到超时或者直到识别到该画面，当然也可以按照一定间隔重复执行，直到执行次数达到最大值或者识别到该画面。例如，一组指令是在识别到画面1的时候，执行对(x，y)的点击，如果执行到该组指令的时候，一直没有识别到画面1，则会不断重复识别画面1，直到执行超时或者识别到画面1。通过将用户的多个操作和对应的画面关联起来，形成多组有顺序的指令，从而得到一个将云游戏从画面1操作到画面2的剧本。在该步骤中，由于剧本是已经录制好的，只需要根据加载指令，查找到对应的剧本(即第一指令集)，就可以通过执行剧本来完成云游戏的预加载。

步骤130、加载第一存档，以使云游戏加载至第一画面。

具体地，在本步骤中，可以通过多种方式来加载第一存档。

方式一：适用于可以自动读取存档的游戏，这一类游戏在启动时自动加载预设路径下预设名称的存档文件，并自动加载到存档所保存的游戏节点。因此，通过将第一存档命名为预设名称且放入预设路径下的文件夹即可以由游戏本身完成第一存档的加载。

方式二：基于预先录制的剧本，模拟人在游戏中读取存档的操作。一般可以存档的游戏，在游戏菜单中都包含读取存档的操作，因此可以通过录制剧本的方式来模拟人工加载存档的操作。具体地，模拟人工加载的方式是指模拟人工通过点击游戏菜单加载一个存档的操作来完成存档加载的方式。参照图17，在云游戏启动的时候，进入游戏的第一关，如画面1710所示，可以通过模拟点击设置按钮1711，进入到画面1720，然后通过模拟点击加载存档按钮1721，进入画面1730，此时，通过模拟点击第一存档的选项按钮1731，这样便可以模拟人工读档的动作来实现存档加载。

方式三：基于游戏的加载指令实现加载，在部分游戏中，支持带参数的指令启动。通过编辑一个指令集，并通过该指令集启动游戏，游戏根据指令集中的指令完成存档的读取。例如，部分游戏支持命令行启动，例如，通过在命令行中运行指令，“star C:\game1–round1-session12”，在该例子中，“star”是启动指令，“C:\game1”是游戏位置，“-round1”是指加载到游戏的第一回合，“-session12”是指第一回合的第12章节。

其中，第一存档所保存的节点所显示的是第一画面，因此云游戏加载第一存档后可以还原到第一存档当时保存的场景，即第一画面。

步骤140、通过执行第一指令集对云游戏进行操作，使得云游戏从第一画面加载至第二画面。

具体地，本实施例所指的操作包括但不限于：点击、拖拽或者滑动等。在本子步骤中，安卓服务器可以通过一个图像识别程序来执行第一指令集，该图像识别程序具有识别第一指令集中的图像的功能，以及具有执行操作指令的功能。例如，如图7所示，本实施例提供一种容易阅读的剧本的示意图700，该剧本中以文字代替了代码，因此可以理解的是，在实际剧本中，文字指令是对应的指令代码。参照图7和图8，第一个指令是识别与名称为“123”的例图相同的画面(该例图是录制第一指令集(剧本)的时候，在用户执行操作时云游戏的画面截图，其在录制剧本的时候已经关联到第一指令集中)，在该例子中，名称为“123”的例图与画面810相同，当识别到画面810以后，图像程序根据第一指令集模拟点击位置(X1，Y1)。此时游戏会跳转到画面820，在图7中另一个指令是识别与名称为“234”的例图相同的图像。

可以理解的是，在部分的游戏场景中，虽然画面的结构相同，但是局部细节可能不同。例如在图8的骰子游戏中，区域840显示的是掷骰子的结果，每次的结果均可能与录制剧本时的结果不相同。因此，在识别如画面820一样的画面时，可以采取局部识别的方式，例如将例图设置为画面820的局部，例如设置例图为区域830。当然，由于游戏画面一般有固定的顺序，也可以通过降低识别相似度阈值的方式来提高图像识别模型的容错率，比如，设置图像识别程序判定两个画面相同的条件为相似度大于80％(该条件比较宽松)。当图7的剧本中的第二个指令判定识别到画面820后，图像识别程序会模拟点击位置(X2,Y2)。因此，游戏被顺利加载到第二关，如画面850所示。可以理解的是，剧本也是一种指令集合，其中的多个指令可以基于某些逻辑组合在一起，因此，通过设计指令之间的逻辑关系，可以处理更加复杂的加载场景。

上述实施例已经对本方案的预加载过程进行了说明，可以理解的是，本方案根据加载指令获取云游戏的第一存档和第一指令集，然后通过加载第一存档的方式直接将云游戏加载到第一画面，接着执行包括可以对云游戏进行操作的第一指令集对云游戏进行操作，使得云游戏从第一画面加载至第二画面；通过第一存档的加载，可以快速将游戏加载到游戏保存的场景，即第一画面，并在第一画面的基础上通过执行第一指令集对云游戏进行操作，使得云游戏的场景加载到第二画面，这样的方式相对于相关技术缩短了预加载的时间，同时又可以预加载到云游戏不能保存的场景，这样可以缩短游戏服务器预加载云游戏的时间，减少服务器的压力，一定程度上缓解用户分配不到游戏服务器或者分配等待时间长的问题。

在一些实施例中，云游戏由于不一定是云游戏服务商所提供的，可能是第三方游戏开发商所提供的，因此，云游戏服务商往往无法及时得知游戏开发商的更新或者活动推送，同时，云游戏加载过程中也可能遇到诸如程序崩溃或者网络中断等情况。因此在预加载过程中，如果遇到剧本不能处理的画面时，需要寻找异常解决方案。在该情形下，由于剧本不能处理这些异常画面，云游戏的画面会一直停留在异常画面处，使得云游戏的画面变成一个静态的画面，因此，在本实施例中也将异常画面称作静图。

因此，参照图9，在本实施例提供的云游戏加载方法，还包括以下步骤：

步骤910、当执行第一指令集对云游戏进行操作的过程中，第一指令集中第一指令的执行时间超过第一阈值或者执行次数超过第二阈值，则获取云游戏当前的第三画面；

步骤920、根据第三画面获取用于处理第三画面的第二指令集；

步骤930、执行第二指令集；

步骤940、在执行所述第二指令集后继续执行第一指令以及第一指令集中未执行的指令，或者在执行所述第二指令集后重新执行所述第一指令集。

可以理解的是，步骤910-步骤940可以是步骤140的一种分支步骤。即当在执行第一指令集出现异常时，才执行这些步骤。

在图7的剧本中，如果识别例图“123”的指令执行失败，即没有识别到例图“123”的情况。在这样的情况下，一般会等待一定的时间然后重新执行图像识别指令，例如等待1秒。当执行次数超过10次(相当于第二阈值)的时候，剧本会跳出异常。此时，图像识别程序就可以判定当前剧本无法继续完成加载的任务。同理，在部分实施例中，也可以不限制指令的执行次数，而是限定指令的最大执行时间。例如，如果指令在10秒(相当于第一阈值)内都无法正确执行，则跳出异常。此时，图像识别程序也可以判定当前剧本无法继续执行。

由于在云游戏系统中，运行云游戏的安卓服务器的数量众多，而且不同安卓服务器执行加载的时间可能有先后次序。因此，部分安卓服务器可能已经遇到过异常画面，并且OSS服务器已经生成了对应的异常处理子剧本。异常处理子剧本以异常画面作为例图供安卓服务器索引，在该实施例中，每个异常处理子剧本可以设置一个例图，例图通常是主剧本无法处理的异常画面，例如更新画面、公告画面等。因此，当一个安卓服务器在执行预加载的时候遇到无法处理的异常画面的时候，可以通过将截取的异常画面与异常处理子剧本的例图进行比对的方式来查找到对应的异常处理子剧本，这样就可以不用重复生成异常处理剧本了。

因此，在步骤910中获取第三画面(异常画面)后，可以通过第三画面在OSS服务器中检索对应的第二指令集(即异常处理子剧本)。可以理解的是，异常处理子剧本也和主剧本类似，同样是由图像识别程序来执行，异常处理子剧本中的指令一般包括异常画面的识别指令和对应的操作指令。参照图10，图10是一种常见的异常画面，如画面1010所示，在游戏加载过程中遇到网络不稳定。异常处理子剧本可以识别画面1010中的提示框1020，并在识别到提示框1020的情况下，对提示框1020中的重连网络按钮1030进行点击。如果在网络可以恢复的情况下，可以从第一指令集执行异常的节点处继续执行，以完成云游戏的加载任务。在以上例子中，由于第一指令是最后执行且出现执行异常的指令，因此使用异常处理子剧本处理异常画面后，会在第一指令处继续执行，一般情况下，第一指令是一种条件指令(即根据当前条件决定执行后续的哪些步骤)，例如可以一个图像识别指令。

参照图11，在一些实施例中，步骤920、根据第三画面获取用于处理第三画面的第二指令集，包括：

步骤1110、根据第三画面在多个第三指令集中匹配第二指令集。需要理解的是，第三指令集在本实施例中是指异常处理子剧本，每个游戏可以拥有多个异常处理子剧本，每个异常处理子剧本都有对应的例图(即可以处理的异常画面)，在安卓服务器检测到异常画面(第三画面)时，可以根据第三画面和多个第三指令集的例图进行匹配，将相匹配的第三指令集作为本步骤所指的第二指令集。

步骤1120、在匹配失败的情况下，从第三画面中识别第一按钮的位置，生成第二指令集，其中，第二指令集中包括用于点击第一按钮的指令。

可以理解的是，如果第三画面(异常画面)对应的第二指令集(异常处理子剧本)存在，安卓服务器只需要读取第二指令集即可，但是如果在第三画面对应的异常处理子剧本不存在的情况下，则安卓服务器无法匹配到用于处理第三画面的异常处理子剧本。此时，则可以由安卓服务器或者OSS服务器根据第三画面，生成异常处理子剧本。其中，如果异常处理子剧本由安卓服务器生成，则生成的异常处理子剧本需要上报到OSS服务器中存储，以便于共享给其他安卓服务器，这样可以避免其他安卓服务器重复生成异常处理子剧本。同理，该步骤也可以由OSS服务器完成,OSS服务器在安卓服务器请求匹配第三画面对应的异常处理子剧本时，如果发现没有对应的异常处理子剧本，则生成第三画面对应的第二指令集。其中，大多数的异常画面可以概括为以下几种，更新提示界面、网络中断提示界面和公告提示界面等。这些界面的共同点都是具有操作按钮，通常，这些操作按钮中都有诸如“更新”、“确定”、“好的”、“已清楚”、“OK”、“继续”等等的常用词语。因此，可以通过识别按钮轮廓以及按钮轮廓中的文字，可以识别出特定按钮(第一按钮)的位置，然后通过生成点击该按钮的指令，再将识别第三画面的指令和点击第一按钮的指令组合起来，就可以得到第三画面的异常处理子剧本。

参照图12，具体地，步骤1120中、从第三画面中识别第一按钮的位置，生成第二指令集，包括：

步骤1210、通过图像识别模型从第三画面中识别第一按钮的位置。

步骤1220、生成识别第三画面的指令以及生成用于点击第一按钮的指令作为第二指令集。

从以上实施例的分析可知，可以结合按钮的图像特征和文字特征来确定第一按钮的位置，并将识别第三画面的指令和点击第一按钮的指令组合在一起得到第二指令集。

在本实施例中，将对按钮识别的过程进行详细的说明。具体地，步骤1210、通过图像识别模型从第三画面中识别第一按钮的位置的步骤，包括以下两种方式：

第一种方式，通过识别关键词的方式确定按钮的位置，参照图13，第一种方式包括步骤1310和步骤1320。

步骤1310、通过图像识别模型从第三画面中识别属于第一词语集合的第一词语。

其中，第一词语集合可以是常见于异常画面的词语，其可以是中文、英文等常见语言中的词语。例如，“更新”、“确定”、“好的”、“已清楚”、“OK”、“继续”等，通过构造一个足够大的第一词语集合，可以应对大多数的异常画面中按钮的识别情况。

步骤1320、将第一词语的所在的位置作为第一按钮的位置。

对于部分场景而言，异常画面中会存在弹出框，弹出框之中包含第一按钮，按钮中包括特定的词语。基于步骤1310的所识别的第一词语的位置，基本上可以确定出按钮的位置。在部分场景中，第三画面中包括多个属于第一词语集合的第一词语，此时，可以采取点击所有第一词语所在的位置的策略，即将所有的第一词语所在的位置都作为第一按钮的位置，并生成多个点击指令。由于正确的按钮一般只有一个，所以该方法生成的多个指令中，会有一个是可以点击到第一按钮的。当然，如果需要避免多次点击产生的误操作，可以进一步结合字体特点、字体是否处于一个按钮轮廓中等条件从多个第一词语中确定出第一按钮的位置。

第二种方式，通过识别连通域的方式确定按钮的位置。参照图14，第一种方式包括步骤1410和步骤1420。

步骤1410、通过图像识别模型从第三画面中识别满足预设条件的第一连通域。

具体地，由于按钮边框有明显的轮廓，因此可以通过图像分割的方式，识别出第三画面中的连通域，其中，连通域是指由一个曲线围成的区域，对图像进行二值分割后，往往会形成一些由线条围成的区域，即连通域。例如，可以将第三画面进行灰度化，然后进行二值分割，可以得到画面中的各种连通域。而对于按钮而言，按钮的大小通常会在一定的大小范围内，同时，按钮一般是规则形状，例如按钮可能是矩形、圆角矩形、菱形、椭圆形或者圆形等等。基于连通域所围成的面积大小和围成的形状，可以很容易地确定出画面中的按钮位置。具体地，当第一连通域所围成的面积属于预设范围且第一连通域的形状为对称形状，则判定第一连通域满足预设条件。上述实施例对于按钮位置的识别特别准确，对于只有一个按钮的情况，该实施例具有很好的处理效果。

步骤1420、将第一连通域所在的位置作为第一按钮的位置。

与识别特定文字的方案类似，本步骤将识别出的连通域所在的位置当作第一按钮的位置。可以理解的是，如果识别到多个连通域，可以进一步结合连通域内的文字来确定哪个是需要点击的按钮。一般情况下，会选择表达含义为正面含义的文字所处的连通域，例如，识别到两个连通域中的文字分别是“确定”和“取消”，一般选择点击“确定”的按钮。

在部分实施例中，为了改善第一按钮的识别准确率，在文字识别的基础上加上连通域识别。步骤1320、将第一词语的所在的位置作为第一按钮的位置，通过以下逻辑实现：

首先判断识别到的第一词语的数量是否大于1。可以理解的是，由于异常画面的提示框里面除了按钮以外往往还有其他提示性质的描述，例如，提示用户“发布了新活动，确认参加在22点前在公告栏填写报名信息。”，提示框的按钮为确定。图像识别模型可能会识别出“确认”和“确定”两个第一词语。

当第一词语的数量为一个时，由于没有其他的选择，因此可以将第一词语所在的位置作为第一按钮的位置。通常这个第一词语所在的位置就是按钮所在的位置。

当第一词语的数量为多个时，检测各第一词语是否处于满足预设条件的第二连通域内，将处于第二连通域内的第一词语所在的位置作为第一按钮的位置。

在本实施例中，首先可以检测异常画面中的连通域，其中检测方式可以是通过将异常画面灰度化，然后进行二值分割。这样可以利用按钮的边缘轮廓与背景色存在差异的特点，识别出表示按钮轮廓的第二连通域。鉴于按钮的大小一般处于某个尺寸范围内，并且按钮的形状一般是规则形状，因此可以基于连通域围成的形状以及围成的面积大小来判定这个连通域是否一个按钮的轮廓。具体地，当第二连通域所围成的面积属于预设范围且第二连通域的形状为对称形状，则判定第二连通域满足预设条件。即便识别出多个第一词语，也可以结合第二连通域来确定第一按钮的位置。本实施例在出现多个第一词语的情况下，可以有效地提升识别结果的准确性，与此同时，这样可以减少点击指令的数量，一方面提升剧本的执行效率，另一方面可以避免错误点击而触发其他计划外的时事件。

在部分实施例中，步骤1420、将第一连通域的位置作为第一按钮的位置，包括：

判断第一连通域的数量是否大于1。

当满足所述预设条件的第一连通域的数量为一个时，将第一连通域所在的位置作为第一按钮的位置。可以理解的是在这一情况下，满足预设的面积和形状条件的第一连通域只有一个的时候，基本上不会误判第一按钮的位置。

当满足预设条件的连通域的数量为多个时，检测各第一连通域内是否包含属于第二词语集合的第二词语，将包含第二词语的第一连通域的位置作为第一按钮的位置。在这一情况下，由于满足预设条件的连通域有多个，一般是两个，例如，一个是“确定”，另一个“取消”。此时，可以通过识别连通域内的文字，当然这里所指的连通域内的文字是指第三画面原图上的文字。通过识别第一连通域内的文字是否属于第二词语集合，可以从多个连通域中确定出第一按钮的准确位置。例如，本实施例的第一按钮是确定按钮，那么第二词语集合中的词语可以是诸如“确定”、“OK”或者“确认”等等词语。可以理解的是，通过连通域检测和文字检测的配合，可以准确地确定出第一按钮的位置，可以避免错误点击触发其他事件，增加异常画面处理的成功率。

参照图15，在本实施例中，步骤130，加载第一存档，包括：

步骤1510、将第一存档复制到云游戏在服务器的存档路径下，其中，云游戏根据存档路径读取存档。如图16所示，首先安卓服务器从OSS服务器中获得第一存档。然后安卓服务器将第一存档复制到云游戏在安卓服务器中的存档路径下。如图16所示，在该例子中的存档路径为“C:\\hrj\game1\userfile\”。

步骤1520、执行第四指令集使云游戏读取第一存档。

具体地，在本实施例中，第四指令集也可以是一个剧本，而该剧本可以是专门在游戏开始时进行存档加载的剧本。参照图17，在云游戏启动的时候，进入游戏的第一关，如画面1710所示，可以通过第四指令集模拟点击设置按钮1711，进入到画面1720，然后通过第四指令集模拟点击加载存档按钮1721，进入画面1730，此时，通过第四指令集模拟点击第一存档的选项按钮1731，这样便可以通过第四指令集模拟人工读档的动作来实现存档加载。

参照图18，本实施例中的第一指令集通过以下步骤获得：

步骤1810、获取将云游戏从所述第一画面加载至第二画面的第四指令，以及第四指令被执行时所述云游戏的第四画面；

步骤1820、根据各第四指令，以及各所述第四指令对应的第四游戏画面生成第一指令集。

具体地，用户可以通过脚本录制程序，来进行脚本的录制，其中，从第一画面处开始进行操作，直到游戏加载到第二画面。在录制的过程中，脚本录制程序会记录用户的每一个操作指令(即第四指令)，这些操作指令包括但不限于：点击、拖拽或者滑动等操作。同时，在脚本录制程序在每捕捉到一个第四指令时，会将当时的画面(即第四画面)进行截图，并生成用于识别第四画面的指令，以及对应的第四指令构成一组条件执行的指令，即识别到第四画面就执行对应的第四指令。通常识别第四画面的指令由函数指令“match”和待识别图像的文件名称组成，例如，待识别的图像名称可以以“name＝123.jpeg”表示。当然，指令中也可以包括第四画面的识别区域，如“ROI＝523,458,250,235”，指令最大执行次数，如重试50次“retry＝50”等，实际上生成指令的过程是将参数的数值填入语句模板中，得到指令。

本实施例结合表1，对以上实施例所提到的剧本(包括主剧本和异常处理子剧本等等)进行更详细的说明。表1为构成剧本的节点的功能和配置说明，本申请中的所有剧本均由表1中的若干种节点构成。

表1、节点的功能和配置说明

图19示出本实施例中的一种剧本的代码截图1900，截图1900中的剧本是的一种游戏更新的剧本。

<？xml version＝“1.0”encoding＝”utf-8”？>//声明xml的版本和编码。

<root>//根节点root。

<match name＝“123.jpeg”template＝“234.jpeg”hessian＝“200”,retry＝“50”,delay＝“10000”ROI＝“523,458,240.235”useOldScreenShot＝“0”method＝“surf”checkPrev＝“0”>//通过图像相似度SURF算法(OpenCV特征点提取方法，从图像的轮廓和角点中寻找特征点)匹配游戏更新开始画面(234.jpeg)。

<true>//如果匹配游戏更新开始画面成功。

<input actionType＝“0”offset＝“0,0”times＝“1”/>//点击游戏更新按钮，开始更新游戏。

</true>//匹配游戏更新开始画面成功操作结束。

</match>//匹配游戏更新开始画面结束。

<watch name＝“345.jpeg”template＝“456.jpeg”hessian＝“200”,retry＝“50”,delay＝“2000”ROI＝“723504,240.216”useOldScreenShot＝“0”method＝“surf”checkPrev＝“1”>//匹配游戏更新结束画面(456.jpeg)。

<true>//如果匹配游戏更新结束画面成功。

<function actionType＝“5loadPrevScropt＝“1”loadOldStep＝“1”/>//退出游戏更新。

</true>//匹配游戏更新结束画面成功操作结束。

</watch>//匹配游戏更新结束画面结束。

</root>//根节点root结束。

截图1900中的代码表示一下含义：第1行：声明xml的版本和编码。第2行：根节点root。第3行：通过图像相似度SURF算法(OpenCV特征点提取方法，从图像的轮廓和角点中寻找特征点)匹配游戏更新开始画面(234.jpeg)。第4行：如果匹配游戏更新开始画面成功。第5行：点击游戏更新按钮，开始更新游戏。第6行：匹配游戏更新开始画面成功操作结束。第7行：匹配游戏更新开始画面结束。第8行：匹配游戏更新结束画面(456.jpeg)。第9行：如果匹配游戏更新结束画面成功。第10行：退出游戏更新。第11行：匹配游戏更新结束画面成功操作结束。第12行：匹配游戏更新结束画面结束。第13行：根节点root结束。其中上述的一行以一组“<>”表示。

以上是一种主剧本的实施例，根据实际游戏的不同、场景的不同，上述剧本中的指令会有所不同。

参照图20、本实施例公开了第一存档的获得方式，具体包括以下步骤：

步骤2010、获取保存指令。

步骤2020、根据保存指令，获取所述云游戏的会话数据和缓存数据。

步骤2030、从所述会话数据中提取第一参数组，从所述缓存数据中提取第二参数组，并将所述第一参数组和第二参数组保存为第一存档。

步骤2040、从所述会话数据、缓存数据或者第一存档中提取第三参数组，根据所述第三参数组得到所述第一存档的标签。

在本实施例中，保存指令由玩家在进行保存操作时触发，属于游戏中的指令。当检测到游戏中的保存指令后，会读取游戏的会话数据和缓存数据。在本实施例中，会话数据是指游戏运行过程中在内存中加载的用户私有数据，例如用户游戏的进度，人物等级等等数据，而缓存数据可以存储在硬盘中，主要包括游戏本身的全局数据，例如游戏本身的操作数据流、游戏场景的状态等。在本实施例中，从会话数据中读取一些关键参数(即第一参数组，如游戏进度，人物等级等等)，从缓存数据中读取另一些关键参数(即第二参数组，例如游戏场景的状态等)，然后将第一参数组和第二参数组保存为第一存档。可以理解的是第一参数组和第二参数组可以以一个或者多个文件的形式存在，第一存档也可以以一个文件或者多个文件的形式存在。可以理解的是，对于游戏存档而言，一般只记录存档时间、以及随着游戏进程发生变化的关键参数，这些数据在游戏运行时一般会被加载到内存之中,这些关键参数可以是诸如人物等级、游戏进度、人物属性、道具、积分等等的信息。上述的存档保存方式只是一种示例性说明，也有部分游戏可以仅通过保存会话数据中的关键参数来获得第一存档。如图21所示，在内存之中，包括多个进程(不同进程通常属于不同的程序)的会话数据，而会话数据中包括很多个参数，在生成存档的时候，就是将其中的部分参数保存起来。例如，在图21的例子中，从会话数据Session1中读取Data4和Data5作为第一参数组写入存档。类似地，也可以从缓存数据中提取需要保存的数据，作为第二参数组写入存档。

为了运营人员确认存档文件是哪个游戏哪个关卡的存档，可以从会话数据、缓存数据或者存档数据中读取游戏名称、游戏关卡等信息，作为存档的标签。例如，以“某某游戏”和“第10关”来命名存档或者作为存档的两个标签。在部分实施例中，如果主剧本也通过一定的规则进行命名，则服务器可以自动将主剧本和游戏存档进行组装，得到游戏切片。

参照图22，本实施例从整个云游戏系统的角度，对上述云游戏加载方法进行说明。

该实施例包括步骤2201-步骤2216。

步骤2201，运营人员通过OSS服务器进行预加载剧本的录制，并将录制好的剧本按照预设的命名规则进行命名。

步骤2202，运营人员在游戏过程中保存存档，OSS服务器会在存档保中读取某些信息，例如游戏名称和当前的关卡数等，并将其作为存档的标签。例如，当用户玩到某一关卡后，可以选择将该游戏点保存下来，点保存时，会触发安卓服务器的存档生成程序。先将该玩家的游戏session(会话数据)提取出来，然后找到游戏的cache(缓存)文件并经过精炼(即将记录游戏时间点及操作的日志等关键信息打包)后，得到存档文件并将其上传到OSS服务器。OSS服务器通过解析存档包里记录的游戏id，游戏关卡等信息，将该存档关联至相应的游戏并打上标签。

步骤2203，将存档和预加载剧本制作成切片。如图23所示，界面2300为切片编辑的界面，运营人员可以通过访问OSS服务器来访问上述界面，然后在界面2300中完成切片的编辑工作在界面2300中，运营人员可以选择切片所述的游戏、编辑切片的名称、切片的相关说明、以及选择对应的存档和剧本。在图23的例子中，针对某某游戏的第三关第二个场景进行切片编辑，其中具备是第三关开始到第二个场景的剧本，而存档则是将游戏加载到第三关的存档。

步骤2204，后台服务器向安卓服务器发送加载指令，以使按照服务器按照加载指令加载切片。一般首先是OSS服务器通过将游戏启动参数(如场景ID、游戏ID、切片ID等)传递给后台服务器，然后后台服务器将切片ID传递给安卓服务器，安卓服务器通过切片ID从OSS服务器中获取切片(包含存档和主剧本)，随后加载切片对应的存档并拉起图像识别程序执行切片对应的主剧本。上述ID是指唯一标识。

步骤2205，安卓服务器向OSS服务器请求加载指令所指定的游戏的切片。具体地，可以通过在请求中写入切片ID来实现。

步骤2206，OSS服务器向安卓服务器返回切片，其中切片中包括存档和预加载剧本。该切片就是安卓服务器需要加载的场景对应的切片。

步骤2207，安卓服务器加载存档，然后执行预加载剧本。一般情况下，存档加载的过程会顺利完成，但是预加载剧本的执行，有可能中途因为种种原因而中断，例如，公告，网络中断或者游戏更新等。

步骤2208，如果检测到预加载剧本执行超时，获取当前的云游戏的画面作为静图。

步骤2209，安卓服务器向OSS服务器上报静图。

步骤2210，OSS服务器通过静图来检测异常处理处理剧本。

步骤2211，如果OSS服务器基于静图无法匹配到异常处理子剧本，则基于静图生成异常处理子剧本。具体地，OSS服务器通过图像识别模型识别静图中的按钮，然后生成检测该静图的指令以及点击这个按钮的指令，作为异常处理子剧本。参照图24，当云游戏服务器在预加载游戏时，会启动静图监控服务，如果发现静图(一直停留在某一个特定画面，由剧本执行超时触发)，此时图像识别程序会将该静态图上报至OSS服务器。OSS服务器通过对上传的静图进行语义识别，如果发现有异常，则会上报至告警服务，并启动生成异常切片的服务生成处理该类型的异常处理子剧本，加入统一的异常处理剧本中。每个游戏拥有很多个切片(不同的切片拥有加载到不同场景的能力)，但也有一个异常处理剧本，包含多个类型的异常处理子剧本，如：游戏更新异常处理子剧本等，以修复不同的异常类型。当预加载过程中出现问题的话，会自动遍历该游戏的异常处理子剧本进行处理。在本实施例中OSS服务器承担了静图的图像识别和异常提取的功能，并自动生成游戏对应的异常处理子剧本。在一些实施例中OSS服务器也包含警告服务，用于提醒运营人员异常的产生，以便于运营人员可以及时介入处理OSS服务器无法自动处理的情况。

步骤2212，OSS服务器向安卓服务器返回异常处理子剧本。

步骤2213，安卓服务器执行异常处理子剧本处理异常画面(静图)。

步骤2214，安卓服务器中预加载剧本执行异常的指令处继续执行预加载剧本，从而顺利完成预加载。

步骤2215，安卓服务器向后台服务器发送完成预加载的信息。

步骤2216，后台服务器在收到完成预加载的信息后，将安卓服务器分配给用户终端。

可以理解的是，上述实施例结合存档和预加载剧本，可以实现大部分场景的预加载，并向相对于单使用剧本进行预加载的方案，更加节省加载时间，从而避免安卓服务器加载不及时导致没有足够的安卓服务器分配给用户。此外，可以理解的是，本方案在遇到异常时，可以基于检测到的游戏静图来自动生成处理剧本，其减少了系统对人工的依赖，提升了系统的运作效率。

参照图25，本实施例公开了一种云游戏加载系统，所述云游戏在服务器中运行，所述服务器用于向终端传输所述云游戏的视频流，以及接收所述终端针对所述云游戏的第三指令，所述系统包括：第一获取单元2510，用于获取加载指令；第二获取单元2520，用于根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；加载单元2530，用于加载所述第一存档，以使所述云游戏加载至第一画面；执行单元2540，用于通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面。本实施例公开了一种云游戏加载装置，包括：程序；存储器，用于存储所述程序；处理器，用于加载所述程序以执行所述的云游戏加载方法。

本实施例公开了一种云游戏系统，包括：

第一服务器，用于获取分配请求，根据所述分配请求向终端分配一个第二服务器，并向所述第二服务器发送所述云游戏的加载指令。参照图3，本实施例中的第一服务器可以是指后台服务器310。

第二服务器，用于获取加载指令；根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；加载所述第一存档，以使所述云游戏加载至第一画面；通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面；以及向所述终端传输所述云游戏的视频流，以及接收所述终端针对所述云游戏的第三指令。在本实施例中，第二服务器可以是指安卓服务器331。

本申请实施例还公开了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述的推广资源配置方法。

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

以上是对本申请的较佳实施进行了具体说明，但本申请并不限于上述实施例，熟悉本领域的技术人员在不违背本申请精神的前提下还可做作出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (14)

1.一种云游戏加载方法，其特征在于，所述云游戏在服务器中运行，所述服务器用于向终端传输所述云游戏的视频流，以及接收所述终端针对所述云游戏的第三指令，所述方法包括以下步骤：

获取加载指令；

根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；

加载所述第一存档，以使所述云游戏加载至第一画面；

通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面。

2.根据权利要求1所述的云游戏加载方法，其特征在于，所述方法还包括以下步骤：

当所述通过执行所述第一指令集对所述云游戏进行操作的过程中，所述第一指令集中第一指令的执行时间超过第一阈值或者执行次数超过第二阈值，则获取所述云游戏当前的第三画面；

根据所述第三画面获取用于处理所述第三画面的第二指令集；

执行所述第二指令集；

在执行所述第二指令集后继续执行所述第一指令以及第一指令集中未执行的指令，或者在执行所述第二指令集后重新执行所述第一指令集。

3.根据权利要求2所述的云游戏加载方法，其特征在于，所述根据所述第三画面获取用于处理所述第三画面的第二指令集，包括：

根据所述第三画面，在多个第三指令集中匹配与所述第三画面相匹配的所述第二指令集；

在匹配失败的情况下，从所述第三画面中识别第一按钮的位置，生成所述第二指令集，其中，所述第二指令集中包括用于点击所述第一按钮的指令。

4.根据权利要求3所述的云游戏加载方法，其特征在于，所述从所述第三画面中识别第一按钮的位置，生成所述第二指令集，包括：

通过图像识别模型从所述第三画面中识别所述第一按钮的位置；

生成识别所述第三画面的指令以及生成用于点击所述第一按钮的指令；

将所述识别所述第三画面的指令以及用于点击所述第一按钮的指令作为第二指令集。

5.根据权利要求4所述的云游戏加载方法，其特征在于，所述通过图像识别模型从所述第三画面中识别所述第一按钮的位置，包括：

通过图像识别模型从所述第三画面中识别属于第一词语集合的第一词语；

将所述第一词语的所在的位置作为所述第一按钮的位置；

或者

通过图像识别模型从所述第三画面中识别满足预设条件的第一连通域；

将所述第一连通域所在的位置作为所述第一按钮的位置。

6.根据权利要求5所述的云游戏加载方法，其特征在于，所述将所述第一词语的所在的位置作为所述第一按钮的位置，包括：

当所述第一词语的数量为一个时，将所述第一词语所在的位置作为所述第一按钮的位置；

当所述第一词语的数量为多个时，检测各所述第一词语是否处于满足预设条件的第二连通域内，将处于所述第二连通域内的所述第一词语所在的位置作为所述第一按钮的位置。

7.根据权利要求5所述的云游戏加载方法，其特征在于，所述将所述第一连通域所在的位置作为所述第一按钮的位置，包括：

当满足所述预设条件的连通域的数量为一个时，将所述第一连通域所在的位置作为所述第一按钮的位置；

当满足所述预设条件的连通域的数量为多个时，检测各所述第一连通域内是否包含属于第二词语集合的第二词语，将包含所述第二词语的第一连通域所在的位置作为所述第一按钮的位置。

8.根据权利要求1所述的云游戏加载方法，其特征在于，所述加载所述第一存档，包括：

将所述第一存档复制到所述云游戏在服务器的存档路径下；

执行第四指令集使所述云游戏根据所述存档路径读取所述第一存档，其中，所述第四指令集用于控制所述云游戏进行存档读取。

9.根据权利要求1所述的云游戏加载方法，其特征在于，所述第一指令集通过以下步骤获得：

获取将所述云游戏从所述第一画面加载至第二画面的多个第四指令，以及各所述第四指令被执行时所述云游戏的第四画面；

根据各所述第四指令，以及各所述第四指令对应的第四画面生成第一指令集。

10.根据权利要求1所述的云游戏加载方法，其特征在于，所述第一存档通过以下方式得到：

获取保存指令；

根据保存指令，获取所述云游戏的会话数据和缓存数据；

从所述会话数据中提取第一参数组，从所述缓存数据中提取第二参数组，并将所述第一参数组和第二参数组保存为第一存档；

从所述会话数据、缓存数据或者第一存档中提取第三参数组，根据所述第三参数组得到所述第一存档的标签。

11.一种云游戏加载系统，其特征在于，所述云游戏在服务器中运行，所述服务器用于向终端传输所述云游戏的视频流，以及接收所述终端针对所述云游戏的第三指令，所述系统包括：

第一获取单元，用于获取加载指令；

第二获取单元，用于根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；

加载单元，用于加载所述第一存档，以使所述云游戏加载至第一画面；

执行单元，用于通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面。

12.一种云游戏加载装置，其特征在于，包括：

程序；

存储器，用于存储所述程序；

处理器，用于加载所述程序以执行如权利要求1～10任一项所述的云游戏加载方法。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有程序，所述程序被处理器执行时实现如权利要求1～10任一项所述的云游戏加载方法。

14.一种云游戏系统，其特征在于，包括：

第一服务器，用于获取分配请求，根据所述分配请求向终端分配一个第二服务器，并向所述第二服务器发送所述云游戏的加载指令；

第二服务器，用于获取加载指令；根据所述加载指令获取所述云游戏的第一存档和第一指令集，其中，所述第一指令集包括至少一个用于对所述云游戏进行操作的指令；加载所述第一存档，以使所述云游戏加载至第一画面；通过执行所述第一指令集对所述云游戏进行操作，使得所述云游戏从所述第一画面加载至第二画面；以及向所述终端传输所述云游戏的视频流，以及接收所述终端针对所述云游戏的第三指令。

Images