Has anyone ever implemented a state machine where the transitions were determined based on a state transition table? I am trying to avoid using a series of "if" statements to check for transitions. I have seen state machines in table form (on paper), where each row is the current state, each column are the possible destination states, and what''s in the cell is the condition that would cause the state change. It seems simple enough when you think of a few examples. If the player''s character is standing facing left (SL state) and the player is pressing the "right" control (button, key, whatever), the state machine transitions to standing right (SR). In the SR state, if the player is pressing the "right" control, the state machine transitions to running right (RR). Where it starts to get complicated is when you have multiple input conditions (pressing up but not right), or priorities (what if the "jump" and "down" are both pressed), or conditions that do not directly relate to player input ("action" pressed and not falling). This is all in the design stage (on paper) so I haven''t tried to implement anything yet. Just wondering if anyone had done this, and if not, what has been the technique you''ve used so far. Maybe the "if"s aren''t as bad as I think they''re going to be.

It sounds like it would get incredibly unwieldy if you had more than a very small number of possible inputs. My states are usually much more complicated than that. In the program I am currently working on, a state tends to correspond to 1 function, and returns the state to succeed it, depending on what happens within that function. The calling function looks like this:

void loop(){    int state = STATE_START;    for ( ; ; )    {        switch(state)        {        case STATE_START:            state = StateStart();            break;        case STATE_DO_SOMETHING:            state = StateDoSomething();            break;        case STATE_DO_SOMETHING_ELSE:            state = StateDoSomethingElse();            break;        case STATE_END:            return;        }    }}  

When I find myself needing more that just 1 function per state, I will move to the State pattern.


Edited by - Kylotan on August 21, 2001 11:37:58 PM

Thanks for the reply. Sounds like a decent method. I think I''ll look at doing something similar.

You can use a message map to avoid if''s and switches, they also allow you to add message handlers at run-time (from dll''s for instance).

You can build state machines as a heirarchy of classes. Use a base class that defines the events and/or message structure, and then you make a sub-class for each state.


Magmai Kai Holmlor
- Not For Rent