一种基于状态机的界面跳转和事件触发系统

摘要

本发明公开了一种基于状态机的界面跳转和事件触发系统，包括：状态图模块，用于创建基于全屏界面的状态图；其中每个全屏界面为状态图上的一个节点；事件触发机制，用于将每个全屏界面通过状态进行事件触发；其中每个状态为一个结构体；状态继承机制，用于将类似事件的全屏界面基于有向无环图进行状态继承；状态转移机制，用于获取新状态与新状态的前一个状态的跳转关系，且将新状态在结构体中进行处理，得到新状态对应的新全屏界面；状态切换机制，用于设置快捷切换方式，并根据设置的快捷切换方式实现全屏界面的切换；有限状态存储机制，用于判断全屏界面状态的跳转次数是否达到预设阈值，若是，则清除初始跳转的状态。

说明书

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于状态机的界面跳转和事件触发系统。

背景技术

UI界面在游戏中主要是以两种形式存在，一种是全屏抢占式，一种是弹出式窗口，全屏抢占式界面一般每个时刻只有一个界面存在，弹出式窗口是有可能叠加的。然而一个游戏在开发过程中，随着需求的增加，会使得游戏的功能越来越多，需求也会随之增多，全屏抢占式界面也会日益增多，比如说全屏大厅界面、全屏商城界面、全屏仓库界面、全屏房间界面等等，不同的事件在不同界面的处理可能不尽相同，不同界面也有各种跳转，开发到后期，每加入一个全屏界面都需要考虑和之前所有界面的跳转关系，使得开发成本大大提高。

为了解决上述存在的问题，本发明提供了一种结构清晰、易于维护和查错、重用性高的界面跳转和事件触发系统，并且大大提高了程序的开发效率。

发明内容

本发明的目的是针对现有技术的缺陷，提供了一种基于状态机的界面跳转和事件触发系统。

为了实现以上目的，本发明采用以下技术方案：

一种基于状态机的界面跳转和事件触发系统，包括：

状态图模块，用于创建基于全屏界面的状态图；其中每个全屏界面为状态图上的一个节点；

所述状态图模块中包括事件触发机制、状态转移机制、状态继承机制、状态切换机制、有限状态存储机制；

事件触发机制，用于将每个全屏界面通过状态进行事件触发；其中每个状态为一个结构体；

状态继承机制，用于将类似事件的全屏界面基于有向无环图进行状态继承；

状态转移机制，用于获取新状态与新状态的前一个状态的跳转关系，且将新状态在结构体中进行处理，得到新状态对应的新全屏界面；

状态切换机制，用于设置快捷切换方式，并根据设置的快捷切换方式实现全屏界面的切换；

有限状态存储机制，用于判断全屏界面状态的跳转次数是否达到预设阈值，若是，则清除初始跳转的状态。

进一步的，所述状态图模块中创建基于全屏界面的状态图的创建方式具体为：

若两个全屏界面进行单向跳转，则在状态图中将两个全屏界面对应的节点单向连接；

若两个全屏界面进行双向跳转，则在状态图中将两个全屏界面对应的节点双向连接。

进一步的，所述事件触发机制中结构体包括三个基本结构，其中三个基本接口包括状态进入的回调函数onEnte、状态离开的回调函数onLeave、状态的各种事件处理函数onEvent。

进一步的，所述状态继承机制中进行状态继承是将类似事件的全屏界面对应的状态继承处理相同逻辑的基类。

进一步的，所述状态转移机制中将新状态在结构体中进行处理是在状态的各种事件处理函数onEvent中进行处理的。

进一步的，所述状态转移机制中还包括在状态基类添加调试信息。

进一步的，所述状态切换机制中设置快捷切换方式为设置快捷切换键。

与现有技术相比，本发明具有以下有益效果：

1、结构清晰，能够一眼看出两个界面之间的跳转关系；

2、可以在后台记录玩家的跳转关系，方便记录玩家行为进行分析；

3、易于维护和查错，方便调试；

4、维护性高，增加一个界面，只需要考虑和前一个界面的跳转关系，不需要考虑之前全部的界面，条理简单；

5、状态继承减少了出错率，相同类型的只需要一份代码实现，减少代码量；

6、栈式状态切换和有限状态存储即增加了玩家的体验，又平衡了存储上的开销。

附图说明

图1是实施例一提供的种基于状态机的界面跳转和事件触发系统的状态图；

图2是实施例一提供的事件触发机制的示意图；

图3是实施例一提供的状态继承机制的示意图；

图4是实施例一提供的状态切换机制示意图。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

本发明的目的是针对现有技术的缺陷，提供了一种基于状态机的界面跳转和事件触发系统。

实施例一

本实施例提供一种基于状态机的界面跳转和事件触发系统，包括：

状态图模块，用于创建基于全屏界面的状态图；其中每个全屏界面为状态图上的一个节点；

状态图模块中包括事件触发机制、状态转移机制、状态继承机制、状态切换机制、有限状态存储机制；

事件触发机制，用于将每个全屏界面通过状态进行事件触发；其中每个状态为一个结构体；

状态继承机制，用于将类似事件的全屏界面基于有向无环图进行状态继承；

状态转移机制，用于获取新状态与新状态的前一个状态的跳转关系，且将新状态在结构体中进行处理，得到新状态对应的新全屏界面；

状态切换机制，用于设置快捷切换方式，并根据设置的快捷切换方式实现全屏界面的切换；

有限状态存储机制，用于判断全屏界面状态的跳转次数是否达到预设阈值，若是，则清除初始跳转的状态。

如图1所示为一种基于状态机的界面跳转和事件触发系统的状态图，即游戏中每个全屏界面跳转的状态图。

在本实施例中，状态图的构建方式为先由工程师确定好每个全屏界面与每个全屏界面之间的跳转关系，然后通过程序代码实现每个跳转的逻辑，形成全屏界面的状态图。

具体为：

若两个全屏界面进行单向跳转，则在状态图中将两个全屏界面对应的节点单向连接。

如图1中示出的商城界面和仓库界面，商城界面到仓库界面之间能够进行单向跳转，即商城界面可以到仓库界面，则在状态图中将商城界面对应的节点和仓库界面对应的节点连接一条有向边，方向为从商城界面可以到仓库界面。

若两个全屏界面进行双向跳转，则在状态图中将两个全屏界面对应的节点双向连接。

比如图1中示出的仓库界面和房间界面，仓库界面和房间界面之间能够进行双向跳转，即仓库界面可以到商城界面，房间界面也可以到仓库界面，则在状态图中将仓库界面对应的节点和方面界面对应的节点连接两条有向边，第一条的方向为从仓库界面到房间界面，第二条的方向为从房间界面可以到仓库界面。

根据上述方式进而得到系统的有向带环图的状态结构图。

在状态结构图中还包括各种机制，如事件触发机制、状态转移机制、状态继承机制、栈式状态切换机制、有限状态存储机制。

在事件触发机制中，将每个全屏界面通过状态进行事件触发；其中每个状态为一个结构体。

每个全屏界面都由一个状态来维护，在实际编码过程中每个状态定义一个结构体，结构体提供三个基本接口onEnter、onEvent、onLeave，其中onEnter是状态进入的回调函数，onLeave是状态离开的回调函数，onEvent负责对该状态下各种事件进行处理；

其中，结构体是由一批数据组合而成的一种新的数据类型。组成结构型数据的每个数据称为结构型数据的“成员”。

如图2所示为事件触发机制的示意图，图中其它界面到商城界面中的状态为进入状态，商城界面到其他界面的状态为离开状态；然而在商城界面中还需要处理进入该商城界面的状态下要处理的事件，比如购买装备等事件。

在状态继承机制中，将类似事件的全屏界面基于有向无环图进行状态继承。

状态继承机制即将具有类似事件处理的状态之间进行状态的继承，而状态继承图是一个DAG图(有向无环图，允许多继承所以不是树)。

如图3所示为状态继承机制的示意图，图中仓库界面和金库界面的来源状态(入边)和出口状态(出边)一模一样，所以可以继承自一个处理相同逻辑的基类库。

其中，基类为在面向对象设计中，被定义为包含所有实体共性的class类型。

在状态转移机制中，获取新状态与新状态的前一个状态的跳转关系，且将新状态在结构体中进行处理，得到新状态对应的新全屏界面。

在实际开发过程中，每加入一个新的界面就是添加一个新的状态的过程，只要理清楚之前状态和新状态的跳转关系并且在onEvent函数中进行处理；其中理清楚之前状态与新状态的跳转关系需要工程师向确定跳转关系，然后在通过代码程序实现。

onEvent主要是为了接收玩家的操作带来的各种事件的处理，比如玩家发起购买物品，那么如果在商城界面，则执行购买逻辑；反之，如果是在仓库界面，如果仓库界面不支持购买，则会跳过处理。

在本实施例中，增加新界面，首先考虑和之前老界面的异同，如果有80％以上的相似点，则可以提出基类进行状态继承，然后本身再实现特性状态；如果基本完全不同，则直接创建新状态，创建过程即实现一系列接口，包括：OnEnter、OnLeave、OnEvent。

在本实施例中，在状态转移机制中还可以在状态基类中添加各种调试信息，一旦出错就能很快定位到是在哪个状态中出的Bug，结构清晰，易于查错。

基类的目的主要是为了实现逻辑的复用，比如说两个状态下有90％的逻辑是一致的，只有10％的逻辑需要各自处理，那么就可以把90％的逻辑放在基类的状态中，这样需要修改逻辑的时候只要改一个地方，避免或减少修改引起出错的概率。

在状态切换机制中，设置快捷切换方式，并根据设置的快捷切换方式实现全屏界面的切换。

本实施例提供一种快捷输入，可以直接跳回到上一个状态，这样对于游戏实际体验上更加符合人的直观体验。

如图4所示为状态切换机制示意图，如果用户通过(1)(2)(3)(4)的方式进行界面切换，那么通过给用户提供一个快捷键(例如ESC)，就能将界面以(4)(3)(2)(1)的方式返回回来。

在有限状态存储机制中，判断全屏界面状态的跳转次数是否达到预设阈值，若是，则清除初始跳转的状态。

整个状态跳转提供有限状态存储，即如果已经存储了20次状态，那么进行存储状态的循环以为，不会返回到20次状态之前的状态，节省存储空间。

与现有技术相比，本实施例具有以下有益效果：

1、结构清晰，能够一眼看出两个界面之间的跳转关系；

2、可以在后台记录玩家的跳转关系，方便记录玩家行为进行分析；

3、易于维护和查错，方便调试；

4、维护性高，增加一个界面，只需要考虑和前一个界面的跳转关系，不需要考虑之前全部的界面，条理简单；

5、状态继承减少了出错率，相同类型的只需要一份代码实现，减少代码量；

6、栈式状态切换和有限状态存储即增加了玩家的体验，又平衡了存储上的开销。

本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。