We are currently building game systems relying on Gameplay Abilities.
We are noticing that there seems to be a difference between creating a regular blueprint of class Gameplay Ability, versus creating a Gameplay Ability Blueprint (which also ends up being of Gameplay Ability class)
Noticeable differences:
In the content browser, the regular blueprint appears as Blueprint Class while the other appears as a Gameplay Ability Blueprint (image 2)
The Blueprint has an Event Graph while the Gameplay Ability Blueprint has a Gameplay Ability Graph though they are both of Gameplay Ability class (image 3)
I’m sure there must be more, but I just want to illustrate my point.
What we are not sure of is whether there is a functional difference between the 2 or if they are interchangeable?
As you mentioned, both creation paths target the UGameplayAbility class. The key difference lies in how the Blueprint is created behind the scenes.
When you create a GameplayAbility blueprint, the editor creates a UBlueprint that internally references the class you selected in the widget picker. The UBlueprint is created by the UBlueprintFactory class. On the other hand, when you create the Blueprint asset from the Blueprints or Gameplay section, it generates a UGameplayAbilityBlueprint managed by the UGameplayAbilitiesBlueprintFactory. These factory classes exist to add specialized behavior to certain Blueprint types when needed. This is done inside the virtual UFactory::FactoryCreateNew method.
When an ability is created from the Blueprint or Gameplay section, UGameplayAbilitiesBlueprintFactory::FactoryCreateNew gets called. The only extra work that is done is that it generates a custom graph called GameplayAbilityGraph instead of the standard EventGraph. It also generated in the graph the ActivateAbility and OnEndAbility events by default to help the user. If you want to see all the code as mentioned before, it is inside the UGameplayAbilitiesBlueprintFactory::FactoryCreateNew class.
In summary, while both approaches manage a UGameplayAbility, using the Gameplay/Blueprint tab provides a slightly more specialized setup tailored for the Gameplay Ability System, and is generally the preferred method. Unreal devs might expand it in the future.
There is no functional difference at the moment. All internal casts and checks are still performed against UBlueprint, not UGameplayAbilityBlueprint. The main difference is simply that they are different classes (UBlueprint vs. UGameplayAbilityBlueprint) and that they use different Blueprint Editors.
Personally, I would recommend creating them from the Gameplay tab for future-proofing, in case Epic adds additional functionality later. But right now this is just a precaution, not something that provides a real usability benefit.
I believe that in older versions of Unreal you couldn’t select a subclass of GameplayAbility when creating them from the Gameplay tab, so creating them through the standard Blueprint menu made sense back then — but that’s no longer the case.