playMaker

Author Topic: SubFSM!  (Read 9918 times)

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
SubFSM!
« on: May 03, 2011, 10:27:33 AM »
We've started discussion about nested FSMs (or SubFSMs, kinda like "subroutine") in this thread: http://hutonggames.com/playmakerforum/index.php?topic=10.0

And many important points were brought up, including how you can currently use "Next Frame" to execute multiple states in a single update. Recently while completing a short game project I've had many problems trying to make things run in the same update, it quickly became obvious that they don't do it by default. If I got it correctly each state takes one update. "Next Frame" can supposedly make multiple states execute in the same update, yet it never got clear to me what defines that the "state block" started, only that it has ended, and Alex's example only cites a loop. ???

Anyways, back to the point, the more and more we dig into PlayMaker the clearer it gets that nested FSMs are the way to go. It has been mentioned that one state would "link" to a complete new FSM. Supposing that's still the idea, would all the the states (and consequently the actions in it) in that FSM be executed in the same logic frame (update)? Sorry for the probably stupid question but what happens when/if the execution of those states take too long, does Unity slows everything down to try and keep up or would it "clip" the execution of actions after a certain threshold, and keep executing them in the next frame? I imagine the right answer is the first one, but I want to make this crystal clear 'coz it's a very important concept.

In any ways, please make Nested/SubFSMs a top priority, it'd make our lives 10x easier - and the need for new/hybrid actions, 10x rarer.
--
Breno "MaDDoX" Azevedo
@brenoazevedo

jasonlee

  • Playmaker Newbie
  • *
  • Posts: 12
Re: SubFSM!
« Reply #1 on: May 03, 2011, 11:45:24 PM »
Personally, I found the name of "Next Frame Event" is rather confusing too. From my understanding, what it do is acutally "Send event in current frame, Kick off next state's OnEnter event in current frame, make next state's OnUpdate start to execute in Next Frame". So the most confusing part is, if you put chains of "Next Frame Event" in multiple states, they'll all actually be executed in "Current Frame" instead of "Next Frame".

And the root course of that confusion is the Life cycle of State Actions is mixed with the Life cycle of State, which might not be what user expected.

Back to the topic of Nest FSM (Hierarchy FSM/SubFSM), I also like that idea to have that feature in PlayMaker.

Here's one example borrow from aigamedev:



Though it could be achieved now by dividing and linking multiple FSMs, it's not ideal, for it's not a logical representation of the hierarchy nature and make it harder to maintain.



jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: SubFSM!
« Reply #2 on: May 04, 2011, 01:12:58 AM »
I am all up for sub fsm ( or what ever it gets called), and agree completly with all the pros of subfsm as you describe it.

 The main feature I am looking for such feature is the ability to define it like "templates", that is not tight to a particular fsm, self contained and functional.  Basically a block you trigger by wiring an event and have transitions already define to wire out. It could actually look exactly like a conventionnal State, onmly with a different color or something ( just to stand out basically).

 The very important feature aside this is to have all instances of this block referenced, that is, if I change the internal content, all instances of that subfsm should reflect this changes. and like prefabs, variable used in that templates, could be exposed for change and tweak. Say we have subfsm to move something at a certain speed: the speed variable would be tunable for each instances created.

 I appreciate this might be a far reach... :) hopefully not !


 Bye,

 Jean

tobbeo

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 186
Re: SubFSM!
« Reply #3 on: May 04, 2011, 05:42:32 PM »
I fully agree with this and don't have any more thoughts on how it's implemented other than this is an issue that should be very high priority to get into Playmaker. It would speed up development time and it would make everything easier. Please post Huttong masters so we know you are listening :).

Alex Chouls

  • Administrator
  • Hero Member
  • *****
  • Posts: 3987
  • Official Playmaker Support
    • LinkedIn
Re: SubFSM!
« Reply #4 on: May 04, 2011, 09:51:08 PM »
Hierarchical FSM support is on the roadmap, and will probably include some kind of reference graph ability as Jean describes.

We were considering this a 2.0 version feature, but we can take another look at it...

In the meantime I think organizing state machines hierarchically by breaking them up is still a good idea, and the PlayMakerGlobals component will make inter-FSM communication easier to maintain (e.g., easier refactoring of variables and events).

We're also toying with a project view editor window that shows FSMs and their connections visually, potentially giving you the benefit of hierarchical FSMs without complicating the FSM editor... it might be how we actually implement hierarchical FSMs.

tobbeo

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 186
Re: SubFSM!
« Reply #5 on: May 04, 2011, 10:46:59 PM »
Hierarchical FSM support is on the roadmap, and will probably include some kind of reference graph ability as Jean describes.

We were considering this a 2.0 version feature, but we can take another look at it...

In the meantime I think organizing state machines hierarchically by breaking them up is still a good idea, and the PlayMakerGlobals component will make inter-FSM communication easier to maintain (e.g., easier refactoring of variables and events).

We're also toying with a project view editor window that shows FSMs and their connections visually, potentially giving you the benefit of hierarchical FSMs without complicating the FSM editor... it might be how we actually implement hierarchical FSMs.

All sounds good and exciting to me!

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Re: SubFSM!
« Reply #6 on: May 04, 2011, 11:30:01 PM »
Personally, I found the name of "Next Frame Event" is rather confusing too. From my understanding, what it do is acutally "Send event in current frame, Kick off next state's OnEnter event in current frame, make next state's OnUpdate start to execute in Next Frame". So the most confusing part is, if you put chains of "Next Frame Event" in multiple states, they'll all actually be executed in "Current Frame" instead of "Next Frame".
Is that really how it works? I haven't checked its code, but if it does it's quite powerful. Supposing you don't have any "every frame" you'de be able to chain as many events as you want (and, consequentially, their actions) in the same update. Not intuitive like you say, but still very powerful.

Quote
We're also toying with a project view editor window that shows FSMs and their connections visually, potentially giving you the benefit of hierarchical FSMs without complicating the FSM editor... it might be how we actually implement hierarchical FSMs.
This would be okay, but it wouldn't compare to the power of having a special state which, once clicked, instantly opened another FSM. You'd be able to save and re-use the current load templates without a problem like Jean requests. The only actual addition to the interface would then be back/next buttons (I'm thinking Flash/Illustrator here, pretty easy) for when you're digging into multiple FSM levels. The big functional change would be that, once the sub-FSM is called, the current FSM is paused and execution is resumed once the called FSM does its thing - maybe through a new/default "RETURN" event?

As for the current use of multiple FSMs for such tasks, I think we shouldn't downplay the extra hurdle demanded for having more than one FSM in the same object, never mind having to make sure the right actions are executed and the right event is passed to resume execution of the starting FSM. I'd rather keep my brain cycles for when it's really needed, ie. communicating between non-dependent FSMs. It's the same situation as using explicit messages instead of global variables - it's do-able, but it really defeats the main premise of ease-of-use and user-friendliness.

Just my $0.02
--
Breno "MaDDoX" Azevedo
@brenoazevedo

jasonlee

  • Playmaker Newbie
  • *
  • Posts: 12
Re: SubFSM!
« Reply #7 on: May 05, 2011, 03:06:49 AM »
Is that really how it works? I haven't checked its code, but if it does it's quite powerful. Supposing you don't have any "every frame" you'de be able to chain as many events as you want (and, consequentially, their actions) in the same update. Not intuitive like you say, but still very powerful.
Sorry, I was wrong about that. Double check the action code, since the Event call only happen in OnUpdate, so even you chains "Next Frame Event", it'll still be called on next frame. So, it's indeed "Next Frame".


jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: SubFSM!
« Reply #8 on: February 21, 2012, 08:01:10 AM »