有限状态机(finity state machine)

       有限状态机简称FSM,FSM就是描述一个过程由有限个独立状态组成,这些状态可以互相迁移,直到最终离开这个过程.游戏就是一个FSM,因为游戏总是由一些状态组成,每个场景就是一个状态,然后游戏的整个过程就是不断在这些场景中切换,来推动游戏的进行.可以说游戏框架不只是FSM,但是FSM绝对是游戏框架的核心.

        前一段时间通过移植一款韩国游戏,我从中抽出了一个FSM框架,是BREW平台上的.虽然现在这个FSM还不是很完善,可是足以拿来学习用了. 下面的类图描述了这个框架的静态结构.

       从上图可以看出,AbstractState类是所有状态类的接口,所有状态只是通过接口类AbstractState访问,AbstractState类隐藏了所有具体状态的细节,对外呈现一致的接口.状态管理类StateManager包含一个本程序中所有状态的数组,和一个当前激活状态的引用,因为在程序生命周期的任何时候都只有一个状态,而通过AEEApplet来的所有请求和事件,都转交给StateManager类,而StateManager类有通过
一致接口将其交给当前状态去处理.通过这样一个框架,有效的减少了具体状态和程序入口主体的耦合性,利于扩展.

        状态转移是怎么样实现的呢?首先有一点就是只有每个具体状态知道当前是否要改变状态,所以当知道要改变的时候,当前状态就将设置一个标志,设置下一个状态的ID,而StateManager类,当每一个刷屏时钟到的时候都要检测当前状态的改变状态标志,然后再改变状态.这样改变状态就是比较简单,但是有些耦合性,就是到处都有AbstractState::ChangeState()被调用.你也可以采取另一种方式来做这件事,就是在这个框架中加一个消息队列,然后每当要改变状态时就发消息,然后StateManager每一帧都在消息队列里抓消息,这样好像比较强大啊,但是你发消息不是还要在具体状态类中发吗,所以说具体类和状态改变之间的耦合在这种情况下是无法避免的.有一种情况是可以避免的,就是实现知道状态转化顺序的时候,这时可以建立一个静态转换表,然后要查表转化来转化状态.要不就是状态是线性的,状态管理类可以做成一个堆栈,进入下一个状态就是压栈,退出一个状态就是出栈,可是这样只适用于线性状态转化.在游戏中线性状态转化的情况很少.

谁要源码可以联系我zhaoxj01@hotmail.com