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;
.....


Menu
Categories
Content Tags







vBulletin Message