Some good FSM practices for optimal results [Discussion]

[mrminico]

Hi Everyone,

Today I was making a sprinting system that has a lot to do with input axes and I ran into a bunch of FPS issues out of a newbie mistake I would make in my earlier days of using playmaker. I found a clever way to fix my issue and thought I'd make a discussion on some of the methods I used that helped me get the most optimal results. I hope this thread will help others searching for ways to make optimal FSM's and I'd like for the playmaker veterans to also give us their wisdom on anything I may not know

Now I'm no programmer but I am aware that as much as there is good code there is also bad code and the same rules apply to FSMs.

I've been using playmaker for almost 2 years+ and here's a really short list of things I try to be consistent with:

• Avoid calling actions on every frame in starting states unless neccessary
• Avoid getting variables on every frame unless necessary
• Split FSM's into smaller components it can help with referencing variables
• Replace FINISHED event with custom event "Done" FINISHED is used systematically. I've experienced Issue with certain MATHS operations while using FINISHED.
  
  Example of FINISHED systematic use: (Try using wait and dont assign a finish event in the action inspector only assign FINISHED to the state transition event. It'll automatically transition over to the next state)
  
• When using rigidbodies always check FixedUpdate if given the option (unity updates physics in FixedUpdate)
• Use Add force or Set Velocity actions when moving rigid bodies
  
  *If you end up using translate check the fixed update option. It'll make things much smoother although it's not the most optimal option by unity standards. I hope we get better rigidbody translate action*

I'm still learning and anything I find based off my readings/trail and error I'll update this list. Now there are TONS of ways to go about making optimal FSM's. If anyone has something else that works well in practice please feel free to share I'd like to hear everyone else's opinion on the topic and what they think works best based off their experiences.

To conclude I have a question for the Playmaker Vets Is it more optimal to use get axis once and have "get fsm float" everyframe for other FSM states / actions to use the input value or is it the same just using a new Get Axis action?

Thanks for reading hope you all have a wonderful day or night!

[djaydino]

Hi.
It is also good to check this page :

Best Practices

[mrminico]

Thanks for the page links!

[Fat Pug Studio]

Split, split, split. For every important function of your object make a separate FSM. Easier for tracking the flow and debugging. Do not make one big mess of an FSM that will handle everything.

Use global events for communication between FSM's, use switchboard to have a clear presentation of what's going on and to avoid spaghetti FSM's.

Do not omit debug states! Use colors, use debug states that will send messages directly to your unity console so you always know where the problem is.

Always backup before upgrading Playmaker

[djaydino]

Hi.
Not only backup when upgrading, always backup A LOT.

Best is to use github or something similar.

[mrminico]

Split, split, split. For every important function of your object make a separate FSM. Easier for tracking the flow and debugging. Do not make one big mess of an FSM that will handle everything.

Use global events for communication between FSM's, use switchboard to have a clear presentation of what's going on and to avoid spaghetti FSM's.

Do not omit debug states! Use colors, use debug states that will send messages directly to your unity console so you always know where the problem is.

Always backup before upgrading Playmaker

Hi.
Not only backup when upgrading, always backup A LOT.

Best is to use github or something similar.

Thanks for the tip contributions!

[jeanfabre]

Hi Everyone,

• Avoid calling actions on every frame in starting states unless neccessary

Hi,

Thanks for sharing your tips, very useful!

 on that point, I don't think it counts. It's perfectly valid to have a start state doing something everyframe, I do that all the time, on fsm that are responsible for continous animations for example.

If you have experienced trouble, can you explain the case, I think it deserves more attention as you might have a misconception on some features.

Bye,

 Jean[/list]

[mrminico]

Hi Everyone,

• Avoid calling actions on every frame in starting states unless neccessary

Hi,

Thanks for sharing your tips, very useful!

 on that point, I don't think it counts. It's perfectly valid to have a start state doing something everyframe, I do that all the time, on fsm that are responsible for continous animations for example.

If you have experienced trouble, can you explain the case, I think it deserves more attention as you might have a misconception on some features.

Bye,

 Jean[/list]

That's a valid way to use every frame and is exactly what I meant by use only if necessary. A bad example would be trying to get a variable every frame that you can easily assign at the start of the first frame. There are definitely many ways to go about it. And I've seen some performance hits especially when I do heavy maths at start states on every frame D:

[jeanfabre]

Hi,

 true

If you have some test scene you would like me to review regards perfs, let me know. Indeed the start state timing also correspond to the time where the FSM is setting itself, so it can lead to a cumulation of activity for a single fsm that becomes noticeable.

Are you using prefabs in these cases?

 Bye,

 Jean

[mrminico]

I'm not using prefabs (yet... lol) but I try not to blame PM too much for any performance issues. There are TONS of things PM can do in one frame and since I haven't optimized my scene with some GPU memory hacks (Which I'll be posting here) Its safe to say that my scene is flooded which impacts performance. I do however keep in mind the amount of update activity its a good thing to practice.

[jeanfabre]

Hi,

 well, the best way to make sure you are trying to optimize the right aspect of your game, is to profile it.

 it could be sound uncompression, or some of the actions that are taking up performances and not PlayMaker itself.

 for example, if you use the action FindGameObject, every frame on a large hierarchy, you will experience some perfs issues, because Unity own api to search a gameobject by name is slow.

Now if you profile this scene, your first guess as your profiler will show will be to say that PlayMaker is to blame because everything points to PlayMaker internal methods, but if you dig deeper, you'll see that it's actually the Unity api that is used by an action, itself used by PlayMaker that is the issue.

 tricky to debug indeed, especially when you have no experience in coding, it becomes obscur as to what exactly is the problem.


 Bye,

 Jean

[djaydino]

Hi.
Maybe some sort of 'Price List' would be handy to know what kind of action can become expensive (unity wise)

[jeanfabre]

Hi,

 yep, but that would need to come from Unity itself... otherwise we would put on ourselves yet another layer of indirection.

And it's also about the frequency of usage and when it's used. So typically, it's ok to use GameObjectFind, but it's not ok to use it during your gameloop or for everything and anything, which is why I think it's good to jsut go for it, and then profile, find the issues and correct them. 90% of your fsm might be ok using a given api, yet there is one or two fsm that are critical and should be refactored for a different usage of that api. So it would be very difficult to rate actions this way.

 Bye,

 Jean

[mrminico]

Hi,

 well, the best way to make sure you are trying to optimize the right aspect of your game, is to profile it.

 it could be sound uncompression, or some of the actions that are taking up performances and not PlayMaker itself.

 for example, if you use the action FindGameObject, every frame on a large hierarchy, you will experience some perfs issues, because Unity own api to search a gameobject by name is slow.

Now if you profile this scene, your first guess as your profiler will show will be to say that PlayMaker is to blame because everything points to PlayMaker internal methods, but if you dig deeper, you'll see that it's actually the Unity api that is used by an action, itself used by PlayMaker that is the issue.

 tricky to debug indeed, especially when you have no experience in coding, it becomes obscur as to what exactly is the problem.


 Bye,

 Jean

Agreed. I always use the profiler before making any assumptions. Out of all my years in using playmaker not even the worst FSM's would give me severe frame drops the same way unoptimized assets would.

The only time I see playmaker becoming an issue is when you needlessly abuse actions on every frame. I've done a lot of research on optimization and most of my optimal FSM practices come from understanding Unity not playmaker. Playmaker only serves as the bridge that grants functionality based on certain parameters you need to build for (identical to programming only predefined) 

Although picking up playmaker can be very easy (for some) having optimal results can be a matter of checking the right options in playmaker (or Unity) since the game engine demands this.

I remember during my newbie stages there was a case that I was experiencing SEVERE frame drops in a 2d mobile game i was developing. I was going nuts and thought it was playmaker since the profiler kept showing playmaker at the top of the list. After messing around more with unity i found the main problem.

This.




Unity would automatically convert the mesh type of each sprite and will add extra verts and tris per sprite mesh. This was very bad since I had a lot going on in my screen.


I then did this which gave me good results and lessen the amount of tris and verts per sprite mesh. The game was running at an amazing 60FPS on lowend devices.



All I had to do was select the sprite files and change the mesh type to full rect which made plane meshes for EVERY object which is only 4 verts and 2 tris each.



So whenever I have to optimize anything in a game 90% of the time its never a playmaker issue. Aside from profiling, understanding Unity (And your job role lol) is most definitely the first step in making anything optimal including FSMs.


 

[jeanfabre]

Hi,

 Thanks for sharing your experience, you are spot on on all your points. When I benchmarks PlayMaker against the Unity 2d platformer, I had the same conclusions. you can mess up your game performances with just Unity fine it takes a lot of experience and perseverance to optimize, gain the knowledge of where to look, how to solve things, etc etc. PlayMaker is very light bridge between Unity api and developers, thus the impact of PlayMaker is really small.

 Bye,

 Jean