As I concluded before, the best part of PlayMaker can give you nice visual overview of a finite-state machine (FSM), an oft used construct in rapid game prototyping.
This overview is something you surely don’t have when implementing a FSM in code.
However, from a programmer’s point of view, it’s quite clumsy to use PlayMaker to add behavior to the FSM’s states.
The solution is to take the best of both worlds: creating states and connecting them using PlayMaker, and writing the states’ behavior in your favorite Unity programming language.
To be able to do this, you have to add events in PlayMaker’s FSM Editor. These events can be used to add the state transitions in a visual way, and can be raised in your code.
The following is an example state class to use with PlayMaker:
using UnityEngine;
using HutongGames.PlayMaker;
public class Idle : MonoBehaviour {
private PlayMakerFSM fsm;
// Use this for initialization
public virtual void Start () {
// Initialize the behavior
fsm = (PlayMakerFSM)gameObject.GetComponent(typeof(PlayMakerFSM));
}
// Update code goes here
public virtual void Update() {
// Call this to raise the event of your choice
fsm.Fsm.Event("FINISHED");
}
}
To add this code to a state, you need to add a ScriptControl Action in the FSM Editor, and then add a script.
Feel free to comment to this post and share your experiences!
Interesting approach, sounds like a good option to integrate existing code in a Playmaker FSM – you can do a similar thing with the ‘Enable Behavior’ action. The disadvantage with this approach is that you lose the quick reference to what the state is doing by simply clicking on it.
I think we could really use some more algorithmic actions in PlayMaker to avoid so much state fragmentation that things get crowded and hard to understand, I’ve already released one such action and am currently working on others.
Thanks for your reaction. The advantage of using the approach Jonas described is that you can use it to trigger state transitions from your code. This would probably be possible with the ‘Enable Behavior’ action as well though, but then you’ll need to add a script for each state to your game object.
Custom actions may improve the functionality and will sure be great for those who’re not programmers and want to get more out of Unity, but for the rest I think custom code will remain a must if anything a little bit complex needs to be created.
Hi,
Yes, I also find this approach convenient. Tho I don’t think the fsm variable should be public, it should be private since you anyway set it in Start()
Maybe I am missing the point here. Willing to learn 🙂
I also use another technic for quick communication the other way, that is from playmaker to a script, by sending a message and get an answer from it. It’s explained here:
http://hutonggames.com/playmakerforum/index.php?topic=95.msg346#msg346
You might find this also useful.
Bye,
Jean
Hi Jean,
Thanks for the comment.
You are right, the fsm variable should not be public.
I have edited the post.
For some things it’s indeed interesting to get values from your script into PlayMaker, for example if you using more actions in the FSM editor.
Hello,
Can you please make a small tutorial (or re-explain a bit deeper) this approach. It’s provably me but I still don’t get it.
Tanks in advance. 🙂
For tutorials on PlayMaker, check out http://www.digitalwarlords.com
-Also key misconception
–PlayMaker can be used by itself to make something but it does not own programing. Programing will always be important.
THE POWER comes from a standard communication layer between a designer/scriptor/artist and programer. You can very easily create your own scripts that just have ACTIONS that communicate with them.
Hi Jonas, do you find any performance different between using “Add a script” vs “Enable behavior”? A little concern about “AddComponent may bring bad performance for mobile platform (before I do more profiling myself). Any experience to share?