Jump to content
  • Advertisement
Sign in to follow this  
Moe

Using a finite state machine to control program flow...

This topic is 4778 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 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).

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

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!