//
void StateManger::Setup()
{
state.push_back( new StateStart() );
state.push_back( new StateMiddle() );
state.push_back( new StateFinish() );
}
// call this in the update loop
stateManger->Update(dt);
// implementation
void StateManger::Update(float dt)
{
for( all states )
state->Update(dt);
}
[source/]
where does the state machine come into it?
i have a state manager and state classes but why do i need a state machine class?
Help with my state machine....
Author
Here is what i am doing...
1) create base State class with an enum of all possible states
2) for each unique state, derive a new state class
3) create a state manager that stores the states and iterates through them
Author
question got merged with code above...here it is
where does the state machine come into it?
i have a state manager and state classes but why do i need a state machine class?
where does the state machine come into it?
i have a state manager and state classes but why do i need a state machine class?
Quote:Original post by gameplayprogammer
why do i need a state machine class?
Um, if it works the way you want it to, why would you need any additional code? If you don't know why you need it, you probably don't.
I don't really understand the issue.
Author
I saw an implementation of a state machine once that had a state manager and state machine class as well as the state classes. just wondering what i am missing out.
By updating the states you're really transmorfing the state in state machines.
A state don't update.
A state machine updates from one state to another.
A state don't update.
A state machine updates from one state to another.
Depending on how you want to structure your code you can do one of two things:
1)
This means that your STATES are doing all the work. This can get really messy, as your states do have to know about eachother, and there is no good way to know what state should be modifying the world right now.
2)
This means that each state would have to implement some means of selection, like a "can activate". The selectNewState function would then find the state with the best response to "can you activate", then switch to it (posible shortcuts include letting the active state always win if it can still activate, thus cutting the total number of checks that you have to do). Then only one state is updated at any one time, and thus no state technically every has to know about any other states in the machine.
1)
addStates(...);while ( 1 ) updateAllStates( dt );This means that your STATES are doing all the work. This can get really messy, as your states do have to know about eachother, and there is no good way to know what state should be modifying the world right now.
2)
addStates(...);while ( 1 ) if ( selectNewState() ) changeToNewState(); updateActiveState( dt );This means that each state would have to implement some means of selection, like a "can activate". The selectNewState function would then find the state with the best response to "can you activate", then switch to it (posible shortcuts include letting the active state always win if it can still activate, thus cutting the total number of checks that you have to do). Then only one state is updated at any one time, and thus no state technically every has to know about any other states in the machine.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement