You may be thinking... "But, that's going to be really complicated... my game has 12 menus, an inventory screen and the game itself!"
![Shocked](images/pgdsmilies/surprise.gif)
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