playMaker

Author Topic: OnAwake, OnEnter and Playmaker  (Read 6239 times)

muppetpuppet

  • Junior Playmaker
  • **
  • Posts: 77
OnAwake, OnEnter and Playmaker
« on: February 21, 2014, 06:26:36 AM »
So I've read up on the different states and the onEnter and onUpdate in the actions.

Now I have two questions with regards to this, slightly related.

1. Is it possible to have an OnFSMactive state in the custom action. The reason for this is , that I tend to make loops for complicated logic chains.  But when doing this, the result is multiple states being triggered per frame.  And offcourse the OnEnter is called eached time a state is activated.  And any transform caching and initing is done each time.  Which is logical for the majority of states where you use "every frame" it gets triggered once, and then it loops only through OnUpdate.   

But when doing lots of states in a single frame, it would be great to cache transforms and such only on fsmactivate.

Would it be possible to add an OnFSMactivate state in the playmaker engine?  where you could cache transforms and other stuff that is basically static and only needs to be inited when an FSM activates, and doesn't change even onEnter or OnUpdate?   It could save some overhead when doing a lot of large FSM graphs.

2. This one is a bit different, but part of my learning to optimise FMS graphs. 
On mobile platforms activating a gameobject with several complex FSMcomponents  will cause a hickup.  As the graphs are only parsed and created onActivate, or onStart. (not quite sure, but seing as the FSMupdate spike is when I activate a gameObject not when I create it, it seems logical)

Is it possible to pre-warm a fsm, or add this feature.  So the FSM engine will FSM update a graph and keep it de-activated (or reset state) onAwake? 

This way when you use object pooling you can reduce the FSMupdate spikes tremendously as that work is done when the object was created during your pooling code (for instance during a load screen).

I've theorized I could get the same result by creating clones and activating them and then de-activating them. But that would mean adding more states to stop each graph from going down the full statemachine the first time (and causing a ruckus as the rest of the gamelogic is not up and running yet, during pool creation)

I don't know if this makes sense to you?   as far as I can tell the FSMupdate spike is the only real perfomance hickup that exists with Playmaker on mobile. 

Cheerio
tomas
« Last Edit: February 21, 2014, 06:41:30 AM by muppetpuppet »

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: OnAwake, OnEnter and Playmaker
« Reply #1 on: February 24, 2014, 08:46:25 AM »
Hi,

As is, I would address the problem at its root. you mention you are using loops. Instead I would rely on a different mechanism based on events happening ( as opposed to loop and catch changes). Loops are bad in this case I would argue. Never do a loop in a "game loop" without some kind of temporization, else indeed, even without Playmaker, you will get bad spikes.

Could you elaborate a concrete use case? I am sure Alex will be all ears for a way to improve PlayMaker Update cycles.



bye,

 Jean

muppetpuppet

  • Junior Playmaker
  • **
  • Posts: 77
Re: OnAwake, OnEnter and Playmaker
« Reply #2 on: February 24, 2014, 04:20:14 PM »
Well,  i'm an old virtools hand,  so I can come up with visual decision trees in my sleep,  especially when working with vectors and  such.   Now I realise the core logic of virtools was based on a loop and not state machines , but I still try.. ;)

I find I create a lot of simple movement systems based on a simple velocity vector, some friction and forces.   So for instance the camera has a velocity, a friction and gets a force added to the velocity based on distance vector to a targetPos.  The reason I create this little "simple physics"systems is basically control, and very precise control at that. Plus Its simple and easy to manage.


So an example.. my camera system. simplified a bit

state 1
actions that get, transform and calculate a force based on the mouse or touch delta

state 2
A check if the camera is getting out of bounds (its limited to a range from the active creature), simple distance check (either go directly to state 3 or state 4)

state 3 if the distance is beyond the range, I transform the touch force along the radius of the range circle of the object (forcing the camera to stay within range, while still providing movement ontouch or onmousedrag)  , there will be a few other states that show a boundary UI indicator and lerp the color etc etc.

state 4 actions to determine if the player is pushing the camera or if its un-used(idle)  go to next state if its idle or to state 6 if the camera is moved

state 5 if the user input is idle, the camera is following the creature. So I do a check if the creature is moving, and another state to calculate the target force for the camera to move towards the active creature

state 6 the camera is already moving through touch or mouse interaction, so it basically continues to state 7 (I add a few GUI indications during this state as well) 

state 7. combine all the forces with the friction and transforms the camera.
ends with next frame event back to state 1

It sounds over-engineered, but provides a really nice interactive camera that can  do a lot of things.. there's a whole bunch of other states in there, for checking if the another manager is over-riding the camera for dialogue (camera is targeted to the NPC, just switches the forces over from following a creature to a npc)

Here's a screengrab, Now I haven't cleaned up, so its a prototype, I guess I can combine a lotta states, but not all.


Here's a video of what of the end result


So It's all a big decision tree, run in one frame.  So I'm contemplating writing some C# code to manage this, but honestly that's a pain for me. Especially if this FSM already does exactly what it needs to do, but its a bit of a performance hog.

So in this case the majority of the transforms, (the camera, the camera main target, etc) are static, and only an updated position is required. So if those could be cached at an onStart that would save at least some overhead.

Sorry if some of my lingo is off regarding transforms and such, I really try to stay within visual scripting, as typing and doing syntax bums me out. 

Alex Chouls

  • Administrator
  • Hero Member
  • *****
  • Posts: 3987
  • Official Playmaker Support
    • LinkedIn
Re: OnAwake, OnEnter and Playmaker
« Reply #3 on: February 24, 2014, 05:20:14 PM »
Actions have an Awake method that's called once when the action is loaded. See the RunFSM action for an example.

Does that help in your case? Are you writing custom actions?

I'll look into the hitch when activating FSMs...

Alex Chouls

  • Administrator
  • Hero Member
  • *****
  • Posts: 3987
  • Official Playmaker Support
    • LinkedIn
Re: OnAwake, OnEnter and Playmaker
« Reply #4 on: February 24, 2014, 05:43:09 PM »
Do you see a hitch in a standalone build as well as in the editor? Heavyweight initialization should happen in Awake, but there is more overhead in the editor.

muppetpuppet

  • Junior Playmaker
  • **
  • Posts: 77
Re: OnAwake, OnEnter and Playmaker
« Reply #5 on: February 24, 2014, 05:46:25 PM »
I see the hitch both in standalone and android build.. it's when I activate an existing gameobject for the first time, and its defintly in the fsm creation, as I can track it as well in the profiler.. its very specific.

muppetpuppet

  • Junior Playmaker
  • **
  • Posts: 77
Re: OnAwake, OnEnter and Playmaker
« Reply #6 on: February 24, 2014, 05:47:20 PM »
And only when its activated the first time,, so it's not recuring if i de-activate and activate later

PaulH

  • Junior Playmaker
  • **
  • Posts: 50
Re: OnAwake, OnEnter and Playmaker
« Reply #7 on: September 16, 2014, 05:43:59 AM »
did anything ever happen with this? i have the same problem.

when activating game objects (through pooling etc) on IOS for the first time, i get a big FPS spike. It only happens the 'first time' an object is activated, then when i deactivate and reactivate its fine.

Also first time collisions etc cause a major spike, then there after no problem, just the first ones.

Is there any way around this? a way to have all this happen before on startup so it doesn't happen mid game? because this does cause a major problem in my game, i have tried everything to get rid but with no luck.

regards,

ps maybe an action that lets you list the objects you need preloading into the GPU?
« Last Edit: September 16, 2014, 07:23:47 AM by elusive52 »

PaulH

  • Junior Playmaker
  • **
  • Posts: 50
Re: OnAwake, OnEnter and Playmaker
« Reply #8 on: September 17, 2014, 06:45:15 AM »
bump

to get an answer?

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: OnAwake, OnEnter and Playmaker
« Reply #9 on: September 18, 2014, 09:34:29 AM »
Hi,

 Is it related to Pooling? I replied to your thread on this, it's basically something to first deal with with the pool system and then see how it performs once you know the pool is prefilled at editor time.

 Bye,

 Jean