Startup data: granting abilities from a data asset

Commit 5960ce1 + work in progress · DataAsset_StartupDataBase, DataAsset_HeroStartupData, AWarriorBaseCharacter::CharacterStartupData · 9 min

The data asset

UCLASS()
class UDataAsset_StartupDataBase : public UDataAsset
{
public:
    virtual void GiveToAbilitySystemComponent(UWarriorAbilitySystemComponent* InASCToGive, int32 ApplyLevel = 1);
protected:
    UPROPERTY(EditDefaultsOnly, Category = "Statup Data")
    TArray<TSubclassOf<UWarriorGameplayAbility>> ActivatedOnGivenAbilities;
    UPROPERTY(EditDefaultsOnly, Category = "Statup Data")
    TArray<TSubclassOf<UWarriorGameplayAbility>> ReactiveAbilities;

    void GrantAbilities(const TArray<TSubclassOf<UWarriorGameplayAbility>>& InAbilitiesToGive,
                        UWarriorAbilitySystemComponent* InASCToGive, int32 ApplyLevel = 1);
};

• TSubclassOf<UWarriorGameplayAbility>: a class, not an object. You're listing which kinds of ability to grant; the ability system creates the instances. The template also filters the editor dropdown to only show UWarriorGameplayAbility subclasses. It's the same <T> idea as the templates page.
• Two lists, two jobs:
  • ActivatedOnGiven: abilities with the OnGiven policy that run once, straight away. The axe spawn goes here.
  • Reactive: granted now, but they wait for something to trigger them. Think hit reactions and death, which react to events.
  In code, both lists are granted the same way. The split is so designers know where to put things. The ability's own activation policy (last lesson) decides what happens once it's granted.
• virtual Give…: the hero version (UDataAsset_HeroStartupData, empty for now) can override it to grant hero-only extras later, calling Super:: for the shared part.
• Base + hero subclass again: the same pattern as characters, anim instances and weapons. Enemies will get their own subclass.

Granting: the loop

for (const TSubclassOf<UWarriorGameplayAbility>& Ability : InAbilitiesToGive)
{
    if (!Ability) continue;                          // skip an empty slot in the editor list

    FGameplayAbilitySpec AbilitySpec(Ability);
    AbilitySpec.SourceObject = InASCToGive->GetAvatarActor();
    AbilitySpec.Level = ApplyLevel;
    InASCToGive->GiveAbility(AbilitySpec);
}

• The spec, from the last lesson: "this ability, at this level, on this ASC". You build it, then GiveAbility it.
• SourceObject: records what granted this ability. Inside the ability you can read it back with GetCurrentSourceObject(). Using the avatar (the character) here means "the character itself granted it". It becomes more useful when a weapon grants abilities: the ability can then find out which weapon it belongs to.
• Level: GAS abilities have levels, so damage and costs can scale by level. The default of 1 is fine for now.
• if (!Ability) continue;: someone added a slot to the array and left it empty. Skip it, don't crash.
• The loop is by const reference (why).

The character side (work in progress)

// WarriorBaseCharacter.h
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "CharacterData")
TSoftObjectPtr<UDataAsset_StartupDataBase> CharacterStartupData;

// AWarriorBaseCharacter::PossessedBy
WarriorAbilitySystemComponent->InitAbilityActorInfo(this, this);
ensureMsgf(!CharacterStartupData.IsNull(), TEXT("Forgot to assign startup data to %s"), *GetName());

// AWarriorHeroCharacter::PossessedBy
Super::PossessedBy(NewController);
if (!CharacterStartupData.IsNull())
    if (UDataAsset_StartupDataBase* LoadedData = CharacterStartupData.LoadSynchronous())
        LoadedData->GiveToAbilitySystemComponent(WarriorAbilitySystemComponent);

Why a soft pointer?

This is your mock Q9 in real code. The startup data lists abilities; the abilities reference montages, weapon Blueprints, meshes and sounds. A hard pointer would load all of that whenever the character class loads, even in a menu. A TSoftObjectPtr stores only the asset's path, so nothing loads until you ask.

• IsNull(): "was a path assigned at all?" It's different from "is it loaded yet?", which is IsValid() / Get() returning non-null.
• LoadSynchronous(): "load it now, and wait". Simple, but the game freezes until it's loaded. For the one player at spawn that's acceptable. For enemies spawning mid-fight it would hitch, so the usual answer there is an async load (UAssetManager / FStreamableManager) with a callback when it's ready.

Your ensure, in real code

The base character checks with ensureMsgf: if nobody assigned startup data, you get a message with a callstack in the log, once, and the game keeps running. The character just starts without abilities. That's the right choice here: a missing asset is a mistake to report, not a reason to crash the editor. Compare checkf on the input config, where the game can't run at all without it.

%s + *GetName() puts the character's name in the message, so you know which Blueprint is missing its data. (The same *-on-FString trick as the Debug helper.)

Order matters: why grant after Super::PossessedBy

The base PossessedBy calls InitAbilityActorInfo. Granting needs that done first: an OnGiven ability activates during GiveAbility, and activation needs to know the owner and avatar. Calling Super first guarantees the ASC is set up before anything is granted. Swap the order and the axe-spawn ability would try to run without an avatar.