Quote:Original post by Holy Fuzz
A state in an FSM needs to know what state came before to do such tasks as returning to the previous state.
The code in that link that I posted earlier, everything that the fsm need is in the fsm class. Even the previous state, but (IIRC) in a real FSM "returning to the previous state" doesn't exist, only going to new states :)
Quote:Original post by Holy FuzzQuote:In this case I would probably have done a state in a popup-stack that overrides the game-state. ie:
update: if popupstack is empty update game-state, if popup is nonempty - update popup.
rendering: render game-state, then render popups
If I understand correctly, then you are proposing to implement a stack system for only those "base" states that really need a stack, which also turns it into a "bottom-up" system rather than a "top-down" system. Other than requiring a (probably insignificant) amount of work, I only see one problem with this method: By having a base state manually implement a stack system you are requiring every base state to know whether another state may or may not be pushed on top of it. In my opinion, this limits extensibility, though an argument could be made that it also keeps the state system from being abused with needless pushing of states ontop of other states.
no no no ;) That system would be used for popups only to override the game-loop. In this system a popup != gameloop. Popup stops the loop(to some extent) while the game loop is a loop, so the game loop lives in a happy little world not knowing what happens with the popup and for what it is conserned popups doesn't exist. sortof like popup(msg); could also be print(msg);.
Quote:Original post by Holy FuzzQuote:void GameState::update(float p_deltaTime) {
m_currentGame->update(p_deltaTime);
if( someCondition ) gameMashine->setState(InGameMenyState::instance());
}
or
void GameState::update(float p_deltaTime) {
m_currentGame->update(p_deltaTime);
if( someCondition ) gameStack->pushState(InGameMenyState::instance());
}
Again, if a pure FSM was used, you would need to hardcode in or otherwise tell the new state which state it should return to after it is done executing. In the first chunk of code, InGameMenyState::instance() would need to be passed a handle to the previous state.
See above, but if a true fsm would be used, I would have to send events to it all the time and have it call the updates.
Quote:Original post by Holy FuzzQuote:I really can't argue with this, but is it needed? A pause state might want to update the view, but not the game logic(like max payne pause) and there goes IMHO the beauty of stack.
Hm... maybe "stack" isn't the proper term... How about "runtime state inheritance"? What I'm describing is actually a lot like type inheritance and polymorphism, except with states instead of classes. For example, pushing state A onto a stack whose top state is state B really means that A is inheriting (and probably overriding some of) the functionality of B, which in turn may inherit and override the functionality of C, and so on... So yeah, it's like polymorphic states where inheritance happens a runtime.
So the update function in the pause state can move the game camera? but isn't this one hidden from the pause state since it belongs to the game state? How would it be coded into the states? Giving the state a getCamera() function seems like a stupid idea? A Meny or a popup state can't return a camera, right?
I think this isn't really a discussion about game-states but on if a meny state(Game Menu, Options Menu, Quit Menu etc) is a game state or a menu is a game state?
Maybee itsn't such a bad idea if you can make the whole menu as a single gamestate(and menu states as nodes in a tree). But I'm still unsure of wether it's a good idea to have a stack - stack overflow (and underflow) might occur unless managed correctly [rolleyes] ...