New Nodes

State Designer supports two workflows for custom Actions and Conditions: a GameObject workflow and an ECS workflow. Both are first-class options, and you can choose the one that best fits your project, team, and performance goals.

GameObject nodes are usually the easiest to build. A custom GameObject action derives from Action, and a custom GameObject condition derives from Condition. The API is very familiar if you’re used to MonoBehaviour-style callbacks (OnStart, OnUpdate, OnEnd, IsValid, etc.).

ECS nodes are designed for high-performance, data-oriented execution. A custom ECS action derives from ECSAction<TSystem, TBufferElement, TComponentFlag>, and a custom ECS condition derives from ECSCondition<TSystem, TBufferElement, TComponentFlag>. These nodes write data into ECS buffers/components, and your ECS systems/jobs process that data.

GameObject Workflow Advantages

• Fastest to author and iterate on.
• Familiar callback-style API.
• Easier to work with scene objects and existing Unity APIs.
• Shared Variable usage is straightforward for gameplay scripting.
• Still benefits from DOTS-backed graph traversal and transition evaluation.

ECS Workflow Advantages

• Built for Burst + Jobs workflows.
• Can schedule work in parallel across many entities.
• Better fit for large-scale simulations and heavy per-frame logic.
• Encourages data-oriented patterns that scale well.

Which One Should You Use?

As a practical rule of thumb, if you have under ~50 active state machine agents and your custom logic isn’t computationally heavy, start with the GameObject workflow. It’s usually faster to build, easier to debug, and often performs well enough. If profiling later shows a bottleneck, migrate that specific action or condition to ECS. That hybrid approach usually gives the best balance: quick development up front, targeted optimization where it actually matters.