怪物AI的实现方式

1、对于AI的看法——一种条件。
达到这种条件，然后去执行某些行为——执行AI。
目的：让玩家与怪物的交互产生可抗衡性，从而吸引玩家。随着怪物AI的不断提升，玩家也需要更加牛X的装备、技巧来与怪物进行抗衡。

2、实现AI有很多种方式：
    1）状态
我们可以硬性的将怪物AI这种状态分成——PeaceState,FightState,EscapeState。
其中，AI类本身不再包含具体的状态处理逻辑代码，而是把这部分代码拆分到具体的状态类里。AI的状态装换，也需要建立准确的实现机制。
    状态的基础设计
    一个状态包含了一下几个重要的接口（也就是4个类）：
        receive(Cond);
        enter(EntityType);
        leave(EntityType);
        execute(EntityType)
    通过强行划分以上几个状态转换步骤，希望可以将状态转换所需要的各种逻辑规划清楚。
   
    设计要点：
        1）将各个状态的逻辑处理拆分到不同的状态类中；
        2）通过组合不同的状态实现可以形成不同的AI类型。
            例如，怪物AI都有和平状态，但是我们可以实现被动怪和平状态（PeaceStateA）、主动怪和平状态（PeaceStateB） AIController通过配置具体地选择是使用PeaceStateA还是PeaceStateB，与其他不同的状态实现组合，即组合出新的AI类型。
        3）与外部模块的交互状态的装换分为内部转换和外部请求转换。这里的外部/内部是相对于模块内外而言。
            例如，在怪物和平状态运行（excute）期间，若检测到周围有敌人，则自发地转换为战斗状态，这是内部转换；
            在怪物受到技能伤害时，怪物也需要转换为战斗状态，这是外部转换。
        内部转换由状态本身的逻辑代码决定，不存在问题。
        外部转换则需要做一些处理：ALController在某个角度上，是沟通各个状态和怪物之间的桥梁，同时也是AI模块对外部模块的交互界面（interface）。也就是说，技能模块在与AI模块交互时，也会如现有AI结构一样调用诸如WhenBeenHurted的函数。
        4）状态间的交互理论上，状态之间不应该交互。在实际实现时，不应该存在某个状态里的代码调用到其他状态里的代码。凡是涉及到状态之间公用的接口/数据，都置放于ALController里。ALController同时担当状态间交互的桥梁。
        5）提供给脚本足够的控制力。
            在目前的AI结构中，AI模块提供给脚本的AI控制力，涉及到结构方面的，基本都是通过周期行为（Cycle Spring）来实现的。
            周期行为在现有代码中，本质上是一种在优先级上高于普通行为的状态。即一旦存在周期行为，不管怪物目前处于什么状态，一定会先把周期行为执行完。

还有其余的AI设计方法：比如分层有限状态机，行为树，决策树等等，这些我们稍后再聊