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):





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.

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.

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.

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').

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.

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.

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.