Archived

This topic is now archived and is closed to further replies.

dapeos

Using a Stack for Game state managment

Recommended Posts

dapeos    124
I pulled out jim adams book for his idea on using a state manager instead of dirty switch statments because I felt like it was time I started maturing more in my programming, and Ilove it but I have a few questions. Is there harm in handling input in different places(not just having one function to do it), for example say I have two states GAME_MENU and GAME_PLAY the input would be handled radicly different between the two states.So when they are pushed on the stack and it comes time to process them should they each have there own handle input funtions. Or should handleInput be aware of what state is being run and then I am back to another switch statement.(Did that make any sense?) Should each state be have all there own loops render, handleInput,etc? Should I draw only in one part of the game,is it bad pratice to render in different places? for example pD3d->beginScene blah blah pD3d->endScene Is it a good idea to to push a game shutdown funtion on the stack first or not to put it on the stack? Do you guys use the winProc at all running a full screen game using direct X, and if so what for? thanks in advance [edited by - dapeos on January 25, 2004 4:29:51 PM]

Share this post


Link to post
Share on other sites
Megahertz    286
I''m using the state model as well and I pretty much treat each state as if it were its own little program. Each state has its own OnRender, OnKeyDown, OnUpdate, OnMouseDownL, etc.. methods.

As far as which state to pass events for input you prolly wanna pass the event to all the states on the stack. Of course it really depends on the behavior youre trying to achieve.

In my project, I dont use a stack as the game can only be in one state at a time. I''m either at the login screen, the server select screen, the character selection screen, or im playing the game.

There''s a few other states like if the player is zoning from one area to another or loading the game but thats the basic setup.

The only real problem with the whole state pattern method, at least the way i''ve implemented it is that its really hard to have persistent objects from one state to the next if those objects are created within the state. Whenever a state change happens i call a DeInitialize method that destorys everything the state created and whenever the state is reentered the objects are recreated. Not a big deal since theres not that many objects for each state save maybe the playgame state but thats usually gonna be reloaded every time anyway.


-=[ Megahertz ]=-

Share this post


Link to post
Share on other sites
Mage2k    336
Yes, each state should have its own version of handleInput, onRender, etc.... whatever... -- this should be done thru polymorphism, i.e. write an abstract base class that specifies the methods that all states should implement and inherit from it for each state. Then all you need is a base class pointer that you can use to point to whatever the active state is and call each of those methods in your game loop with it.

peace and (trance) out

Mage

Share this post


Link to post
Share on other sites
Endurion    5411
A) I''m using a stack for my states. 99% of the times i''m having only one state on the stack. The 1% is having a in-game submenu state on top of the game state.

Every state has it''s on Init,Exit,Display and Update functions.

In the beginning i had my state machine change states as soon as i requested it to. On rare occasions i would run into troubles since the old state was still finishing but already gone. Then i decided to push the stack change onto a message queue and process that queue only after all the frames are updated. It''s simply safer that way. The same with the game shutdown.

As Megahertz said, kind of a problem arises with persistent objects. Since those are usually important game data objects i tend to have a game data singleton which more or less just stores the persistent stuff plus some widely used routines which work on the game data.

B) I''m using the WinProc for handling the messages WM_ACTIVATE plus some others (sizing,moving,prevent the screensaver from popping up).

Share this post


Link to post
Share on other sites
dapeos    124
Hey that helps alot, it was what I figured, but I wanted to ask to make sure I didn''t learn any bad habits.
Is it a bad idea to put the shutdown function on the stack so when all the other states are poped ex.GAME_MENU that shutdown will automaticly be called or should it be more like

initialize junk
while(states left)
shutdown

well you know what I mean.
thanks again

Share this post


Link to post
Share on other sites
Endurion    5411
I''d favor the second approach, the shutdown is not really a kind of state. Once i told my app to shutdown i set a flag and the next time my state manager hits its processing method it''ll pop states off the stack and then initiate the real shutdown.

Share this post


Link to post
Share on other sites