Actions

An Action is where the actual behavior happens. If a State is mostly a container (the “mode” your object is in), then actions are the pieces that do the work while that state is active. This is usually where most of your customization happens.

In practical terms, actions are the part of the system that make things happen. They can play animations, move something, update values, trigger effects, call into other systems, or perform game-specific logic. When people want to add new behavior, they usually create a new action and place it inside a state.

How Actions Relate to States and Conditions

Actions make the most sense when you look at them together with states and conditions. A State groups behavior together. It gives you a clean place to define what should happen in a specific mode, such as IdlePatrol, or Attack. The Actions inside that state are the behavior that runs for that mode. Conditions are separate from actions and are used to decide whether a transition is valid (in other words, whether the state machine should switch to another state).

A simple way to think about the relationship is:

  • The state is the container.
  • The action is the behavior.
  • The condition is the check that decides when to switch.

This separation is important because it keeps your graph easier to read and easier to maintain. Actions focus on “doing,” while conditions focus on “deciding.”

What Actions Are Used For

Actions are typically used for all of the “active” parts of your logic. For example, an action might handle playing an animation, setting a variable, moving toward a target, rotating a character, or triggering an event. The exact behavior depends on the action, but the role is always the same: actions are what make the state feel alive.

Because actions are attached to states, the same action type can often be reused in different places with different settings. That makes actions a strong building block for creating behavior without duplicating logic.

Actions Are Usually the Main Extension Point

This is one of the most important concepts for users to understand:

Most of the time, if you want to add new behavior, you should create a new Action, not a new State.

States are usually used to organize behavior into modes. Actions are where the behavior itself is implemented. This means actions are typically the main extension point for day-to-day gameplay logic. So if you find yourself asking, “How do I make this character do something new?”, the answer is usually “add or create an action.”

Actions vs Conditions

It is easy to mix up actions and conditions at first because both affect behavior, but they have different jobs.

An action should generally be responsible for the behavior you want to run while a state is active. A condition should generally be responsible for checking whether a transition should happen. If you are trying to decide whether to leave a state, that logic usually belongs in a condition, not in an action.

Keeping that split clear makes your state machine much easier to reason about later.

Designing Good Actions

Good actions tend to be focused. Instead of one action trying to do everything, it is usually better to create smaller actions that do one job well and then combine them inside a state. This keeps behavior more reusable and makes debugging easier because each action has a clear purpose. It also helps to think of states as composition points. You build up a state by combining actions, then use conditions to control when the machine moves to the next state.

Imagine a Chase state. The state itself is just the container for that behavior mode. Inside it, you might place actions that move toward a target and rotate to face it. Separately, transition conditions might check whether the target is close enough to switch to an Attack state, or whether the target was lost and should transition back to Patrol. In that example, the state organizes everything, the actions do the chase behavior, and the conditions decide when to leave chase.

New Actions

New actions can be created using the State Designer API. See the New GameObject Action and the New ECS Action page for more details.