Behavior系统的思考和实现(2)


上次说了AI行为的一些想法,在很多的游戏AI引擎中,都或多或少存在这样的概念,这篇文章想继续上面的话题,说说实现。在现在的项目里,我做过一些探索,并且用两种方式实现过AI行为系统,效果都还可以。

在实现前,一般有几个必须要考虑的问题,当然,这些不仅适用于游戏AI开发,也适用于其他类型的软件开发。

  1. 利于扩展:因为在开发中需求可能一直在膨胀,预先设计的系统必须尽可能的满足这种需求。
  2. 利于任务分摊:当一个结构确定了之后,会有多个人一同来实现相应的功能和细节,所以,实现上要尽可能的使任务独立,方便多人协作。
  3. 利于调试:能实时的监控运行情况。

下面来介绍一下我尝试过的两种实现方法,当然,这里给出的是一些思路,一些很细节的东西,我不会很深入,要不就成代码解释了,顺便说一句,这两个名字是我自己取得,只是为了便于说明和理解。先介绍第一个。

基于动态命令队列的行为系统(Based on Dynamic Command Queue’s Behavior System)


behavior-2-1

这种系统自顶向下分为三个部分, 行为命令(Behavior Command),行为机(Behavior Machine),行为结点(Behavior Node)

  1. 行为命令(Behaviour Command):是面向AI决策层的接口,AI把行为命令压入行为队列,等待行为机的处理。这里的命令都是预先定义好的,再用上次举过的小狗的例子,决策层发现小狗的疲劳度很高了,需要“睡觉”,就可以发一个定义好的睡觉的命令,然后再由下层行为机负责处理。
  2. 行为机(Behaviour Machine):行为机的主要任务是维护一个行为队列,并执行队列中的行为命令,每一个行为命令都对应一个定义好的执行单元,即行为结点
  3. 行为结点(Behaviour Node):真正的行为执行单元,是一组简单行为的集合。结点内部,根据行为命令中的相关信息,进行处理,如选择动画,播放动画等等

在这种结构中,复合行为是由预定义的行为命令来实现的,比如定义一个 “边吃饭边喝水”的命令,这样的话,如果我们要扩展,只需要扩展行为命令,然后再添加相应的行为结点作为执行单元即可。

行为机是整个系统的核心部分,我做的时候,接受命令请求的队列容量是2,即当前执行的和下一个要执行的,这可以根据实际需求来调整。另外实现过程中,发现有可能有用的Tips,给大家参考:

  1. 检测行为命令是否相同:AI可能重复发一个行为命令(很多情况下无法避免),所以在命令进入队列的时候,需要检测这个命令是否与队列中相同
  2. 检测行为命令的优先级:因为命令是被压入的,而不是立即执行的,所以可能有时希望命令间有优先级,比如,小狗 ”睡觉“”移动“的优先级高,这样当”睡觉“指令入队列的时候,”移动“命令就不会覆盖掉”睡觉“ 的指令。
  3. 提供特殊命令:行为机可能需要提供一些控制命令,如重置,剔除,暂停,查询等给AI接口,当然,过多的控制命令会破坏行为机的封装性,只能平衡一下了。
  4. 用FSM(有限状态机)来实现行为结点一个行为执行可能是一个需要不断重入的过程,也就需要几帧或者几十帧来完成,这样可以考虑用FSM把行为结点分为Enter,Execute,Exit三段(我叫这种为3E结构)来处理,会十分的方便。

调试这种结构也很便捷,可以做一个工具来监控整个行为命令队列的运行情况,比如,当前是哪个,下一个是哪个,集成在AI的调试工具里即可。

相关:

—>Behavior系统的思考和实现(1)

————————————————————————

作者:Finney
Blog:AI分享站(http://www.aisharing.com/)
Email:finneytang@gmail.com
本文欢迎转载和引用,请保留本说明并注明出处
————————————————————————



(已被阅读2,799次)

发表评论

电子邮件地址不会被公开。

Copyright © 2011-2017 AI分享站    登录