PlayMaker 2

About PlayMaker 2 – Unity Editor Tool & Plugin

PlayMaker 2 Unity Asset Overview

In my 8+ years working inside Unity, I have watched visual scripting tools evolve from simple node graphs into full production pipelines. PlayMaker 2 continues the tradition of its predecessor by centering developer logic around an intuitive, high-performance Finite State Machine (FSM) paradigm. Rather than treating visual scripting as a replacement for standard programming, PlayMaker 2 acts as a bridge between visual node routing, event handling, and custom C# scripts.

Honestly, the biggest problem PlayMaker 2 solves is structural friction. In traditional codebases, managing state transitions for player controllers, UI flows, and game loops often results in sprawling switch statements or fragmented boolean flags. PlayMaker 2 encapsulates state logic into isolated visual nodes, allowing developers to track execution paths in real-time. Whether you are building UI state drivers, environment triggers, or full game loops, the FSM workflow keeps your project architecture decoupled and easy to read.

Core Technical Features & Highlights

PlayMaker 2 brings several engine-level refinements and under-the-hood optimizations over classic iterations. It avoids runtime string reflection where possible, using cached event tables and direct action bindings to keep performance tight across platforms.

Key Technical Capabilities

• State Machine Execution: Node-based state logic with explicit transition events, global events, and nested FSM support.
• Custom Action API: Complete flexibility to extend the framework by writing custom FsmStateAction classes in C#.
• Realtime Visual Debugging: Live state highlighting, breakpoint setting, frame stepping, and variable inspection during active Play Mode.
• UI & Event System Integration: Built-in actions tailored for Unity's UI (uGUI), Canvas Group management, event triggers, and input processing.
• Template & Preset Architecture: Save modular state machines (e.g., door interaction, vehicle entry, generic button logic) into reusable templates across scenes.

Extending FSM Logic via C#

As a developer, I rarely rely 100% on pre-packaged visual nodes. The strength of PlayMaker 2 lies in how easily you can write custom actions to execute high-performance C# code within an FSM state. Below is an example of a custom action designed to apply a physics impulse while dispatching an FSM event upon completion:

using HutongGames.PlayMaker;
using UnityEngine;

[ActionCategory("Physics")]
[Tooltip("Applies an immediate impulse force to the target Rigidbody and finishes execution.")]
public class ApplyCustomImpulse : FsmStateAction
{
    [RequiredField]
    [CheckForComponent(typeof(Rigidbody))]
    public FsmOwnerDefault targetObject;

    public FsmVector3 impulseForce;

    public override void OnEnter()
    {
        GameObject go = Fsm.GetOwnerDefaultTarget(targetObject);
        if (go != null)
        {
            Rigidbody rb = go.GetComponent<Rigidbody>();
            if (rb != null)
            {
                rb.AddForce(impulseForce.Value, ForceMode.Impulse);
            }
        }

        // Signal that action execution is complete for this state
        Finish();
    }
}

Ideal Use Cases & Game Genres

PlayMaker 2 is versatile, but in my experience, it shines brightest in specific architectural roles across different game styles:

• UI State Controllers: Managing screens, menus, options overlays, and modal transitions. Visualizing UI flow in FSMs eliminates state overlap bugs.
• Mobile & Hyper-Casual Mechanics: Rapid creation of instant replay loops, win/fail triggers, level progression, and simple touchscreen inputs.
• Indie RPG Systems: Handling branching dialogue setups, non-player character (NPC) behavior states (Idle, Alert, Attack), and quest objective flags.
• Interactive Environments: Configuring scene triggers, sliding doors, pickups, lights, and environmental puzzles without writing unique one-off monobehaviours.

Quick-Start Unity Setup & Integration Guide

Integrating PlayMaker 2 into an existing or new Unity project is straightforward. Here is the workflow I follow to ensure clean integration without cluttering scene hierarchies.

1. Initial Window & Layout Setup

Once imported, open the main editor window via PlayMaker > PlayMaker Editor from the top Unity menu bar. Dock the main state graph window alongside your Scene view for fluid visual testing.

2. Adding an FSM Component

Select any target GameObject in your hierarchy, right-click inside the PlayMaker Graph window, and choose Add FSM. This automatically attaches a PlayMakerFSM component to your object.

3. Interfacing C# Systems with FSM Events

If you have existing C# manager scripts, you don't need to rewrite them. You can easily trigger state transitions inside PlayMaker 2 directly from standard C# code using the PlayMakerFSM class interface:

using UnityEngine;
using HutongGames.PlayMaker;

public class PlayerHealthManager : MonoBehaviour
{
    [SerializeField] private PlayMakerFSM playerStateFSM;
    [SerializeField] private float maxHealth = 100f;
    private float currentHealth;

    private void Start()
    {
        currentHealth = maxHealth;
    }

    public void ReceiveDamage(float amount)
    {
        currentHealth -= amount;

        // Update FSM float variable directly
        playerStateFSM.FsmVariables.GetFsmFloat("CurrentHealth").Value = currentHealth;

        if (currentHealth <= 0f)
        {
            // Send global or local transition event to the FSM
            playerStateFSM.SendEvent("PLAYER_DIED");
        }
    }
}

Pros & Cons Assessment

Pros

• Instant Visual Traceability: Debugging logic visually during runtime saves hours of stepping through break points in Visual Studio.
• Clean Decoupling: Isolates complex animation states, audio triggers, and environment interactions away from core C# systems.
• Extremely Extensible: Writing custom C# actions takes minutes and exposes full Unity API access directly into the FSM editor.
• Production-Proven: Used in dozens of high-profile commercial titles, proving its reliability across platforms.

Cons

• Potential Graph Clutter: Large, complex sub-systems can become visual spaghetti if you don't break them down into templates or nested sub-FSMs.
• Memory Allocation Overhead: Unoptimized FSMs using high-frequency per-frame updating actions can generate minor garbage collection (GC) pressure if not tuned carefully.

Developers Who Downloaded This Also Downloaded

Related Unity Tools Assets