Jump to content
  • Advertisement
Sign in to follow this  
riruilo

When implementing a FSM (statechart), do you add START and END states?

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

Hi guys! Just an implementing question. When implementing a FSM (statechart), do you add START and END states? Which one is correct:
enum STATE {
LOADING,
PLAYING
};
Or:
enum STATE {
START_STATE,
LOADING,
PLAYING,
END_STATE_1
END_STATE_2
};
Thanks for replies.

Share this post


Link to post
Share on other sites
Advertisement
Don't know about being 'correct'.. by who's standards? It would also depend on your particular situation, i.e. what the FSM is representing/controlling, the details of which aren't provided.

Guessing at your situation (a standard game loop, with the FSM in question being one for the entire game state, with loading and playing at least), I would implement something like the following.

I don't see the need for a separate START state, instead the FSM's initial state can just be LOADING. You could say that this is just making LOADING the START state instead, at any rate it's giving it a better name.
The game resources would start being loaded (in a background thread or similar), the FSM would have initial state LOADING, and the game would enter its main loop. A loading screen would then be rendered during the LOADING state. The transition from LOADING to PLAYING would of course be the completion of resource loading.

I suppose if you had an differentiated START state, you could the enclose the triggering of the resource loading in the loop itself.
Make the FSM's initial state START, and enter the main game loop. Have a transition from START to the LOADING state immediately without input, with an transition action that started off the loading of game resources in the background similarly. A loading screen is then displayed while loading as previously.
I guess a benefit of this might be to allow entirely different resources (say, on a map change) to be loaded easily, at least from any code that can transition the FSM; upon making note of what resources need to be loaded, transition to the START state again, which starts the loading in the background and transitions to LOADING. Without this differentiated START state, there would be no easy way to tell when resource loading needs to be restarted, or if it has already been initiated and a loading screen just needs to be rendered in the meantime.

For an exit state, not sure why you'd need more than one. Having (just) one is useful to signal when to stop the main game loop and exit the game. Add transitions from any other state to END (perhaps better named EXITING), that fire whenever the user chooses to close the game. The entry action for the state can just be to drop out of the bottom of the main game loop, i.e., only loop while the state is not EXITING.

IMO that's a lot of talk about small details :), so consider whether you need to complicate things with more states than you might need otherwise.

Share this post


Link to post
Share on other sites
There is no wrong answer, just don't add states for the sake of ading states. Add states if they will be useful. You might not know if they are useful beforehand, so don't necessarily add them straight away.

Share this post


Link to post
Share on other sites
FSM must be started in some point, and execute some code from START to PLAY, so I guess adding a start state is a must. But it is not clear for me if I have to add ending states.

Share this post


Link to post
Share on other sites
The start state is just whatever state you initialize the FSM with. It doesn't have to be called START or anything in particular. Similarly, the end state is just whenever it stops, if it does, depending on the application. Don't think too hard.

Share this post


Link to post
Share on other sites
Quote:
Original post by ricardo_ruiz_lopez
FSM must be started in some point, and execute some code from START to PLAY, so I guess adding a start state is a must. But it is not clear for me if I have to add ending states.
That depends on whether you perform your initialisation entirely before starting the state machine or not. If you do all your initialisation and then start your state machine it can jump right into a useful state like PLAY and not have any initialisation state.
On the other hand, if objects in your program refer to the current state then then they might need to know when your program is still starting, or when it is terminating. In fact I work on a service that goes through a series of about 3 or 4 initialisation states that other parts of the service need to know about.

It really is a case of just using what feels best for your situation.

Share this post


Link to post
Share on other sites
Quote:
Original post by iMalc
Quote:
Original post by ricardo_ruiz_lopez
FSM must be started in some point, and execute some code from START to PLAY, so I guess adding a start state is a must. But it is not clear for me if I have to add ending states.
That depends on whether you perform your initialisation entirely before starting the state machine or not. If you do all your initialisation and then start your state machine it can jump right into a useful state like PLAY and not have any initialisation state.
On the other hand, if objects in your program refer to the current state then then they might need to know when your program is still starting, or when it is terminating. In fact I work on a service that goes through a series of about 3 or 4 initialisation states that other parts of the service need to know about.

It really is a case of just using what feels best for your situation.


OK, it makes sense. Thanks a lot.

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!