一个多态性的游戏状态机系统

关注

转载最新推荐文章于 2026-03-06 00:24:06 发布 842 阅读 AI 写同款· GEO 优化 ›

状态机（有限状态机、并发状态机、层次状态机） 2. 可以知道状态from-to，知道是从哪个状态向哪个状态进行切换，可以进行一些前置操作，例如在游戏暂停时重新开始游戏，可以在切换前重置游戏数据。使用状态机，可以避免使用if-else/switch-case进行逻辑的条件判断，导致代码臃肿，难以维护，扩展性差。游戏状态：初始化、开始、暂停、恢复、下一波敌人、3选1技能、失败、胜利、退出游戏等。但是角色的状态，行走、攻击、跳跃等是可以并行的，例如行走并攻击，跳跃并攻击。游戏流程的状态是单一的，从初始化，开始，结束等状态都只会同时存在一个。阅读详情

-潘宏

-2012年12月

-本人水平有限，疏忽错误在所难免，还请各位高手不吝赐教

-email: popyy@netease.com

-weibo.com/panhong101

任何一款游戏产品，都需要在几种界面之间进行转换：logo、trailer、main menu、in-game、settings menu等等，并且会在这些转换之间处理资源问题。对于实现这样的转换，不同的游戏做法有所差异，但基本上会实现一个游戏状态机系统。状态机系统在游戏开发中根深蒂固，以至于该系统应该是游戏引擎不可或缺的一个核心部件。

简单游戏状态机结构

状态机的实现方法有很多。相对简单的有switch-case方法，它通过对游戏状态进行枚举化来进行选择判断。下面的示例代码展示了这一点：

    enum GameState  
    {  
        GAME_STATE_LOGO = 0,  
        GAME_STATE_TRAILER,  
        GAME_STATE_MAIN_MENU,  
        GAME_STATE_INGAME,  
        GAME_STATE_SETTINGS_MENU,  
    };  
      
    void gameCycle( int gameState )  
    {  
        switch( gameState )  
        {  
            case GAME_STATE_LOGO: {...}  
            case GAME_STATE_TRAILER: {...}  
            case GAME_STATE_MAIN_MENU: {...}  
            case GAME_STATE_INGAME: {...}  
            case GAME_STATE_SETTINGS_MENU: {...}  
        }  
    }

这就是一个相当简单的游戏状态机系统，实现起来很直接、简洁。我们在几年前的一个Java引擎中就使用了这样的一个状态机系统（当然，实际代码要比这复杂一些，但结构是这样的）。它表现得很好，能够满足大多数的需求——有好几个商业游戏都使用了这个结构。

可是，在那之后，我们在一个新的C++引擎中，却放弃了这种方法。我们的理由主要有以下几点：

1）该方法不是OO的，我们的引擎是完全OO的。

2）该系统难以维护——所有的状态判断都在gameCycle的switch-case中，我们每增加或者修改一个状态，都需要在enum和gameCycle中增加新的代码，这会导致大量的重新编译。

3）大量的状态逻辑被集中到了switch-case中，导致代码臃肿，难以维护。

4）我们希望把每一个game state逻辑交给一个工程师来编写，这让我们很难做到。

5）“switch-case在OO中是一种‘坏味道’”思潮影响。

考虑到上面的几个原因，我们开始探索新的实现方式，然后，我们就有了一个新的、基于多态性的游戏状态机系统。

状态机基本结构设计

该系统的一个基本结构如下所示：

State manager就是状态管理器（后面简称manager），它聚合并管理多个game state（后面简称state）。注意，Manager只聚合state的基类指针，而state拥有自己的类体系。因此，manager通过多态的方式处理各种state。

该方法实际上实际上是一种state模式（如果对该模式感兴趣，请参考GoF的《设计模式》）。这里StateMgr相当于该模式的Context类，而GameState相当于该模式的State类。

我们的类初步设计如下：

    class GameState  
    {  
    public:  
        virtual ~GameState() {}  
      
        virtual void cycle() = 0;  
        virtual void draw( GraphicsContext& g ) = 0;  
    };  
      
    class StateMgr  
    {  
    public:  
        void addState( GameState* state )  
        {  
            m_states.push_back( state );  
        }  
      
          
        void cycle()  
        {  
            m_curState->cycle();  
        }  
      
        void draw( GraphicsContext& g )  
        {  
            m_curState->draw( g );  
        }  
          
      
    private:  
        std::set< GameState* >        m_states;  
        GameState*              m_curState;  
    };

从代码中可以很容易看出该系统的工作原理。

GameState是state的base class，提供了GameState::cycle和GameState::draw两个方法，分别处逻辑更新和渲染两种工作。该base class是抽象的——只允许完成具体工作的derived class进行实例化。

StateMgr就是manager类，它通过m_states保存所有状态，并对当前状态m_curState进行更新和渲染。StateMgr::addState方法用语增加新的游戏状态。

我们看GameState的具体类的一个例子：

    class GameState_Logo : public GameState  
    {  
    public:  
        GameState_Logo()  
        {  
            Init m_logoImage and m_logoPos...  
        }  
      
        virtual void cycle()  
        {  
            if( m_logoPos is not identical to the screen center )  
            {  
                make m_logoPos close to the screen center...  
            }  
        }  
      
        virtual void draw( GraphicsContext& g )  
        {  
            draw m_logoImage at m_logoPos...  
        }  
      
    private:  
        Image*      m_logoImage;  
        Point2D     m_logoPos;  
    };

上面的类处理进入游戏之后的logo界面。GameState_Logo的ctor初始化logo图片和位置这两个成员。GameState_Logo::cycle将logo的位置逐帧移动到屏幕中心。GameState_Logo::draw则在当前位置画出logo图片。

基本结构就是这样，简单吧！对于游戏不同状态的编写，基本上就是对不同的GameState子类进行实现。一个典型的游戏状态体系如下所示：

这样一个结构设计的好处是什么呢？

1）StateMgr只依赖GameState，和GameState的derived class没有耦合。

2）增加任何一个新的state，都不会影响manager，不会导致额外的重新编译。

3）state模式的全部优势。

4）该方法是完全OO的。

坏处呢？

1）使用了virtual function抽象，增加了间接层开销。

2）增加了大量的类源文件，实现起来不够紧凑。

现在，我们已经有了基本的结构。接下来要做的，就是在这些state之间进行转换。

游戏状态转换设计

游戏中的状态转换都会形成一个树形结构——游戏状态树。下图就是一个典型的游戏状态树：

在游戏中，某个时刻只有当前state在运行。因此，游戏将会在树上进行状态转换。比如我们刚刚进入游戏之后，会进入logo界面，然后转到trailer界面，接下来是主菜单，这几步都是不可逆的。然后玩家可以选择in-game（进入游戏）、credits（制作团队介绍）和settings（设置）这三个状态，并且可以从这三个状态返回主菜单状态。在in-game状态下可以进入pause menu（暂停菜单）并返回。

此外，我们有时候需要在一种状态下显示另一种状态。比如在pause menu中显示暂停选项的时候仍然显示游戏背景（用某种颜色的全屏幕半透明矩形覆盖使其暗化，并且游戏逻辑此时不会更新），如下图所示：

这意味着给state增加一个parent pointer会很方便：

    class GameState  
    {  
      
    // ...as above  
      
    public:  
        void setParent( GameState* state ) { m_parent = state; }  
        GameState* getParent() { return m_parent; }  
    private:  
        GameState*      m_parent;  
    };

这样，我们可以这样实现pause menu的draw方法：

    void GameState_PauseMenu::draw( GraphicsContext& g )  
    {  
        m_parent->draw( g );  
        draw the transparent mask layer...  
        draw pause menu items...  
    }

我们首先渲染parent，对于pause menu状态来说，它的parent就是in-game状态。然后渲染半透明覆盖层。最后渲染pause menu的选项。

此外，parent pointer对于状态的转换也是非常方便的。

为了能够方便地操纵游戏状态在状态树上进行转换，我们扩展manager类：

    class StateMgr  
    {  
      
    // ...as above  
      
    public:  
        enum StateOP  
        {  
            STATE_OP_PUSH = 0,  
            STATE_OP_POP,  
        };  
          
    public:  
        void changeState( GameState* newState, int op )  
        {  
            if( op == STATE_OP_PUSH )  
            {  
                newState->setParent( m_curState );  
                m_curState = newState;  
            }  
            else if( op == STATE_OP_POP )  
            {  
                m_curState = m_curParent->getParent();  
            }  
        }  
    };

我们增加了state操作方法StateMgr::changeState并通过两个操作类型：push和pop，可以很方便地在状态树上移动，如下图所示：

Loading状态

以上设计有一个很大的问题，你能看出来吗？似乎所有的state同时存在，这将导致大量的资源存在于内存中。就算是当进入到main menu状态之后，我们再也无法返回trailer或者logo状态，它们的资源也还驻留在内存里。因此，我们需要把这些状态划分阶段（phase），只让当前一个phase内的所有state留在内存里。当游戏从一个phase转到另一个phase的时候，会释放旧phase资源，然后载入新phase资源。这通过一个叫做GameState_Loading的类来实现。在释放旧资源和载入新资源的过程中，GameState_Loading将接管局面，并显示载入进度界面。我们先把目前的状态树划分phase如下：

整个状态树被划分为4个phase：

logo(logo)

trailer(trailer)

main menu(main menu, credits, settings menu)

in-game(in-game, pause menu)

括号里面的就是该phase所包含的状态，会在一个loading过程中全部驻留内存。每一个phase实际上都形成一个子树，通过一个stack结构和上面的push、pop操作进行转换。我们扩展上面的类如下：

    class GameState  
    {  
    // ...as above  
      
    public:  
        int getStateOP() const { return m_stateOP; }  
        int getNextPhase() const { return m_phaseToLoad; }  
      
    protected:  
        int m_stateOP;  
        int m_phaseToLoad;  
      
    };  
      
    class GameState_Loading : public GameState  
    {  
    public:  
        enum Phase  
        {  
            PHASE_LOGO = 0,  
            PHASE_TRAILER,  
            PHASE_MAIN_MENU,  
            PHASE_INGAME,  
        };  
      
    public:  
        void setNextPhase( int phase ) { m_phaseToLoad = phase; }  
        GameState* getNextState() { return m_nextState; }  
      
        virtual void cycle()  
        {  
            free the old phase...  
            init the new phase frame by frame...  
            save the new states to StateMgr::m_states...  
      
            if( initialization is completed )  
            {  
                m_nextState = default state of the phase  
                m_stateOP = StateMgr::STATE_OP_NEW_STACK;  
            }  
        }  
      
        virtual void draw( GraphicsContext& g )  
        {  
            draw the progress interface...  
        }  
      
    private:  
        int m_phaseToLoad;  
        GameState* m_nextState;  
    };  
      
    class StateMgr  
    {  
      
    // ...as above  
      
    public:  
        enum StateOP  
        {  
            STATE_OP_NONE = -1,  
            STATE_OP_PUSH = 0,  
            STATE_OP_POP,  
            STATE_OP_LOAD,  
            STATE_OP_NEW_STACK,  
        };  
    public:  
        void cycle()  
        {  
            // ...as above  
      
            leaveFrame();  
        }  
      
    private:  
        void leaveFrame()  
        {  
            if( m_curState->getStateOP() != STATE_OP_NONE )  
            {  
                if( m_curState->getStateOP() == STATE_OP_LOAD )  
                {  
                    GameState_Loading* state = new GameState_Loading;  
                    state->setNextPhase( m_curState->getNextPhase() );  
                    m_curState  = state;  
                }  
                else if( m_curState->getStateOP() == STATE_OP_NEW_STACK )  
                {  
                    GameState_Loading* state = static_cast< GameState_Loading*>( m_curState );  
                    changeState( state->getNextState(), STATE_OP_PUSH );  
                    delete state;  
                }  
            }  
        }  
    };

GameState_Loading类处理所有的状态转换工作，这当然包括旧资源释放和新资源初始化，同时绘制loading界面。

StateMgr新增了两个操作方式。StateMgr::STATE_OP_LOAD就是开始建立一个新的phase，也就是从旧phase进入loading状态，然后进行资源载入和新phase中各个state的建立等工作，这些工作在GameState_Loading::cycle中逐帧完成。StateMgr::STATE_OP_NEW_STACK表示从当前loading状态进入到新建立的phase的默认state中。

StateMgr::cycle方法中新增加调用一个新加入的方法StateMgr::leaveFrame。该方法用于在离开当前帧的时候做一些事情。在这里我们主要处理state转换。

GameState增加了两个成员，m_stateOP用于告诉StateMgr是否需要转换到另一个phase，默认值是StateMgr::STATE_OP_NONE——什么也不做。m_phaseToLoad告诉StateMgr它要转换到哪一个phase。这些phase都定义在GameState_Loading中。比如在logo状态中需要转换到trailer状态，我们可以在GameState_Logo::cycle中写：

m_stateOP = StateMgr::STATE_OP_LOAD;

m_phaseToLoad = GameState_Loading::PHASE_TRAILER;

StateMgr::leaveFrame就会建立一个loading状态来进行状态转换。当GameState_Loading::cycle完成了初始化，它就会通过StateMgr::STATE_OP_NEW_STACK让流程进入新的phase的默认state中，正如上面代码所示。

（我在程序中使用了一些伪码来避免陷入过多细节，目的是更好的表达出这个结构的思路。如果你非常需要了解该系统的具体实现，可以和我联系）

改进方向

好了！我们已经完成了该系统的基本框架。读者完全可以根据该框架实现一个自己的游戏状态机，并取得良好的运行效果。但我还是要说，这和真正游戏中使用的工程级别代码比，还差一些！下面我会指出一些设计上的改进和扩展，让该系统更容易在游戏产品中使用。感兴趣的读者可以自行实现。

1 给GameState加上自定义“构造函数”和“析构函数”

如果能给state增加方法：

GameState::onActive

GameState::onUnactive

会让很多事情事半功倍，且可以得到良好的结构和健壮性。在StateMgr::changeState中进行state转换（push和pop）的时候，给即将停止的state调用onUnactive，给即将运行的state调用onActive，可以给这些state一个机会做一些构造和析构工作（比如释放和申请一些小资源，或重新初始化一些数据等等）。我们的代码就强烈地依赖这些方便的小方法。

2 增加state之间的界面过渡

很多游戏在界面过渡之间都使用了一些特效，最常见的就是淡入淡出效果。令人兴奋的是，通过上面的状态机系统增加这样的过渡效果非常方便。比如我们自己设计了一个叫做FullScreenEffect的基类，通过设计不同的子类来完成不同的过渡效果。

提示：在StateMgr里面合成该类的一个实例，然后在StateMgr::cycle和StateMgr::draw中调用FullScreenEffect::cycle和FullScreenEffect::draw方法，并通过一些标志来禁止和启动StateMgr::m_curState的更新和渲染。

3 通过事件分发系统进行状态改变通知

通过我们之前介绍的事件分发系统（http://blog.youkuaiyun.com/popy007/article/details/8242787）来通知系统进行state转换是个很不错的设计思路！

4 把StateMgr写成一个singleton

StateMgr应该只有一个且可以被方便地访问，写成一个singleton吧！（关于singleton模式，可以参考GoF的著作）

5 给loading状态增加一个资源载入管理器

在loading状态中，我们有时候需要画出当前的进度比例，这个比例如何计算出呢？很多游戏用的是假数据——只体现一个递增的效果。但还有些用的是真实数据，对于真实数据来说，该机制和你游戏的资源管理系统有很大关系，这里我提供一个简单思路。

我们将需要载入或申请的所有资源进行分类，比如：

字符串

纹理