You may be thinking... "But, that's going to be really complicated... my game has 12 menus, an inventory screen and the game itself!"

You don't have to put everything in one gigantic state machine. That would be truly scary.
Break it up a little and have a number of state machines that deal with a particular aspect and then one main machine that deals with the overall state of your application, so for example:-
Code:
WHILE (1=1) DO CASE MAINSTATE OF MS_STATE_INITIALISING : BEGIN ..... END MS_STATE_MAINMENU : BEGIN ..... END MS_STATE_LOADING_GAME : BEGIN ..... END ..... END IF NEXT_MAIN_STATE<>0 THEN MAINSTATE:=NEXT_MAIN_STATE; NEXT_MAIN_STATE:=0; END IF END WHILE
With this state machine within a state machine approach there are a number of decisions you'll need to make, mainly relating to flow, code organisation and controlling the state of the top level state machine.
One approach is to have the sub-state machines (i.e. the one for handling the initialising, the one for handling the main menu etc.) as functions that return a value that is the next required main state.
For example:-
Code:
function mainStateInitialising:integer; begin result:=0; case fInitialisingState of ..... // Do initialisation states here ..... INIT_STATE_DONE : begin result:=MS_STATE_MAINMENU; end; end; if (fNextInitialisingState<>0) then begin fInitialisingState:=fNextInitialisingState; fNextInitialisingState:=0; end; end;
Code:
..... MS_STATE_INITIALISING : begin nextState:=mainStateInitialising; END; ..... END; if (nextState<>0) then begin mainState:=nextState; nextState:=0; end; .....
vBulletin Message