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

## 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 {
PLAYING
};

Or:
enum STATE {
START_STATE,
PLAYING,
END_STATE_1
END_STATE_2
};

Thanks for replies.

##### Share on other sites
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.

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.

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 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 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 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 on other sites
Quote:
 Original post by ricardo_ruiz_lopezFSM 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 on other sites
Quote:
Original post by iMalc
Quote:
 Original post by ricardo_ruiz_lopezFSM 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.

1. 1
Rutin
32
2. 2
3. 3
4. 4
5. 5

• 13
• 9
• 9
• 9
• 14
• ### Forum Statistics

• Total Topics
633319
• Total Posts
3011348
• ### Who's Online (See full list)

There are no registered users currently online

×