In this lesson, you will learn how to balance memory efficiency and state persistence by choosing the correct InstancingPolicy for your Gameplay Abilities.
When defining a UGameplayAbility, the InstancingPolicy determines how the engine manages the lifecycle and memory footprint of that ability class when it is activated. Choosing the right policy is a critical architectural decision in the Gameplay Ability System (GAS).
Non-Instanced (InstancedNone)
This is the most memory-efficient policy. When activated, the ability does not create a new object; instead, it runs its logic directly from the Class Default Object (CDO). Because there is no unique instance, you cannot store any variables (like a timer or a target reference) on the ability itself. This is perfect for simple, stateless abilities, such as an instant "Heal" or a quick "Fireball" launch where the logic is purely procedural and short-lived.
Instanced Per-Actor (InstancedPerActor)
When using this policy, GAS creates exactly one instance of the ability per AbilitySystemComponent (ASC). The instance persists as long as the actor exists. This is ideal for abilities that need to maintain state across multiple activations, such as a "Mana Shield" that needs to track how much damage it has absorbed, or a toggleable "Sprint" ability that keeps track of the current duration.
Instanced Per-Execution (InstancedPerActor vs InstancedPerExecution)
While InstancedPerActor keeps state, it is limited to one instance at a time. If you need to run the same ability multiple times concurrently (e.g., a "Summon" ability that spawns multiple minions), you should use InstancedPerExecution. This policy creates a unique instance of the ability object every time it is activated. This allows each execution to track its own unique Ability Tasks, local variables, and logic flow independently without interfering with other active instances of the same ability.
// Set in the constructor of your Ability class
UMyAbility::UMyAbility()
{
// Best for complex logic needing state tracking per-trigger
InstancingPolicy = EGameplayAbilityInstancingPolicy::InstancedPerExecution;
}
By choosing InstancedNone for stateless effects and InstancedPerExecution for complex, concurrent tasks, you ensure your game remains performant while maintaining the flexibility required for intricate gameplay mechanics.
Key Takeaway: Use InstancedNone for stateless performance, InstancedPerActor for persistent state, and InstancedPerExecution for independent, concurrent ability logic.