【游戏_忍者六道】状态机设计和实践之C++篇

一 状态机原理

图 1  状态分布

1. 蓄水池 是 存储 外部流入的水；
2. 下拉开关 是 当 蓄水池 水 达到一定量时，开关控制 动滑轮 线上的 发电门阀下落，阻止水继续流出；
3. 上拉开关 是 当 蓄水池 水 达到存储足够量时， 开关 控制 动滑轮 上线的 发电门阀 上拉 至 一定高度，让水流出蓄水池；
4. 发电门阀 是 控制 蓄水池 水量的开关；
5. 发电电扇 是 蓄水池 水流出，冲击 电扇进行发电，并存储电量；

所谓状态机是拥有有限个状态，进行无限逻辑的，一旦触发相关事件，符合条件，状态切换到其他状态，执行其他状态的动作，状态分：起始状态，其他一系列状态，终态（结束状态）。起始状态一般是启动状态机进入的第一个状态， 蓄水池未满时，进行蓄水，外部水流入蓄水池，此刻发电门阀是关闭的；如果蓄水池水已满，则打开发电门阀，进行发电。然后，其他状态是  蓄水池 水流出到一定量之后，发电门阀下拉，阻止水流出。此刻，发电装置 没有终态，时刻处在事件触发进行 相应动作执行的逻辑。

图 2   蓄水池发电状态机

二 游戏状态机应用

在游戏开发中，各个状态都是由各种类逻辑实现的，定义一个Base基类，各个状态继承并实现它，基类中一般情况会包括两个虚函数：进入状态（EnterState）和离开状态（LeaveState）。

// 枚举出所有状态
enum  EMyState{
ESTART = 1,
EWAIT,
EEND,
}
struct BaseState{
// 进入状态
virtual void EnterState(EMyState nState ) = 0;
// 离开状态
virtual void LeaveState() = 0;
}

其中还需要一个状态管理器StateManager，实现管理状态接口，每个继承的子类都聚合在此实现状态迁移，耦合度低。

class CStateManager{

public:
void DoChangeState(EMyState nState)
{
...
// 离开 当前状态
pCurrentState->leaveState();
...

switch(nState)
{
case xxx:
pCurrentState = pxxx; // pxxx 是 BaseState 子类
....
}
pCurrentState-> EnterState(nState ) ;
}

private:
BaseState* pCurrentState;
}

游戏开发中，ESTART开始状态是走的数据加载，整个功能的实现，首先需要数据的驱动支持，将数据加载至内存中之后，依赖外部事件触发，然后根据条件，触发相关的事件，切换状态，执行动作，跟状态的顺序无关，取决于各个事件触发的发生顺序，为一个事件而响应的行动不仅取决于事件本身，还取决于机器的内部状态。另外，采取 的行动还会决定并更新机器的状态。这样一来，任何逻辑都可建模成一系列事件/状态组合。
终态一般是在游戏维护或者功能设计时设计好的，游戏维护是在动态修改内存数据，刷新修改脚本，维护包括修复bug，修改某些游戏玩法，某些数据等等。

图3  游戏应用一般状态机机制类图

数据驱动类CDataDriver，为每个状态提供数据支持，该类数据接口，设计尽量要做到简便，不涉及强逻辑，数据操作不需要太过于复杂， 一般涉及到数据获取，设置，更新等，对数据库进行操作，游戏开发中一般使用MySql数据库，采用分布式服务器架构，数据库使用的同一个DataBase。

图 4  简单游戏分布式架构图

当各个客户端进行请求服务器操作，事件触发时，状态机切换，执行动作。

三 总结

状态机在游戏中得到普遍应用，贯穿整个游戏过程，也是游戏开发者第一手知道掌握的设计模式。