Jump to content
  • Advertisement
Sign in to follow this  
Kalnos

Gamestate stack question

This topic is 3089 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

Hey guys, I'm planning out a basic gamestate system that uses classes instead of an enum and I've come to something standard like this (I haven't coded everything yet, so everything isn't here):



class GameState //abstract class gamestates are derived from
{
public:
virtual function() = 0;
virtual run() = 0;
//etc

};






class GameState;

class GameStateManager
{
void push_state();
void pop_state();
etc

private:
vector<GameState*> stateList;
};




My question then is, how would you go about letting individual states communicate with each other? For example, play is pressed in the menu and then a playing state should be pushed onto the vector (stack). Possible solutions I can think of are making the Manager a singleton(I don't really want to do that) or adding a return type on the run function that will then notify the manager as to what should be pushed / popped.

I'm really just looking for opinions here. Are there any downsides to just returning an int type / gamestate from the run function and then letting the manager run them through a switch?

Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Kalnos
I'm really just looking for opinions here. Are there any downsides to just returning an int type / gamestate from the run function and then letting the manager run them through a switch?
AI FSMs tend to be large and developed iteratively, making the maintenance of parallel switch statements more time-consuming and risky than an OO approach. Additionally, they tend to be very regular in behavior and in their interactions, making the OO approach simple. In contrast, "game state" FSMs are small and badly behaved, seldom changed, and seldom touched. A small handful of enums and bools will serve you far better in this area than trying to normalize things into a stiff little OO thing.

Share this post


Link to post
Share on other sites
Not disagreeing with Sneftel, but I'll go ahead and offer an alternate point of view here.

An OO, data-driven game state system *can* be useful, IMO. In modern PC games, menu systems can be somewhat involved due to the various options that are often made available to support different user preferences and hardware configurations. Depending on the complexity of the game, you can end up with a lot of menus and (assuming each menu is a separate state) a lot of states as well. IMO, hard-coding all of these states and their contents can be inconvenient and excessively rigid (especially if you're coding in a language like C++).

The way I've done it is to use a generic, data-driven state system where the states and their interrelationships are defined in text files. There's more up-front work involved coding-wise, but the advantage is that you can then design and modify the state/menu system more easily.

Now, if your requirements are simple (e.g. a couple of menu states and the game state), a simple enum-based approach is probably the way to go. But for more involved projects, I think an object-oriented game-state system can have some advantages.

Share this post


Link to post
Share on other sites
Thanks for the replies.

Jyk, I can see where your method would be useful, but I don't need anything *that* complex, though it's interesting to think about. I've used enums before and they work fine (which probably means I should just keep using them); I was just trying to plan out an OO approach to see how it would work, and I can't decide if I like it or not.

I just can't seem to think of a way to let the gamestates notify the manager to push or pop a state that isn't a singleton or that doesn't seem overly complex (which is probably what Snef meant by 'stiff OO').

Share this post


Link to post
Share on other sites
Quote:
Jyk, I can see where your method would be useful, but I don't need anything *that* complex, though it's interesting to think about. I've used enums before and they work fine (which probably means I should just keep using them); I was just trying to plan out an OO approach to see how it would work, and I can't decide if I like it or not.
Yeah, if the advantages that such a system would offer in your particular case aren't immediately obvious, I wouldn't bother with it.

Share this post


Link to post
Share on other sites
In turn I'm not disagreeing with jyk, but I'd hasten to point out that game state systems and menuing systems need not be the same thing. In situations where you have a complicated menu structure, it may make more sense to separate that entirely from the notion of a game state. This allows you to code in the terminology of menus in your menuing system, without trying to figure out what the "cancel" button for your PlayGame state is.

Share this post


Link to post
Share on other sites
Well, this has been enlightening. I think I will continue to use an enum/switch system until the need arises for something else. I just wanted to play around with the idea more than anything I think.

Thanks guys.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!