Jump to content
  • Advertisement
Sign in to follow this  
garyfletcher

State machines - a few questions.

This topic is 4845 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all. I'm looking at ways to incorporate a FSM architecture into my engine. Currently my basic engine follows the task system set out in the enginuity articles. I'm wondering how I would incorporate the FSM. Would the kernel drive the state machine or vise-versa? Would the state machine and the game loop (kernel) be totally independant, or would I have a state task that would query the curent game state and update/pause/enable tasks accordingly? Does the FSM apply only at an application level or does it apply to game entities, ie. would state class be an interface and my game state class and character classes inherit from the state class? Hmmmm...lots of questions..has anyone seen any good articles they can recommnend or implemented a FSM and have any pointers? Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
If you are using the kernek/task idea from enginuity, you'd need to design the state machine to run a task that would update the current state. There are many ways to implement this but I'd recommend having some sort of StateManager class that has a way to access a StateUpdater task and then when a state is made current make sure to notify the StateUpdater class with the new state it should be updating.

My state system actually requires two tasks (but my Kernel is not based on the enginuity one), I have an update task and a render task.

Share this post


Link to post
Share on other sites
I would say an FSM module should be pretty independent, i mean it shouldn't need to know about Tasks etc.

Anyways if you can get your hands on this book it has a nice chapter on implementing a basic FSM module in C++ with tips on how to take it further it doesn't really give you the theory though. Its really nice, its declarative, it uses the concept of state transition tables you define an STT (actually in C++ code) and its generates the necessary code for you. Its definitely the better FSM modules i've seen, instead of typical ways like using inheritance etc to implement them.

[Edited by - snk_kid on August 14, 2005 3:02:59 PM]

Share this post


Link to post
Share on other sites
The only reason I'd say that the FSM module need know about tasks is that if the application essentially registers all tasks with the Kernel and then calls Kernel::run() until all tasks finish, there is no way to update the state from outside the Kernel, so the State Machine's actions must be integrated into the kernel. If the kernel is a stepping kernel and not a run-until-done kernel (meaning you call Kernel::step() every frame rather than Kernel::run once) you have more options.

Share this post


Link to post
Share on other sites
I've been thinking a little (always dangerous) thought that each "system" (i/o, renderer, file application manager, even the Kernel) could have it's own event manager, which in turn would register with an event system, specifying which event types it needs to know about.

Whenever any event occurs it is sent to the event system, which in turn sends appropriate messages to the registered local event managers, which change the state of the individual entities.

This way a event task would be needed in the Kernel to get the event system to send messages to the appropriate event managers..the update functions of the entities would see what state they were in, run the appropriate code, and send messages to the event system.

The event system would be independent of the Kernel, and some kind of IPC trickery would be needed, maybe SDL_net for ease of use and portability.

So the event system would be a basic client sever...listening for incoming messages, spawning a child to deal with message.

The Objects update function (as run via the Kernel) would.

1. Listen for messages.
2. Update State.
3. Process State.
4. Send new event to event system.

The Kernel would be basically the same...although I'd need to think about that some more????

Does this basic design seem okay..or is it very flawed?

Comments would be great.

Share this post


Link to post
Share on other sites
It sounds like you have a decent start to an idea, I think you need to make sure to plan it out fairly well before you jump in, if it's not carefully designed you'll run into all sorts of problems (I sure did when I first started with my Task/Kernel system [wink])

best of luck

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!