游戏编辑中调试方法、装置、设备及存储介质与流程

1.本技术实施例涉及游戏技术领域，尤其涉及一种游戏编辑中调试方法、装置、设备及存储介质。


背景技术：

2.游戏编辑器通过向用户提供一系列编辑工具以创造自定义玩法副本，其中触发器系统是玩法实现的载体，当监听到事件发生时，判断所有条件是否满足，若满足则执行相应动作；调试系统是用于作者对所编辑玩法测试运行的辅助系统，能够辅助用户快速定位所编写的玩法逻辑中漏洞。
3.目前提供编辑器玩法的游戏产品中，pc平台上一般有war3编辑工具、dota2创意工坊工具组等，其中war3编辑工具没有提供调试功能，需要用户根据实际运行情况自行猜测触发器中可能的漏洞；dota2创意工坊工具组中，用户通过lua脚本编写来实现游戏逻辑，调试可直接使用lua语言相关的调试工具，且工具组本身也提供了控制台输出窗口，能直接输出脚本运行日志，可以查看代码运行错误或代码中输出语句的结果。
4.但是，war3编辑工具由于没有提供调试系统，所以用户通过分析每次的副本运行结果判断触发器中的漏洞，效率不高；dota2创意工坊工具组则是需要用户有较好的lua语言编程基础，直接通过调试代码来定位缺陷所在，门槛较高，不适合普通的用户，无法满足普通用户的需求。因此，现有技术中无法在保证满足不同用户需求的情况下，快速有效地定位所编写的玩法逻辑中漏洞，进而影响用户体验。


技术实现要素：

5.本技术实施例提供一种游戏编辑中调试方法、装置、设备及存储介质，以克服现有技术中无法在保证满足不同用户需求的情况下，快速有效地定位所编写的玩法逻辑中漏洞的问题。
6.第一方面，本技术实施例提供一种游戏编辑中调试方法，包括：
7.响应于用于指示调试检测的触发请求，获取待检测信息，所述待检测信息包括触发器节点或所述触发器节点中的目标参数；
8.确定执行检测所述触发器节点或目标参数的目标调试检测组件；
9.通过所述目标调试检测组件对所述触发器节点或目标参数进行调试检测；
10.根据所述触发请求，在相应的客户端显示各个调试检测结果。
11.在一种可能的设计中，所述目标调试检测组件包括至少一个调试检测组件，所述调试检测组件配置有组件名、判定失败错误描述、判定失败错误类型、判定实现、判定条件、调用接口串；所述触发器节点包括事件、条件、动作，所述目标参数包括事件、条件以及动作对应的参数信息；
12.所述确定执行检测所述触发器节点或目标参数的目标调试检测组件，包括：
13.根据所述事件、条件、动作或所述参数信息，确定与所述待检测信息相关联的判断
逻辑；
14.从各个所述调试检测组件中获取符合所述判断逻辑的目标调试检测组件。
15.在一种可能的设计中，所述通过所述目标调试检测组件对所述触发器节点或目标参数进行调试检测，包括：
16.对所述目标调试检测组件中的调用接口串执行求值操作，将所述触发器节点或目标参数传入所述目标调试检测组件中进行调试检测；
17.当判定条件未能满足时，获取所述目标调试检测组件中的各个调试检测组件检测后的错误描述相关信息，所述错误描述相关信息包括触发器标识符信息、参数标识符信息、错误描述、错误类型；
18.将所述错误描述相关信息作为所述调试检测结果。
19.在一种可能的设计中，所述判定条件用于表示每个所述调试检测组件中的目标值比较部分，所述目标值为阈值；
20.在获取所述错误描述相关信息之前，所述方法还包括：
21.在所述目标调试检测组件中将从所述判定实现中获取的参数实际值与相应的阈值比较，判断所述参数实际值是否满足所述判定条件；
22.若所述参数实际值不满足所述判定条件，则确定所述判定条件未能满足。
23.在一种可能的设计中，在所述将从所述判定实现中获取的参数实际值与相应的阈值比较之前，所述方法还包括：
24.根据所述判定实现中的参数id，通过调用预设函数库，获取所述参数实际值；
25.其中，所述预设函数库是由处于各个判定实现中的共用模块生成出来的。
26.在一种可能的设计中，所述调试检测组件用于执行逻辑检测；所述通过所述目标调试检测组件对所述触发器节点或目标参数进行调试检测，包括：
27.根据所述触发请求对应的测试触发环境，确定所述测试触发环境为本地测试或联机测试；
28.若所述测试触发环境为本地测试，则通过所述目标调试检测组件在本地测试对应的客户端上执行检测操作；
29.若所述测试触发环境为联机测试，则通过所述目标调试检测组件在服务端上执行检测操作。
30.在一种可能的设计中，所述根据所述触发请求，在相应的客户端显示各个调试检测结果，包括：
31.根据所述触发请求对应的测试触发环境，确定所述测试触发环境为本地测试或联机测试；
32.若所述测试触发环境为本地测试，则在所述本地测试的客户端显示各个所述调试检测结果；
33.若所述测试触发环境为联机测试，则在所述联机测试的各个客户端分别显示各个所述调试检测结果。
34.第二方面，本技术实施例提供一种游戏编辑中调试装置，包括：
35.第一获取模块，用于响应于用于指示调试检测的触发请求，获取待检测信息，所述待检测信息包括触发器节点或所述触发器节点中的目标参数；
36.检测组件确定模块，用于确定执行检测所述触发器节点或目标参数的目标调试检测组件；
37.调试检测模块，用于通过所述目标调试检测组件对所述触发器节点或目标参数进行调试检测；
38.显示模块，用于根据所述触发请求，在相应的客户端显示各个调试检测结果。
39.第三方面，本技术实施例提供一种游戏编辑中调试设备，包括：至少一个处理器和存储器；
40.所述存储器存储计算机执行指令；
41.所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计中所述的游戏编辑中调试方法。
42.第四方面，本技术实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一方面以及第一方面各种可能的设计中所述的游戏编辑中调试方法。
43.本实施例提供的游戏编辑中调试方法、装置、设备及存储介质，首先响应于用于指示调试检测的触发请求，获取待检测信息，这里的待检测信息包括触发器节点或所述触发器节点中的目标参数；然后确定执行检测所述触发器节点或目标参数的目标调试检测组件，通过该目标调试检测组件对所述触发器节点或目标参数进行调试检测，因此，通过定义调试检测组件，能被任意模板节点(即触发器节点)或参数使用，给节点或参数自由组合调试检测组件，进而实现调试检测，然后将调试检测结果进行显示，能够快速定位错误，缩短用户追踪缺陷的时间，进而增加编辑器可玩性和健壮性，以实现用户高效编写副本地图。
附图说明
44.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
45.图1为本技术实施例提供的游戏编辑中调试系统的场景示意图；
46.图2为本技术实施例提供的游戏编辑中调试方法的流程示意图；
47.图3为本技术实施例提供的调试检测组件与运行环境示意图；
48.图4为本技术实施例提供的检测组件的属性及运行组装示意图；
49.图5为本技术实施例提供的本地测试与联机测试中的逻辑层与表现层关系图；
50.图6为本技术实施例提供的触发器动作示例的示意图；
51.图7为本技术实施例提供的调试系统错误提示示例的示意图；
52.图8为本技术实施例提供的游戏编辑中调试装置的结构示意图；
53.图9为本技术实施例提供的游戏编辑中调试设备的结构示意图。
具体实施方式
54.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是
本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
55.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例，例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
56.现有技术中提供编辑器玩法的游戏产品不多，其中同时兼有可高度自定义玩法的触发器系统，以及辅助性调试系统的则更少了。例如，pc平台上一般有war3编辑工具、dota2创意工坊工具组等，其中war3编辑工具没有提供调试功能，需要用户根据实际运行情况自行猜测触发器中可能的漏洞；dota2创意工坊工具组中，用户通过lua脚本编写来实现游戏逻辑，调试可直接使用lua语言相关的调试工具，且工具组本身也提供了控制台输出窗口，能直接输出脚本运行日志，可以查看代码运行错误或代码中输出语句的结果。但是，war3编辑工具由于没有提供调试系统，所以用户通过分析每次的副本运行结果判断触发器中的漏洞，效率不高；dota2创意工坊工具组则是需要用户有较好的lua语言编程基础，直接通过调试代码来定位缺陷所在，门槛较高，不适合普通的用户，无法满足普通用户的需求。此外，对于有触发器编辑工具的编辑器，可以直接通过提供显示输出类型的动作结点来供作者手动添加输出型调试语句，查看触发器节点中所引用变量具体的值以定位错误，通过显示输出动作节点来实现调试系统的方式是比较受新手用户的欢迎，但是给副本带来很多的冗余触发器节点，且是不隐藏的，是作为玩法本身存在的，在不需要调试系统时如地图审核通过后，仍会运行。
57.其中，带来冗余触发器节点的原因是显示输出的相关动作本身也是触发器节点，相当于为了显示其他触发器节点执行时状态，又加了这些节点。而这些节点只是用于显示输出，在地图审核通过后，这些节点会被视作用户所编辑玩法的一部分，而其实有无都不影响游戏逻辑，因为只是打印状态。所以在其他用户游玩该副本时(调试系统对编写副本地图的用户有用，但对其他用户没必要)，导致服务器执行了多余的不必要的触发器节点。
58.为了解决上述问题，本技术的发明构思是将调试检测条件组件化，通过定义调试检测组件能被任意触发器节点或参数使用，给触发器节点或参数自由组合调试检测组件，在逻辑层运行调试检测，调试检测过程不影响触发器系统即副本玩法的运行，对其是隐藏的，同时收集检测结果通知到表现层，表现层主要将检测结果可视化，便于快速定位玩法逻辑中漏洞，且能够满足不同用户需求，提高用户体验。
59.下面以具体地实施例对本技术的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
60.参考图1，图1为本技术实施例提供的游戏编辑中调试系统的场景示意图。在实际应用中，调试系统可以包括逻辑层和表现层。逻辑层在每个触发器节点或参数执行时，基于需要(在目标调试检测组件中)依次运行配置的所有调试检测组件，并收集各个调试检测组件的运行结果，将其通知(即notify)到表现层，表现层主要将调试检测结果可视化，无需用
户有较好的lua语言编程基础，即可定位缺陷所在，便于快速有效地定位，满足用户需求，进而提高用户体验。
61.具体地，首先确定调试检测组件的实体，使其可被自由搭配，调试检测运行在逻辑层，结果通知到表现层，逻辑与表现分离使本技术能在本地单人运行或者联机多人运行，本地单人运行时逻辑层运行在本地，联机多人运行时逻辑层则运行在服务端，表现层只负责处理逻辑层的调试检测结果，并能够快速定位。其中，调试系统附着于触发器系统存在，不影响触发器系统即副本玩法的运行，对其是隐藏的。
62.具体地，如何实现游戏编辑中调试检测的，参见图2所示，图2为本技术实施例提供的游戏编辑中调试方法的流程示意图。
63.参见图2，所述游戏编辑中调试方法，包括：
64.s101、响应于用于指示调试检测的触发请求，获取待检测信息，所述待检测信息包括触发器节点或所述触发器节点中的目标参数。
65.本实施例中，实现游戏编辑中调试方法的执行主体可以是游戏编辑器中的调试系统。这里的游戏编辑器可以适用于电脑端也适用于移动端(即手游)，在此不作限定。
66.在实际应用中，以手游为例，用户在手游编辑器中创造自定义玩法副本时，为了能够辅助用户快速定位所编写的玩法逻辑中漏洞，用户可以在客户端上通过开启调试检测功能的按钮，触发用于指示调试检测的请求，并将该触发请求发送至调试系统，调试系统接收到该触发请求后，响应于该触发请求，确定调试检测组件的实体，获取到触发器节点或所述触发器节点中的目标参数。
67.s202、确定执行检测所述触发器节点或目标参数的目标调试检测组件。
68.本实施例中，可以定义检测组件，能被任意模板节点或参数使用，可以给触发器节点或参数自由组合调试检测组件，该触发器节点或目标参数可以分别对应一个调试检测组件或多个调试检测组件，该组合好的调试检测组件即为目标调试检测组件。
69.其中，定义调试检测组件是指将普通的检测条件变成被该调试系统可使用的组件。下面中的将检测条件设计上考虑：独立于触发器节点或参数(可以为目标参数)；组件化；纯逻辑检测。将检测条件包装成调试检测组件，以满足调试系统需要。
70.具体地，实现自由组合是检测条件满足了独立于触发器节点或参数和组件化。其中，组件化的目标是使任何一个检测条件可以被用在任意触发器节点或参数上，例如“单位模型是否有效”这个检测条件变成调试检测组件后，可以用在：触发器—动作—将xxx单位的模型放大xx倍；也可以用在：触发器—动作—命令xxx移动到目标点xxx。即使后面的是一个移动动作，跟模型无关，但由于组件化，也可以自由组合该调试检测组件，还可以加上其他的调试检测组件：“点是否在场景内”。
71.s203、通过所述目标调试检测组件对所述触发器节点或目标参数进行调试检测。
72.本实施例中，进行检测条件时，对组件中判定实现接口调用串进行求值(eval)操作，则自动将上下文的节点、参数、阈值等相关值传入判定实现接口串中相应形参，运行判定。
73.其中，在每个触发器节点或参数执行时，基于需要依次运行配置的所有调试检测组件即目标调试检测组件，进而实现调试检测。
74.s204、根据所述触发请求，在相应的客户端显示各个调试检测结果。
75.本实施例中，在收集组件的运行结果后，将其通知到表现层，表现层主要将调试检测结果可视化，便于快速定位。具体地，表现层运行在提供用户创造自定义玩法副本的客户端。
76.本技术实施例提供的游戏编辑中调试方法，通过响应于用于指示调试检测的触发请求，获取待检测信息，这里的待检测信息包括触发器节点或所述触发器节点中的目标参数；然后确定执行检测所述触发器节点或目标参数的目标调试检测组件，通过该目标调试检测组件对所述触发器节点或目标参数进行调试检测，因此，通过定义调试检测组件，能被任意模板节点(即触发器节点)或参数使用，给节点或参数自由组合调试检测组件，进而实现调试检测，然后将调试检测结果进行显示，能够快速定位错误，缩短用户追踪缺陷的时间，进而增加编辑器可玩性和健壮性，以实现用户高效编写副本地图。
77.在一种可能的设计中，本实施例在上述实施例的基础上，比如，在图2所述实施例的基础上，对s102进行了详细说明。其中，所述目标调试检测组件包括至少一个调试检测组件，所述调试检测组件配置有组件名、判定失败错误描述、判定失败错误类型、判定实现、判定条件、调用接口串；所述触发器节点包括事件、条件、动作，所述目标参数包括事件、条件以及动作对应的参数信息。
78.这里的目标参数可以作为触发器节点的核心要素，比如某个动作结点：触发器—动作—将xxx单位的模型放大xx倍。这里有两个参数：xxx单位和xx倍对应的参数类型：单位、浮点数，而参数本身又可以嵌套(由其他参数或函数混合而成)，如单位类型参数：直接指定的场景单位xxx、单位变量执行值的单位、单位变量数组中第xx个所指单位、最后创建的单位等等，即参数本身其实也可能存在执行失败，如单位变量所指为空单位，所以也需要进行调试检测。
79.具体地，所述确定执行检测所述触发器节点或目标参数的目标调试检测组件，可以包括以下步骤：
80.步骤a1、根据所述事件、条件、动作或所述参数信息，确定与所述待检测信息相关联的判断逻辑。
81.步骤a2、从各个所述调试检测组件中获取符合所述判断逻辑的目标调试检测组件。
82.在实际应用中，调试检测设计上独立于具体的触发器节点或参数；调试检测设计上组件化；调试检测设计为纯逻辑检测，无表现层相关内容。综合所考虑的三点，本实施例中，创建的调试检测组件独立于节点或参数，由组件名、判定失败错误描述、判定失败错误类型、具体判定实现、判定条件组成，调试检测组件在判定实现时再继续降耦合，将本该置于组件内部实现中的本体抽离出组件，生成共有的函数库。
83.其中，函数库是将本身应该处于各个判定实现里共用模块抽离出来，比如：findunit函数，根据单位参数执行的单位id获取具体单位，可以被用于各种跟单位相关的检测条件中，因为这些检测条件首先是要拿到参数所对应的实际单位，再获取其身上的属性进行判定。比如“单位等级是否已经满级”、“单位是否已经死亡”、“单位是否是可建造单位”。
84.具体地，调试检测设计上独立于具体的触发器节点或参数。触发器节点之间、参数之间以及触发器节点与参数之间存在需要检测的相似部分，例如一般的“值是否为正数”、
“
单位引用参数值是否有效”等，特殊的有“玩家可控单位数量是否达到上限”等，这些是在浮点值相关参数、单位相关动作中是经常需要被检测的，还有既要在参数中被检测，也在动作中被检测的，如“玩家有无主控单位”在玩家所控制单位的单位类型参数中需要检测，也在设置操作镜头的镜头类型动作中被检测，因为设置操作镜头时，如果没有主控单位，所设置的操作镜头将朝向地图中心，即有无主控单位的动作执行逻辑可能会有不同，这是需要被用户所知的。在检测条件运行的时候，再组装节点对象、参数对象、检测值等参数。
85.调试检测设计上组件化。组件化的目标是使任何一个检测条件可以被用在任意节点或参数上，这样可以自由配置节点或参数所要用到的调试检测组件，调试检测组件对节点或参数隐藏，这要求在实现调试检测组件时兼容与其不相关的结点或参数，如“单位模型是否有效”应只用于单位模型相关动作中的检测，在实现兼容时不通过判断节点是否是单位模型相关动作节点来处理，而是以判断节点是否存在有效单位来处理，存在有效单位时检测其模型是否有效来返回值，没有则以出错处理，这样带来的好处是如果出现其他非单位模型相关的动作节点，且也需要判断模型是否有效时，可以直接配置该检测条件。
86.调试检测设计为纯逻辑检测，无表现层相关内容。为了使调试系统能同时适用于本地(单人)测试和联机(多人)测试，需要将表现层内容从调试检测组件中分离，只进行纯逻辑检测，在本地测试和联机测试中，通过使逻辑层分别运行在客户端和服务端，从而使调试系统同时兼容于单人测试(或本地测试)和多人测试(过联机测试)。调试检测组件中分离表现层内容，主要在逻辑层记录表现层内容的状态，再通知到表现层更新，如单位的朝向具体值，模型缩放值等，对于一些表现层特有的，如自定义图片的显示大小会因不同机型分辨率进行适配，对逻辑层是未知的，这种则采用上行通知到逻辑层记录。
87.其中，逻辑层、表现层、公共函数库以及检测组件(即调试检测组件)的关系可以参见图3所示，图3为本技术实施例提供的调试检测组件与运行环境示意图。根据逻辑层的逻辑状态，通过公共函数库可以获取运行时参数列表、检查某值是否引用变量、获取具体单位、获取参数标识符、描述超出范围、式神技能可用等，并在调试检测组件中运行检测，逻辑层记录表现层内容的状态，再通知到表现层更新。
88.在一种可能的设计中，本实施例在上述实施例的基础上，比如，在图2所述实施例的基础上，对s103进行了详细说明。所述通过所述目标调试检测组件对所述触发器节点或目标参数进行调试检测，可以包括以下步骤：
89.步骤b1、对所述目标调试检测组件中的调用接口串执行求值操作，将所述触发器节点或目标参数传入所述目标调试检测组件中进行调试检测。
90.步骤b2、当判定条件未能满足时，获取所述目标调试检测组件中的各个调试检测组件检测后的错误描述相关信息，所述错误描述相关信息包括触发器标识符信息、参数标识符信息、错误描述、错误类型。
91.步骤b3、将所述错误描述相关信息作为所述调试检测结果。
92.本实施例中，进行检测条件时，对组件中判定实现接口串(调用接口串)进行求值(eval)操作，则自动将上下文的结点、参数、阈值等相关值传入判定实现接口串中相应形参，运行判定。其中，参见图4所示的检测组件的属性及运行组装示意图。
93.具体地，检测组件是由判定条件、判定失败错误描述、判定失败错误类型、调用接口串、具体实现组成，通过该检测组件(即调试检测组件)可以检测事件是否使用全局变量，
如果事件中使用了全局变量，事件只注册一次，后续即使改变全局变量的值也不会改变事件；然后进行事件注册报警，获取事件中的所有参数，依次检测是否使用变量。还可以检测单位是否有效，如果无效，则单位参数为空，节点运行失败，然后依次检测单位id，根据单位id参数，findunit函数获取单位进行检查。
94.其中，调试检测结果的收集基于节点所选的调试检测组件集合即目标调试检测组件，当判定条件未能满足时，收集该错误描述相关信息(触发器标识符信息、参数标识符信息、错误描述、错误类型等等)，传送给表现层。
95.在一种可能的设计中，本实施例在上述实施例的基础上，对游戏编辑中调试方法进行了详细说明。其中，所述判定条件用于表示每个所述调试检测组件中的目标值比较部分，所述目标值为阈值。在获取所述错误描述相关信息之前，所述方法还可以包括以下步骤：
96.步骤c1、在所述目标调试检测组件中将从所述判定实现中获取的单位值与相应的阈值比较，判断所述参数实际值是否满足所述判定条件。
97.步骤c2、若所述参数实际值不满足所述判定条件，则确定所述判定条件未能满足。
98.本实施例中，结合图4所示，判定条件是指每个调试检测组件中的目标值比较部分，如“单位是否有效”，判定实现里获取具体的参数实际值，然后与判定条件比较：这里判定条件就是not none即是否为空，判断单位是否有效；其他的调试检测组件，如“等级是否>0”中的判定实现：获取单位等级，判定条件：>0。
99.在一种可能的设计中，本实施例在上述实施例的基础上，对游戏编辑中调试方法进行了详细说明。在所述将从所述判定实现中获取的参数实际值与相应的阈值比较之前，所述方法还可以包括：根据所述判定实现中的参数id，通过调用预设函数库，获取所述参数实际值。
100.其中，所述预设函数库是由处于各个判定实现中的共用模块生成出来的。
101.本实施例中，通过参数唯一性标识符id获取参数(对象),并执行(调用对象的execute函数即对象的执行函数)，得到参数值(即参数实际值)。比如，通过findunit函数，根据单位类型参数执行的单位id获取具体单位等。
102.在实际应用中，参数不局限于单位类型参数，除了单位类型参数，还有其他类型的参数，如变量类型参数、整数类型参数、区域类型参数、变量类型参数等等，还有单位组参数、浮点数参数、布尔值参数、点参数、玩家参数、玩家组参数、字符串参数、数组参数、触发器参数、计时器参数、计分板参数、图片参数、图标类型参数、文本参数、物品参数、物品组参数、物品类型参数、特效参数、特效类型参数、镜头参数、简要信息面板参数等。其中，触发器系统中的参数系统，参数是一个object,有唯一标识符id,也有execute函数，参数系统通过标识符id(即参数id)检索到这个参数，然后执行操作得到参数的实际值即参数实际值。
103.在一种可能的设计中，所述调试检测组件用于执行逻辑检测，如何进行调试检测，可以通过以下步骤实现：
104.步骤d1、根据所述触发请求对应的测试触发环境，确定所述测试触发环境为本地测试或联机测试。
105.步骤d2、若所述测试触发环境为本地测试，则通过所述目标调试检测组件在本地测试对应的客户端上执行检测操作。
106.步骤d3、若所述测试触发环境为联机测试，则通过所述目标调试检测组件在服务端上执行检测操作。
107.其中，根据所述触发请求，在相应的客户端显示各个调试检测结果，可以包括以下步骤：
108.步骤e1、根据所述触发请求对应的测试触发环境，确定所述测试触发环境为本地测试或联机测试。
109.步骤e2、若所述测试触发环境为本地测试，则在所述本地测试的客户端显示各个所述调试检测结果。
110.步骤e3、若所述测试触发环境为联机测试，则在所述联机测试的各个客户端分别显示各个所述调试检测结果。
111.本实施例中，结合图2，参见图5所示的本地测试与联机测试中的逻辑层与表现层关系图。在联机测试时，调试检测运行在服务端，其实就是调试检测的核心部分逻辑层运行在服务端，调试检测结果通知到客户端；在本地测试中，逻辑层和表现层都运行在客户端，所以服务端实现调试检测，其实是服务端执行了调试检测的逻辑部分，因为纯逻辑部分是无表现(特效、模型、ui)相关的，可以根据情况需要运行在服务端或客户端。
112.具体地，本地单人测试与联机多人测试中，逻辑层的运行环境不同使得其与表现层的连接方式有差异，在本地测试中表现层与逻辑层处于同一环境中，检测结果(即调试检测结果)直接添加到表现层的错误信息管理(debuginfomgr)中，联机测试中逻辑层与表现层处于不同环境，逻辑层的内容需要由通知层(notify)发送到表现层后再添加到错误信息管理中，可以参见图5所示。
113.其中，在表现层，错误信息管理(debuginfomgr)负责收集错误信息、调试信息显示以及触发器逻辑定位。测试时在运行模式阶段，错误信息管理收集检测结果，并将检测条件不通过的错误信息显示出来，在运行模式结束回到编辑状态时，可根据错误信息中的触发器标识符信息或参数标识符信息实现快速定位，为方便定位，错误信息的具体属性如下表：
[0114][0115]
其中，通过节点或参数标识符来完成具体的触发器定位，当该标识符信息不存在时，说明该标识符对应的触发器属于副本运行时动态创建的，来源于模板节点或模板参数，则根据源节点信息定位到包含模板的触发器。对于名字信息、组件输出信息以及变量名信息则用于在运行模式时的错误提示。
[0116]
在实际应用中，参见图6所示的触发器动作示例的示意图，这里是命令局部变量
var指向的单位走到所设定目标点，然而var前面所设置的类型是布尔型变量，这里局部变量参数类型不匹配，造成单位走动结点没有目标单位，错误提示如图7所示，图7为本技术实施例提供的调试系统错误提示示例的示意图，通过分组信息、触发器名字信息、以及触发器节点可直接定位错误所在。
[0117]
本技术通过定义调试检测组件，能被任意模板节点或参数使用；能够给节点或参数自由组合调试检测组件；其中，在逻辑层运行调试检测，收集结果通知到表现层；在表现层处理检测结果显示及辅助快速定位。具体地，先确定调试检测组件的实体，使其可被自由搭配，调试检测运行在逻辑层，结果通知到表现层，逻辑与表现分离使该方法能在本地单人运行或者联机多人运行，本地单人运行时逻辑层运行在本地，联机多人运行时逻辑层则运行在服务端，表现层只负责处理逻辑层的调试检测结果，并能够快速定位。由于调试系统附着于触发器系统(可以认为是触发器)存在，则不影响触发器系统即副本玩法的运行，对其是隐藏的。
[0118]
因此，本技术提供一种在游戏编辑中调试方法，不受平台限制；其中，执行该方法的调试系统同时适用于游戏副本的本地单人运行测试与联机多人运行测试；且调试检测条件组件化，触发器节点或参数可自由配置进行测试，保证满足不同用户的需求，且能够快速有效地定位所编写的玩法逻辑中漏洞。
[0119]
为了实现所述游戏编辑中调试方法，本实施例提供了一种游戏编辑中调试装置。参见图8，图8为本技术实施例提供的游戏编辑中调试装置的结构示意图；所述游戏编辑中调试装置80，包括：第一获取模块801、检测组件确定模块802、调试检测模块803、显示模块804；第一获取模块801，用于响应于用于指示调试检测的触发请求，获取待检测信息，所述待检测信息包括触发器节点或所述触发器节点中的目标参数；检测组件确定模块802，用于确定执行检测所述触发器节点或目标参数的目标调试检测组件；调试检测模块803，用于通过所述目标调试检测组件对所述触发器节点或目标参数进行调试检测；显示模块804，用于根据所述触发请求，在相应的客户端显示各个调试检测结果。
[0120]
本实施例通过设置第一获取模块801、检测组件确定模块802、调试检测模块803、显示模块804，用于响应于用于指示调试检测的触发请求，获取待检测信息，这里的待检测信息包括触发器节点或所述触发器节点中的目标参数；然后确定执行检测所述触发器节点或目标参数的目标调试检测组件，通过该目标调试检测组件对所述触发器节点或目标参数进行调试检测，因此，通过定义调试检测组件，能被任意模板节点(即触发器节点)或参数使用，给节点或参数自由组合调试检测组件，进而实现调试检测，然后将调试检测结果进行显示，能够快速定位错误，缩短用户追踪缺陷的时间，进而增加编辑器可玩性和健壮性，以实现用户高效编写副本地图。
[0121]
本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。
[0122]
在一种可能的设计中，所述目标调试检测组件包括至少一个调试检测组件，所述调试检测组件配置有组件名、判定失败错误描述、判定失败错误类型、判定实现、判定条件、调用接口串；所述触发器节点包括事件、条件、动作，所述目标参数包括事件、条件以及动作对应的参数信息；所述检测组件确定模块，具体用于：根据所述事件、条件、动作或所述参数信息，确定与所述待检测信息相关联的判断逻辑；从各个所述调试检测组件中获取符合所
述判断逻辑的目标调试检测组件。
[0123]
在一种可能的设计中，所述调试检测模块，具体用于：对所述目标调试检测组件中的调用接口串执行求值操作，将所述触发器节点或目标参数传入所述目标调试检测组件中进行调试检测；当判定条件未能满足时，获取所述目标调试检测组件中的各个调试检测组件检测后的错误描述相关信息，所述错误描述相关信息包括触发器标识符信息、参数标识符信息、错误描述、错误类型；将所述错误描述相关信息作为所述调试检测结果。
[0124]
在一种可能的设计中，所述判定条件用于表示每个所述调试检测组件中的目标值比较部分，所述目标值为阈值；所述装置还包括：第一处理模块；第一处理模块，用于在获取所述错误描述相关信息之前，在所述目标调试检测组件中将从所述判定实现中获取的参数实际值与相应的阈值比较，判断所述参数实际值是否满足所述判定条件；若所述参数实际值不满足所述判定条件，则确定所述判定条件未能满足。
[0125]
在一种可能的设计中，所述装置还包括：第二获取模块；第二获取模块，用于在所述将从所述判定实现中获取的参数实际值与相应的阈值比较之前，根据所述判定实现中的参数id，通过调用预设函数库，获取所述参数实际值；其中，所述预设函数库是由处于各个判定实现中的共用模块生成出来的。
[0126]
在一种可能的设计中，所述调试检测组件用于执行逻辑检测；调试检测，具体用于：根据所述触发请求对应的测试触发环境，确定所述测试触发环境为本地测试或联机测试；若所述测试触发环境为本地测试，则通过所述目标调试检测组件在本地测试对应的客户端上执行检测操作；若所述测试触发环境为联机测试，则通过所述目标调试检测组件在服务端上执行检测操作。
[0127]
在一种可能的设计中，所述显示模块，具体用于：根据所述触发请求对应的测试触发环境，确定所述测试触发环境为本地测试或联机测试；若所述测试触发环境为本地测试，则在所述本地测试的客户端显示各个所述调试检测结果；若所述测试触发环境为联机测试，则在所述联机测试的各个客户端分别显示各个所述调试检测结果。
[0128]
为了实现所述游戏编辑中调试方法，本实施例提供了一种游戏编辑中调试设备。图9为本技术实施例提供的游戏编辑中调试设备的结构示意图。如图9所示，本实施例的游戏编辑中调试设备90包括：处理器901以及存储器902；其中，存储器902，用于存储计算机执行指令；处理器901，用于执行存储器存储的计算机执行指令，以实现上述实施例中所执行的各个步骤。具体可以上述方法实施例中的相关描述。
[0129]
本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上述的游戏编辑中调试方法。
[0130]
在本技术所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。另外，在本技术各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在
一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
[0131]
上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本技术各个实施例所述方法的部分步骤。应理解，上述处理器可以是中央处理单元(英文：central processing unit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digital signal processor，简称：dsp)、专用集成电路(英文：application specific integrated circuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
[0132]
存储器可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器，还可以为u盘、移动硬盘、只读存储器、磁盘或光盘等。总线可以是工业标准体系结构(industry standard architecture，isa)总线、外部设备互连(peripheral component，pci)总线或扩展工业标准体系结构(extended industry standard architecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本技术附图中的总线并不限定仅有一根总线或一种类型的总线。上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。
[0133]
一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(application specific integrated circuits，简称：asic)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。
[0134]
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
[0135]
最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。