Sign in to follow this  
Nicholas Kong

An alternative in creating the main menu to overworld transition

Recommended Posts

if(GameState.getState() == "MAINMENU")
{
mouseCursor.collide(menuButtonObjects);
drawAllGameObjects(g2D);
}
 
if(GameState.getState() == "OVERWORLD")
{
updateCharacters();
drawAllCharacters(g2D);
}
 
I am curious what other alternative others can suggest in creating the main menu to overworld transition feature in a 2D game.
 
What I did in my game is add the above code in a game loop in the Game class. This ensure every game objects whether it is a main menu button or characters can all appear in the same graphics context of the Game class
 
Code is written in Java.
 
Is there any other way of doing it or is this as readable and clean code as it gets?
 
 

Share this post


Link to post
Share on other sites

Mine basically goes like this: (pseudocode)

GameState has:
 - abstract Update(timePassed)
 - abstract Draw(screen);
 - abstract HandleEvents(events)

MainMenu IS-A GameState
Options_Root IS-A GameState
Options_AudioSettings IS-A GameState
Options_GraphicSettings IS-A GameState
Exploring IS-A GameState
InGameMenu IS-A GameState
Combat IS-A GameState
NpcDialog IS-A GameState

Most of those GameStates don't actually exist yet, because my game is still in development... So no Combat or NPC Dialog for example is actually working. But the GameState system itself is fully implemented and functional. smile.png

 

Then my main loop goes:

while(game-is-running)
{
    if(we-have-events)
    {
        currentGameState.HandleEvents(events)
    }

    currentGameState.Update(amountOfTimePassed)
    currentGameState.Draw(screen)
}

And I basically have a stack of GameStates in an array. The GameState at the top of the stack is the active one.

So a GameState can push another GameState to the top of the stack, like Options_Root can push Options_AudioSettings to the top of the stack when you click the 'Audio Settings' button. A GameState can also pop itself from the stack, so Options_AudioSettings can pop itself (making Options_Root the top state again) when the 'Done' or 'Cancel' button is pressed.

 

...and there's other assorted features I have in the GameState class as well, but the above gives the overview of my architecture. This is the first game I'm doing this architecture in, so my implementation isn't quite battle-proven yet.

Share this post


Link to post
Share on other sites

Using the stacked state architecture allows for things like letting the map be drawn 'under' the menu windows, etc. It can potentially take up more memory, depending on how you manage resource lifetimes. The other popular alternative is run-and-return-successor, where you have a single active state object; which, when updated, returns a pointer to itself to continue execution, a pointer to a new state object (which it created) in order to change states, or a null pointer to signal that the program should end. This gives tighter control over memory use, but does not allow easy interaction between active states like the stack method does.

Share this post


Link to post
Share on other sites

Mine basically goes like this: (pseudocode)

GameState has:
 - abstract Update(timePassed)
 - abstract Draw(screen);
 - abstract HandleEvents(events)

MainMenu IS-A GameState
Options_Root IS-A GameState
Options_AudioSettings IS-A GameState
Options_GraphicSettings IS-A GameState
Exploring IS-A GameState
InGameMenu IS-A GameState
Combat IS-A GameState
NpcDialog IS-A GameState

Most of those GameStates don't actually exist yet, because my game is still in development... So no Combat or NPC Dialog for example is actually working. But the GameState system itself is fully implemented and functional. smile.png

 

Then my main loop goes:

while(game-is-running)
{
    if(we-have-events)
    {
        currentGameState.HandleEvents(events)
    }

    currentGameState.Update(amountOfTimePassed)
    currentGameState.Draw(screen)
}

And I basically have a stack of GameStates in an array. The GameState at the top of the stack is the active one.

So a GameState can push another GameState to the top of the stack, like Options_Root can push Options_AudioSettings to the top of the stack when you click the 'Audio Settings' button. A GameState can also pop itself from the stack, so Options_AudioSettings can pop itself (making Options_Root the top state again) when the 'Done' or 'Cancel' button is pressed.

 

...and there's other assorted features I have in the GameState class as well, but the above gives the overview of my architecture. This is the first game I'm doing this architecture in, so my implementation isn't quite battle-proven yet.

 

That's interesting, I never thought you can use a stack for GameState. Interesting implementation!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this