MMORPG战斗系统随笔(三)、AI系统简介

  在设计一款游戏的时候,如果我们是玩家,是希望自己能够操作角色畅玩游戏的。在一款MMORPG游戏中,大部分的实际游戏角色,是需要玩家来操作的,通过在游戏大世界相互完成游戏中的任务等等来体验游戏。在大世界交互场景中,不可避免的会有怪物的存在,也会有NPC,某些策划布置的场景角色怪物等等。同时,在常见的MMORPG游戏中,自动战斗是不可避免的一个功能。这些表面的角色或者功能的背后,其实就是游戏的AI机制。

  说到游戏的AI,和现在比较流行的人工智能有一定的区别。现在的人工智能是全面的AI,包含数据收集,数据分析,行为支配等等操作。而游戏中的AI,属于比较特定的一类,主要是为战斗系统提供的一种机制。现在主流的机制主要分为两类:状态机和行为树。这两类机制,各有其优势,在实际的应用中需要结合实际的需求来采用。我分别在两款游戏中采用了这两种机制,下面也算一个个人的总结吧。

一、状态机

  状态机这种机制,主要是针对战斗状态不太复杂的应用场景。如果我们的角色,在整个游戏过程中,只有少数几个可以列举的状态,比如:站立,寻敌,攻击,行走,受击这样可以枚举出来的几个状态,那么,我们可以考虑用状态机的方式实现这几种状态的相互切换。具体的关于状态机的实现,我这儿就不再赘述了,网上有很多详细的讲解,也有比较多开源的代码,大家可以参考github上的代码类似的实现自己的状态机。我就写几点个人的一些总结吧。

    1、从基础搭建开始

  网上比较多的状态机,都是结合其实际的应用场景,包含一些特定的实现设计在里面,我们在搭建自己的状态机的时候,可以从一个细小的状态开始搭建,先搭建一个节点,然后依据同样的设计,搭建类似的多个节点;

      2、保持节点的简洁性和去耦性

  通常,在最初的节点搭建完后,是不可能一劳永逸的,后续反复的修改,都会对这些节点进行特定的修改和某些特定规则的设计。

  举个列子,射击这样一个状态节点,A英雄的设计是单发,B英雄是连续10发,那么如何保证对这两个英雄的同一个射击状态的兼容?一种设计方式,是将当前的英雄作为一个参数进行传递,那么在执行的时候,就读取当前传入参数的英雄的具体配置,进行相关的射击动作。把射击相关的逻辑封装在该英雄对应的攻击执行器中,那么其具体执行的射击单发还是射击10发,就可以作为一个循环执行,单发循环一次,10发循环10次。

  以前我的设计实现思路,是针对单一的英雄,特定重载实现其对应的射击节点,这样也算一种解决方法,只是这样的设计有一个弊端,就是随着英雄类型的增多,其对应的特定实现会不断的扩大,相应的重载实现的版本会增多。如果设计思路和文本清晰,那还可以维护,如果设计思路不清晰,那么就会带来维护的消耗。

       3、做好节点的剥离,避免节点耦合太多

  通常状态机是用在比较简易的游戏类型中,角色本身的状态类型不会太多,那么对应的状态节点应该避免相互之间的耦合和功能交叉,状态的切换可以走相同的属性设置来实现交互。如果随着设计的变化,状态实现越来越多,可以考虑用行为树来实现,避免相互之间的耦合太多。

 

二、行为树

  在RPG游戏中,行为树是用的比较多的一种AI机制。就其本质而言,行为树是状态机的一种更高封装的实现。我个人的理解,行为树就是将特定的行为节点进行封装,做成叶子节点,这样可以实现任意节点的拼接。想象一下,如果我们把每个特定的状态机进一步的封装,做成一片片叶子,这样我们在搭建树的时候,就可以收集特定的叶子,来搭建特定的树,最后得到特定功能的行为树,这就是我对行为树的一个简易理解:D 如果用更为规范的说法,那么这些叶子节点,就是行为树中的行为节点,行为树的行为节点的执行结果,可以用枚举的方式列出:

RunningStatus = 
{
      INVALID   =  0,  
      SUCCESS  = 1,   --执行成功
      FAILURE   =  2,  --执行失败
      RUNNING  = 3,  --执行中
}

  一棵树的搭建,不能只有叶子,还需要有枝干,这就需要行为树中的一些特定的节点来搭建这棵树,这就是行为树中的控制节点(Control Node)的作用。注意一点,行为节点是和游戏实际关联的,在行为节点中,我们会去具体的定义如何攻击(shoot/attack),寻路(patrol),闲置(idle)等,但是在控制节点中,其具体运行的逻辑是和实际游戏数据没有关联的,其只需要负责基本的控制逻辑即可 。通过控制节点,我们可以清晰的知道整个行为树的执行逻辑,这就是行为树的一大优势:执行逻辑可见。 行为树主要有以下几种控制节点,举例说一下:

  4种Composite节点

   1、Sequence节点: 顺序执行控制节点,其执行的基本逻辑是:对其下面的所有叶子节点,均顺序执行,直到遇到返回为FAILURE的节点。(我对这种节点的理解,就是串联电路的思维,电流顺序走过每个电阻(叶子),如果遇到第一个无法流过的电阻,则返回,否则会一直流过去,直到所有电阻都流过)

     2、Selector节点:选择执行控制节点,其执行的基本逻辑是:对其下面的所有叶子节点,顺序执行,直到遇到第一个返回为SUCCESS/RUNNING执行结果的节点。观察上面的Sequence节点,和Selector节点的区别仅仅在于选中的节点的返回结果的不同处理。在其他地方好像对选择节点进行了分类,可以分为:带优先级的选择节点,不带优先级的选择节点,带权值的选择节点。带优先级,是指在选择那个节点更新的时候,会根据优先级进行比较来选择。不带优先级的时候,一般会设置为每次更新的时候会沿用上一次的更新节点,因为一般更新的时候,会有一段时间持续处于某个节点的状态(目前我用的就是这样的选择节点),而对于带权重的选择节点,一般用来做多样的随机性,比如游戏中的宠物,需要表现一个交互动作,那么可以做多个交互动作,在每次做选择节点的时候,根据权重随机一个节点用来表示交互动作。

     3、Parallel节点:并行执行控制节点,其执行的基本逻辑是:对其下面的所有叶子节点,各自执行一次,如果返回结果不为RUNNING,则分别统计SUCCESS和FAILURE的结果,一般结果会采用“与”和“或”的操作。比如当前Parallel节点的返回条件可以分为 全SUCCESS或者任意一个SUCCESS,全FAILURE或者任意一个FAILURE。在执行完所有叶子节点后,可以对比其执行的SUCCESS和FAILURE节点的个数,和其设置的返回结果对比,如果满足则返回SUCCESS(SUCCESS条件)或者FAIULURE(FAILURE条件),或者返回RUNNING。

     4、Detector节点:检测执行控制节点,其执行的基本逻辑是:对其下面的所有叶子节点,逐个执行,如果返回的不为RUNNING,则检测,如果为SUCCESS,则接着执行,为FAILURE,则执行结束。即遇到第一个返回为FAILURE的节点,就结束执行。

     6种Decorator节点

    1、Invert节点:反转装饰节点,其执行的基本逻辑是:只有一个叶子节点,如果返回为SUCCESS,则返回FAILURE;如果返回为FAILURE,则返回SUCCESS;否则返回RUNNING

    2、Sucees节点:Success装饰节点,其执行的基本逻辑是:只有一个叶子节点,执行后,直接返回SUCCESS

    3、SuccessToRunning节点:根据名字就可以知道,其叶子节点在执行完后,如果返回为SUCCESS,则修改其结果为RUNNING,其他的状态不改变,返回最终执行状态给上一层。

    4、FailureTORunning节点:类似于上一个节点,其叶子节点在执行完后,如果返回为FAILURE,则修改其结果为RUNNING,其他的状态不改变,返回最终执行状态给上一层。

    5、SuppressSuccess节点:suppress的意思是抑制,所以这个节点的功能,就是不准返回SUCCESS的执行结果,如果叶子节点返回为RUNNING则返回RUNNING,其他都返回为FAILURE给上一层

    6、SuppressFailure节点:类似于上一个节点,该节点只会返回RUNNING或者SUCCESS这两种执行结果

    除了常见的Compositor节点和Decorator节点,还有Condition节点,依据前面两种类型节点,不难推出后面的Condition节点的功能,就是在某些条件下才触发某些特定返回结果的一些节点。

    简而言之,行为树就是在三个大类的控制节点:Compositor节点、Decorator节点、Condition节点的搭建下,结合各个行为叶子节点,拼接出一个基本的AI执行机制,举个例子:

 bt_atk

<Root>
     <Selector>
          <Attack>
          <Homing>
      </Selector>
</Root>

  这是一个简单的站在原地攻击的行为树设计,首先执行Selector节点,然后顺序执行其下面的所有叶子节点,首先会执行攻击的叶子节点,如果返回为Success,则继续执行Homing节点。所以其基本的设计思想就是:触发一次攻击检测,如果有攻击对象,则执行攻击,返回SUCCESS,否则返回FAILUER。如果返回FAILURE,则结束这次AI节点的tick,如果返回SUCCESS,则继续执行Homming节点。

  通过构建一颗基本的行为树,我们可以组件一颗更大的树,比如我们再构建一颗巡逻的行为树:

bt_patrol

<Root>
      <Selector>
          <Patrol>
          <Homing>
       </Selector>
</Root>

   通过这两颗基本的行为树,我们可以组建一个更大的行为树:

bt_monster

<Root>
    <Selector>
            <Selector>
                  <Patrol>
                  <Homing>
             </Sequence>
             
              <Selector>
                   <Attack>
                   <Homing>
              </Sequence>
      </Selector>
</Root>

  当然我只是一个引申,更加具体的设计可以根据具体的设计来实现,有时候不只是叶子节点可以复用,某些树也可以整体作为一个叶子复用,这样可以实现设计的复用。

  在行为树中,一般的设计思路,是会构建一个行为树的模版,比如上面的bt_atk,在每个使用该模版的角色进行初始化行为树的时候,是从该模版缓存中取出一份,然后初始化相关的信息得到一份实例,在进行行为树更新的时候,是更新其对应的实例。

  而且为了通用各个树干和叶子节点,都是采用数据封包传递,在数据包中封闭当前角色相关的信息或者黑板信息,这样在每个节点更新的时候,都是从数据封包中获取当前角色相关的信息,从而进行对应的逻辑更新。这样,就避免了一些设计上的将数据封存在action行为节点上的问题,通过封包的传递,可以降低耦合,提高复用性。

  对于行为树的优化,我提一个优化点吧。大部分的行为树在具体的项目中应用都是结合具体的设计来实现的,所以我采用的优化未必适合于其他游戏的优化,但是可以采用一个更新频率的设置来降低行为树的更新频率,这个是可以通用的。我在测试服务器的代码性能的时候发现,当场景中的角色数量比较少的时候,大部分的游戏性能都被场景中的怪占用了,而怪物的更新中对于AI的更新又是一个很大的占用。我采用一种距离配置的方法进行优化,当怪物周边没有玩家的时候,降低怪物的更新频率或者就不执行怪物的AI更新,当怪物进入玩家的视野的时候,采用较高的更新频率,当怪物进入玩家的攻击范围的时候,采用正常的更新频率。通过不同距离检测设置不同的更新频率,可以较好的优化在玩家个数较少时的怪物AI性能。

总结:游戏中两种常见的状态机和行为树都做了一个简单的讲解,当然现在网上比较多相关的资料,如果想深入的学习,可以搜集相关的资料研究,有较多的开源代码也可以参考研究一下。当然我说的都是较为浅显的设计,具体的状态机和行为树节点的设计,其中具体逻辑的编写,是需要结合实际的游戏设计来实现的,这就需要程序和策划具体的商量和实现了。好了,今天AI的简介就说到这儿,下一篇再说说一些优化的总结吧:D

 

posted @ 2017-10-10 15:58 zblade 阅读(...) 评论(...) 编辑 收藏