Public Group

# 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.

## 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 on other sites
Quote:
 Original post by KalnosI'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 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 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 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 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 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.

1. 1
2. 2
Rutin
19
3. 3
khawk
15
4. 4
5. 5
A4L
13

• 13
• 26
• 10
• 11
• 44
• ### Forum Statistics

• Total Topics
633743
• Total Posts
3013644
×