— AI分享站

Archive
Tag "行为树"

第一部分 第二部分

行为树最后一个要讲的地方,是关于前提(Precondition),在第一部分里,我略微提到了一下,这次我们来仔细看看,再来看看关于前提的纯虚基类的定义:

 1: class BevNodePrecondition
 2: {
 3: public:
 4:     virtual bool ExternalCondition(const BevNodeInputParam& input) const = 0;
 5: };

每一个前提类,都需要实现这个判断的虚函数。我在《用类来表示逻辑运算–关于行为树前提的一种实现方式》提到,我们可以用类来表示逻辑运算,这样的好处是可以做到模块化,同样的判断条件可以复用,所以在库中,我也实现了这种逻辑的表达方式,定义了基本的逻辑运算类

 1: class BevNodePreconditionTRUE{};
 2: class BevNodePreconditionFALSE{};
 3: class BevNodePreconditionNOT{};
 4: class BevNodePreconditionAND{};
 5: class BevNodePreconditionOR{};
 6: class BevNodePreconditionXOR{};

从这些类的名字应该就可以明显的看出这些类的含义了,和逻辑操作符一样,有些类的构造函数需要两个参数,以此来表示二元的逻辑运算(AND,OR,XOR),有些只需要一个参数,以此来表示一元的逻辑运算(NOT)。前提类被用来附在行为树的节点上(每一个节点都可以附加),默认情况下,节点上是没有前提类的,也就是不存在“外在前提”,而只有“内在前提”,这和附了一个BevNodePreconditionTRUE(永远返回True)的“外在前提”的节点是等价的。

好了,行为树库的内容基本就是这些了。接下去我们来看看例子程序,介绍如何用库来创建行为树,例子的代码在BevTreeTest这个工程中,编译后可直接运行,这个例子分别演示了三个行为树,从简单到复杂,单击鼠标可以在这三个例子间切换。这个程序实现了这样一个功能,“在场景地图上,定时会产生一个目标点,智能体就会根据行为树的定义,用不同的行为模式移动到目标点”。

在这个程序中,我为智能体一共定义了4个行为:

 1: class NOD_Idle{};      //空闲,表现是颜色不停变化
 2: class NOD_Breathe{};   //呼吸,表现是大小规律性变化
 3: class NOD_MoveTo{};    //移动,平移到某目标点
 4: class NOD_FaceTo{};    //转向,转向到某方向

再定义了2个“外在前提”:

 1: class CON_HasReachedTarget{};    //是否到达目标点
 2: class CON_HasFacedToTarget{};    //是否朝向目标点

我就用第一个例子来说,第一例子的行为树图如下:

BevTreeTest1

这是一个很简单的行为树,根节点是一个带优先级的行为节点,所以MoveTo比Idle的优先级高,MoveTo带有一个“外在前提”,“当没有到达目标点”时,会选在MoveTo的行为,反之,则选Idle的行为。

在代码中,可以这样来定义这棵行为树

 1: BevNode& ret =
 2:     BevNodeFactory: :o CreatePrioritySelectorNode(NULL, "root");
 3:         BevNodeFactory: :o CreateTeminalNode<NOD_MoveTo>(&ret, "move to")
 4:             .SetNodePrecondition(new BevNodePreconditionNOT(new CON_HasReachedTarget()));
 5:         BevNodeFactory: :o CreateTeminalNode<NOD_Idle>(&ret, "idle")
 6:             .SetNodePrecondition(new BevNodePreconditionTRUE());
 7: m_BevTreeRoot = &ret;

我在库中定义了一些工厂方法,帮助创建相关的节点。值得注意的是,我在这里演示了用类表示逻辑的用法。我在定义行为树的时候,会用一些格式上的缩进,来表示相应的父子结构,这仅仅是为了视觉上比较明了。当然,以后可以改进行为树的定义接口,更可以用数据文件来定义行为树。

这样定义完毕后,我们就可以用行为树来决策我们的行为了,代码相当简单

 1: BevNodeInputParam input(&m_BevTreeInputData);
 2: BevNodeOutputParam output(&m_BevTreeOutputdata);
 3: if(m_BevTreeRoot->Evaluate(input))
 4: {
 5:     m_BevTreeRoot->Tick(input, output);
 6: }

在例子中,我尽量把行为树中要输出的变量写到BevNodeOutputParam结构中(而不是直接修改智能体的信息),这样做的好处是可以让行为树的输入和输出的接口相当清晰,做成黑盒,可以参考我在这里的讨论。

第二个例子演示了并行节点的用法,第三个例子演示了序列节点的用法,就不多说了,大家可以自行看代码。

所有的代码可以通过以下方式获得:

下载地址:

GoogleCode下载点(exe文件夹中已包含可执行文件)

也可用svn通过以下地址来得:

http://tsiu.googlecode.com/svn/branches/blogver/

编译方法:

用VS2005以上打开,选择Debug NoDx或者Release NoDx,编译后,运行BevTreeTest.

相关代码:

TAI_BevTree.h

TAI_BevTree.cpp

关于TsiU

TsiU是我一直在维护的一个自己用的小型的框架,我平时做的一些AI的sample,或者一些工具,都会基于这个框架,TsiU有一些基本的UI控件库,网络模块库,GDI绘图模块,D3D绘图模块等等,可以快速的做成一个小型的示例程序,很方便(具体可参考SampleApps里的例子程序),并且整个架构是用Object的方式来组织,非常容易理解和扩展。整个框架很轻量化,基本就是做了一些底层的基本的功能,这样我在平时做东西的时候,就不需要重新写底层了,把精力都放在高层的实现了。以后分享代码都会基于这个框架,大家也可以通过svn来随时update到我最新的改动。下图就是TsiU里的几个工程介绍,代码不多,大家想看的也可以自己看一下 :)

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

Read More

第一部分

上一次说到了节点的基类,它描述了在行为树上一个节点的基本结构。我们知道,在行为树上有两大类的节点,一种我称之为“控制节点”,像“选择节点”,“并行节点”,“序列节点”都属于此类,这类节点负责行为树逻辑的控制,是和具体的游戏逻辑无关的,属于行为树库的一部分,并且这类节点一般不会作为叶节点。还有一类称为“行为节点”,也就是行为树上挂载的具体行为,是和游戏逻辑相关的,不属于行为树库的一部分,需要自己去继承和实现,这类节点一般都作为叶节点出现。

先来看看“行为节点”的代码,我先从节点的基类继承了一个所有“行为节点”的基类

 1: class BevNodeTerminal : public BevNode
 2: {}

在它的Tick方法中,我做了一个简单的状态机(可以自行看代码),负责处理进入行为(Enter),更新行为(Execute),退出行为(Exit),所有的行为节点应该继承自BevNodeTerminal类,并且重写这些虚函数,在进入和退出行为里,可以做一个初始化和清理的工作:

 1: class BevNodeTerminal : public BevNode
 2: {
 3: protected:
 4:     virtual void                _DoEnter(const BevNodeInputParam& input)                                {}
 5:     virtual BevRunningStatus    _DoExecute(const BevNodeInputParam& input, BevNodeOutputParam& output)  { return k_BRS_Finish;}
 6:     virtual void                _DoExit(const BevNodeInputParam& input, BevRunningStatus _ui_ExitID)    {}
 7: }

值得注意的是,在Tick方法中,它有一个返回值,表示当前节点是否处理完毕,在库中,我定义了一个enum来表示节点的运行状态:

 1: enum BevRunningStatus
 2: {
 3:     k_BRS_Executing                 = 0,
 4:     k_BRS_Finish                    = 1,
 5:     ...
 6: };

当返回k_BRS_Finish的时候,就表示当前节点已经处理完毕了,如果再次进入该节点,就认为是重新进入了。用上面描述的那个状态机的来说的话就是,如果是重新进入,会先调用_DoEnter方法,然后调用_DoExecute方法,如果_DoExecute返回正在运行(k_BRS_Executing),那么以后再进入这个节点就会直接调用_DoExectue,如果返回已经结束(k_BRS_Finish),则会调用_DoExit,以后再进入这个节点就会重新调用_DoEnter方法了。

对于控制节点来说,它的运行状态和子节点的运行状态是息息相关的,比如,选择节点的运行状态,就是它当前选择的这个节点的运行状态,并且,有时控制节点的控制逻辑也和子节点的运行状态有关,比如序列节点,当它前一个子节点运行结束,序列节点就会自动的切换到下一个子节点运行。所以在实现具体的行为类时,我们应该要正确的返回节点的运行状态。在例子程序中,我做的一个“空闲”(idle)的行为节点,就能很好的说明问题:

 1: class NOD_Idle : public BevNodeTerminal
 2: {
 3: public:
 4:     NOD_Idle(BevNode* _o_ParentNode)
 5:         :BevNodeTerminal(_o_ParentNode)
 6:     {}
 7: protected:
 8:     virtual void _DoEnter(const BevNodeInputParam& input)
 9:     {
 10:         m_WaitingTime = 0.5f;
 11:     }
 12:     virtual BevRunningStatus _DoExecute(const BevNodeInputParam& input, BevNodeOutputParam& output)
 13:     {
 14:         const BevInputData& inputData = input.GetRealDataType<BevInputData>();
 15:         BevOutputData& outputData = output.GetRealDataType<BevOutputData>();
 16:
 17:         f32 timeStep = inputData.m_TimeStep;
 18:         m_WaitingTime -= timeStep;
 19:         if(m_WaitingTime < 0)
 20:         {
 21:             outputData.m_BodyColor = D_Color(rand() % 256, rand() % 256, rand() % 256);
 22:             return k_BRS_Finish;
 23:         }
 24:         return k_BRS_Executing;
 25:     }
 26: private:
 27:     float m_WaitingTime;
 28: };

这段代码中的某些内容不明白也没有关系,我们主要关注的是关于节点运行状态的部分。这个Idle行为做了一件这样的事,就是不停的变换自己的颜色,间隔是0.5秒,当时间一到,就会返回运行结束(k_BRS_Finish),并输出当前的颜色,当时间还没到,则返回运行中(k_BRS_Executing),并且维持当前颜色。可以看到,我们用运行状态控制了计时器的重置,选择在_DoEnter方法中重置了计时器,当然,更合理的做法是在时间一到的时候,就重置计时器,并且永远返回运行中,不过这个例子里,我主要就是想用来演示运行状态,和_DoEnter的相关用法。

接下去再来看看控制节点,我一共写了5种控制节点,带优先级的选择节点(BevNodePrioritySelector),不带优先级的选择节点(BevNodeNonePrioritySelector),序列节点(BevNodeSequence),并行节点(BevNodeParallel),循环节点(BevNodeLoop),这些节点的进入条件和选择逻辑都是按照在行为树中改节点的定义来做的,我想用一张表格来说明:

测试(Evaluate) 更新(Tick)
带优先级的选择节点(BevNodePrioritySelector) 从第一个子节点开始依次遍历所有的子节点,调用其Evaluate方法,当发现存在可以运行的子节点时,记录子节点索引,停止遍历,返回True。 调用可以运行的子节点的Tick方法,用它所返回的运行状态作为自身的运行状态返回
不带优先级的选择节点(BevNodeNonePrioritySelector) 先调用上一个运行的子节点(若存在)的Evaluate方法,如果可以运行,则继续运保存该节点的索引,返回True,如果不能运行,则重新选择(同带优先级的选择节点的选择方式) 调用可以运行的子节点的Tick方法,用它所返回的运行状态作为自身的运行状态返回
序列节点(BevNodeSequence) 若是从头开始的,则调用第一个子节点的Evaluate方法,将其返回值作为自身的返回值返回。否则,调用当前运行节点的Evaluate方法,将其返回值作为自身的返回值返回。 调用可以运行的子节点的Tick方法,若返回运行结束,则将下一个子节点作为当前运行节点,若当前已是最后一个子节点,表示该序列已经运行结束,则自身返回运行结束。若子节点返回运行中,则用它所返回的运行状态作为自身的运行状态返回
并行节点(BevNodeParallel) 依次调用所有的子节点的Evaluate方法,若所有的子节点都返回True,则自身也返回True,否则,返回False 调用所有子节点的Tick方法,若并行节点是“或者”的关系,则只要有一个子节点返回运行结束,那自身就返回运行结束。若并行节点是“并且”的关系,则只有所有的子节点返回结束,自身才返回运行结束
循环节点(BevNodeLoop) 预设的循环次数到了就返回False,否则,只调用第一个子节点的Evaluate方法,用它所返回的值作为自身的值返回 只调用第一个节点的Tick方法,若返回运行结束,则看是否需要重复运行,若循环次数没到,则自身返回运行中,若循环次数已到,则返回运行结束

可能看表格内的描述会感觉有点拗口,可以结合代码一起看,会理解的更好。特别要提一点的是,在某些控制节点的Evaluate方法中,我会修改和记录可以运行的节点索引,当调用Tick的时候,就可以用这个索引来找到可以运行的节点了。这种模式和我以前提到的行为树更新模式有点不太一样,不过本质上是相同的。

(待续…)

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

Read More

最近一直在忙新项目的准备,甚少涉及AI的东西,所以博客也疏于更新。春节前,收到一个网友的邮件,说看了行为树的一些东西,但还是不知道如何去入手实现,我就乘着春节假期,动手写了一个简单的行为树的库,和大家一起边分析代码,边说说行为树的具体实现方法。这个库很简单,一共也就800行的代码左右,不过麻雀虽小,五脏俱全,行为树中的主要部分基本都有涵盖,包括前提(Precondition),选择节点(Selector),并行节点(Parallel),序列节点(Sequence)等等。在分析代码前,如果有朋友对行为树的相关概念还不是很了解,建议先阅读本站上对于行为树介绍的相关文章。

这次的代码以及示例程序,还是基于我自己维护的一个框架TsiU,在系列文章的最后会给出下载链接。

行为树,由名字就可以看到,它是一个树结构,通过各个节点相互连接,所以我先定义了节点的基类:

 1: class BevNode{}

要把树链接起来,需要在这个类中保留父节点指针,和子节点指针,我用了一个固定的数组来保存子节点指针,它的大小是16,也就是说,一个节点最多可以有16个子节点

 1: class BevNode
 2: {
 3: protected:
 4:     BevNode*    mao_ChildNodeList[k_BLimited_MaxChildNodeCnt];
 5:     ...
 6:     BevNode*    mo_ParentNode;
 7: }

有了这些变量的定义,我们就可以串联起一颗树了。到目前为止,这个节点类还仅仅是一个树的节点,作为行为树的节点还差了些东西,在以前的介绍中,我们知道行为树的每一个节点都可以绑定一个称为前提(Precondition)的部分,用来作为是否进入这个节点的条件,在我的实现中,我把这个前提拆分成了两个部分,一个称为“内在前提”,一个称为“外在前提”。“内在前提”是和节点类静态绑定的(也就是说,这个节点的固有前提),而“外在前提”是可以和节点做动态绑定的。这样做的原因是,由于在行为树上,节点是可以被复用的,在不同的子树上他的进入条件往往是不同的。比如,“移动”,这是一个常见的行为节点,逃跑的时候,可能需要“移动”,追击的时候也需要“移动”,但进入这个节点需要不同的“外在前提”,所以这里就需要让节点支持动态绑定的前提。“内在前提”,我用继承的方式来实现,而“外在前提”,我用了另一个类来实现

 1: class BevNode
 2: {
 3: public:
 4:     bool Evaluate(const BevNodeInputParam& input)
 5:     {
 6:         return (mo_NodePrecondition == NULL || mo_NodePrecondition->ExternalCondition(input)) && _DoEvaluate(input);
 7:     }
 8: protected:
 9:     virtual bool _DoEvaluate(const BevNodeInputParam& input)
 10:     {
 11:         return true;
 12:     }
 13: protected:
 14:     BevNodePrecondition* mo_NodePrecondition;
 15: }

可以看到这里用到了一个叫做BevNodePrecondition的类,用来表示“外在前提”,他是一个纯虚函数,只有一个方法,先看一下它的定义,后面会有详细的讨论。

 1: class BevNodePrecondition
 2: {
 3: public:
 4:     virtual bool ExternalCondition(const BevNodeInputParam& input) const = 0;
 5: };

_DoEvaluate虚方法就是需要被子类继承并实现的“内在前提”,这两种前提在Evaluate方法中被结合了起来,用来检测进入条件,当返回True时,就表示当前节点可以被运行。返回False时,就表示当前节点进入条件不满足,不能被运行。

在节点基类的中,还有两个重要的方法是:

 1: class BevNode
 2: {
 3: public:
 4:     void Transition(const BevNodeInputParam& input)
 5:     {
 6:         _DoTransition(input);
 7:     }
 8:     BevRunningStatus Tick(const BevNodeInputParam& input, BevNodeOutputParam& output)
 9:     {
 10:         return _DoTick(input, output);
 11:     }
 12: }

转移(Transition)的概念是第一次出现,转移(Transition)指从上一个可运行的节点切换到另一个节点的行为。这个方法会被在节点切换的时候调用,比如,在一个带优先级的选择节点下有节点A,和节点B,节点A的优先级高于节点B,当前运行的节点是B,然后发现节点A可以运行了,但带优先级的选择节点就会选择去运行节点A,这时就会调用节点B的Transition方法,所以在这个方法中,一般可以用来做一些清理的工作。Tick方法就是通常的更新方法,就不多说了。

再来看一下这三个重要方法的参数,一共有两种类型的参数,BevNodeInputParam和BevNodeOutputParam,前者是传入参数,可以认为是行为树的输入,用const作为限定符,表示只读,后者是传出参数,可以认为是行为树的输出,可以修改。其实,从代码中可以看到,这两种类型的本质都是一样的,都是一个名为AnyData的类

 1: typedef AnyData BevNodeInputParam;
 2: typedef AnyData BevNodeOutputParam;

由于输入和输出参数是游戏相关的,所以这里用AnyData这个类来表示,这个类可以存放任意的数据结构,所以,这个类中真正的内容是需要玩家自己定义的。

最后来看看行为树是如何被定义和更新的(可以在示例程序中找到相关代码)

 1: //define input & output data
 2: struct BevInputData{...}
 3: struct BevOutputData{...}
 4: BevInputData    m_BevTreeInputData;
 5: BevOutputData   m_BevTreeOutputdata;
 6: ....
 7: //create tree
 8: m_BevTreeRoot = CreateTree();
 9: ...
 10: //update
 11: BevNodeInputParam input(&m_BevTreeInputData);
 12: BevNodeOutputParam output(&m_BevTreeOutputdata);
 13: if(m_BevTreeRoot->Evaluate(input))
 14: {
 15:     m_BevTreeRoot->Tick(input, output);
 16: }
  1. 定义自己的输入和输出参数(BevInputData,BevOutputData)
  2. 创建行为树,保存根节点指针(m_BevTreeRoot)
  3. 测试是否有可以运行的节点,如有则更新

(待续…)

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

Read More

自开博以来,经常会有网友发信给我,询问一些关于AI方面的问题,一般我都会尽力一一回答,也希望我的这些经验,对网友有些帮助,我想,有些问题可能是大家都会有的,所以,这一次,我会把一些网友的提问,和我的回答列在这个地方,供更多的同学参考,也欢迎一起讨论,才疏学浅,不吝赐教。

Q:你好,我在你的博客上看了你的一些关于行为树的文章,写得很好,让我受益匪浅。我想实践一下怎么用,在网上找了一个相关的库libbehavior(https://code.google.com/p/libbehavior/),想用这个库做个小例子,它里面有一些演示程序,但牵涉到很多库,不好学习,我就想将一个简单的状态机示例程序源码改成用行为树实现,发现还是很茫然,不知道你是否有空给些提示,谢谢!

A:我下载了程序简单看了下,libbehavior好像已经实现了一个可用的behavior tree了,虽然可能还不够完善,但基本的行为树的样子已经有了,你可以考虑基于他这个,然后根据自己的需求添加。 不知道你有没有看到它里面的sample,我从Scenario3.h里摘录了一段建行为树的例子来说明下,我还画了一张示意图作为参考

 1: //opponent->brain是一个ParallelNode,并行的节点
 2: //在并行节点上添加第一个子节点,行为是转向目标TurnTowardsTarget
 3: opponent->brain->addChild(new TurnTowardsTarget(1));
 4: //建立一个随机节点作为第二个子节点,下面三个序列节点应该会随机选一个执行
 5: ProbabilityNode* pNode = new ProbabilityNode();
 6: //在这个随机节点上,建立一个序列节点
 7: pNode->addChild((new SequentialNode())
 8:         //在序列节点上建立第一个子节点,感觉这个应该是个判断条件
 9:          ->addChild(new BoolCondition<GameObject>(&GameObject::alignedWithPlayer,true))
 10:         //在序列节点上建立第二个子节点,行为是射击Fire
 11:          ->addChild(new Fire())
 12:         //在序列节点上建立第二个子节点,行为是等待CD,防止太频繁
 13:          ->addChild(new Cooldown(500)),5.0);
 14: //在这个随机节点上,再建立一个序列节点,下面的子节点就不说明了
 15: pNode->addChild((new SequentialNode())
 16:          ->addChild(new FloatCondition<GameObject>(&Ship::getXPosition,LESS_THAN_FP,200,1))
 17:          ->addChild(new GotoPoint(point(300,50),500))
 18:          ->addChild(new Cooldown(200)))
 19: //在这个随机节点上,再建立一个序列节点,下面的子节点就不说明了
 20: pNode->addChild((new SequentialNode())
 21:          ->addChild(new FloatCondition<GameObject>(&Ship::getXPosition,GREATER_OR_CLOSE,200,1))
 22:          ->addChild(new GotoPoint(point(100,50),500))
 23:          ->addChild(new Cooldown(200)));
 24: //在这个随机节点的上面做一个循环节点,把上面的行为无限循环
 25: opponent->brain
 26:     ->addChild((new RepeatNode(-1))
 27:         ->addChild(pNode));

Scenario3BevTree

 

所以如果你要把状态机改成行为树的话,可以考虑用我说过的Selector节点+Precondition的方式(libbehavior里好像是叫PriorityNode,但它好像没有Preconditon的概念),因为状态机里不是要跳转嘛,你原先每一个state都会有进入条件的,比如下面这个

 1: if (pMiner->PocketsFull())
 2: {
 3:     pMiner->ChangeState(VisitBankAndDepositGold::Instance());
 4: }

这样的话,你可以把pMiner->PocketsFull()作为VisitBankAndDepositGold的Precondition挂在一个Selector节点下面,然后让Selector节点帮助你选择应该进入那个状态。我建议,你可以先看看libbehavior每一个Scenario的行为树创建部分的代码,这样应该会有点感觉,另外,可以边参考我网上的文章,边来看libbehavior\BehaviorTree-src里的源码,会好理解很多 :) ,希望对你有所帮助!欢迎继续来信交流!(状态机和行为树之间转换可以参看这里这里

Q:看了你写的一系列文章,写的真不错。我也最进在游戏行业,做AI相关的工作。涉及一些游戏AI设计的问题,能否指教一下。目前我们游戏AI设计的部分考虑NPC的AI部分可配置成AI执行脚本文件方式。我考虑是可以设计AI框架,依据游戏对象的配置,框架决定加载相应的脚本引擎。我看 《浅谈层次化的AI架构》 不错,你能不能分享一下AI设计中如何分离AI框架和AI脚本内容的呢。分离的话,感觉状态转换是应该在AI脚本中完成的吧? 暴露AI引擎的API接口的通用设计一般是怎么样的呢?学习中...., 谢谢。

A:如果想在脚本中写很多AI逻辑的话,如何调试是个比较麻烦的事情,需要比较好的调试接口。我用过一种做法,你可以试试看,就是用脚本做AI的配置,逻辑还是在C++端。C++提供一个个AI逻辑模块,然后在脚本端把它配置起来,因为我用的是行为树(可以参看我博客上关于行为树的相关文章),所以比较容易配置。接口的话,首先最好是引擎能支持反射,然后就能方便的导出函数和变量直接给脚本用,至少我用lua做脚本语言,这样是可行的。

Q:您好。今天再搜索层次状态机相关资料的时候进入了您的博客。本人只在游戏中使用过简单的FSM,属于AI初学者,阅读了几篇文章后产生了几个问题:

  • HFSM和行为树到底是什么关系。我对行为树和状态机的区别还是把握不了……
  • 您有一文章说:大部分的AI,都可以分成“决策”和“行为”,二者通过一个双缓冲的“请求层”通信,但是这篇文章您没有举例子,我非常模糊。
  • 对“并行节点”我还是很模糊……您可以给我举个例子吗……麻烦了…。

A:谢谢,针对每一个问题,我的回答如下:

  • HFSM和行为树其实没什么关系,是两种不同的AI结构,区别的话,可以看我在这里的评论http://www.aisharing.com/archives/90#comment-111
  • 有人和你提出了一样的问题,可以参看我这里的回复,http://www.aisharing.com/archives/86#comment-115
  • 比如一个并行节点下有A和B两个节点,那在一次循环里,如果前提满足的话,既会执行A,又会执行B,举个实际的例子,比如要描述“又吃又喝”,就可以用并行节点:)

Q:最近在学习行为树,有幸拜读了您几篇关于行为树的文章,感觉收获颇多。刚开始接触行为树,所知有限,特来请教几个问题:

  • 关于以下代码,在文章评论中,您回复说 input 是传入行为树的参数,那么 request 是指输入的事件吗?比如移动事件、死亡事件等。 如果是事件,那您实例代码的行为树是事件驱动的,还是Tick驱动?
 1: action = root.FindNextAction(input);
 2: if action is not empty then
 3:     action.Execute(request,  input)  //request是输出的请求
 4: else
 5:     print “no action is available”
  • 在FSM中,状态进入和退出时可以做相对应的事情,比如进入某个状态身上挂个循环特效,退出该状态将这个特效移除,在行为树上,怎么实现同样的功能?
  • 按我现在对行为树的理解,感觉行为树就是将FSM中的状态变成了子树,挂在行为树的相应位置,通过行为树的节点完成状态的迁移。但是,在您文章的总结中提到:"在AI设计过程中,一般来说,我们并不是先有状态机,再去转化成行为树的,当我们选择用行为树的时候,我们就要充分的理解控制节点,前提,节点等概念,并试着用行为树的逻辑方式去思考和设计。",看后对自己将状态视为子树的理解产生了很大的怀疑,您能详细地解释下这句话吗?不知是否可以提供一张您平时设计的较复杂些的行为树供我学习之用?

A:谢谢,针对每一个问题,我的回答如下:

  • request是输出的请求,也就是行为树的输出,就像你说的,像移动,死亡等,可以看看我博客上关于分层次的AI架构的相关文章,整个行为树的决策还是在Tick中更新的。
  • 一般我在做行为树的Execute时会分成三个阶段,onEnter() ,onExecute(),onExit(),在第一次进入这个节点的时候,会调用onEnter,在从这个节点切换出去的时候,会调用onExit()。每个行为树的节点,我都会做成这种1P(前提Precondition) + 3E(Enter, Execute, Exit)的结构
  • 行为树的思考方式是指,对于每一个节点我都需要明确知道它的进入条件是什么,它要做的事情是什么。把跳转逻辑写到控制节点中,用控制节点来控制行为树的选择流程。和状态机不同的是,对于行为树的节点,一般不需要知道它是从哪个节点过来的,它只是需要关心,满足什么条件(前提)可以进入这个节点,这些条件的判断依据都是通过行为树的输入参数传入的,所以行为树和黑板的组合是很好用的,可以看看我博客上关于黑板和行为树结合的文章
  • 项目里的行为树图不太好给,呵呵,而且需要解释才能明白。复杂的话,一般就会用到序列节点,并行节点等等。行为树的好处就是只要定义了进入前提,就可以加入到现有的行为树中,这样就越来越复杂了~,不过,这也就是行为树的好处了 :)

Q:Hi,在我们现在的项目里面涉及到AI的一些东西,之前学习了关于你写得行为树,正好可以发挥一下,现在有一个问题,就是关于怪物行走,怪物行走我们这边的做法就是发目标A*路径给客户端通知其他玩家,然后,怪物每秒刷一步就走一步...这样的做法...我想问问...你们那边关于怪物行走是如何实现的呢?巡逻和追击 两个地方行为怎么做互斥?

A:针对你的问题,我在想哦,对于怪物移动的话,可以分两个部分,一般的移动,就是你说的巡逻,可以不需要用A*,因为毕竟A*的开销是比较大的,因为怪物一般的移动不会太复杂,而且一般是在一定的区域内移动(当然这是看你们怎么设计了),可以在区域内设置几个路点,然后每过一段时间选择临近的路点就可以了,也就是仅仅做一步的“寻路”。如果是要追击玩家的话,可以尝试用到A*。

网页游戏我没做过,其他游戏里,我们用到过同步位置信息的方式,也就是每隔一段时间同步一次位置,然后两次同步之间的移动,都是客户端本地模拟。如果模拟后的位置和服务器上的位置有偏差,简单的做法是瞬移到服务器上的位置,好一点的话就是平滑的从客户端现在的位置移动到服务器上的位置。

巡逻和追击我觉得比较大的不同是,巡逻中是没有目标敌人的,而追击是存在目标敌人的,所以这样就可以做到互斥了。

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

Read More

记得以前我在博客中,提到过一种层次化的AI架构,这种架构的核心就是定义了“请求层”的概念,用来分隔决策和行为,并通过行为请求来清晰的定义了决策和行为之间的输入输出关系,不过,当我们仔细审视这个结构的时候,发现其中貌似缺失了对于某种情况的处理,这就是我今天要谈到,如何处理“被动式的行为请求”

一般来说,我们通常所认为的决策是一种“主动式(Active)的行为请求”,比如,我按了个键,玩家所控制的角色就是做出某些行为,或者AI通过对于当前情况的判断,做出了下一步的行为决策,所以说,主动式的行为请求,就是表达了一种“我想要去做什么”的语义。在游戏中,大部分的行为都是输入主动式的行为,那FPS(第一人称射击)类游戏来说,它可能包含的主动式行为有,移动,跳跃,射击,与游戏场景中物体的交互(拾取物品,开门)等等,当玩家和NPC在行动的时候,就是在这些已经定义的主动式行为中,做出决策。在我们以前提到的那种层次化的AI架构中,可以很好的满足这些需求。

但在游戏中,还是一些行为并不在主动式的行为中,比如死亡,当角色生命值等于0的时候,游戏系统就会触发这个行为请求,它不是由玩家或者NPC所发起的,而是有游戏系统判断出某些条件满足的时候,自动触发并赋予角色的行为请求。这一类的请求,我们就可以称之为“被动式(Passive)的行为请求”,在谈如何处理前,我们可以先看看这种请求有什么样的特点。

首先它可能会覆盖原本的主动式的行为请求。比如玩家想要快跑向前走,那他就会发出一个“快速移动”的行为请求,但就在这个时候,角色正好被横在路中间的一根树干绊了一下,当游戏系统检测到这个事件的时候,就会触发一个“绊倒”的行为请求,期望做一个摔倒的行为。显然,“绊倒”这个行为不是玩家主动做出的,是属于被动式的请求,而且这个请求应该被立刻响应(要不就不真实了),所以,当比较这两个请求的时候,我们就会用“绊倒”覆盖掉原先的“快速移动”,将其作为当前请求传给行为层。那我这里为什么说是“可能会覆盖”呢?因为并不是所有的被动请求都需要被响应的,这取决于当前产生的主动和被动,这两个请求的优先级设定,这种优先级设定一般来说会来自与游戏设计的需要。假设,我们在游戏中有一个行为是“超级移动”,这种行为很强大,效果也很炫,是游戏的一个很大的卖点和可玩点,所以游戏设计者就希望尽量能让玩家触发出这种行为,以提到游戏的游戏性和画面效果,所以当玩家触发“超级移动”的时候,我们可能就会忽略掉同时触发的“绊倒”这个行为请求。

其次,它是触发式的,所以意味着同一时刻它可能会有多个。试想一下,对于主动式请求来说,因为角色不可能分身嘛(除非是超人游戏),所以一般来说,同一时刻主动请求只会有一个,也就说,你不可能既想做这个,又想做那个。而被动式请求,就完全不同,在同一时刻,可能会有多个条件被满足,然后同时触发了多个被动行为请求,比如在被绊倒的那一刻,你中了一枪,然后生命值正好减到0(真倒霉。。),所以同时就产生了“绊倒”,“死亡”两个被动请求。那我们就面对,多个请求需要权衡的情况,在上述的例子里,显然,“死亡”的优先级应该是最高的,所以它会成为最后的请求被送到行为层。

还有一个特点就是关于被动请求产生源,在角色与角色交互的时候会非常容易产生被动式的行为请求。举个FIFA的例子(对此我研究了很多 :) ),在足球游戏中,我们可以看到很多球员间交互的例子,比如碰撞后的摔倒,争头球的挤位,带球过程中的拉扯,躲避铲球的跳跃,等等,这些都是被动式的行为请求,是玩家不可操控的,而且这些请求,不像我前面举到的例子,是单个人身上的,而是属于一种“相互作用(Interaction)”的行为请求。它的触发和处理,都会牵涉到两个,甚至多个人的判断。

谈完了特点,接下去来思考下如何来处理这些请求。当然,处理的方案多种多样,我先抛砖引玉的谈谈我想到的两种结构。还是基于原有的层次化的AI架构模型,做一些小的修改。第一种方案采用的是比较直观的集中化的处理。先定义一个结构表示当前时刻所有产生的行为请求。

 1: struct CandidateRequests
 2: {
 3:     Request        m_ActiveRequest;      //主动请求,假设同一时刻只有一个 
 4:     Array<Request> m_PassiveRequests;    //被动请求,同一时刻可以有多个
 5: }

然后,我们定义一个模块来负责处理这个结构,并产生一个最终的行为请求,值得注意的是,我们把当前正在处理的请求也作为考虑的因素之一,传入这个函数中。

 1: class RequestFinalizedModule
 2: {
 3: public:
 4:     static Request GetFinalRequest(
 5:                 const Entity& entity,
 6:                 const Request& curReq,
 7:                 const CandidateRequests& nextReq)
 8:     {
 9:         //添加选择的规则,根据当前请求和下一时刻的候选请求,抉择出最终应该做的行为
 10:     }
 11: }

集中式的处理方式将所以处理的可能性放到一个函数中,这样的好处是便于排查可能导致的选择不正确的问题,而且对于原有的结构没有什么更改,仅仅是在决策和请求层之间加了一个处理模块。缺点就是这块的代码,随着优先级关系的复杂,会显的相对比较乱,不过将脏代码堆在一个地方,也是一种不错的设计 :) ,下面是修改后的架构图

layered-ai-architecture_modified

另一种方案是让游戏系统不直接触发被动式请求,而是触发一些标记,然后AI在决策的时候将这些标记作为决策参考信息的一部分,最终做出一个合理的行为决策,这种方案延伸了决策部分的定义,使其即能产生主动式请求,也能产生被动式请求。如果用行为树的话,可以非常好的表示出这种优先级的关系,如下图:

bt-flag-passive-action

这种方式的优点是可以用到行为树本身对于优先级处理的优势,而不需要额外的添加模块,只需修改原本行为树的设计即可,作为游戏信息的一部分,也可以沿用原有的收集游戏信息的相关模块,做适当的扩展就可以了。缺点是,由于我们将原有的触发式的模式,变成了轮询式的,所以,可能会降低行为树的些许效率,而且对于行为树的设计也提出了更高的要求。不过从架构上来看,是比较清晰,并且能很好的融入原有的设计。修改的架构图如下:

layered-ai-architecture_modified_2

好,就聊到这里了,不知道大家有什么想法,欢迎一起留言讨论。

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

Read More

第一部分见这里

模式3:根据条件跳转到多个状态,包括自跳转

这是在状态机里最常见的模式,由于是基于条件的跳转,所以可以非常方便的用选择节点和前提的组合来描述,特别值得注意的是,对于自跳转而言,其实就是维持了当前的状态,所以,在构建行为树的时候,我们不需要特别考虑自跳转的转换。如下图所描述了,我们先用序列节点来保证跳转的上下文(可以参考模式2中的相关内容),这里用到的另一个技巧是,我们会在状态a结束的时候,在黑板中记录其结束的原因,以供后续的选择节点来选择。另外,我们在第二层选择节点第一次用到了非优先级的选择节点,和带优先级的选择节点不同,它每次都会从上一次所能运行的节点来运行,而不是每次都从头开始选择。

Fsm2BtPattern3

当然,和模式2类似的是,我们也可以不用序列节点,而是单纯的用选择节点,这样的话,作为默认状态的状态a就需要处在选择节点的最后一个,因为仅当所有跳转条件都不满足的时候,我们才会维持在当前的状态。如上图的下面那颗行为树那样。请仔细查看,我在前三个节点对于前提的定义,除了本身的跳转条件外,还加上了一个额外的条件,InAXState,它保证了仅在上一次运行的是A状态或自身的时候,我们才会运行当前的节点,这样就保证了和原本状态机描述是一致的。

模式4:循环跳转

在状态机中存在这样一种模式,在状态a中,根据某条件1,会跳转到状态b中,而在状态b的时候,又会根据某条件2,跳转到状态a,产生了这样一个跳转的“环”。显而易见的是,行为树是一种树形结构,而带环的状态机是一种图的结构,所以对于这种情况,我想了下,觉得需要引入一种新的选择节点,我称之为动态优先级选择节点(Dynamic Priority Selector),这种选择节点的工作原理是,永远把当前运行的节点作为最低优先级的节点来处理。如下图

Fsm2BtPattern4

当我们在节点a的时候,我们会先判断b的前提,当b的前提满足的时候,我们会运行节点b,下一帧再进来的时候,由于现在运行的是节点b,那它就是最低优先级的,所以,我们会先判断节点a的前提,满足的话,就运行节点a,不满足则继续运行节点b,依次类推。下面是我写的相关代码,可以给大家参考。

 1: void DynamicPrioritySelector::Test(const Blackboard& in) const
 2: {
 3:     bool hasRunningChild = IsValid(m_iCurrentRunningChildIndex);
 4:     int nextRunningChild = -1;
 5:     for(int i = 0; i < m_ChildNodes.Count(); ++i)
 6:     {
 7:         if(hasRunningChild &&
 8:            m_iCurrentRunningChildIndex == i)
 9:         {
 10:             continue;
 11:         }
 12:         else
 13:         {
 14:             if(m_ChildNodes[i]->Test(in))
 15:             {
 16:                 nextRunningChild = i;
 17:                 break;
 18:             }
 19:         }
 20:     }
 21:     if(IsValid(nextRunningChild))
 22:     {
 23:         m_iCurrentRunningChildIndex = nextRunningChild;
 24:     }
 25:     else
 26:     {
 27:         //最后测试当前运行的子节点
 28:         if(hasRunningChild)
 29:         {
 30:             if(!m_ChildNodes[m_iCurrentRunningChildIndex]->Test(in))
 31:             {
 32:                 m_iCurrentRunningChildIndex = -1;
 33:             }
 34:         }
 35:     }
 36:     return IsValid(m_iCurrentRunningChildIndex);
 37: }

总结

从上面4种模式的转化方式中,我们好像会有种感觉,用行为树的表达好像并没有状态机的表述清晰,显的比较复杂,罗嗦。这主要是因为我们用行为树对状态机做了直接的转化,并想要尽力的去维持状态机的语义的缘故。其实,在AI设计过程中,一般来说,我们并不是先有状态机,再去转化成行为树的,当我们选择用行为树的时候,我们就要充分的理解控制节点,前提,节点等概念,并试着用行为树的逻辑方式去思考和设计。

不过,有时,我们也许想用行为树改造一个已有的状态机系统,那这时就可以用我上面提到的这些模式来尝试着去转换,当然在实际转换的过程中,我的建议是,先理清并列出每一个状态跳转的条件,查看哪些是带上下文的跳转,哪些是不带上下文的跳转,哪些是单纯的序列跳转(比如,从状态A,到状态B,到状态C,类似这样的单线跳转,常见于流程控制中),哪些跳转是可以合并的等等,然后再用行为树的控制节点,把这些状态都串联起来,当发现有些跳转用已有的控制节点不能很好的描述的时候,可以像我上面那样,添加新的控制节点。

这四种模式,是我现在能想到的,可能不全,如果大家有问题,可以在后面留言,有指教的也欢迎一起讨论。

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

Read More

选这次主题,要感谢一位网友的来信,他询问了一些如何将有限状态机转成行为树的问题,当时,我回信给了一些建议,但后来我仔细想了一下,觉得可能说得还不够全面,所以我就想通过这篇文章,来整理出一些比较典型的转化“模板”,给有这方面疑惑的朋友一些帮助,如果有朋友有一些自己的见解的,可以在后面留言,我们一起讨论。

有限状态机维护了一张图,图的节点是一个个的状态,节点和节点的连线是状态间根据一定的规则做的状态转换,每一个状态内的逻辑都可以简要描述为:

如果满足条件1,则跳转到状态1
如果满足条件2,则跳转到状态2
...
否则,不做跳转,维持当前状态

稍作整理的话,我们可以对状态机的几种跳转的情况一一描述出来,然后看看如果将这些情况用行为树来表示的话,可以怎么做。这就是我前面说的“转化模板”,当然我不能保证我下面列出的是状态机的所有可能情况,如果大家在实践中发现还有其他的情况,欢迎留言,我随时更新。

在这之前,我们可以先回忆一些关于行为树的一些概念(可以参考12

  • 控制节点:选择节点,序列节点,并行节点,等等
  • 行为节点:两种运行状态,“运行中”和“完成”
  • 前提条件

模式1:当处在任何状态中,一旦某条件满足,即跳转到某个特定的状态。

比如,在状态机中的一些错误处理,经常会用到上面的这种模式,当状态在运行过程中,发生了某些异常,那一般,我们会把状态机跳转到某个异常状态。这种情况,我们可以用到带优先级的选择节点(Priority Selector)方式,如下图,可以看到,我们把状态c作为行为树里的行为节点,跳转条件(Condition1)作为这个节点的前提(Precondition)。

Fsm2BtPattern1

再用上面举到的错误处理的例子,在状态机中,我们一般会这样写:

 1: STATE A::Update()
 2: {
 3:     ...
 4:     if(error)
 5:     {
 6:         return TO_ERROR_STATE();
 7:     }
 8:     ...
 9:     return UNCHANGED_STATE();
 10: }

转换到行为树中,我们会通过外部的黑板来做通信(可以参考这里),在行为节点a中,我们会这样写

 1: EXECUTE_STATE A::Execute(BlackBoard& out)
 2: {
 3:     ...
 4:     if(error)
 5:     {
 6:         out.error = error;
 7:         return EXECUTE_STATE_FINISH;
 8:     }
 9:     ...
 10:     return EXECUTE_STATE_RUNNING;
 11: }

然后对于节点c的前提里,我们来读取黑板里的error值

 1: bool Condition1::IsTrue(const BlackBoard& in) const
 2: {
 3:     return in.error == true;
 4: }

模式2:对于同一个跳转条件,处在不同的状态会有不同的跳转

比如,我们有两个状态,a和b,他们都对同一个跳转条件作出响应,但和模式1不同的是,a对跳转到状态c,而b会跳转到状态d,换句话说,这是一种带有上下文的状态跳转方式。对于这种情况,可以用到序列节点的相关特性,如下图

Fsm2BtPattern2

序列节点中,当前一个节点运行完成后,会执行下一个节点,利用此特性,在上图中可以看到,我们在a中,当满足条件Condition1的时候,则返回“完成”,那行为树就会自动跳转到c节点中,参考代码如下:

 1: EXECUTE_STATE A::Execute(BlackBoard& out)
 2: {
 3:     ...
 4:     if(condition1 == true)
 5:     {
 6:         return EXECUTE_STATE_FINISH;
 7:     }
 8:     ...
 9:     return EXECUTE_STATE_RUNNING;
 10: }

对于这种模式的另一种转化,可以不用序列节点,还是用到选择和前提的组合,但我们在前提中加上一个当前状态的附加条件,如下图

Fsm2BtPattern2 (1)

在第二层的前提中,我们可以这样写

 1: bool InACState::IsTrue(const BlackBoard& in)
 2: {
 3:     return in.current_running_node = A::GetID() ||
 4:            in.current_running_node = C::GetID();
 5: }
 6:
 7: bool InBDState::IsTrue(const BlackBoard& in)
 8: {
 9:     return in.current_running_node = B::GetID() ||
 10:            in.current_running_node = D::GetID();
 11: }

这样对于c的前提就是Condition1和InACState的“与”(回想一下前提的相关内容)。由于我们保留了上下文的信息,所以通过对于前提的组合,我们就转化了这种模式的状态机。

(待续…)

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

Read More

LOD(Level Of Detail)是3D渲染中用到的概念,按照wikipedia上的翻译,可以译为“细节层次”,它是一种根据与观察点的距离,来减低物体或者模型的复杂度来提升渲染效率的优化技术,因为显而易见的是,当一个物体离我们很远的时候,我们不需要用很复杂的多边形来绘制,只要用一个粗略模型或者低精度的贴图即可,所以在3D渲染中,这是一个很常见的优化技术。

对于AI来说,当一个AI对象离我们很远的时候,其实,它做出什么样的决策,做出什么样的行为,我们并不能“感觉的”到,虽然它的行为可能会对游戏世界有影响,但玩家一般只会专注于离自己比较近的AI行为,所以我们在AI的优化中,也可以采用这种“LOD”的技术,来提升AI部分的运行效率。

我在玩真三国无双的时候,对此非常有感触,虽然我并不知道他是否在AI层做了LOD,但类似于这种大场景,超多NPC的游戏,AI层的LOD的优化技术就非常适合。同样的NPC,当他离玩家不同的距离的时候,我们就可以赋予它不同的AI行为,如下表所示:

  1. 近:攻击,防御,追踪,掩护,包围,等待,...
  2. 中:追踪,包围,等待,...
  3. 远:等待,...
一般来说,AI候选的行为越多,它决策所花费的时间也越多,根据这样的假设,我们就可以通过限制AI行为的方式,来起到提升效率的作用。上面说的是一种LOD的方式,还有一种实现方式是减少AI的决策频率,这也是我以前讨论过的AI中的懒惰问题,比如如下表:
 
  1. 近:攻击,防御,追踪,掩护,包围,等待,...(0.1秒决策一次)
  2. 中:攻击,防御,追踪,掩护,包围,等待,...(1秒决策一次)
  3. 远:攻击,防御,追踪,掩护,包围,等待,...(5秒决策一次)

我们可以根据需要来混合使用上面两种方式。说到这里,我想大家脑海中会有一个自己的代码实现框架,我也想了一种,可以用到我经常说的行为树的方式来实现,行为树最好的就是可以任意的添加行为分支,所以可以说,对于第一种的LOD实现是天生支持的,我们只要建立三个行为分支表示近,中,远,并且在这三个分支下,挂上不同的候选行为,这样,我们就建立了一棵带LOD优化功能的行为树,如下图:

 
Lod1
 
对于第二种LOD实现,我们可以创建一种新的控制节点(回忆一下控制节点的概念),可以称之为LazyNode,这是一个一元的节点,它的功能就是维护一个时钟,当时间一到就执行它的子节点。同样的,我们用LazyNode,也建立近,中,远三个行为分支,然后在下面挂上相关的行为子节点,如下图:
 
Lod1 (1)
可以看到,如果我们用行为树,就不需要用什么附加的模块来做LOD优化,而是用行为树强大的扩展能力把这些直接整合进了AI结构中,这种不破坏结构,从架构层面的优化方式,是我相当推崇的。
LOD是一种懒人化的优化方式,无论是概念还是实现都非常简单,当然,所有这些都是以不破坏游戏性为前提的,有时,我们有可能需要远处的AI做一些复杂的决策,比如,在即时战略游戏中,虽然我们AI离我们很远,但它确实需要做一些完整决策,在这种情况下,LOD可能并不是很适用,所以,AI中的一些问题没有一成不变的解决方案,实际情况,实际分析是相当之重要的 :) ,大家对AI优化有什么心得呢,欢迎大家留言讨论。
 
 
————————————————————————
作者:Finney
Blog:AI分享站(http://www.aisharing.com/)
Email:finneytang@gmail.com
本文欢迎转载和引用,请保留本说明并注明出处
————————————————————————
Read More

前置阅读推荐:1 2 3

一直在说AI可以分为决策层(Strategy Layer)和行为层(Behavior Layer),和行为层打交道最多的,就是动画了,说到动画,游戏引擎一般都会提供完整的底层的动画系统,包括如何转换数据,如何做动画Blend等等,但这些一般不属于AI程序员的工作范畴,所以不在这次的讨论范围内,我们这次说到的“动画的选择和控制”是相对比较高层的东西,在我的定义里是属于AI行为层的内容。

现在的游戏中,动画越来越多,也越来越复杂,据说FIFA里就用到了4000到5000个动画,所以如何来驱动和组织这些动画,就成了AI行为层需要考虑的问题。就拿足球游戏为例,比如决策层发出“射门”的请求,那行为层就要从几千个动画中决定播放哪个动画来完成这个请求。直观感觉上,这就是一个if-else的问题,但我们要做的,是要有一个好的AI架构来做这样的一个对于动画的选择和控制。

从上面的描述中,我们可以看到,其实行为层的决策问题,和决策层的决策问题是一样的(这也是为什么他们都属于AI的原因),只是输入和输出的不同。对于决策层而言,输入是游戏世界信息(Game World Info),输出是请求(Request),而对于行为层而言,输入是请求和游戏世界信息,输出是动画和动画的播放控制信息(Animation Info)。如下图所示:

StrategyLayerAndBehaviorLayer

对于单个动画来说,我们可以定义两个附加的信息来选择和控制动画

  • 动画的选择条件信息(Animation Condition)
  • 动画的运行时状态(Animation Running Info))

动画的选择条件信息定义了播放此动画的条件,举个例在来说,在足球游戏中,我们有一个倒挂金钩的动画,要播放这个动画,就需要定义一系列的条件,比如球要在一定的高度,人要背对球门等等,这些条件都是预先定义好的,是选择动画的一个依据。

动画的运行时状态定义了动画在播放时的所有相关信息,诸如当前放到哪一帧等等,我们都知道,动画数据中存的都是用关键帧(key-frame)信息,有时,AI程序员需要在动画的关键帧中添加一些自定义辅助信息,比如,假设我们想在某一帧之后就可以接下一个动画,那就可以在这一帧上打个标记来标识,再比如,我们想在身体某部位触到地面的时候发个声音,那也可以在动画中身体碰到地面的那一帧上打标记。再用前面那个倒挂金钩的例子,我们可能会在触球的那一帧上有个标记,在更新动画运行时状态的时候,我们就可以知道在这一帧,要把球踢出去了。所以,这些信息,都是需要被监控的,它会影响到游戏方方面面,不仅仅是给行为层来使用。

下面是示意图,可以看到动画运行时状态是可以在多动画间共享的,因为一般来说,同一时刻只会有一个动画在播放,如果会有多个动画的Blend,比如上下身分开的动画系统,可以仅关心需要关心的那个主要动画的运行状态。所以动画运行时状态也可以称为“当前动画运行时状态”。

AnimationAtomStructure

有了动画,有了动画选择的条件后,我们会发现,这和行为树(Behavior Tree)的结构很像,如果我们把动画看成行为树的节点(Node),把动画选择条件看成节点的前提(Precondition),那我们就可以用行为树来搭建这样一个“动画选择树”。用行为树还有一个好处是,由于控制节点的存在,所以对于一个请求,我们可以用序列节点,作出序列动画的能力,举个例子来说,我们有一个摔倒(Falling Down)的动画,然后后续想接不同的起身(Getup)动画来丰富行为,那用行为树的话,就可以很轻松的做到这点,看下图,我们用了一个序列节点和一个选择节点的组合。

SeqAnimation

对于动画运行信息呢,就比较自由,可以放在行为树中,也可以单独的做一个模块来更新。如果选择放在行为树中的话,可以在根节点使用并行控制节点(而不是一般的选择控制节点),然后左子树是更新动画运行信息,右子树是动画选择树,这样在更新的时候,就会又执行左子树(更新运行时状态),又执行右子树(根据新的请求选择动画),将动画运行时信息放在前面更新的原因是,我们在选择动画时,可能需要参考当前的动画运行状态,就像我们前面所说的那个接下一个动画的问题那样。所以一般推荐先更新动画信息,再选择新的动画。

如果想用行为树来做动画的选择和控制,最需要考虑的就是“叶节点的粒度问题”,如果叶节点是单个动画的话,对于动画量不大的游戏,还可以接受,但像我前面说的类似FIFA的这种有几千个动画的游戏,会导致行为树过于庞大,不好维护,所以,有时我们需要控制叶节点的粒度,比如,将叶节点针对一组动画(相关性很大的一些动画)等。

好,这次就聊这么多,如果大家有什么想法,可以直接留言在下面,我都会回复的 :)

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

Read More

我们在学习程序的时候,都会提到一些逻辑计算方面的事情,像与(and),或(or),非(not)等,在编程语言层面也提供了相关的符号来表述逻辑的计算。我们都知道,对于AI来说,逻辑是非常重要的,一些简单的AI系统,就是由if-else搭起来的一个庞大的逻辑网,里面包含了各种预设好的可能性,最后得到一个决策结果,这样的系统还有一个名字,叫基于规则的AI系统(Rule based AI System),当然随着游戏逻辑越来越复杂,这样简单的靠分支的系统已经不能满足要求了,所以出现了各种AI架构,像有限状态机(FSM),行为树(Behavior Tree),计划器(Planner)等等。但不管架构如何变化,我们在AI中还是充斥着各种逻辑的计算。

那为什么我们要用类来表示逻辑计算呢?这就要牵扯到我们一直在聊的行为树的问题了,我们知道行为树在每个节点上都需要一个称之“前提”(Precondition)的部分,用来帮助我们来决定此节点是否能被执行,所以这个“前提”就会包含一个逻辑表达式,要么返回False,要么返回True,对于不同的节点来说,它的“前提”基本上都不会相同,那自然的,我们就会从程序设计的角度来思考,如何去实现它。当然,方法有很多,不过如果从以下两个方面来考量的话,可以考虑用类的方式来做。

  1. 模块化(目的复用逻辑项)
  2. 为行为树的编辑器做准备(目的可视化的逻辑表达)

说到类的实现方式之前,我们可以先来看一下,一般代码中的逻辑表示,以c/c++为例:

 1: bool a = IsAOk();
 2: bool b = IsBOk();
 3: bool c = IsCOk();
 4: if(a && (b || c))
 5:     //do sth
 6: else
 7:     //do other things

这样的方式很直接,很简单,作为“前提”的实现也是很好的,比如我们可以提供这样一个类,然后让用户继承这个类,自己在isTrue的方法里写需要的逻辑计算。

 1: class Precondition
 2: {
 3: public:
 4:     virutal bool isTrue() const = 0;
 5: };

但考虑到我上面的两点需求,这样的实现就显得不够模块化,因为我们并不能复用上面的任何一个逻辑项,而且更重要的是,我们也没有办法在编辑器中“看到”它的逻辑表达。基于这样的原因,我们再来看看用如何用类来表示逻辑计算,还是用上面这个纯虚类,我们定义几个称之为类逻辑操作符的新类

  • PreconditionAND
  • PreconditionOR
  • PreconditionNOT
  • PreconditionXOR

这些类继承自上面的Precondition,并重写了isTrue方法,我们用PreconditionAND举例:

 1: class PreconditionAND : public Precondition
 2: {
 3: public:
 4:     PreconditionAND(Precondition* lhs, Precondition* rhs)
 5:         : m_Lhs(lhs),m_Rhs(rhs)
 6:     {}
 7:     virtual bool isTrue() const
 8:     {
 9:         return m_Lhs->isTrue() && m_Rhs->isTrue();
 10:     }
 11: protected:
 12:     Precondition* m_Lhs;
 13:     Precondition* m_Rhs;
 14: };

可以看到,这个类很简单,它接受两个Precondition的实例,然后在isTrue里再调用这两个实例的isTrue方法,并返回它们的And结果。对于其余的逻辑符号类,我们也用同样的方式来定义,值得注意的是,对于PreconditionNOT来说,它只接受一个Precondition的实例,因为Not是一元的操作符。

有了逻辑操作符,我们就可以复用Precondition的逻辑项了,比如

 1: Precondition* precon = new PreconditionNOT(
 2:                             new PreconditionAND(
 3:                                 new PreconditionA(), new PreconditionB()
 4:                             )
 5:                         );
 6: //ret means !(A && B)
 7: bool ret = precon->isTrue();

我们用类逻辑操作符链接了逻辑项,使之达到了复用和模块化的效果。对于这种方式,我们需要不断的整理和提炼,并预先定义一些我经常用到的一些单个的逻辑项,就像上面所示的A,B一样,然后通过类逻辑操作符,组合成我们需要的逻辑计算结果。对于这些单个的逻辑项,因为需要被复用的关系,所以要尽量保持内部的逻辑是简单的。

就我们想要的行为树编辑器来说,我们可以将这些预先定义好的单个逻辑项导出到编辑器,然后在编辑器里,我们通过类逻辑操作符,来组成出我们需要“前提”,这样,我们就可以在编辑器里直观的“看到”逻辑的表达式,也方便我们检查逻辑的正确性。

当然,这种方式比起第一种直接在代码中书写逻辑的方式,相对复杂,在开发过程中,team对于这种理念的坚持程度也有待验证(因为需要不断的优化逻辑表达式),但对于一种用类实现逻辑的方式,我觉得还是有必要在这里介绍一下。我在实践中,两种方式都用到过,各有利弊,对于极度追求模块化的设计理念,并且想做行为树的可视化编辑器的朋友来说,用类的方式还是非常值得一试的。

好,今天就聊到这里,希望对大家有所帮助。

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

Read More