BOMBERMAN CLONE, GameStates and Mainloop

Hello dear readers, today I will talk about how the gamestates work and is integrated into the game. This will probably be one of the last posts about bomberman as we are soon finishing our course. However If you still want me to write about anything special just leave a message and I see what I can do.  I will also probably make a final post where I upload the finished game so everyone can download and try it out. (However this may take some weeks before the course is finished)

Anyway, lets get right into it, the gamestate itself is a base class for all diffrent type of states, it only has 3 functions wish is all virtual, an destructor, an update and a draw function. In the GameState.h I also stored a enum class that stores the diffrent states that can be used, for bomberman I had for exempel the following:

 
enum GameStates 
{ 
    STATE_NULL, 
    STATE_MENU, 
    STATE_LOCALPLAY, 
    STATE_OPTIONS, 
    STATE_CREDITS, 
    STATE_EXIT, 
}; 

As seen above I had a total of 6 different gamestates. STATE_NULL was used for when it was idling and didn’t have to change state and where STATE_EXIT was used for when exiting the game.

The way I used this was that in the main game loop I only had one update and draw function calls. But instead of calling a specific drawing function it would call on the current states draw function. If the current gamestate would under anytime become something else then STATE_NULL it meant we wanted to switch to another state, I then simple called a function called switchGameState as shown below:

 
void MainGame::switchGameState() 
{ 
    GameStates tr = m_gameState; 
    if (currentState != nullptr) 
    { 
        delete currentState; 
    } 
    switch (tr) 
    { 
    case STATE_MENU: 
        currentState = new Menu(m_system); 
        break; 
    case STATE_LOCALPLAY:
        currentState = new StateLocalPlay(m_system, &m_gameScores);
        break;
    case STATE_OPTIONS:
        currentState = new StateOptionsMenu(m_system);
        break;
    case STATE_CREDITS:
        currentState = new StateCredits(m_system);
        break;
    }
    m_gameState = GameStates::STATE_NULL;
} 

As seen in the code above, whenever I called a function I also input an m_system as a parameter. This m_system parameter was just a simple class of pointers that were in the beginning initialized. The main game for example only created one audio manager and input manager, but then made the system point to them. By doing this I didn’t have to recreate everything when switching states.

I first didn’t do this way and ended up having many different if and switches in the game loop too decide wish code to run. By doing this I made it easier to read but also separated the main loop from the different states.Anyway, this made so If I ever wanted to add more game states I would just have to slightly change switchGameState() and then code the gamestate for itself. (making sure it is inheriting the base class)

Well, this is all for today, if you have any question about the gamestate or how the main loop works just leave a comment and I will maybe make a new post about it. (You can of course also ask about other aspects of the game)

Anyway, this is it for today, as I said earlier I probably won’t be making anymore posts because I have a lot of things to finish and hand in, but sometime after we get our grades for the course I will see if I can upload the game in its whole glory for everyone to check out. Thanks for reading!

About Pontus Berglund

2015 Programming