CN111054077B - 管理游戏玩法的方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请公开了管理游戏玩法的方法、装置、电子设备及存储介质，属于多媒体技术领域。方法包括：获取游戏玩法的配置数据。基于配置数据生成流程框架，流程框架包括用于描述游戏玩法的一个或多个阶段，每个阶段包括一个或多个条件节点与动作节点的对应关系。根据流程框架对游戏玩法进行管理。本申请通过阶段、条件节点以及动作节点所构成的流程框架描述游戏玩法，使得对游戏玩法的管理过程更为简单快捷。并且，条件节点以及动作节点对应的程序可多次复用，当前游戏玩法的流程框架也可以持续沉淀，以用于其他游戏玩法的开发，从而降低了玩法开发中出错的概率和人力消耗。

Description

管理游戏玩法的方法、装置、电子设备及存储介质

技术领域

本申请涉及多媒体技术领域，特别涉及一种管理游戏玩法的方法、装置、电子设备及存储介质。

背景技术

随着多媒体技术的发展，越来越多的应用程序被应用到人们的生活中，游戏类应用程序便是其中一种。对于游戏类应用程序中提供的游戏玩法，在开发阶段往往需要经过多次管理才能提供给用户。因此，需要提供一种针对游戏玩法的管理方法。

在相关技术中，首先获取游戏玩法的配置数据，再根据配置数据编辑一套程序，从而得到游戏玩法的脚本文件，运行该脚本文件即可提供游戏玩法。若策划人员对配置数据进行修改，则需要根据修改后的配置数据重新编辑一套程序，得到更新的脚本文件，从而完成对游戏玩法的管理。

可以看出，相关技术在每次对游戏玩法进行管理的过程中，都需要重新编辑一套程序。该管理过程较为繁琐、效率不高。

发明内容

本申请实施例提供了一种管理游戏玩法的方法、装置、设备及存储介质，以解决相关技术管理过程较为繁琐、管理效率不高的问题。所述技术方案如下：

一方面，提供了一种管理游戏玩法的方法，所述方法包括：

获取游戏玩法的配置数据；

基于所述配置数据生成流程框架，所述流程框架包括用于描述所述游戏玩法的一个或多个阶段，每个阶段包括一个或多个条件节点与动作节点的对应关系；

根据所述流程框架对所述游戏玩法进行管理。

在示例性实施例中，所述基于所述配置数据生成流程框架，包括：

将所述配置数据导出为字节文件；

调用方法接口，通过所述方法接口基于所述字节文件生成所述流程框架。

在示例性实施例中，所述根据所述流程框架对所述游戏玩法进行管理，包括：

获取修改后的配置数据；

根据所述修改后的配置数据确定需要更新的目标阶段；

根据所述修改后的配置数据更新所述目标阶段所包括的条件节点与动作节点的对应关系，得到更新后的流程框架，所述更新后的流程框架用于描述管理后的游戏玩法。

在示例性实施例中，所述根据所述修改后的配置数据更新所述目标阶段所包括的条件节点与动作节点的对应关系，包括：

在所述目标阶段所包括的条件节点与动作节点的对应关系中，修改条件节点及动作节点中的一个或两个；

或者，向所述目标阶段中补充新条件节点及新动作节点中的一个或两个。

在示例性实施例中，所述根据所述流程框架对所述游戏玩法进行管理，包括：

监听基于所述流程框架的游戏事件；

若所述游戏事件满足所述条件节点，根据所述条件节点与动作节点的对应关系执行所述条件节点对应的动作节点。

在示例性实施例中，所述监听基于所述流程框架的游戏事件，包括：

从所述流程框架所包括的阶段中确定当前生效的目标阶段；

针对所述目标阶段所包括的任一个条件节点与动作节点的对应关系中的条件节点，确定与所述条件节点相关的游戏事件；

监听所述与所述条件节点相关的游戏事件。

一方面，提供了一种管理游戏玩法的装置，所述装置包括：

获取模块，用于获取游戏玩法的配置数据；

生成模块，用于基于所述配置数据生成流程框架，所述流程框架包括用于描述所述游戏玩法的一个或多个阶段，每个阶段包括一个或多个条件节点与动作节点的对应关系；

管理模块，用于根据所述流程框架对所述游戏玩法进行管理。

在示例性实施例中，所述生成模块，用于将所述配置数据导出为字节文件；调用方法接口，通过所述方法接口基于所述字节文件生成所述流程框架。

在示例性实施例中，所述管理模块，用于获取修改后的配置数据；根据所述修改后的配置数据确定需要更新的目标阶段；根据所述修改后的配置数据更新所述目标阶段所包括的条件节点与动作节点的对应关系，得到更新后的流程框架，所述更新后的流程框架用于描述管理后的游戏玩法。

在示例性实施例中，所述管理模块，用于在所述目标阶段所包括的条件节点与动作节点的对应关系中，修改条件节点及动作节点中的一个或两个；或者，向所述目标阶段中补充新条件节点及新动作节点中的一个或两个。

在示例性实施例中，所述管理模块，用于监听基于所述流程框架的游戏事件；若所述游戏事件满足所述条件节点，根据所述条件节点与动作节点的对应关系执行所述条件节点对应的动作节点。

在示例性实施例中，所述管理模块，用于从所述流程框架所包括的阶段中确定当前生效的目标阶段；针对所述目标阶段所包括的任一个条件节点与动作节点的对应关系中的条件节点，确定与所述条件节点相关的游戏事件；监听所述与所述条件节点相关的游戏事件。

一方面，提供了一种电子设备，所述设备包括存储器及处理器；所述存储器中存储有至少一条指令，所述至少一条指令由所述处理器加载并执行，以实现本申请的任一种可能的实施方式所提供的管理游戏玩法的方法。

另一方面，提供了一种可读存储介质，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现本申请的任一种可能的实施方式所提供的管理游戏玩法的方法。

本申请实施例所提供的技术方案带来的有益效果至少包括：

通过阶段、条件节点以及动作节点所构成的流程框架描述游戏玩法，使得对游戏玩法的管理过程更为简单快捷。并且，条件节点以及动作节点对应的程序可多次复用，当前游戏玩法的流程框架也可以持续沉淀，以用于其他游戏玩法的开发，从而降低了玩法开发中出错的概率和人力消耗。

附图说明

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

图1是本申请实施例提供的实施环境示意图；

图2是本申请实施例提供的管理游戏玩法的方法的流程图；

图3是本申请实施例提供的结构示意图；

图4是本申请实施例提供的方法流程图；

图5是本申请实施例提供的静态类图；

图6是本申请实施例提供的静态类图；

图7是本申请实施例提供的静态类图；

图8是本申请实施例提供的静态类图；

图9是本申请实施例提供的管理玩法的装置的结构示意图；

图10是本申请实施例提供的终端结构图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请实施例提供了一种管理玩法的方法，该方法可应用于如图1所示的实施环境中。图1中，包括至少一个终端11和服务器12，终端11可与服务器12进行通信连接，以从服务器12上通过接口调用一个或多个方法类，方法类用于基于获取到的配置数据生成流程框架。

其中，终端11可以是任何一种可与用户通过键盘、触摸板、触摸屏、遥控器、语音交互或手写设备等一种或多种方式进行人机交互的电子产品，例如PC(Personal Computer，个人计算机)、手机、智能手机、PDA(Personal Digital Assistant，个人数字助手)、可穿戴设备、掌上电脑PPC(Pocket PC)、平板电脑、智能车机、智能电视、智能音箱等。

服务器12可以是一台服务器，也可以是由多台服务器组成的服务器集群，或者是一个云计算服务中心。

本领域技术人员应能理解上述终端11和服务器12仅为举例，其他现有的或今后可能出现的终端或服务器如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

基于上述图1所示的实施环境，参见图2，本申请实施例提供了一种管理游戏玩法的方法，该方法可应用于图1所示的终端中。如图2所示，该方法包括：

步骤201，获取游戏玩法的配置数据。

其中，游戏玩法是游戏类APP(Application，应用程序)中所提供的副本、任务等玩法。在开发阶段，游戏玩法是策划需要设计的内容，策划通过编辑配置数据来设计游戏玩法。在运行阶段，APP用户往往通过控制虚拟对象来体验该游戏玩法。例如，用户所控制的虚拟对象进入游戏APP所提供的一个区域，在区域中击败参考数量个其他虚拟对象后会得到虚拟资源，便可作为一个游戏玩法。

在本实施例中，将游戏玩法表示成一个或多个阶段(stage)，每个阶段相当于游戏玩法对应的整个游戏流程中的其中一部分。在每个阶段中，还包括一个或多个条件节点(condition)以及一个或多个动作节点(action)，条件节点与动作节点之间具有对应关系，且该对应关系可以是一对多、多对一或者多对多种的任意一种。在实施中，条件节点是可根据游戏流程的运行时间或者用户的游戏行为所触发的条件，例如上例中“在区域中击败参考数量个其他虚拟对象”便为一个条件节点。而条件节点所对应的动作节点，则是在条件节点被触发之后所执行的动作。例如在上例中“向用户所控制的虚拟对应发送虚拟资源”便为一个动作节点。

基于上述构思，游戏玩法的配置数据需要包括阶段、每个阶段中的条件节点、动作节点以及条件节点与动作节点的对应关系。因此，游戏玩法的配置数据可参见如下的表1：

表1

阶段ID	条件ID	动作ID	动作ID	动作ID
					1	首个玩家进入副本	创建区域	切换阶段
2	进入区域	回收区域	创建怪物	切换阶段
					3	怪物被击败	发送资源	提示成功

其中，表1中每一行均为一个阶段，每一行中所包括的条件节点及动作节点之间具有对应关系。阶段ID(Identification，标识)用于区分不同的阶段，条件ID用于指示一个条件节点，且条件ID索引至一个条件节点对应的程序，在游戏玩法的运行过程中，对于任一个条件节点均是通过该条件节点所对应的程序来确定该条件节点是否被触发的。动作ID用于索引至一个动作节点对应的程序，在游戏玩法的运行过程中，对于任一个动作节点均是通过该动作节点对应的程序来实现动作的执行的。

需要说明的是，在实施中，终端可提供Excel(电子表格软件)，将通过Excel检测到的数据作为配置数据，从而完成配置数据的获取。对于配置数据中任一个条件ID或者动作ID所索引的程序，均由开发人员根据条件节点或动作节点的实际内容进行编辑，从而通过程序来实现条件节点或动作节点。在编辑得到程序之后，将程序与条件ID进行关联即可。可以看出，本实施例中策划可专注于游戏玩法的设计，而开发人员可专注于程序实现。并且，每个条件节点或者每个动作节点均对应有独立的一段程序。

另外，条件节点及动作节点还需要对应有参数ID，参数ID用于索引至条件节点或动作节点所需要的相关数据，以便于开发人员通过程序实现该条件节点。例如，“进入区域”的条件节点对应的参数ID需要索引至一个区域ID，从而描述所进入的虚拟区域是游戏APP所提供的哪一个区域。再例如，“提示成功”的动作节点对应的参数ID需要索引至提示内容和显示方式。在后续执行“提示成功”这一动作节点时，是按照索引的显示方式来显示索引的提示内容，从而完成动作节点的执行。再例如，“切换阶段”的动作节点对应的参数ID需要索引至待切换的阶段ID，从而描述需要从当前所在阶段切换至其他阶段中的哪一个阶段。其中，待切换的阶段可以是当前所在阶段的前一个或后一个阶段，也可以是不与当前所在阶段相邻的其他阶段。

步骤202，基于配置数据生成流程框架。

在获取到配置数据之后，便可基于所获取的配置数据生成流程框架。由于配置数据包括阶段，阶段中包括条件节点以及动作节点，且条件节点与动作节点之间具有对应关系，因而基于配置数据所生成的流程框架可参见图3，流程框架包括用于描述游戏玩法的一个或多个阶段，每个阶段包括一个或多个条件节点与动作节点的对应关系。

由图3可以看出，多个阶段形成一个流(roundflow)。在图3所示的多个阶段中，阶段ID为1-n的阶段是上述说明中包括条件节点与动作节点的阶段，在游戏玩法的运行过程中可在这些阶段中不断进行切换。而阶段ID为0的阶段是在整个游戏玩法的运行过程中均生效的一个阶段(headstage)，该阶段中仅包括全局生效的动作，且该阶段不受到用户的游戏行为的影响。例如，该阶段所包括的动作可以为整个游戏玩法中的天气变化、背景变化等等。在实施中，当游戏玩法被启动后，首先加载headstage以执行全局生效的动作。之后，再从阶段ID为1的阶段开始加载，通过切换阶段来执行阶段ID为1-n中的任意阶段。

另外，每个阶段中还包括一个或多个并行的触发器(trigger)，每个触发器均由一个条件节点与动作节点的对应关系组成，触发器的作用即在于，当检测到条件节点被触发时，根据条件节点与动作节点的对应关系，执行条件节点对应的动作。在实施中，触发器同样由开发人员通过开发程序来实现。

在示例性实施例中，基于配置数据生成流程框架，包括：将配置数据导出为字节文件；调用方法接口，通过方法接口基于字节文件生成流程框架。

由于策划往往在excel表格中设计配置数据，因此需要将配置数据从excel表格中导出为终端可理解的形式。参见图4中的步骤401-403，可首先将excel表格导出为字节(bytes)文件，再将字节文件转换成rounddesc(排序)数组，最后通过资源校验转换成roundinfo(信息)，终端通过读取roundinfo便可获取到图5中的各项参数。接着，继续调用ServiceRoundFlow方法接口，通过方法接口所提供的类便可将基于字节文件生成如图3所示的流程框架。

进一步地，在图5中，CRoundFlow表示生成的流程框架，m_iMainlandId表示副本资源ID，m_iMainlandInstId表示副本实例ID，m_iCurStageIndex表示当前阶段索引，RoundStageParam表示阶段参数，一个流程框架中具有多个阶段。RoundFlowListener表示流程监听器，用于确定阶段所包括的任一条件节点是否被触发，在后文会加以详细说明。SPlayerDataList表示玩家数据列表，该列表中往往包括副本中多个玩家的相关数据。SMainlandMonsterGroupMgr表示怪物组数据。上述SPlayerDataList、SMainlandMonsterGroupMgr均为副本相关数据的举例，在实施中副本相关数据还可能包括其他多种数据，例如副本中的区域数据等等，此处不一一进行列举。

另外，一个RoundStageParam对应多个RoundTriggerParam触发器参数，代表一个阶段中包括有多个触发器。每个触发器参数对应m_ConditionIDList条件节点ID列表、m_ActionIDList动作节点列表以及条件节点与动作节点的交互信息RoundContext。该交互信息用于通过iPlayerID玩家ID以及iGroupID队伍ID来指示条件节点是由副本所包括的多个玩家或队伍中的哪个玩家或队伍触发的，以便于针对触发条件节点的玩家或队伍执行条件节点对应的动作节点。

步骤203，根据流程框架对游戏玩法进行管理。

在得到流程框架之后，策划可试运行该流程框架，以体验游戏玩法，并根据实际体验对游戏玩法的配置数据进行调整，从而得到修改后的配置数据。相应地，在示例性实施例中，根据流程框架对游戏玩法进行管理，包括：获取修改后的配置数据；根据修改后的配置数据确定需要更新的目标阶段；根据修改后的配置数据更新目标阶段所包括的条件节点与动作节点的对应关系，得到更新后的流程框架，更新后的流程框架用于描述管理后的游戏玩法。

其中，相比于步骤201中的配置数据，修改后的配置数据可能对条件节点与动作节点中的一种或两种进行了修改。由于流程框架具有多个阶段，因而首先需要确定修改后的配置数据所修改的条件节点及动作节点位于多个阶段中的哪个阶段，从而将所位于的阶段作确定为需要更新的目标阶段。之后，可根据修改后的配置数据对目标阶段中的条件节点与动作节点的对应关系进行更新，从而得到更新后的流程框架，该更新后的流程框架即可用于描述管理后的游戏玩法。

在示例性实施例中，根据被修改的配置数据更新目标阶段所包括的条件节点与动作节点的对应关系，包括：在目标阶段所包括的条件节点与动作节点的对应关系中修改条件节点及动作节点中的一个或两个。例如，修改前的对应关系中，条件节点为击败一个其他虚拟对象，动作节点为提示，则修改过程中可将条件节点修改为进入区域等等。对于用户而言，初始的游戏玩法是在玩家击败一个其他虚拟对象时收到提示，管理后的游戏玩法则是在进入区域时收到提示。

或者，更新对应关系的方式还可包括：向目标阶段中补充新条件节点及新动作节点中的一个或两个。例如，修改前的对应关系中，条件节点为击败一个其他虚拟对象，动作节点为提示，则修改过程中在提示这一动作节点的基础上，增加发送虚拟资源的动作节点。则对于用户而言，初始的游戏玩法是玩家击败一个其他虚拟对象时收到提示，管理后的游戏玩法则是收到提示以及虚拟资源。

需要说明的是，在相关技术中，由于未将游戏玩法通过阶段、条件节点、动作节点以及条件节点与动作节点的对应关系进行抽象表示，因而相关技术需要针对配置数据编辑一套程序。一旦策划对配置数据进行了修改，则需要重新编辑另一套程序，该过程复杂、繁琐，使得管理一个游戏玩法较为困难。

而在本实施例中，在修改配置数据的情况下，只需要更新流程框架中条件节点与动作节点之间的对应关系，相当于策划通过对条件节点及动作节点的重新规划组合便可得到更新的游戏玩法，使得管理、打磨游戏玩法的过程简单方便。即使需要补充新的条件及动作节点，开发人员也无需对已有的程序进行调整，而是在已有程序的基础上，针对所补充的条件节点及动作节点编辑新的程序即可，不仅降低了程序运行错误的可能性，还提高了已有程序的可沉淀性。

另外，正是由于各个节点对应的程序各自独立，因而每个节点对应的程序除了当前的游戏玩法以外，还可复用在其他游戏玩法中，例如策划对每个节点进行重新排列组合，即可开发出新的游戏玩法。

在示例性实施例中，可按照如下的方式运行流程框架，从而实现对游戏玩法进行管理，包括：监听基于流程框架的游戏事件(event)；若游戏事件满足条件节点，根据条件节点与动作节点的对应关系执行条件节点对应的动作节点。

其中，游戏事件是用户的游戏行为所造成的游戏状态，例如用户所控制的虚拟对象被击败、用户所控制的虚拟对象击败其他虚拟对象等等。在示例性实施例中，监听基于流程框架的游戏事件，包括：从流程框架所包括的阶段中确定当前生效的目标阶段；针对目标阶段所包括的任一个条件节点与动作节点的对应关系中的条件节点，确定与条件节点相关的游戏事件；监听与条件节点相关的游戏事件。

当前生效的目标阶段中可能包括多个条件节点与动作节点的对应关系，因而首先需要根据对应关系确定出每个条件节点，再进一步针对每个条件节点确定与该条件节点相关的游戏事件，从而将与条件节点相关的游戏事件作为上述基于流程框架的游戏事件，对于条件节点相关的游戏事件进行监听。以条件节点为击败三个其他虚拟对象为例，则与条件节点相关的游戏事件可以为一个其他虚拟对象被击败。则当用户控制的虚拟对象击败一个其他虚拟对象时，便可监听到一次游戏事件。

监听的作用在于及时确定游戏事件是否发生，从而在确定游戏事件的发生次数、发生时间等等满足条件节点的情况下，执行与条件节点对应的动作节点。仍以条件节点为击败三个其他虚拟对象、游戏事件为一个其他虚拟对象被击败为例，则可在监听过程中游戏事件已发生三次时，确定游戏事件满足条件节点，从而执行条件节点对应的动作节点。

在实施中，一个条件节点相关的游戏事件的数量可能有一个或多个，因此可针对每个游戏事件设置不同的事件ID，从而区分不同事件。参见图6，由于在流程框架中进行的监听是对游戏事件的监听，因而上述RoundFlowListener流程监听器依赖于StageEventListener事件监听器，该事件监听器通过程序实现，用于通过事件ID的索引来监听一个或多个游戏事件。在实施中，DelStageListener代表上述从流程框架中确定目标阶段的过程，其中所确定的目标阶段包括当前生效的阶段StageEventListener cur以及全局生效的阶段StageEventListener head。之后，AddListenCondition代表从目标阶段中确定条件节点的过程，以便于基于条件节点确定与条件节点相关的游戏事件。

进一步地，参见图7，上述说明中条件节点对应的程序用于基于事件监听器的监听结果确定条件节点是否被触发。在图7中，IRoundConditionNode表示条件节点，Init代表初始化，HandleEvent代表对与条件节点相关的事件进行注册，以便于事件监听器对于条件节点相关的事件进行监听。Recover代表条件节点被触发一次后的重置操作，IsReach代表确定条件节点是否被触发的操作，GetContext代表获取条件节点与动作节点之间的交互信息的操作。另外，RoundFlowCondUnion表示条件节点的相关数据，即条件节点对应的参数ID所索引的数据，RoundDynamicUnion表示条件节点的动态数据，每监听到一次与条件节点相关的游戏事件，该动态数据都会增加一个数值，直到游戏事件满足条件节点便可确定条件节点被触发，即条件达到。

图7所示的流程也可参见图4中的步骤406-411。步骤406中进行初始化，步骤407中根据条件节点注册事件，步骤408中事件监听器对所注册的事件进行监听。在步骤409中监听到注册事件之后，便可在步骤410中找到注册事件所对应的条件节点。在步骤411中，当所监听到的游戏事件满足条件节点时，确认条件达到。

另外，对于不同的条件节点，需要通过CRoundFlowConditionImp接口调用不同的数据处理类来确定该条件节点是否被触发。例如玩家进入区域(PlayerEnterAreaCondition)的条件节点对应的数据处理类为OnPlayerEnterArea，怪物被击败(MonsterDieCondition)的条件节点对应的数据处理类为OnMonsterDie。

相应地，参见图8，上述说明中动作节点对应的程序用于执行动作。在图8中，IRoundActionNode表示动作节点，Init代表初始化，DoAction代表对动作的执行操作，GetContext代表获取条件节点与动作节点之间的交互信息的操作。RoundFlowActionUnion表示动作节点的相关数据，即动作节点对应的参数ID所索引的数据，RoundDynamicUnion表示动作节点的动态数据，每执行一次动作，该动态数据都会增加一个数值。参见图4中的步骤413，在条件节点被触发的情况下，便可按照图8所示的流程来执行条件节点对应的动作。若动作节点为切换阶段，则进一步执行图4中的步骤414。若动作节点为切换阶段以外的普通动作，则直接对普通动作进行执行即可。

对于不同的动作节点，需要通过CRoundFlowActionImp接口来调用不同的数据处理类来实现动作的执行。例如接收任务(AcceptTaskAction)动作节点对应的数据处理类为AcceptTask，生成区域(CreateAreaAction)动作节点对应的数据处理类为CreateArea。

根据上述说明可知，条件节点对应的动作节点中可能包括切换阶段的动作。当阶段发生改变时，则需要重新确定当前生效的阶段、重新确定与当前生效的阶段相关的游戏事件，从而将所确定的游戏事件重新注册，以便于事件监听器能够基于当前生效的阶段监听相应的游戏事件。在实施中，在每次阶段发生改变时，均重新进行一次注册，直到游戏玩法结束。

综上所述，本实施例所提供的方法通过阶段、条件节点以及动作节点所构成的流程框架描述游戏玩法，使得对游戏玩法的管理过程更为简单快捷。并且，条件节点以及动作节点对应的程序可多次复用，当前游戏玩法的流程框架也可以持续沉淀，以用于其他游戏玩法的开发，从而降低了玩法开发中出错的概率和人力消耗。

基于相同构思，本申请实施例提供了一种管理游戏玩法的装置，参见图9，该装置包括：

获取模块901，用于获取游戏玩法的配置数据；

生成模块902，用于基于配置数据生成流程框架，流程框架包括用于描述游戏玩法的一个或多个阶段，每个阶段包括一个或多个条件节点与动作节点的对应关系；

管理模块903，用于根据流程框架对游戏玩法进行管理。

在示例性实施例中，生成模块902，用于将配置数据导出为字节文件；调用方法接口，通过方法接口基于字节文件生成流程框架。

在示例性实施例中，管理模块903，用于获取修改后的配置数据；根据修改后的配置数据确定需要更新的目标阶段；根据修改后的配置数据更新目标阶段所包括的条件节点与动作节点的对应关系，得到更新后的流程框架，更新后的流程框架用于描述管理后的游戏玩法。

在示例性实施例中，管理模块903，用于在目标阶段所包括的条件节点与动作节点的对应关系中，修改条件节点及动作节点中的一个或两个；或者，向目标阶段中补充新条件节点及新动作节点中的一个或两个。

在示例性实施例中，管理模块903，用于监听基于流程框架的游戏事件；若游戏事件满足条件节点，根据条件节点与动作节点的对应关系执行条件节点对应的动作节点。

在示例性实施例中，管理模块903，用于从流程框架所包括的阶段中确定当前生效的目标阶段；针对目标阶段所包括的任一个条件节点与动作节点的对应关系中的条件节点，确定与条件节点相关的游戏事件；监听与条件节点相关的游戏事件。

综上所述，本实施例所提供的方法通过阶段、条件节点以及动作节点所构成的流程框架描述游戏玩法，使得对游戏玩法的管理过程更为简单快捷。并且，条件节点以及动作节点对应的程序可多次复用，当前游戏玩法的流程框架也可以持续沉淀，以用于其他游戏玩法的开发，从而降低了玩法开发中出错的概率和人力消耗。

需要说明的是，上述实施例提供的装置在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

参见图10，其示出了本申请实施例提供的一种终端1000的结构示意图。该终端1000可以是便携式移动终端，比如：智能手机、平板电脑、笔记本电脑或台式电脑。终端1000还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端1000包括有：处理器1001和存储器1002。

处理器1001可以包括一个或多个处理核心，比如4核心处理器、10核心处理器等。处理器1001可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)所组成的群组中的至少一种硬件形式来实现。处理器1001也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(CentralProcessing Unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1001可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏1005所需要显示的内容的渲染和绘制。一些实施例中，处理器1001还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器1002可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1002还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1002中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器1001所执行以实现本申请中方法实施例提供的管理游戏玩法的方法。

在一些实施例中，终端1000还可选包括有：外围设备接口1003和至少一个外围设备。处理器1001、存储器1002和外围设备接口1003之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口1003相连。具体地，外围设备包括：射频电路1004、显示屏1005、摄像头1006、音频电路1007、定位组件1008和电源1009所组成的群组中的至少一种。

外围设备接口1003可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器1001和存储器1002。在一些实施例中，处理器1001、存储器1002和外围设备接口1003被集成在同一芯片或电路板上；在一些其他实施例中，处理器1001、存储器1002和外围设备接口1003中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路1004用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路1004通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1004将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1004包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路1004可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路1004还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏1005用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏1005是触摸显示屏时，显示屏1005还具有采集在显示屏1005的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器1001进行处理。此时，显示屏1005还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1005可以为一个，设置终端1000的前面板；在另一些实施例中，显示屏1005可以为至少两个，分别设置在终端1000的不同表面或呈折叠设计；在再一些实施例中，显示屏1005可以是柔性显示屏，设置在终端1000的弯曲表面上或折叠面上。甚至，显示屏1005还可以设置成非矩形的不规则图形，也即异形屏。显示屏1005可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。

摄像头组件1006用于采集图像或视频。可选地，摄像头组件1006包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1006还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路1007可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1001进行处理，或者输入至射频电路1004以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端1000的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1001或射频电路1004的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1007还可以包括耳机插孔。

定位组件1008用于定位终端1000的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。定位组件1008可以是基于美国的GPS(GlobalPositioning System，全球定位系统)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源1009用于为终端1000中的各个组件进行供电。电源1009可以是交流电、直流电、一次性电池或可充电电池。当电源1009包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端1000还包括有一个或多个传感器1010。该一个或多个传感器1010包括但不限于：加速度传感器1011、陀螺仪传感器1012、压力传感器1013、指纹传感器1014、光学传感器1015以及接近传感器1016。

加速度传感器1010可以检测以终端1000建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1011可以用于检测重力加速度在三个坐标轴上的分量。处理器1001可以根据加速度传感器1011采集的重力加速度信号，控制显示屏1005以横向视图或纵向视图进行用户界面的显示。加速度传感器1011还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器1012可以检测终端1000的机体方向及转动角度，陀螺仪传感器1012可以与加速度传感器1011协同采集用户对终端1000的3D动作节点。处理器1001根据陀螺仪传感器1012采集的数据，可以实现如下功能：动作节点感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器1013可以设置在终端1000的侧边框和/或显示屏1005的下层。当压力传感器1013设置在终端1000的侧边框时，可以检测用户对终端1000的握持信号，由处理器1001根据压力传感器1013采集的握持信号进行左右手识别或快捷操作。当压力传感器1013设置在显示屏1005的下层时，由处理器1001根据用户对显示屏1005的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件所组成的群组中的至少一种。

指纹传感器1014用于采集用户的指纹，由处理器1001根据指纹传感器1014采集到的指纹识别用户的身份，或者，由指纹传感器1014根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1001授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器1014可以被设置终端1000的正面、背面或侧面。当终端1000上设置有物理按键或厂商Logo时，指纹传感器1014可以与物理按键或厂商Logo集成在一起。

光学传感器1015用于采集环境光强度。在一个实施例中，处理器1001可以根据光学传感器1015采集的环境光强度，控制显示屏1005的显示亮度。具体地，当环境光强度较高时，调高显示屏1005的显示亮度；当环境光强度较低时，调低触示屏10010的显示亮度。在另一个实施例中，处理器1001还可以根据光学传感器1015采集的环境光强度，动态调整摄像头组件1006的拍摄参数。

接近传感器1016，也称距离传感器，通常设置在终端1000的前面板。接近传感器1016用于采集用户与终端1000的正面之间的距离。在一个实施例中，当接近传感器1016检测到用户与终端1000的正面之间的距离逐渐变小时，由处理器1001控制显示屏1005从亮屏状态切换为息屏状态；当接近传感器1016检测到用户与终端1000的正面之间的距离逐渐变大时，由处理器1001控制显示屏1005从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图10中示出的结构并不构成对终端1000的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

基于相同构思，本申请实施例提供了一种电子设备，设备包括存储器及处理器；存储器中存储有至少一条指令，至少一条指令由处理器加载并执行，以实现本申请的任一种可能的实施方式所提供的管理游戏玩法的方法。

基于相同构思，本申请实施例提供了一种可读存储介质，存储介质中存储有至少一条指令，指令由处理器加载并执行以实现本申请的任一种可能的实施方式所提供的管理游戏玩法的方法。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种管理游戏玩法的方法，其特征在于，所述方法包括：

获取游戏玩法的配置数据；

将所述配置数据导出为字节文件，将所述字节文件转换成排序数组，通过资源校验将所述排序数组转换成信息；调用方法接口，通过所述方法接口读取所述信息生成流程框架，所述流程框架包括用于描述所述游戏玩法的多个阶段，所述多个阶段具有顺序关系，所述多个阶段形成所述游戏玩法对应的整个流程，每个阶段为所述游戏玩法对应的整个流程的一部分，所述每个阶段包括一个或多个条件节点与动作节点的对应关系；

根据所述流程框架对所述游戏玩法进行管理。

2.根据权利要求1所述的方法，其特征在于，所述根据所述流程框架对所述游戏玩法进行管理，包括：

获取修改后的配置数据；

根据所述修改后的配置数据确定需要更新的目标阶段；

根据所述修改后的配置数据更新所述目标阶段所包括的条件节点与动作节点的对应关系，得到更新后的流程框架，所述更新后的流程框架用于描述管理后的游戏玩法。

3.根据权利要求2所述的方法，其特征在于，所述根据所述修改后的配置数据更新所述目标阶段所包括的条件节点与动作节点的对应关系，包括：

在所述目标阶段所包括的条件节点与动作节点的对应关系中，修改条件节点及动作节点中的一个或两个；

或者，向所述目标阶段中补充新条件节点及新动作节点中的一个或两个。

4.根据权利要求1所述的方法，其特征在于，所述根据所述流程框架对所述游戏玩法进行管理，包括：

监听基于所述流程框架的游戏事件；

若所述游戏事件满足所述条件节点，根据所述条件节点与动作节点的对应关系执行所述条件节点对应的动作节点。

5.根据权利要求4所述的方法，其特征在于，所述监听基于所述流程框架的游戏事件，包括：

从所述流程框架所包括的阶段中确定当前生效的目标阶段；

针对所述目标阶段所包括的任一个条件节点与动作节点的对应关系中的条件节点，确定与所述条件节点相关的游戏事件；

监听所述与所述条件节点相关的游戏事件。

6.一种管理游戏玩法的装置，其特征在于，所述装置包括：

获取模块，用于获取游戏玩法的配置数据；

生成模块，用于将所述配置数据导出为字节文件，将所述字节文件转换成排序数组，通过资源校验将所述排序数组转换成信息；调用方法接口，通过所述方法接口读取所述信息生成流程框架，所述流程框架包括用于描述所述游戏玩法的多个阶段，所述多个阶段具有顺序关系，所述多个阶段形成所述游戏玩法对应的整个流程，每个阶段为所述游戏玩法对应的整个流程的一部分，所述每个阶段包括一个或多个条件节点与动作节点的对应关系；

管理模块，用于根据所述流程框架对所述游戏玩法进行管理。

7.根据权利要求6所述的装置，其特征在于，所述管理模块，用于获取修改后的配置数据；根据所述修改后的配置数据确定需要更新的目标阶段；根据所述修改后的配置数据更新所述目标阶段所包括的条件节点与动作节点的对应关系，得到更新后的流程框架，所述更新后的流程框架用于描述管理后的游戏玩法。

8.根据权利要求7所述的装置，其特征在于，所述管理模块，用于在所述目标阶段所包括的条件节点与动作节点的对应关系中，修改条件节点及动作节点中的一个或两个；或者，向所述目标阶段中补充新条件节点及新动作节点中的一个或两个。

9.根据权利要求6所述的装置，其特征在于，所述管理模块，用于监听基于所述流程框架的游戏事件；若所述游戏事件满足所述条件节点，根据所述条件节点与动作节点的对应关系执行所述条件节点对应的动作节点。

10.根据权利要求9所述的装置，其特征在于，所述管理模块，用于从所述流程框架所包括的阶段中确定当前生效的目标阶段；针对所述目标阶段所包括的任一个条件节点与动作节点的对应关系中的条件节点，确定与所述条件节点相关的游戏事件；监听所述与所述条件节点相关的游戏事件。

11.一种电子设备，其特征在于，所述设备包括存储器及处理器；所述存储器中存储有至少一条指令，所述至少一条指令由所述处理器加载并执行，以实现权利要求1-5任一所述的管理游戏玩法的方法。

12.一种可读存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如权利要求1-5任一所述的管理游戏玩法的方法。

Images