Monthly Archives: April 2015

关于行为树的实现，我在网上看到几个实现版本都对节点规划了running状态，表示节点的动作未执行完毕，每次执行时从上次未执行完毕的节点开始执行而跳过之前已经执行完毕的节点。 问题在于，处于同一selector节点下的子节点，位置越靠前的节点优先级是越高的，如果因为running恢复机制而跳过了已经执行完毕的节点，岂不是无法实现“打断”现有逻辑的需求？ 我想问，节点running状态的引入是为了解决什么问题？为什么不每次都top-down执行所有节点？ http://www.zhihu.com/question/29486474 1. 行为树肯定要有 RUNNING状态的，否则你长时间做一件事情很难描述呀，比如你先做“走过去”，再做“采矿”再做“返回”，一颗行为树就表达完了。每件事情都是持续的，如果没有RUNNING，那其实就更像一颗“决策树”而非“行为树”了。 2. 假设你有三层状态机，行为树也只会用在最后一层，头两层都是一些“确定的动作”，不需要行为树来弄，比如“跑过去”，“采矿”这些分解动作，本来变化也不多，如果这都要行为树来弄的话，你的开发反而会很累。 3. 行为树是“树形逻辑”，“树形状态变迁”，但是有些时候逻辑不是树形的，比如就是个纯粹的是有向图的，这种情况下非要用行为树的话，要打比较多Patch 4. 针对你说的“停止”，问题，状态机/行为树，肯定要可以随时打断安排新任务的，具体的做法可能是，update的时候传入一个事件（比如时钟，或者结束），就像tcp的状态机，时钟和网络包都是它的输入，如果不能处理输入，那你做出来的东西只会自顾自的在屏幕上动来动去罢了。 5. 针对实现停止，有三种做法，一种是节点前判断，一种是行为树跑完后，都要跑一个通用的状态机；第二种是增加RESET整棵树的操作；第三种是通用状态机来处理任务改变的消息，一旦改变就复位树，或者调用一颗新的树，比如你把“巡逻”，“逃避”，“进攻”，写成了三颗不同的行为树，相当于一个“高级状态”来用。 PS：由于国内单机游戏凋零，网游类型单一，早年国内说 AI 都在说寻路，而这两年说 AI 大家都在说行为树。行为树是好用的，但是最近两年有些滥用了。它不是银弹，不是什么问题都可以扔给行为树让它来解决的。

BehaviorTree：国内很多正式商用项目确实用了，不管RTS，还是RPG，而且用的还行，毕竟写AI一大半时间在调试上，有图形化的界面，调试起来更方便点，有的项目策划可以直接来写AI。值得花时间封装的东西，你做出一套来，以后其他项目都可以用，但是两个人一个多月的时间是最起码的，一个人写一个GUI编辑器，另一个人写 BehaviorTree的运行时，用你们熟悉的语言来写。包括若干基类，运行跟踪，状态单步，以及可以脱离游戏环境的调试方式。如果找到称手的AI框架，拿过来， 比如你可以评估下 U3D的 BehaviorTree的库和编辑器是否可以，能否集成到你的项目？我自己没有用过，我们用自己之前的一个实现。 NaviMesh：大部分情况最好不用，现在国内大部分游戏都是显示3D，但是内部数据还是2D的，比如地图，还是用的格子，在这种情况下，引入NaviMesh会逼迫你客户端使用全3D数据结构，并且逼迫你服务端从2D计算升级到3D计算，主要是 NaviMesh实现起来起码也要一个多月，然后要调试很久。确实很优秀，但是不要为了用它来增加整体项目复杂度，我同事之前实现过 NaviMesh，但是仅仅在试验项目里用了，正式线上产品开发时，我们还是选择用纯2D地图，上传统寻路。