How RainbruRPG will handle game states

This design-related post will try to explain how we're implementing RainbruRPG's game states.

As stated in the last announcement, we now have to handle multiple states : main menu and local test. The game states will allow us to have multiple screens, one at a time.

UML diagrams

The class diagrams show the StateManager as a separated class from the GameEngine one. The GameEngine class publicly inherits StateManager and has access to its members/functions.

The sequence diagram shows how we'll call each function :

This is a simplified version, without any event handling or class members.

C++ implementation

The StateManager class

The StateManager is pretty simple.

class StateManager
{
public:
  StateManager(GameEngine*);
  ~StateManager();

  GameState* getCurrentState()const;
  void setCurrentState(GameState*);
 
protected:
  GameEngine* mGameEngine;
  GameState* mCurrentState;
};

I removed all obvious functions implementation, like getter, destructor etc...

StateManager::StateManager(GameEngine* ge):
  mGameEngine(ge),
  mCurrentState(NULL)
{

}

void
StateManager::setCurrentState(GameState* gs)
{
  if (mCurrentState)
    mCurrentState->exit(mGameEngine);

  // Actually changing gamestate
  mCurrentState = gs;
  gs->enter(mGameEngine);
}

The GameEngine class

Here are the changes involved in the GameEngine class :

class GameEngine: public StateManager
{
  GameEngine();
};

And its constructor implementation :

GameEngine::GameEngine(void):
  StateManager(this)
{
  MainMenu mm;
  setCurrentState(&mm);
}

The GameState class

Note that this is just an interface, containing pure virtual functions you'll need to implement in subclasses.

class GameState
{
public:

  GameState(){};
  virtual ~GameState(){};
  
  virtual void enter(GameEngine*)=0;
  virtual void exit(GameEngine*)=0;

};

Conclusion

This is not the current implementation used in RainbruRPG but the state mechanism is here. The implementation already started here.