About OnEnter, OnUpdate, OnExit?

[jasonlee]

It puzzles me that in custom action, we can overide OnEnter,OnUpdate,OnExit method for different behavior, that's cool,  but in state's action editor, there's no way to organize actions base on enter/update/exit. Personally, I don't think it's action's responsibity to know it's entering or exiting a state, it   's state should know which action to call and when.
Eg, I want my enemy game object, when enter "chase" state, play some animation, initialize some variables; when in the state, keep chasing player; when exiting state, play another animation, release some resource, etc. It seems I might have to split it into 2 or 3 states for that in playmaker, is it? Or I missed something obviously?

[jeanfabre]

Hi,

From your description, you do have 3 states, "enter chase", "keep chasing", "contact with player" and that's fine in my opinion

 Use the enterChase state to init the chase, and then enter "keep chasing", in keep chasing you follow and try to get closer to the player. Now you have two options, either you manage somewhere else the algorythm that detect if you are close enough to engage battle ( like a collisiong trigger or something) . Else you can detect that you are close enough right within the "keep chasing" state.

One State to do it all would be too dense, difficult to maintain and defeat the wonder of states, action and transitions combo.

Regards the flow of actions within a state, I believe you actually can achieve more or less what you want by simply moving up and down actions and order them. Say first action init a variable, second action animate that variable, third action compare that animate value and trigger events accordingly. So you do have a sense a procedure and order within a state. But you'll get a lot more power and flexibility by letting your states, transitions and wiring deal with the grand view of your procedure. Actions simply "act" really, they should not be too clever on that regards (at least I think...).

Bye,

 Jean

 Bye,

 Jean
 

[jasonlee]

Hi Jean,

Thanks for your answer.

I agree that sometimes it's better to divide a state into Enter/Update/Exit states for more flexibility. But in some cases, it just seems more logical to me to make it one state.

Here's one scenario:

A Weapon will become Gold Weapon for 10 seconds when player drank some magic potion.
A Gold Weapon will automatic launch grenade towards 3 nearest enemies.

In my ideal FSM:

There's a "Gold Weapon" state for weapon game object, and there'll be 3 groups' of actions, corresponding to state's OnEnter/OnUpdate/OnExit:

OnEnter:   Change mesh to Gold Weapon Mesh; Change Material, etc
           Setup an array to keep track of 3 most closed enemies;
OnUpdate:  Playing shining animation of Gold Weapon;
           Update the array.
           Lauch grenade towards enemy in a specific time lapse.
OnExit:    Stop the shining animation and clean up the array.


Talking about actions, totally agree that most actions should not be too smart to know about state status. That's why I really dont like the "every frame" design. ( Maybe it's only because I'm too new to playmaker, I just cant figure why some actions has the "every frame" flag, some don't. )

An action should not care when it's been invoke, so there should not be the need for "every frame" flag, if there're predefined action group(OnEnter/OnUpdate/OnExit) for each state.

If an action is been put in OnEnter or OnExit group, it'll execute only once;
If an action is been put in OnUpdate group, it'll run in every frame. (For more flexibility, it might help to has a "Every N Frames" action to invoke action every N frames under OnUpdate group)

[jeanfabre]

Hi JasonLee,

Interesting thread

Yes, I understand what you mean, and actually I sometimes wish actions could have methods we can invoke from the state instead of having to rely on Enter/Update/Exit. but I think it's the wrong approach.

 Alex would better formulate this of course. But Enter/Update/Exit methods are not "states" as per playmaker description,  they simply follow the common pattern we found in standard script components you plug to a gameObject. These components do not fit the "state" paradigm at all. This is simply a mechanism to do something on init, do something repeatably and do something when exiting.

Now, yes, it could be cool to have different groups within a states to organize actions. Why not.

Regards the EveryFrame situation. I think that it would be difficult to do it otherwise in many cases. Since Each Action is responsible for its implementation, State can not expose flags or groups to decide when and how an action is performed at a higher level ( that is as a common interface to ALL actions). EveryFrame is actually very handy, because, for the same action like typically checking a boolean, I can use it as a sole check to implement an "if" statement, Or I can check Everyframe and it becomes a watcher. Excellent I'd say ( not speaking from a perf point of view, but from a practical point of view). It's really up to the action author to decide whether to expose the "EveryFrame" flag or not, because it depends very much of the purpose and scope of the said action. You can't really prevent this from happening, and it's a good thing when used properly I think.

Now, I too would like to be able to clearly see the scope of actions regards enter/update/exit functionnalities. I do miss that very much when I open a state, I have to reverse engineer and think seriously about each and every action to deduce the flow and each of there action/scope. On that, I think action interface and display would gain incredible understanding if it was clearly stipulated visually somehow. I made a post on this actually: http://hutonggames.com/playmakerforum/index.php?topic=156.msg577#msg577


Bye,

 Jean

[jasonlee]

Now I begin to think it might not be such a good idea to introduce Enter/Update/Exit action groups.

It all come down what'll make your level design's job easy but not just make programmer happy.

In current PlayMaker's design:

   state.OnEnter -> action.OnEnter
   state.OnUpdate -> action.OnUpdate
   state.OnExit -> action.OnExit

It's action programmer's responsibility to decide where to implement to action: Enter/Update/Exit state, as Jean states out. For level designer, he/she only cares whether some action need to run "every frame", so the "every frame" flag comes handy.

If there're Enter/Update/Exit Action groups introduced:

   state.OnEnter -> actionGroup<EnterGroup>.action.Execute
   state.OnUpdate -> actionGroup<UpdateGroup>.action.Execute
   state.OnExit -> actionGroup<ExitGroup>.action.Execute

Now, programmer will be happy since all actions only need to implement one clean Execute method, and it's level designer's responsibility to place suitable actions into each action group. I would say it's more flexible system desin but come with the price of complexity and might encourage "Super Huge State" design.

[jeanfabre]

Hi,

 The current flow of calls for onEnter needs clarifications, at least when several actions are dropped on a state.

 Each action in turn is called onEnter, it is very important actually, cause you can set up a variable in the first action and then play with it in the second, inverting the two actions would results in bugs and faulty behaviors.

Programmer/designer pleasing balance is indeed hard to achieve

 Bye,

[iByte]

Hi, before I purchased PlayMaker I was using the Unity FSM code from Ir0nM0nkey found on the Unity forums.

http://forum.unity3d.com/threads/26030-unity-FSM

This FSM implements what Jason is talking about in that it has Enter, Step and Exit Actions that can be registered with each state. I think the downside of that implementation was that it had you create a class for each action (if I was using it properly

If all these Enter, Step and Exit actions per state could be flagged as such in playMaker I think that would be useful.

EDIT: If I re-read the posts above correctly it *is* possible already to have on enter, step and exit but only in custom actions and not (currently) via the playMaker GUI is that correct?

iByte

[jeanfabre]

Hi iByte,

it *is* possible already to have on enter, step and exit but only in custom actions and not (currently) via the playMaker GUI is that correct?

Yes. What Yann was referring too was indeed a more structure way to organize and trigger these events for actions for pure organizational purpose. Actions do implement enter, update and exit currently but is not very clearly exposed visually as feedback nor controllable at a higher level ( currently only the author of the action can decide to expose these via for example "EveryFrame flag".

 Bye,

 Jean