【步兵 经验篇】状态机（续）

【步兵 经验篇】状态机（续） by EOS.

前面也提到过状态机，是根据人物的动作状态划分的，通过运用状态机可以降低耦合性。
今天来介绍一下 按功能来划分的状态机，目的还是一样的，仍然是为了低耦合。

---

定义

#pragma once

//先定义一个基类
class BaseState
{
public:
    virtual void onEnter() = 0;//进入
    virtual bool onLoop() = 0;//自循环
    virtual void onExit() = 0;//退出

    bool isRunning;
};

//拾取状态
class PickUpState : public BaseState
{
    //...
};

//战斗状态
class BattleState : public BaseState
{
    //...
};

//采集状态
class CollectState : public BaseState
{
    //...
};

//护送状态
class EscortState : public BaseState
{
    //...
};

完成了这些，就可以把人物驱动起来了，当然前提是人物的基本功能已经实现。
而且这套状态机，并不属于人物自身，应该是并行的。
比如用一个FSMExecutor来管理，而且每种state只需要初始化一次。

---

讲解

我就拿 拾取和战斗 来局里说明吧

//FSMExecutor可以存储runState和一个changeState，并在update中进行处理,
//changeState的时候，调用onEnter，并赋值给runState
//然后在update中当是isRunning为true时候调用onLoop
//if(!onLoop()) onExit();
//这只是一种形式，也可以纯回调，省去update开销。
//（但是我更倾向与前者，更加直观，可读性更强，更有大师的味道=。=）

//拾取状态 -- 物品掉落到地上然后去捡起来
class PickUpState : public BaseState
{
    void onEnter(){};//比如强行中断一些状态，直接去捡东西
    bool onLoop() {//自循环
        //这个就比较有讲究了=。=
        //这里的onLoop不应该是帧回调，而是触发式回调
        //比如 我拾取状态 干的事情就是要拾取，并且只负责拾取，这样来达到低耦合
        //所以 onLoop 要干的事情就是，获取我可以拾取物品的队列，物品可以按距离排下序
        //然后 一个onLoop只负责捡去一个，当拾取完的时候回调自己，这个可以用msg来驱动改变run的状态
        //判断下PickUpState 状态，当寻路设置时候设置为false，拾取完设置为true
        //直到当列表为空时，返回false，来触发onExit。
        //纯回调：就是拾取结束 回调onLoop，在onLoop中判断无可拾取，自行调用onExit
    };
    void onExit() = 0;//比如判断 是自动战斗状态，我就直接切入到战斗状态
};

//战斗状态
class BattleState : public BaseState
{
    bool onLoop() {//直接进入重点了
        //有了前面的铺垫这个应该就会好理解多了。
        //战斗 负责的就是打怪，一只一只的打(当然也可以是多个多个的)。
        //获取怪物列表，寻路过去，开干。
        //寻路和战斗的时候isRunning = false，攻击目标消失了就isRunning = true
        //这个就不能列表为空来中断了，一般是无限刷的=。=
        //所以中断条件 比如掉落物品、切换回拾取，捡完再切战斗，这样一个简单的挂机效果就出来了。
        //再或者 要打N个怪这种任务，然后任务完成了，中断，直接去找NPC 之类的
    };
};

从上面可以看出，在onLoop也就是主要逻辑来处理的时候，基本上是和其他状态没有关系的。
（ps：onLoop用文字说明起来，可能觉得代码量很少，但实际代码可能会很多）
这也就降低耦合，也就是相互之间的关联性，我写拾取的时候可以完全不考虑战斗。

就这些 = 3=

See Again~
之前
真爱无价，欢迎打赏~