Jump to content
  • Advertisement
Sign in to follow this  
MeshGearFox

Switching between menus/modes of operation/game systems?

This topic is 3554 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Let's say I'm making an adventure game. When the program run, I'd need it to do some initialization stuff--load some bitmaps, load up some Lua scripts, whatever--and then open up a standard New/Load/Options/Quit menu. New and Load would then take the player to the main game loop game loop. From the main game loop, then, I'd need to be able to access a save game menu, an inventory display, and... let's say a dialogue tree for conversing with other characters in the game. I'm completely clueless as to how I'd go about switching between these things. The sort of underlying structure I'd need the program to have to handle this. Conceptually speaking, of course. The actual coding itself shouldn't be a problem. Reading over some of the tutorials on the site, I get the impression that I could have a Game class, which would be a composed of objects from other classes representing the various modes of operation I need. The Game class would contain all of the important content and state information about the game, and the other objects contained in the Game class would be ways of handling this data in a more contextual manner. I also get the impression that the basic layout for my gameloop should be something like: 1. Get input. 2. Process input. 3. Redraw screen according to results of step 2. Or maybe something like: 1. Get input. 2. Generate an event based on input. 3. Have the current mode of operation parse this event based on the current context. with the even being stored as a variable in the overarching Game class. Still, horribly confused as to how I'd go about writing a program that's not just "Do one specific thing and then quit."

Share this post


Link to post
Share on other sites
Advertisement
A good starting point may be to look at the XNA Game State Management sample, even if you aren't using XNA or C#. It is a relatively simple state machine that implements what you described.

http://creators.xna.com/en-us/samples/gamestatemanagement

As a state machine, it has the inherent problem of being a little cumbersome to add new states if there have many transitions between states. However, for simple game screen states, they should work fine.

Share this post


Link to post
Share on other sites
Go object oriented, IMO.

But a bare bones ("don't do it this way") would look maybe something like this:

int mode = MODE_MENU;
bool finished = false;

while (!finished)
{
// get user input
...
switch ( mode )
{
case MODE_MENU :
...
if ( user clicked on 'Exit' )
finished = true;
break;
case MODE_GAME :
...
break;
}
// render stuff
...
}

The best way to get a handle on this sort of thing is just to write a simple game. Make tic-tac-toe or pacman or tetris or space-invaders or whatever. Use the DirectX examples, the SFML examples, the SDL examples, etc if you get stuck.

Share this post


Link to post
Share on other sites
I think I'm still not getting something here.

Going with the XNA game state manager for a second, it sounds like the main advantage of storing the screens in a stack is that you can, say, go into state Y from state X, go into state Z from state Y, and then get back to state X by popping Z and Y off of the stack and setting X as the active state again, without having to go back to some intermediate state-chooser in between. Is this right?

Going from the State Pattern wikipedia article, though, what would be the advantage of doing *that* over a procedural approach?

I guess my problem is that I'm still not seeing why going object oriented for this would be all that hugely advantageous.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!