关于调试问题

[Cabriter]

可以添加一部分调试部分的逻辑？不太懂你指的在编辑器里怎么打的标志
我感觉可以去递归一下父节点描述+子节点描述+参数 来打不同颜色的日志
例如：Selector (英雄AI)-->FindEnemy(查找敌人范围,args{w=1000,h=500})-->output XEnemy

[xcoding1024]

我有过类似的做法
但实际应用起来，如果行为树非常庞大的时候，逐帧检查会变得非常困难，通常这时候策划会直接来找程序帮忙检查，这不是我所期望的，我希望他们能自己建行为树自己查错！

其实我们对行为树打印的大多数结果都不感兴趣，我们在客户端看表现就基本能猜到是哪几个节点可能有问题了。所以给关键几个节点打上标志，在运行的时候只打印这几个节点即可，像这样

[xcoding1024]

如果客户端是H5，那借助浏览器的调试控制台打印日志，更是非常方便，甚至可以让服务端把行为树日志发到前端显示，用fliter过滤一下，只看自己兴趣的日志。其实策划想要知道的无非是，这个节点有没有执行到，执行结果是成功还是失败，还有执行的时间及当时黑板上的变量

[Cabriter]

嗯，是，你这两个都是自己写的web端的编辑器和调试器吧，我们项目用unity+lua，我把这部分逻辑加入到了lua部分，现在就是在调试上有点蛋疼，不知道改怎么去做，还好目前逻辑不是很复杂，肉眼可以检查出来。

[xcoding1024]

编辑器都是浮云，我甚至还想过打断点，让服务器和客户端同时停下来，单步调试。其实没必要搞那些花里胡俏的，我试过几种方案，还是打日志最靠谱，打印关键节点的日志，越详细越好，很快就能定位问题，策划也会自己查

[Cabriter]

�主要是怕碰到类似run的wait节点，日志会打印很多很多，参数值也变化的比较快，不方便查看。这个怎么做比较好？

[xcoding1024]

所以要打标志呀，在导出的行为树节点参数里，给个debug参数，debug为true才打印，只打一些关键的条件节点和行为节点，像根节点，wait，这些能目测结果的就不要打印，干扰就会少很多。除非是新手连Selector和Sequence的作用都不理解，才需要看完整的执行结果，稍有经验的策划试过几次都懂得怎么找关键点去调试。

[xcoding1024]

另外，最好能实现热更功能，修改行为树能马上在游戏中生效，查错的效率成倍的提升

[Cabriter]

嗯，明白了，热更功能是实现了的，也正是因为这个可以完全在lua实现ai逻辑，才选了这个方案来做，就是朝着可以热更来做的。

[Cabriter]

还有一个问题，例如打断机制，A在行为过程中被B打断了，我目前想的是根结点是个selector，第一个子节点去判断一个标记位是否被打断了。但总感觉这样的逻辑有点硬。

[xcoding1024]

我不是很理解你说的打断指的是什么，被打断不是应该行为树的RUNNING状态清掉吗，我的做法是比较粗暴，所有的节点状态都恢复到初始状态。

[Cabriter]

我指的打断就是A在跑动的过程中被B的技能打断了当前的状态。
清除RUNNING状态不行，因为受击后还会有类似后摇的状态。
如果全部恢复初始状态，那在A跑动的之前所找到的跑动目标和路径之类的就要全部重新算一遍了。这种办法比较粗暴，如果碰到类似受到一个buff状态，导致A每三秒掉血并产生受击状态。来回的路径计算就有点不太好了。

[xcoding1024]

了解，其实你说的是状态的切换问题，这方面用状态机实现会比较好。行为树根据当前状态去做决策和行为，而不应该去管单位的状态切换。按常理来说，AI或者技能，被打断了就是完全中断了，下次就应该重新执行行为树。像受击后摇这些应该是交给状态机去处理

[Cabriter]

嗯，明白了，感谢，我在这里找到了个比较好的实现方法可以借鉴下。https://www.cnblogs.com/McYY/p/11689623.html