GameRes游资网

 找回密码
 立即注册

游戏AI游戏研究(二):状态机与行为树

发布者: 小篱 | 发布时间: 2018-12-6 14:09| 评论数: 0

游戏程序
平台类型:  
程序设计: 算法逻辑/智能AI 
编程语言:  
引擎/SDK:  
文/KillerAery

前文回顾:游戏AI研究(一):感知AI

有限状态机

有限状态机的一般实现是将每个状态写成类,再用一个载体(也就是所谓的状态机)管理这些状态的切换。

关于状态机设计模式介绍,可参考我的另一篇博文:https://www.cnblogs.com/KillerAery/p/9680303.html

在以前,游戏AI的实现基本都是有限状态机,
随着游戏的进步,游戏AI的复杂性要求越来越高,传统的有限状态机实现很难维护越来越复杂的AI需求。

有限状态机的缺陷:

  • 各个状态类之间互相依赖很严重,耦合度很高。
  • 结构不灵活,可扩展性不高,难以脚本化/可视化。

行为树

1.jpg

(一个武装小队队员的AI行为树示例)


可以看到,行为树由一个个节点组成

  • 结构:树状结构
  • 运行流程:从根节点开始自顶向下搜索(执行),最终执行叶节点对应的行为。

我们规定,每个节点都提供执行节点的函数,返还执行失败/成功结果。

然后根据不同节点的执行,一直往下执行,最终执行到叶节点对应的行为。

节点大概接口如下:

//节点类(基类)
class Node{
private:
  std::vector<Node*> children;    //子节点群
  Node* parent;                   //父节点
public:
  void addChild(Node*);           //添加子节点
  virtual bool excute() = 0;      //执行节点,返还 成功/失败
  //...
};

此外,我们还要把节点主要分为两种类型:

  • 控制节点(非叶节点)
  • 行为节点(叶节点)

控制节点

控制节点是用于控制如何执行子节点。它提供(执行成功/执行失败)两种执行结果。

下面列出一些控制节点的介绍:

1.选择节点(Selector)

按顺序执行多个子节点,若成功执行一个子节点,则不继续执行下一个子节点。

2.png


举例:实现要不攻击,要不防御,要不逃跑。

用一个选择节点,按顺序添加<攻击节点>和<防御节点>和<逃跑节点>作为子节点。

class SelectorNode : public Node{
public:
  virtual bool excute()override{
    for(auto child : children){
        //如果有一个子节点执行成功,则跳出
        if(child->excute() == true){return true;}
    }
    return false;
  }
};

2.顺序节点(Sequence)

按顺序执行多个子节点,若遇到一个子节点不能执行,则不继续执行下一个子节点。

3.png


举例:实现先开门再移动到房子里。
用一个顺序节点,按顺序添加<开门节点>和<移动节点>作为子节点。

class SequenceNode : public Node{
public:
  virtual bool excute()override{
    bool result = false;
    for(auto child : children){
        //如果有一个子节点执行失败,则跳出
        if(child->excute() == false){return result;}
        else {result = true;}
    }
    return false;
  }
};

3.并行节点(Parallel)

同时执行多个节点。

4.png


举例:一边说话和一边走路。

用一个并行节点,添加<说话节点>和<走路节点>作为子节点。

class ParallelNode : public Node{
public:
  virtual bool excute()override{
    bool result = false;
    //执行所有子节点
    for(auto child : children){
        if(child->excute() == true){result = true;}
    }
    return result;
  }
};

常用的控制节点一般是<并行节点><选择节点><并行节点>。当然还有其他更多控制节点种类(不常用):

  • 随机选择节点(随机执行一个子节点)。例如偶尔闲逛,偶尔停下来发呆。
  • 随机顺序节点(随机顺序执行若干个子节点)
  • 次数限制节点(只允许执行若干次)
  • 权值选择节点(执行权值最高的子节点)
  • 等等..

可能到这里,有想到还有个问题:为什么控制节点也需要提供(执行成功/执行失败)两种执行结果。

答:这样做就可以做到决策的复合——控制节点不仅可以控制行为节点,也能控制控制节点。

可以规定:对于控制节点,如果它存在任意一个子节点执行成功,则它执行成功。否则,它执行失败。

行为节点

行为节点是代表行为的叶节点,当被遍历(执行)时则执行该节点代表的行为。它提供(执行成功/执行失败)两种执行结果。

行为节点的类型是比较多的,毕竟一个智能体的行为是多种多样的,而且都得根据自己的智能体模型定制行为节点类型。

这里列举一些行为:站立,射击,移动,跟随,远离,保持距离....

1.行为前提条件

执行行为不会总是一帆风顺的,有成功也总会有失败的结果。

这就是引入前提条件的作用——满足前提条件,才能成功执行行为,返还<执行成功>结果。否则不能执行行为,返还<执行失败>结果。

5.png


但是每个行为的前提总会不同,或有些甚至没有前提(换句话说,前提条件总是能满足)

一个可行的做法是:让行为节点含有bool函数对象(或函数接口)。这样对于不同的逻辑条件,就可以写成不同的bool函数,绑定给相应的行为节点。

    std::function<bool()> condition;    //前提条件

另一种更复杂的做法则是把前提条件抽象分离成新的节点类型,称之为条件节点。将其作为叶节点混入行为树,辅助控制节点决策。它相当模块化,脚本性能更高。但是由于逻辑条件的种类繁多,其编写各种条件节点类需要花费一定时间。

2.行为状态

一些行为是可以瞬间执行完的(例如转身?),

而另外一些动作则是执行持续一段时间才能完成的(例如攻击从启动攻击行为到攻击结算要1秒左右的时间)

为了不让每帧重复启动执行一个持续行为,

我们给所有行为节点引入一个成员变量来标志,我们称为<行为状态>。

行为状态一般有2种:

  • ready(可执行)
  • running(正在执行)

这样提供执行结果前就要考虑这些行为状态了:

  • 不满足前提,返还执行失败结果
  • 满足前提,行为状态running时,返还执行成功结果。
  • 满足前提,行为状态ready时,执行行为,返还执行成功结果。

另外可根据自己实际项目需求来定制状态(例如加入fail状态)。

行为节点示例实现
//行为节点类(基类)
class BehaviorNode : public Node{
protected:
    std::function<bool()> condition;    //前提条件
    BehaviorState state;                //行为状态
public:
    virtual bool excute() = 0;          //执行节点
};
//举例:移动行为节点
class Move : public BehaviorNode{
public:
    virtual bool excute()override{
        if(condition() == false)return false;
        //如果状态是完成,则启动行为
        if(state == BehaviorState::finish){
            ...//让智能体启动移动行为
        }
        return true;
    }
};

总结

到这里,我们可以看到行为树的本质:

  • 把所有行为(走,跑,打,站等等)分离出来作为各种<行为节点>,
  • 然后以不同的<控制节点>决策(同时执行,顺序执行等)将这些行为复合在一起,组合成一套复杂的AI。

相比较传统的有限状态机:

  • 易脚本化/可视化的决策逻辑
  • 逻辑和实现的低耦合,可复用的节点
  • 可以迅速而便捷的组织较复杂的行为决策

这里并不是说有限状态机一无所用:

  • 状态机可以搭配行为树:状态机负责智能体的身体状态,行为树则负责智能体的智能决策。这样在行为树做决策前,得考虑状态机的状态。
  • 状态机适用于简单的AI:对于区区需两三个状态的智能,状态机解决绰绰有余。实际上,状态机运行效率略高于行为树。在《杀手:赦免》的人群系统里,人群的状态机AI只有简单的3种状态,由于人群的智能体数量较多,若采取行为树AI,则会大大影响性能。

简言之:行为树是适合解决复杂AI的解决方案。

对于Unity用户,Unity商店现在已经有一个比较完善的行为树设计(Behavior Designer)插件可供购买使用。

额外的细节/优化

可让根节点记录该AI要操控的智能体引用(指针),每次进行决策,传给子节点当前要操控的智能体引用。这样就可以使AI行为树容易改变寄主。

(例如1个丧尸死了被释放内存了,寄生它的AI行为树不必释放并标记为可用。一旦产生新的丧尸,就可以给这个行为树根节点更换新的寄主,标记再改回来)

控制节点里有一种次数限制节点,意思就是执行过N次行为后,就不再执行。得益于树状结构,可以给次数限制节点搞执行N次后,解开与父节点的连接,释放自己以及自己的子节点。这是种'失忆'的小技巧。

共享节点型行为树是可供多个智能体共用的一种行为树,是节省内存的一种设计:http://www.aisharing.com/archives/563

博客地址:https://www.cnblogs.com/KillerAery/p/10007887.html

最新评论

  • App Store力荐,Supercell刚上线的第5款游
  • 游戏开发中最常见的5个错误
  • 王信文:穿越那座绝望山谷
  • 丁磊打碟了,丁磊养猪了 然而,丁磊没有人
  • 请不要让Roguelike成为独立游戏的遮羞布
  • IGDA:2018,游戏最好的时代,也是最糟糕的

小黑屋|稿件投递|广告合作|关于本站|GameRes游资网 ( 闽ICP备05005107-1 )

GMT+8, 2018-12-19 22:17

快速回复 返回顶部 返回列表