Hi,
You need to isolate your performance issue, that's critical in order to make progress in improving your perfs. This is usually a seperate topic than how to build nice fsm, PlayMaker is in 99% of the cases not the issue, so make sure you analyze properly what needs to be done. Don't touch something that works, and if you don't know why there is a perf issue, you may end up touching something unrelated.
Profiling and Debugging:
to isolate an perf issue that I can't pin point using the profiler, I make a copy of the project and break the project apart until I find the moment the perfs is back by disabling features one by one.
that's the hard way when everything else failed, and is usually a sign that you have waited too long before checking perfs
usually, you build a feature, you test it and check the perf, and built it on the targeted platform and check it works and performs fine also on the platform. if it doesn't then you have less to concentrate about.
if your project is already too big, indeed disabling features one by one is the key.
the profiler will help you understand if the issue is in the 3d or asset realm, which is usually the case. If it turns out it's the scripts that causes perfs, then make sure you do a deep profiling and go all the way down to the last possible node that gives you a perf issue, you'll need to pass all the playmaker framework to get to the actual action line of code that is the source of the proble, which usually is a unity api that takes a lot of time to process, and you are doing that in the game loop in all your ennemies for example.
State Management:
Always name your state properly and consistently across your projects and work in general. if you have too many states, you split it in several smaller fsm, and you synchronize them via global events or targeted events.
an efficient fsm is usually one that you don't need to zoom out so much that you can't read the states and transitions anymore, that's basically a good indicator that it should be split, there are exceptions of course, and for sure, as you gain experience, a bigger fsm isn't necessarly a bad thing anymore. I have some pretty big fsms, but they act as "masters", for a given process, like a wizard editor to achive a complex feature, you have many steps, and it make sense to have one fsm that represent the current step of your wizard, and a lot of other fsm that use this master fsm to know what to do, the master fsm can also dispatch events obviously.
Event Handling:
Again, proper and consistent naming is crucial... don't fear long events name, and use '/' as a separator ( it will organize in hierarchy your event in the dropdowns), like "PLAYER / WEAPON / CHANGE" "PLAYER / WEAPON / RELOAD"
Variable Optimization:
I extensivly wrote on this topic, and actually came up with a concept called "META FSM" which is an fsm that does nothing but host a set of variables, that other fsm can use as a repository to get them values. your player will have many features that share the same values, when that's the case, have one fsm at the top of your player prefab, and all the other fsm use GetFsmXXX to get some value to work with. they should not use "SetFsmXXX" to write back, but instead call an event "SET SOME VALUE" and send it to their instance so that every other fsm that use this value can be notified of a change, which makes your system a lot more efficient ( no need to check for variables every frames for example)
https://hutonggames.com/playmakerforum/index.php?topic=21187.msg93550#msg93550Bye
Jean
