应用逻辑的处理方法及装置与流程

本发明涉及计算机领域，具体而言，涉及一种应用逻辑的处理方法及装置。

背景技术：

目前，相关技术中通常所采用的游戏开发方式是在下层通过复杂的编程语言进行操作，而在上层则提供相对简单的脚本。例如：著名的虚幻引擎(Unreal engine)便是采用自身提供的脚本，unity引擎采用的是C#脚本或javascript脚本，暴雪公司(Blizzard Entertainment)出品的魔兽世界采用的是lua脚本，而cryengine3引擎以及网易公司推出的NeoX采用的则是Python脚本。脚本虽然能够在一定程度上降低游戏开发的门槛，甚至使得对游戏开发程序并不熟知的游戏策划人员都能够顺利地参与到游戏开发过程中。然而，对于一般非职业技术人员的普通人而言，对于游戏开发程序的学习过程仍存在较大难度，特别是调试脚本的过程通常会使得初学者苦不堪言。

伴随着沙盒游戏渐渐流行，游戏提供商逐步允许游戏玩家开发自定义副本，以便将游戏玩家自身的想法提供给更多的玩家去分享。此种操作方式在游戏开发领域通常被称为Mod开发。而游戏玩家在进行Mod开发时，通常可以通过编写游戏本身支持的游戏脚本来实现，为此，游戏玩家需要掌握基本的编程语言，才能编写游戏脚步对Mod进行修改。然而，进行Mod开发的大多数人员都是游戏玩家或者非玩家的业余人士，因此，特别是在中国，编程语言便成为Mod开发的准入门槛。

unity引擎曾出现过在人物动作系统中就采用图表拖拽功能来实现动作的跳转。而在角色人工智能(AI)开发中，也曾经出现过采用图表的形式描述行为树的插件。

然而，将图表技术运用于游戏任务开发则至今尚未存在过。目前的游戏任务开发通常是先实现通用接口对约定格式的csv文件进行识别，其次通过游戏策划人员填写特定格式csv表格或者其他脚本的格式以便游戏策划人员去配置各种游戏角色的属性，然后再由计算机程序加以读取并解释。另外，unread还提供了一种叫做蓝图(Blueprint)的解决方案，其也是通过一种图表形式展现程序开发流程，但更多是偏向于程序员使用的。

图1是根据相关技术的通过虚幻引擎的蓝图描述一段游戏逻辑的示意图。如图1所示，在确定触发器事件为进入矩形区域的事件之后，获取游戏角色所归属阵营，该阵营由游戏角色索引(例如：0)来确定。其次，通过计算机程序的比较操作，将返回是或者否的操作，其含义在于：进入矩形区域的游戏角色所属阵营是否为0；如果是，则返回真，如果否，则返回假。再次，再通过布尔值，其表示如果进入矩形区域的游戏角色所归属的阵营为0的推论成立。然后，通过强制转型，确定进入矩形区域的游戏角色所归属的阵营为0的推论成立，并且确定进入的游戏角色为一名玩家。最终，得到的结论为：对于进入矩形区域的游戏角色，如果该游戏角色所归属的阵营为0的推论成立，并且进入的游戏角色为一名玩家，则这名玩家将要执行跳起的动作，即当游戏玩家踩中陷阱时，该陷阱能够将游戏玩家弹起。由此可见，图中表示的内容过于面向程序员，复杂度较高，难以理解。

针对相关技术中在程序开发过程中使用脚本对应用逻辑进行描述的方式，复杂度较高、不易理解的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种应用逻辑的处理方法及装置，以至少解决相关技术中在程序开发过程中使用脚本对应用逻辑进行描述的方式，复杂度较高、不易理解的技术问题。

根据本发明实施例的一个方面，提供了一种应用逻辑的处理方法，包括：

根据预设应用逻辑对待使用的基础图表元素的属性进行配置并确定待使用的基础图表元素之间的执行顺序；按照配置的属性和执行顺序处理预设应用逻辑。

可选地，根据预设应用逻辑对待使用的基础图表元素的属性进行配置包括：根据预设应用逻辑确定待使用的基础图表元素的种类以及每类基础图表元素的处理对象；按照种类和处理对象在待使用的基础图表元素中的部分或全部基础图像元素对应的属性面板中获取待配置属性的属性值。

可选地，根据预设应用逻辑确定待使用的基础图表元素之间的执行顺序包括：根据预设应用逻辑获取待使用的基础图表元素相互间的连接关系，其中，连接关系包括：每个连接组件所连接的相邻基础图表元素以及每个连接组件的连接方向；按照连接关系确定待使用的基础图表元素之间的执行顺序。

可选地，在按照连接关系确定待使用的基础图表元素之间的执行顺序之前，还包括：对待使用的基础图表元素中的第一部分基础图表元素进行封装处理，创建一个或多个流程图组件，其中，一个或多个流程图组件包括以下至少之一：一个或多个闭包，用于配置可重复执行的中间过程逻辑；自定义触发器，用于配置可重复执行的触发判断逻辑；根据一个或多个流程图组件与第二部分基础图表元素之间的连接方式调整连接关系，其中，第二部分基础图表元素为待使用的基础图表元素中除第一部分基础图表元素之外的剩余基础图表元素。

可选地，按照配置的属性和连接关系处理预设应用逻辑包括：在待使用的基础图表元素中获取预设应用逻辑的执行入口；从执行入口出发，按照配置的属性和连接关系逐个执行至下一个待执行的相邻基础图表元素或流程图组件，直至待使用的基础图表元素全部执行完毕。

可选地，待使用的基础图表元素包括以下至少之一：事件触发性图表元素；操作性图表元素；结束性图表元素；连接性图表元素；选择性图表元素；事件计数性图表元素；计时性图表元素；随机约束性图表元素；变量。

根据本发明实施例的另一方面，还提供了一种应用逻辑的处理装置，包括：

第一处理模块，用于根据预设应用逻辑对待使用的基础图表元素的属性进行配置并确定待使用的基础图表元素之间的执行顺序；第二处理模块，用于按照配置的属性和执行顺序处理预设应用逻辑。

可选地，第一处理模块包括：第一确定单元，用于根据预设应用逻辑确定待使用的基础图表元素的种类以及每类基础图表元素的处理对象；第一获取单元，用于按照种类和处理对象在待使用的基础图表元素中的部分或全部基础图像元素对应的属性面板中获取待配置属性的属性值。

可选地，第一处理模块包括：第二获取单元，用于根据预设应用逻辑获取待使用的基础图表元素相互间的连接关系，其中，连接关系包括：每个连接组件所连接的相邻基础图表元素以及每个连接组件的连接方向；第二确定单元，用于按照连接关系确定待使用的基础图表元素之间的执行顺序。

可选地，上述装置还包括：第三处理模块，用于对待使用的基础图表元素中的第一部分基础图表元素进行封装处理，创建一个或多个流程图组件，其中，一个或多个流程图组件包括以下至少之一：一个或多个闭包，用于配置可重复执行的中间过程逻辑；自定义触发器，用于配置可重复执行的触发判断逻辑；调整模块，用于根据一个或多个流程图组件与第二部分基础图表元素之间的连接方式调整连接关系，其中，第二部分基础图表元素为待使用的基础图表元素中除第一部分基础图表元素之外的剩余基础图表元素。

可选地，第二处理模块包括：第三获取单元，用于在待使用的基础图表元素中获取预设应用逻辑的执行入口；执行单元，用于从执行入口出发，按照配置的属性和连接关系逐个执行至下一个待执行的相邻基础图表元素或流程图组件，直至待使用的基础图表元素全部执行完毕。

在本发明实施例中，采用根据预设应用逻辑对待使用的基础图表元素的属性进行配置并确定待使用的基础图表元素之间的执行顺序的方式，通过按照配置的属性和执行顺序处理预设应用逻辑，达到了简化应用逻辑描述方式的目的，从而实现了作为一种游戏逻辑描述的文件，以流程图样式呈现的图表比脚本的操作复杂度较低，更易于理解，便于非技术人员积极参与到游戏开发过程中去的技术效果，进而解决了相关技术中在程序开发过程中使用脚本对应用逻辑进行描述的方式，复杂度较高、不易理解的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据相关技术的通过虚幻引擎的蓝图描述一段游戏逻辑的示意图；

图2是根据本发明实施例的应用逻辑的处理方法的流程图；

图3是根据本发明优选实施例的角色进入陷阱便被弹射的逻辑流程图；

图4是根据本发明优选实施例的选择性逻辑实现过程的流程图；

图5是根据本发明优选实施例的玩家执行日常任务过程的流程图；

图6是根据本发明优选实施例的玩家执行副本任务过程的流程图；

图7是根据本发明实施例的应用逻辑的处理装置的结构框图；

图8是根据本发明优选实施例的应用逻辑的处理装置的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

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

根据本发明实施例，提供了一种应用逻辑的处理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图2是根据本发明实施例的应用逻辑的处理方法的流程图，如图2所示，该方法包括如下步骤：

步骤S22，根据预设应用逻辑对待使用的基础图表元素的属性进行配置并确定待使用的基础图表元素之间的执行顺序；

步骤S24，按照配置的属性和执行顺序处理预设应用逻辑。

通过上述步骤，采用根据预设应用逻辑对待使用的基础图表元素的属性进行配置并确定待使用的基础图表元素之间的执行顺序的方式，通过按照配置的属性和执行顺序处理预设应用逻辑，达到了简化应用逻辑描述方式的目的，从而实现了作为一种游戏逻辑描述的文件，以流程图样式呈现的图表比脚本的操作复杂度较低，更易于理解，便于非技术人员积极参与到游戏开发过程中去的技术效果，进而解决了相关技术中在程序开发过程中使用脚本对应用逻辑进行描述的方式，复杂度较高、不易理解的技术问题。

可选地，上述待使用的基础图表元素可以包括但不限于以下至少之一：

1)事件触发性图表元素；

事件触发性图表元素通常可以作为流程图中的输入符号，其可以采用第一图形(例如：椭圆形)加以表示，用于表示流程图的执行入口。

在应用逻辑流程图中，输入符号主要用于处理以下四类对象：

(1)玩家类事件，可以通过在第一图形中填充第一颜色(例如：红褐色)来加以表示。

(2)非玩家角色(NPC)类事件，可以通过在第一图形中填充第二颜色(例如：普蓝色)来加以表示。

(3)世界类事件，可以通过在第一图形中填充第三颜色(例如：紫色)来加以表示。

(4)界面交互类事件，可以通过在第一图形中填充第四颜色(例如：橙色)来加以表示。

考虑到游戏任务交互通常仅围绕上述几类元素触发(其是指通过特定事件进行激活，例如：进入区域触发的任务是指在游戏角色进入特定区域后，这个任务便会被激活；而时间触发的任务是指在到达固定时间时，这个任务便会被激活)，所以提供其他类事件，以降低使用者入门的难度。

需要说明的是，本发明实施例所提供的流程图的作用并非在于完全代替编程语言，而是将游戏任务开发部分提取出来，以便于游戏玩家自由创作与修改，进而游戏玩家可以通过将游戏内的编辑元素拖拽至相应流程图组件以及通过双击流程图组件弹出属性面板对流程图组件的属性进行修改。

作为本发明的一个优选实施例，以玩家触发器为例，双击玩家类输入组件，在工具的属性面板的下拉菜单中将玩家阵营的属性值由“所有”修改为“1”，以及将玩家职业的属性值由“所有”修改为“法师”。最终，玩家类事件输入符号将会显示为由红褐色填充的椭圆图形，并且在椭圆图形内的红褐色背景下显示如下信息：阵营1法师玩家。

可选地，如果在如下属性面板的触发事件中选择一个特定事件，例如：选择“进入区域”事件，则会在椭圆图形内的红褐色背景下显示如下信息：当阵营1的法师玩家带着“1:号角”进入2号区域。

可选地，如果在如下菜单的触发事件中选择一个特定事件，例如：选择“玩家生命变化”事件，即玩家生命百分比小于30，则会在椭圆图形内的红褐色背景下显示如下信息：等级1-30的玩家血量<30％时。

由此可见，大部分玩家任务可以采用玩家阵营、玩家职业、玩家等级、特定持有物品作为过滤条件。因此，可以直接将具体信息输入至玩家触发器中，当然也可以通过流程图后续的选择功能添加其它过滤条件。

触发器是指按某种特定事件激活的组件，诸如生活中的定时炸弹，到达特定时间点是触发爆炸的事件。当触发条件满足时，炸弹便会被激活。任务触发器更是需要各种事件来激活任务的。玩家触发器支持的所有触发事件都是由各大公司的游戏引擎提供。因此，不能被游戏引擎识别的数据没有任何意义。

而在NPC类触发器中，NPC类触发器是指通过NPC相关的事件激活触发器，其中，相关的事件可以包括但不限于：NPC死亡、NPC受伤、NPC到达特定区域。

世界类触发器是指通过一些世界类事件激活触发器。世界类事件可以包括但不限于：到达特定时间，特定战争开始，特定战争介绍，特定城池被扩展。此类事件可以根据每个游戏在运行过程中的实际需求自行进行差异化扩展。

可选地，属性通配符为一种约定的字符串符号，在最终使用时将会被实际数据所替换。例如：如果需要在游戏运行过程中每5分钟显示一个公告：现在是几点几分，但是，在现实生活中时间是不断变化的，游戏策划人员在配置公告时无法将固定时间写在表格中，那么游戏引擎便可以提供接口约定。凡是在文字中遇到{@HH}便可以将其替换成小时数，遇到{@MM}便可以将其替换为分钟数，那么这条消息便可以配置为：“现在是{@HH}时{@MM}分”。即，在游戏实际运行过程中会被显示为“现在是11时02分”。

属性面板的标签功能可以输入自定义文字。当标签选项被填写时，触发器上显示的文字为标签上的文字，但是，其功能还是按照触发器的属性面板选择的功能为主。标签可以支持所描述对象的属性通配符，提供属性列表双击时将属性通配符加入描述文字。属性通配符的示例如下：

{@player:heath},其配置规则可以由具体负责开发的程序员来制定。

作为本发明的另一个优选实施例，以界面交互触发器为例，双击打开界面交互触发器，在工具的属性面板的下拉菜单中将NPC标识修改为“2:小小乔”，以及将玩家等级范围限制的属性值修改为“5-100”。最终，界面类事件输入符号将会显示为由橙黄色填充的椭圆图形，并且在椭圆图形内的橙黄色背景下显示如下信息：等级在5-100与2:小小乔对话。

2)操作性图表元素；

在流程图中，操作性图表元素通常可以采用第二图形(例如：圆角矩形)加以表示，其中，操作性图表元素可以分为以下三类：

(1)玩家操作，采用第一颜色(例如：绿色)圆角矩形表示,其包含所有玩家的操作；

(2)场景操作，采用第二颜色(例如：橙色)圆角矩形表示，其包含所有非玩家的操作，具体可以包括但不限于：场景解封(即玩家本来无法进入的特定游戏场景，在解封后玩家便可以随意进入)、显示NPC、隐藏NPC；

(3)变量操作，采用第三颜色(例如：蓝色)圆角矩形表示，其表示可以修改文档中的变量，变量是指玩家设计时自定义的一些数值，其数值的意义由设计者具体设定。

以玩家操作为例，双击玩家操作图元，其显示属性面板可以表现出：“物品类型0:小型血瓶”，其含义可以表示为：玩家获得30个标识为0的小型血瓶。

可选地，如果在属性面板中选择跳跃操作，其显示属性面板可以表现出：“跳跃初始加速度10”，其含义可以表示为：玩家以加速度10跳起。

可选地，如果在属性面板中选择地图传送操作，其显示属性面板可以表现出：“地图id 1”，其含义可以表示为：将玩家传送至标识为1的地图的(0,10,10)坐标处。

3)结束性图表元素；

通常采用第三图形(例如：圆形)表示一个流程图的结束，其为一个附加规则，当运行到第一颜色(例如：白色)结束符时，任务结束后将对玩家关闭；而对于未完成可重新再接的任务或者可循环接的任务，则采用第二颜色(例如：黑色)结束符号。

4)连接性图表元素；

其与流程图中的引线用法一致。在一个图元中点击再拖拽至另外一个图元，在两个图元之间便可以直接添加引线。

选择分支图元的引线存在“是”与“否”两种选择，其含义和功能与基本流程图一致。

利用上述图元便可以描述最初图1中所要表现的角色进入陷阱便被弹射这段逻辑。图3是根据本发明优选实施例的角色进入陷阱便被弹射的逻辑流程图。如图3所示，其具体表现形式如下：

S302，采用由红褐色填充(图中未示出)的椭圆图形表示玩家进入0号区域；

S304，采用绿色填充(图中未示出)的圆角矩形表示玩家以加速度10跳起；

S306，任务结束后将对玩家关闭。

5)选择性图表元素；

通常采用第四图形(例如：菱形)加以表示，主要可以分为：

(1)玩家条件选择图元，采用第一颜色(例如：红褐色)菱形表示，其支持玩家条件选择，前提是输入元是玩家才能使用。

(2)NPC(非玩家)条件选择图元，采用第二颜色(例如：橙色)菱形表示，其在任何情况下均可以使用。

(3)变量判断图元，采用第三颜色(例如：蓝色)菱形表示，其用于对变量进行判断。

假设流程图中存在一个特定变量，即死亡次数。

通过双击变量选择器，在工具的属性面板的下拉菜单中将玩家的死亡次数修改为3，则该图元显示如下信息：死亡次数＝3。

以玩家选择条件图元为例，双击玩家条件图元，在工具的属性面板的下拉菜单中将玩家生命的属性值修改为“300”，则该图元显示如下信息：玩家生命<300。

通过采用上述选择图元，可以描述带有选择性的流程：

图4是根据本发明优选实施例的选择性逻辑实现过程的流程图。如图4所示，该流程可以包括以下步骤：

步骤S402，采用由红褐色填充(图中未示出)的椭圆图形表示玩家进入传送门(传送门所在触发器在编辑器中被编辑为2号区域)。

步骤S404，采用由红褐色填充(图中未示出)的菱形图形判断玩家等级是否大于或等于15级；如果是，则转到步骤S406；否则，转到步骤S408；

步骤S406，当玩家等级大于或等于15级时，传送玩家到10号地图的(10，10，35)坐标处；流程结束；

步骤S408，当玩家等级小于15级时，在屏幕上显示此区域还没解锁；流程结束。

需要说明的是，从选择图元引出的引线，默认会添加“是”的分支限制，通过双击可以修改限制值。

6)事件计数性图表元素；

事件计数器与事件触发器之间存在一一映射关系，其中，与事件触发器对应的事件计数器可以包括：

(1)玩家计数器；

(2)NPC计数器；

(3)世界计数器；

(4)界面交互计数器。

假设存在如下两个事件触发器：玩家类事件输入符号会显示为由红褐色填充的椭圆图形，并且在椭圆图形内的红褐色背景下分别显示如下信息：“玩家”与“玩家杀死3:田鼠”。通过采用引线连接两个事件触发器。接受输入的事件触发器将被转换为事件计数器。然后，双击这个事件的计数，工具的属性面板的怪物类型标识对应的下拉菜单中显示“3:田鼠”，而不再显示属性面板中的玩家阵营等条件。如果将计数次数改为2，则可以在计数次数大于1时，在事件计数器的显示图形上的预设位置(例如：椭圆图形右下角)显示次数2。当然，使用后面提到的变量元素配合流程图的其它元素也能达到此目的，但是其缺陷在于：会使得流程图的大小变得臃肿，不易阅读。

计数触发器具有阻塞的作用，需要完成特定事件达到指定次数。另外，计数器无需设定玩家的限定条件，其对应的玩家被默认为事件触发器的玩家。而如果没有使用事件触发器。则默认为指定玩家。

图5是根据本发明优选实施例的玩家执行日常任务过程的流程图。如图5所示，该流程可以包括以下处理步骤：

步骤S502，5级玩家到NPC小小乔处通过对话的方式领取任务，其任务内容为：要求玩家击杀五只狼并交给小周瑜；

步骤S504，玩家击杀五只狼，此时计数为5；

步骤S506，到NPC小周瑜处与小周瑜进行对话；

步骤S508，玩家获得任务奖励物品：布衣；

步骤S510，玩家获得完成任务的经验值：1000；流程结束。

需要说明的是，为了简化流程图，所有任务默认自带放弃任务功能，由游戏逻辑引擎实现。在步骤S504之前，可以在玩家的任务面板中添加任务名称、任务的当前状态信息等显示内容；而在步骤S504之后，如果玩家在任务面板中选取待放弃的任务，则该任务便会结束，玩家将不会得到任何奖励。但是，如果在每个任务的流程图中，均编写上述关于放弃任务的相关说明，则流程图会显得庞大而臃肿，因此，默认玩家在领取任务后，自动在任务面板加以显示；而当玩家放弃任务时，则会自动退出当前任务。

7)计时性图表元素；

该图表元素主要用于延迟执行流程图后续的操作，其单位为秒。例如：在玩家杀死NPC天狗的20秒后，位于坐标：(52,10,36)处的实验室将会发生爆炸。因此，在玩家杀死NPC天狗与实验室发生爆炸之间需要增加20秒的延迟操作。

8)随机约束性图表元素；

在游戏开发过程中，随机数是一个较为常用的配置参数。例如：玩家攻击怪物有30％机率会产生暴击或怪物死亡存在5％机率掉落极品装备。在具体操作过程中，可以从选择器流出的引线，在上面自动添加随机值约束，通过双击可以对其进行修改。例如：玩家击杀山猫后，存在70.3％的机率掉落22:猫皮，或者，存在29.6％的机率掉落56：猫晶核，并且总输入引脚百分比的总和不能超过100％。

9)变量；

在通常情况下不建议使用变量，因为变量与变量判断逻辑会使得流程图变得复杂。绝大多数与计数相关操作都可以通过事件计数器来表达。

变量可以分为公有变量和私有变量，私有变量还有个特殊的统计结果变量，为了不增加玩家的理解负担，变量的基本类型只支持整形和字符串，另外还可以添加一种排序变量，其中，公有变量可以采用第一颜色(例如：粉红色)进行显示，私有变量可以采用第二颜色(例如：蓝色)显示。通过双击任何一个变量进入变量管理器可以添加/删除/修改变量内容。

例如：在控制面板中分别添加了三种变量,第一个变量(死亡次数)为私有变量，其需要分别为每一位都建立对应的副本；第二个变量(公告内容)为公有变量，可以在副本中假设每位玩家看到的公告都是相同的，因此只需要一份公告即可；第三个变量(统计结果)，其实际上对应两个变量，分别为分数，访问这个变量可以得到分数值，以及与分数对应的降序索引，索引从1开始。即分数的排名。

需要说明的是，变量可以配合变量选择器使用，同时变量操作图元可以对其数据进行修改。

可选地，在步骤S22中，根据预设应用逻辑对待使用的基础图表元素的属性进行配置可以包括以下执行步骤：

步骤S221，根据预设应用逻辑确定待使用的基础图表元素的种类以及每类基础图表元素的处理对象；

步骤S222，按照种类和处理对象在待使用的基础图表元素中的部分或全部基础图像元素对应的属性面板中获取待配置属性的属性值。

根据预设应用逻辑(例如：游戏任务开发)确定待使用的基础图表元素的种类以及每类基础图表元素的处理对象。对于上述介绍的各种基础图表元素并不需要完全适用于每个应用逻辑开发，而是需要根据该预设应用逻辑的实际需求选择使用哪些基础图表元素来构成完成的流程图，并且，由于部分基础图表元素还可能分为多个处理对象(例如：玩家类、非玩家类、世界类、界面交互类)，因此，需要根据该预设应用逻辑的实际需求选择该部分基础图表元素的处理对象。进一步地，如果需要对基础图表元素中的特定属性进行赋值，还需要根据该预设应用逻辑的实际需求获取操作人员输入的属性值。

可选地，在步骤S22中，根据预设应用逻辑确定待使用的基础图表元素之间的执行顺序可以包括以下执行步骤：

步骤S223，根据预设应用逻辑获取待使用的基础图表元素相互间的连接关系，其中，连接关系包括：每个连接组件所连接的相邻基础图表元素以及每个连接组件的连接方向；

步骤S224，按照连接关系确定待使用的基础图表元素之间的执行顺序。

在根据预设应用逻辑确定待使用的基础图表元素的种类以及每类基础图表元素的处理对象之后，还需要根据预设应用逻辑的实际需求确定待使用的基础图表元素相互间是依照何种顺序执行的，并在上述多个基础图表元素之间建立连接关系，从而确定完整的逻辑流程图。

可选地，在步骤S224，按照连接关系确定待使用的基础图表元素之间的执行顺序之前，还可以包括以下执行步骤：

步骤S225，对待使用的基础图表元素中的第一部分基础图表元素进行封装处理，创建一个或多个流程图组件，其中，一个或多个流程图组件包括以下至少之一：一个或多个闭包，用于配置可重复执行的中间过程逻辑；自定义触发器，用于配置可重复执行的触发判断逻辑；

步骤S226，根据一个或多个流程图组件与第二部分基础图表元素之间的连接方式调整连接关系，其中，第二部分基础图表元素为待使用的基础图表元素中除第一部分基础图表元素之外的剩余基础图表元素。

如果玩家不满足于流程图默认的四种触发器或者需要对一些较为常用的判断进行封装，则可以自定义触发器。自定义触发器图元允许有多个入口和多个出口，但只允许存在变量操作，其原因在于：触发器的功能只是表示被特定事件的发生所激发，所以除了修改不应该存在其它操作。自定义触发器图元以一个空触发器开头，以一个结束符结束,并且还可以在属性面板修改标签内容。

另外，每张流程图都可以视为一个闭包(其表示一个封闭区域，内部保护的数据与操作对外部不可见)。当游戏开始运行时，全部流程图均处于未激活状态。而当流程图被激活时，该流程图内的触发器才会开始工作。通过将一个或多个闭包作为一个高级图表元素，再与各个基础图表元素之间建立连接关系，从而确定完整的应用执行流程(例如：游戏具体玩法)。

在通常情况下，游戏引擎在运行过程中会去自动装载被预先设置为主流程图的那张流程图，该流程图将被作为游戏的首张流程图。

可以通过将一张流程图拖入另一张流程图，作为另一张流程图的一个图元。玩家可以自定义流程图显示的颜色和文字。

假设存在以下三张流程图：

第一张流程图用于表示玩家击杀三只野狼的任务。

第二张流程图用于表示玩家采集三朵花的任务。

第三张流程图用于表示去曹操处接任务，NPC会随机分配上述第一张流程图的击杀三只野狼任务和第二张流程图采集三朵花的任务。即，上述第一张流程图和第二张流程图分别作为闭包出现在第三张流程图中。当第三张流程图运行到特定闭包处时，将会加载相应的流程图并且创建流程图副本。流程图副本将会在运行完毕后自行销毁。当所有相关的流程图副本均被销毁时，流程图资源将会自动释放。

当然，需要指出的是，上述第三张流程图中存在不足之处，即第一张流程图和第二章流程图除了杀野狼和采花这个计数触发器存在差异外，其余内容都是相同的。为了对该缺陷进行改进，可以将计数触发器设置在流程图的对外接口面板中进行添加。

例如：第一张流程图在未添加任何对外属性并将其拖拽至其它流程图中时，其属性面板上的显示内容基本为空。通过单击第一张流程图，点击其中第二个图元(即“任务栏添加任务：击杀三只狼”)，并在菜单中选择对外公开，在将第一张流程图拖拽至其它流程图后，对其执行双击操作，此时属性面板的显示内容为：NPC标识，1：小百合。然后，再将第三个图元(即“击杀怪物6：野狼3只”)，计数器图元设置为对外公开，此时属性面板的显示内容包括：NPC标识，1：小百合；触发事件：杀死怪物；怪物类型标识6：野狼。那么直接在第三个图元中拖入两个第一张流程图，然后修改公开属性，将触发事件修改为采花，同时在下拉列表中查找鲜花，以及NPC对话内容填入采集三朵鲜花，即可节省第二张流程图。

需要说明的是，不同流程图之间通常不需要进行参数传递，其原因在于：流程图对应的操作数值都是基于玩家数据来实现的。如果有极少数的特殊需求，则可以使用全局变量来实现。

由此可见，利用传统的流程图改进而增加图表的亲和力，针对流程规模较大致使流程图难以管理增加流程图组件设计；针对策划案中常见需求，在传统流程图上添加变量、事件计数器、随机选择器、延迟器等元件；以及针对图表的描述内容较为繁杂的问题，为流程图加入闭包特性和自定义元件的功能，从而成为一种更适合描述应用逻辑(例如：游戏任务逻辑)的图表，作为除应用开发脚本以外的可替代选择。

可选地，在步骤S24中，按照配置的属性和连接关系处理预设应用逻辑可以包括以下处理步骤：

步骤S241，在待使用的基础图表元素中获取预设应用逻辑的执行入口；

步骤S242，从执行入口出发，按照配置的属性和连接关系逐个执行至下一个待执行的相邻基础图表元素或流程图组件，直至待使用的基础图表元素全部执行完毕。

开发人员在应用逻辑设计过程中，首先需要指定特定流程图作为启动时自动加载运行的流程图，其可以被称为主流程图(即上述执行入口)。当应用程序运行时，会自动加载主流程图，并按照该主流程图执行整个应用逻辑。

下面将结合以下示例对上述应用逻辑的执行过程作进一步地详细描述。

任务描述：玩家每天可以进入副本3次，在副本中击杀boss可获得奖励。玩家死亡后有三次复活机会，但需要消耗一定数量的金币，因此，玩家可以选择是否扣除100金币复活继续完成副本。

为此，首先需要建立私有全局变量。此处提到的私有全局变量与编程语言中的变量含义相同，例如：int X，其中，X可以选取任何整数。在流程图中变量会影响的通常体现在变量操作或通过变量的取值做出选择。

例如：“进入副本次数是否小于3”属于通过变量的取值做出选择；“如果进入副本次数小于3，则进入副本次数加1”属于变量操作。

需要说明的是，变量在流程图中并不是必需的，其存在会增加流程图自身的复杂度，因此，在通常情况下，可以选择计数器予以替代。

其次，建立自定义图元，其描述的内容为：如果进入副本次数小于3，则玩家可到钟馗处接任务，并在接到任务后，进入副本次数自动加1，即玩家总共可以在钟馗处接到三次任务。

然后，建立完整的流程图。图6是根据本发明优选实施例的玩家执行副本任务过程的流程图。如图6所示，该流程图可以包括以下执行步骤：

步骤S602-步骤S604，如果玩家在钟馗处接到任务，便被传送到地狱坐标为(0,0,0)的副本处；

步骤S606，在副本内发生玩家死亡事件；

步骤S608，死亡次数自动加1；

步骤S610，判断死亡次数是否大于3次，如果是，则转到步骤S618，如果否，则转到步骤S612；

步骤S612，提示玩家是否使用100金币复活；如果是，则转到步骤S602；如果否，则转到步骤S618；

步骤S614，在副本内发生boss死亡事件；

步骤S616，玩家获得2000经验值的奖励；

步骤S618，玩家被传送回坐标为(0,30,50)的长安城。

需要说明的是，使用私有全局变量可以描述一些较为复杂的任务需求，但是，在通常情况下，可以使用计数器便可满足大多数需求，并且可以使得流程图更加简洁、美观，为此建议尽量减少使用变量。

综上所述，使用流程图作为扩展，可以确保任务流程的健壮性和灵活性。

根据本发明实施例，还提供了一种应用逻辑的处理装置的实施例，图7是根据本发明实施例的应用逻辑的处理装置的结构框图，如图7所示，该装置可以包括：第一处理模块10，用于根据预设应用逻辑对待使用的基础图表元素的属性进行配置并确定待使用的基础图表元素之间的执行顺序；第二处理模块20，用于按照配置的属性和执行顺序处理预设应用逻辑。

可选地，第一处理模块10可以包括：第一确定单元(图中未示出)，用于根据预设应用逻辑确定待使用的基础图表元素的种类以及每类基础图表元素的处理对象；第一获取单元(图中未示出)，用于按照种类和处理对象在待使用的基础图表元素中的部分或全部基础图像元素对应的属性面板中获取待配置属性的属性值。

可选地，第一处理模块10可以包括：第二获取单元(图中未示出)，用于根据预设应用逻辑获取待使用的基础图表元素相互间的连接关系，其中，连接关系包括：每个连接组件所连接的相邻基础图表元素以及每个连接组件的连接方向；第二确定单元(图中未示出)，用于按照连接关系确定待使用的基础图表元素之间的执行顺序。

可选地，图8是根据本发明优选实施例的应用逻辑的处理装置的结构框图，如图8所示，上述装置还可以包括：第三处理模块30，用于对待使用的基础图表元素中的第一部分基础图表元素进行封装处理，创建一个或多个流程图组件，其中，一个或多个流程图组件包括以下至少之一：一个或多个闭包，用于配置可重复执行的中间过程逻辑；自定义触发器，用于配置可重复执行的触发判断逻辑；调整模块40，用于根据一个或多个流程图组件与第二部分基础图表元素之间的连接方式调整连接关系，其中，第二部分基础图表元素为待使用的基础图表元素中除第一部分基础图表元素之外的剩余基础图表元素。

可选地，第二处理模块20包括：第三获取单元(图中未示出)，用于在待使用的基础图表元素中获取预设应用逻辑的执行入口；执行单元(图中未示出)，用于从执行入口出发，按照配置的属性和连接关系逐个执行至下一个待执行的相邻基础图表元素或流程图组件，直至待使用的基础图表元素全部执行完毕。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。