PLAYMAKER TIPS
It’s easy to mistake PlayMaker for a visual scripting tool a la Kismet or uScript, but it is much, much more than that. In fact, I can see a visual scripting tool being used hand in hand with PlayMaker. PM is a tool to help you create state machines. It encourages you to develop games using a slightly different mentality–use states for everything! Of course, it’s not feasible to put all the weight on PM, but there are specific scenarios in which it shines. For example, handling input! Here are some quick tips to get the most out of PlayMaker:
1. Write your own actions: This one is important. It’s easy to get lazy and just use their built-in actions, but it’s rarely the way to go. There are some helpful actions built in that make things faster, but I tend not to use anything besides the iTween action set and maybe bool tests, but even that is rare. By writing your own actions, you do more than one thing in a state, and still have control of execution order, which is not something you can guarantee by stacking actions in a state. This means that you don’t have to separate your states into sub-states, which means a cleaner FSM and smarter use of resources.
2. Integrate it: This one can get confusing. Classes that derive from FsmStateAction are not as easily accessible as MonoBehaviours or other classes, because they are meant to work within the scope of the FSM. However, sometimes you need to trigger methods inside a StateAction to handle data before firing off an event. A great way to do this is to use C# Events and Listeners. Yeah, it may seem a bit awkward at first, but think of it as separating out your PlayMaker Events and your other Game Events.
3. Use multiple FSMs. You can attach several FSMs to the same GameObject. The downside to this is that you can’t easily reference the PlayMakerFSM component from outside the FSM, because there is no way to access it directly by name. You have to get the list/array of PlayMakerFSM components, then loop through them and check for a specific name. The upside is being able to keep functionality separate but dependent on the same variables. For example in input, you can have an FSM listening for input and updating the input axis variables, while a different FSM handles moving the character per the variables, and then you can have a third FSM to handle animation. You could write a big Action to handle all of this for you, but keeping functionality grouped in logical ways can help modify parts of the FSM without breaking everything else. Just be sure to keep track of where the variables are being updated, you don’t want race conditions!
