playMaker

Author Topic: Menu Settings - FSM design  (Read 3144 times)

kinetiknz

  • Junior Playmaker
  • **
  • Posts: 85
Menu Settings - FSM design
« on: November 01, 2011, 02:43:25 AM »
Hi there, I am creating a settings HUD for my app. Currently the user presses tab which enables the HUD including a 'settings' button when clicked it expands another area beneath it. This area will have a bunch of controls for various quality controls.

My question is a design one. What is the best way to design the FSM?

If it is one state drawing all of the elements then it would have so many actions it would be unusable.
Buttons in the settings panel eg. 'advanced lighting - on/off' can't use global events, so effectively I have to duplicate the entirety of the panels with minor adjustments in every state?

or do I have to split up each section of the settings panel (say 8 regions) into their own empty game objects with their own FSM's? It starts to get very hard to manage at that point. I really wish the FSM editor could display all FSM's at once. It would make my experience much easier.

The organisational design of FSM's is the part I struggle with the most. Any tips are really appreciated.
Thanks alot



jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Menu Settings - FSM design
« Reply #1 on: November 01, 2011, 03:05:46 AM »
Hi,

 I am facing this issue too when I try to use playmaker to build a gui above basic needs. I don't understand how it can be used effectivly.

 Bye,

 Jean

Xtopher

  • 1.2 Beta
  • Junior Playmaker
  • *
  • Posts: 71
    • Well Played Games
Re: Menu Settings - FSM design
« Reply #2 on: November 02, 2011, 02:50:51 PM »
I would suggest simplifying as much as possible, which will mean more rather than less FSMs in the scene.  You can put more than one FSM on a game object, which can reduce clutter in the hierarchy, and for me at least it helps group things logically so I can find them again later.  For instance, "go_SpawnManager" could have "FSM_Spawner", "FSM_ClearSpawnPoints" and "FSM_waves" all attached.  That way I know everything to do with spawning happens around that one game object.

Generally, each button or button set could have it's own FSM.  For instance, an on/off button with two states could really be a four state FSM... one state for each of two GUI Button actions, and one state for each thing that button does, all flowing together in a loop.  Setting things up individually will keep you from having cluttery branching stuff to handle all the various cases of things being on or off, etc.  Even with only three buttons you would grow to a huge, unmanageable FSM!  It may seem like more effort to have multiple FSMs instead of one, but trust me, it really isn't, especially when you are trying to fix bugs near the end of the project!

When a buttons action is simple and unique you can put the functionality in the same FSM, but I generally like to have "managers" that do all the real work, and have the GUI elements just "Send Event" to the manager.  That way I can iterate on both throughout the project without breaking either.  This approach lets you focus on two separate things... 1- did the event happen, and 2- did the action I want take place?  This also lets you call the same action/event from various sources, which becomes really important in most games.

I hope that was helpful!