Using a finite state machine to control program flow...
Author
Hey all,
I have been contemplating about the design of my current project (basically, a game). What I have done in the past is keep track of the overall state of the game using a variable called GameState. The GameState basically keeps track of where the program is at, for example whether it is sitting at the main menu, at the options menu, or actually rendering the game. Is this a safe design? How do professional games handle this sort of thing? (Ie: what to render - the options menu, this menu, that menu, or the actual game).
Using a finite state machine to keep track of which game screen you're on is a good idea. From what I've seen, most (indie/amateur) games take this approach; it's easy to implement and does the job very well.
I am not entirely sure what professional games use because I haven't seen much source. I would imagine they use a similar system.
I am not entirely sure what professional games use because I haven't seen much source. I would imagine they use a similar system.
Author
Well, the only thing that I am seeing wrong with this is when in the menus, it might be somewhat cumbersome to add a new 'state' for each new menu created.
I use state classes. Menus are one type of state class that you can pass different parameters to the constructors that determine the menu items and the state the menu items transition to.
Author
Quote:Original post by SiCrane
I use state classes. Menus are one type of state class that you can pass different parameters to the constructors that determine the menu items and the state the menu items transition to.
Hmm, that sounds like a pretty good idea. I think I will have to do a little more thinking about this...
An interesting article on FSMs: Link.
It's a little technical for such a simple concept as an FSM, but pretty good.
Here is another great article. Though targeted toward AI, it goes into considerable depth and should really help you out.
A simple implementation is to define states as being derived from an abstract state class. Keep track of these in a manager class (via, probably, an std::map or std::vector).
Have functions in the abstract interface for initialization, running, and shutdown of the state. The manager class, obviously, is responsible for calling these functions.
You should be able to figure it out from here.
It's a little technical for such a simple concept as an FSM, but pretty good.
Here is another great article. Though targeted toward AI, it goes into considerable depth and should really help you out.
A simple implementation is to define states as being derived from an abstract state class. Keep track of these in a manager class (via, probably, an std::map or std::vector).
Have functions in the abstract interface for initialization, running, and shutdown of the state. The manager class, obviously, is responsible for calling these functions.
You should be able to figure it out from here.
Author
Right now I have a pretty simple system working. It basically uses a switch statement based on what the value of the GameState is (GameState is just a glorified integer). Depending on what the state is, different methods are called.
Using a switch statement for controlling game logic is evil. It ties all of your states into a single location which is not a happy maintenance prospect.
Basically, every time you add or remove a state from your program you need to alter the switch statement. A more maintainable option might be to use a map that maps your state ids to function pointers/objects. Or go to full blown state objects.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement