Перед объявлением атрибутов, в .h файле своего сета необходимо объявить макросы 

// Uses macros from AttributeSet.h
#define ATTRIBUTE_ACCESSORS(ClassName, PropertyName) \
	GAMEPLAYATTRIBUTE_PROPERTY_GETTER(ClassName, PropertyName) \
	GAMEPLAYATTRIBUTE_VALUE_GETTER(PropertyName) \
	GAMEPLAYATTRIBUTE_VALUE_SETTER(PropertyName) \
	GAMEPLAYATTRIBUTE_VALUE_INITTER(PropertyName)

Реализацию макросов можно посмотреть в AttributeSet.h

Они позволяют автоматически генерировать геттер, сеттер и иниттер для атрибутов. Таким образом, для объявления атрибута достаточно следующего кода:

UPROPERTY(BlueprintReadOnly, Category = "Health", ReplicatedUsing = OnRep_Health)
FGameplayAttributeData Health;
ATTRIBUTE_ACCESSORS(UGDAttributeSetBase, Health)

После чего, для атрибута сразу будут доступны функции GetHealth(), SetHealth() и InitHealth().

Кратко пройдемся по доступному функционалу:

Duration Policy – тип эффекта: Instant, Duration или Infinite. Для Duration и Infinite доступна настройка периодичности. Если указан период, то эффект будет срабатывать как Instant раз в период на протяжении времени действия.

Duration Periodic эффект "кровотечение" с периодом 1 сек и длительностью 10 секунд будет наносить урон раз в секунду в течение 10 секунд

Components. Они определяют что делает GE при применении. Например: наложение, снятие или блокировка тега на цели, применение или снятие другого эффекта, выдача способности на время действия и так далее. Обычно доступных по умолчанию вариантов вполне достаточно, но при желании можно создать и кастомные компоненты, наследуясь от UGameplayEffectComponent.

Modifiers – единичные изменения атрибутов. Для каждого Modifier’а нужно указать атрибут, способ его изменения (добавление, умножение, замена значения), величину изменения (может быть как постоянной, так и зависеть от других атрибутов или передаваться как параметр при наложении GE), а также требования к тегам ASC-источника и ASC-цели, которые очень удобно использовать для создания системности геймплея. 

Например, персонаж не может использовать способности, если у него есть тег State.Dead, а эффект горения не применится на цель с тегом Immunity.Fire 

Executions – самый мощный способ которым GE может повлиять на ASC. Он позволяет изменять сразу несколько атрибутов по произвольным правилам. Для этого необходимо создать отдельный класс, наследованный от UGameplayEffectCalculation. Этот класс может “захватывать” указанные атрибуты, то есть иметь к ним доступ и возможность отслеживать их изменения. Таким образом появляется возможность рассчитывать модифицированное значение изменяемых атрибутов в зависимости от различных факторов, в том числе от значений других атрибутов. У этого инструмента есть ограничения. Например, отсутствие возможности предсказания и доступность только для Instanced и Periodic эффектов. 

По моему опыту, для абсолютного большинства эффектов достаточно использовать Modifiers: увеличение скорости на x% (бег), увеличение сопротивления к урону и всё в таком духе. Типичный случай, когда Execution может быть необходим – расчет урона. Он вполне может зависеть от большого количества факторов, причем не обязательно линейно: сопротивление урону цели, увеличение урона у источника, шанс критического урона, шанс уворота, наличие блока и так далее и так далее.

В контексте UGameplayEffectCalculation также стоит упомянуть про Modifier Magnitude Calculations (UGameplayModMagnitudeCalculation). Этот класс наследуется от UGameplayEffectCalculation, несколько менее мощный, но зато может быть предсказан при игре по сети, а также может быть использован для эффектов с любой Duration Policy. Основная цель класса – вернуть вычисленное значение атрибута. Аналогично UGameplayEffectCalculation, для этого могут захватываться другие атрибуты и выполняться произвольные манипуляции с ними.

Gameplay Cues. GC – еще одна сущность GAS, предназначенная для визуализации действия эффектов. Они не должны нести геймплейной логики. Подробнее про них поговорим в следующем разделе, а здесь ограничусь тем, что отмечу, что каждому GE можно привязать несколько GC.

Stacking. Отдельная категория настроек посвящена возможности сложения действия эффекта. Стаки могут накапливаться на источнике или же на цели. Среди настроек – максимальное количество стаков, а также способы обновления, сброса и исчезания стакающегося эффекта.

Чтобы разобраться что вообще делает GA, посмотрим на пример работы простой Gameplay Ability из упомянутой выше документации:

При вызове TryActivateAbility(), при условии, что ASC обладает способностью, переданной в параметрах, выполняется проверка CanActivateAbility() которая проверяет, может ли способность быть активирована. По умолчанию, CanActivateAbility() проверяет валидность основных сущностей, связанных со способностью, а также некоторые дефолтные вещи, такие как соответствие тегов (про это подробнее чуть ниже). 

Если проверка пройдена успешно, способность активируется и вызывается соответствующий ивент ActivateAbility(), который уже выполняет непосредственно логику способности. Логика может быть произвольной, но есть несколько элементов, которые стоит подсветить отдельно:

CommitAbility() – метод, отвечающий за использование ресурсов способностью. Он должен быть вызван вручную (не обязательно в начале выполнения способности) и пытается потратить ресурсы игрока, необходимые для использование способности (например, мана). Метод возвращает bool, характеризующий успешность. Если Commit не удался (например, недостаточно маны) – способность следует отменить. 

Далее идет основная логика способности, которая может быть произвольной. Для завершения способности необходимо вызвать EndAbility() в случае штатного завершения логики либо же CancelAbility(), если способность была прервана по какой-либо причине. В целом, эти методы весьма схожи но использование CancelAbility() может быть полезно чтобы развести логику завершения способности на “корректную” и “не корректную”.

Немного поговорим про настройки GA. По ним пройдемся поверхностно, поскольку информации там хватит на отдельную статью. За подробностями, как и ранее, отсылаю к документации tranek. 

Во-первых, это те самые теги способности. Они разбиты на кучу категорий и совокупно позволяют задать практически любые правила по которым способность может или не может быть использована. 

Например, AbilityTags: это теги, которыми обладает способность и которые описывают её; CancelAbilitiesWithTag: способности с этими тегами будут отменены при активации текущей способности; BlockAbilitiesWithTag: способности с этими тегами нельзя активировать пока активна текущая способность и так далее. Про все рассказывать смысла особого не вижу, поскольку их описания говорят сами за себя. 

Во-вторых, это набор сетевых настроек (були и енумы). Опять же, подробный рассказ о них всех рискует вырасти до неприличных размеров, так что просто приведу их список.

Отдельно подчеркну, что при создании сетевой игры с использованием GAS нужно тщательно за всем этим следить, потому что дебажить потом сетевое взаимодействие в поисках проблемы – удовольствие малоприятное.

В-третьих, стоимость и кулдаун способностей. Данные механики реализуются при помощи особых GE, указываемых в соответствующих полях CostGameplayEffectClass и CooldownGameplayEffectClass. Cost GE – это Instant эффект, который снимает заданное количество некоторого атрибута (опять же банальный пример – мана), а Cooldown GE – Duration эффект, который висит на обладателе ASC заданное время и блокирует повторное применение способности. 

При активации способности ( UGameplayAbility::Activate() ) вызываются функции UGameplayAbility::CheckCost() и UGameplayAbility::CheckCooldown(), которые проверяют, соответственно, наличие нужного количества атрибута и отсутствие кулдаун-эффекта. При невыполнении этих требований способность не активируется.

Для списания стоимости способности и применения кулдауна можно вызвать GameplayAbility::CommitCost() и UGameplayAbility::CommitCooldown(). Эти функции могут быть использованы по отдельности (если необходимо выполнить их в разное время), либо же можно просто вызвать UGameplayAbility::CommitAbility(), которая вызывает обе эти функции.

Для создания пассивной способности понадобится оверрайднуть метод UGameplayAbility::OnAvatarSet(), выполнив в нем TryActivateAbility(). Таким образом, способность сразу активируется и будет выполнять свою логику. Для разделения активных и пассивных способностей можно, например, ввести переменную bool bActivateAbilityOnGranted, определяющий, нужно ли активировать способность в OnAvatarSet() 

void UGameplayAbility::OnAvatarSet(const FGameplayAbilityActorInfo* ActorInfo, const  FGameplayAbilitySpec& Spec)
{
  //Projects may want to initiate passives or do other "BeginPlay" type of logic here.  
}

#include ...

#define ATTRIBUTE_ACCESSORS(ClassName, PropertyName) \
	GAMEPLAYATTRIBUTE_PROPERTY_GETTER(ClassName, PropertyName) \
	GAMEPLAYATTRIBUTE_VALUE_GETTER(PropertyName) \
	GAMEPLAYATTRIBUTE_VALUE_SETTER(PropertyName) \
	GAMEPLAYATTRIBUTE_VALUE_INITTER(PropertyName)

UCLASS()
class GASEXAMPLE_API UExampleAttributeSet : public UAttributeSet
{
	GENERATED_BODY()

public:
	UPROPERTY(BlueprintReadOnly, Category = "Attributes | Stats")
	FGameplayAttributeData Health = 100.f;
	ATTRIBUTE_ACCESSORS(UExampleAttributeSet, Health)
	UPROPERTY(BlueprintReadOnly, Category = "Attributes | Stats")
	FGameplayAttributeData MaxHealth = 100.f;
	ATTRIBUTE_ACCESSORS(UExampleAttributeSet, MaxHealth)

	UPROPERTY(BlueprintReadOnly, Category = "Attributes | Stats")
	FGameplayAttributeData Mana = 100.f;
	ATTRIBUTE_ACCESSORS(UExampleAttributeSet, Mana)
	UPROPERTY(BlueprintReadOnly, Category = "Attributes | Stats")
	FGameplayAttributeData MaxMana = 100.f;
	ATTRIBUTE_ACCESSORS(UExampleAttributeSet, MaxMana)

	UPROPERTY(BlueprintReadOnly, Category = "Attributes | Damage")
	FGameplayAttributeData DamageMultiplier = 1.f;
	ATTRIBUTE_ACCESSORS(UExampleAttributeSet, DamageMultiplier)
};

Для простоты, значения атрибутов я инициализирую сразу, но в настоящем проекте дополнительно может присутствовать метод, выполняющий инициализацию атрибутов любым другим способом (из DT или внешней конфиг-таблицы) и вызывающийся при инициализации персонажа.

//ExampleAbilitySystemComponent.h

#include ...

UCLASS()
class GASEXAMPLE_API UExampleAbilitySystemComponent : public UAbilitySystemComponent
{
	GENERATED_BODY()

	UExampleAbilitySystemComponent();
}


//ExampleAbilitySystemComponent.cpp

UExampleAbilitySystemComponent::UExampleAbilitySystemComponent()
{
	AddSet<UExampleAttributeSet>();
}

Опять же, добавлять AttributeSet можно и в других местах. Например, в той же инициализации персонажа. Причем, в таком случае, на персонаже можно указать какие именно сеты добавлять.

//AGASExampleCharacter.h

class AGASExampleCharacter : public ACharacter
{
    //...
    //Abilities that will be granted to character on game start
  	UPROPERTY(EditDefaultsOnly, Category = "Abilities")
	TArray<TSubclassOf<UGameplayAbility>> GAsToGrant;
	//Effects that will be applied to character on game start
	UPROPERTY(EditDefaultsOnly, Category = "Abilities")
	TArray<TSubclassOf<UGameplayEffect>> GEsToApply;
    //...
}


//AGASExampleCharacter.cpp
void AGASExampleCharacter::BeginPlay()
{
  //...
  
    if (!ASC)
		return;

	for (TSubclassOf<UGameplayAbility>& GAClass : GAsToGrant)
	{
		FGameplayAbilitySpec GASpec = FGameplayAbilitySpec(GAClass);
		GASpec.SourceObject = this;
		ASC->GiveAbility(GASpec);
	}

	for (TSubclassOf<UGameplayEffect>& GEClass : GEsToApply)
	{
		FGameplayEffectSpec GESpec = FGameplayEffectSpec(GEClass->GetDefaultObject<UGameplayEffect>(), ASC->MakeEffectContext());
		ASC->ApplyGameplayEffectSpecToSelf(GESpec);
	}
}

Начнем с виджета. Заводим UserWidget и добавляем туда Progress Bar'ы для здоровья и маны:

Заведем в нём функции для обновления значений в обоих ProgressBar'ах:

Создаем WidgetComponent, указываем у него в Widget Class виджет, созданный на предыдущем шаге и подписываемся на обновления здоровья и маны:

Для отслеживания изменения атрибута в данном случае мы использовали AbilityTask'у WaitForAttributeChange. Можно было воспользоваться напрямую функцией GetGameplayAttributeValueChangeDelegate, которую я упоминал в разделе про атрибуты, но это потребовало бы немного больше заморочек в плюсовой части проекта. А эта таска делает буквально то же самое (в чем любопытный читатель может убедиться, открыв её код), при этом еще и наглядно демонстрируя как можно использовать AbilityTask'и.

Для начала создаем два InputAction'а с триггером Pressed и добавляем их в Input Mapping, уже присутствующий в проекте. Назначаем этим действиям инпуты, у меня это клавиши F и R.

Читателям, не знакомым с тем, что такое все эти инпут экшены и маппинги, настоятельно рекомендую ознакомиться с Enhanced Input плагином, поскольку в UE5 это основной способ взаимодействия с инпутом.

Далее в нашем персонаже AGASExampleCharacter заводим поля, в которые назначим наши InputAction'ы (по аналогии с полями, которые там присутствуют изначально)

/** Use damage spell Input Action */
UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = Input, meta = (AllowPrivateAccess = "true"))
UInputAction* UseSpellAction;
/** Apply increased damage buff Input Action */
UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = Input, meta = (AllowPrivateAccess = "true"))
UInputAction* ApplyBuffAction;

и функции-реакции на инпуты

UFUNCTION(BlueprintImplementableEvent)
void UseSpell(const FInputActionValue& Value);
UFUNCTION(BlueprintImplementableEvent)
void ApplyBuff(const FInputActionValue& Value);

Функции я сделал BlueprintImplementableEvent'ами, чтобы в них можно было удобно добавить любую BP-логику. Осталось только подписать вызов функций на наш инпут. Добавляем в функцию SetupPlayerInputComponent() строчки

void AGASExampleCharacter::SetupPlayerInputComponent(UInputComponent* PlayerInputComponent)
{
  //...

  EnhancedInputComponent->BindAction(UseSpellAction, ETriggerEvent::Started, this, &AGASExampleCharacter::UseSpell);
  EnhancedInputComponent->BindAction(ApplyBuffAction, ETriggerEvent::Started, this, &AGASExampleCharacter::ApplyBuff);

  //...
}

Опять же, там уже привязаны функции под все остальные инпуты, так что действуем по аналогии или, выражаясь умными словами, соблюдаем консистентность.

Начнем с GE_IncreasedDamage, поскольку он проще. По сути, этот эффект просто должен временно изменить значение атрибута DamageMultiplier. Итак, создаем блюпринт, наследуемый от GameplayEffect; меняем Duration Policy на Has Duration; выставляем длительность 3 секунды; добавляем Modifier и настраиваем его как на показано на картинке ниже: модифицируемый атрибут – DamageMultiplier, действие – Override, значение – 2.

Получившийся эффект при применении сделает атрибут DamageMultiplier равным 2, а через 3 секунды пропадет, вернув атрибуту значение по умолчанию (1).

Теперь перейдем к урону. Поскольку величина урона должна рассчитываться с учетом дополнительной информации (значения атрибута DamageMultiplier), для GE_Damage нам потребуется ModifierMagnitudeCalculation. Создадим новый класс, наследуемый от UGameplayModMagnitudeCalculation. В нем нам необходимо завести поля для отслеживаемых атрибутов и переопределить конструктор и функцию CalculateBaseMagnitude_Implementation():

//MMC_Damage.h
#include ...

UCLASS()
class GASEXAMPLE_API UMMC_Damage : public UGameplayModMagnitudeCalculation
{
	GENERATED_BODY()

	FGameplayEffectAttributeCaptureDefinition DmgMultDef;
	
	UMMC_Damage();

	virtual float CalculateBaseMagnitude_Implementation(const FGameplayEffectSpec& Spec) const override;
};

//MMC_Damage.cpp
#include ...

UMMC_Damage::UMMC_Damage()
{
	DmgMultDef.AttributeToCapture = UExampleAttributeSet::GetDamageMultiplierAttribute();
	DmgMultDef.AttributeSource = EGameplayEffectAttributeCaptureSource::Source;
	DmgMultDef.bSnapshot = false;

	RelevantAttributesToCapture.Add(DmgMultDef);
}

float UMMC_Damage::CalculateBaseMagnitude_Implementation(const FGameplayEffectSpec& Spec) const
{
	FAggregatorEvaluateParameters EvaluationParameters;
	float BaseDamage = -30.f;
	float DmgMult = 1.f;
	GetCapturedAttributeMagnitude(DmgMultDef, Spec, EvaluationParameters, DmgMult);
	return BaseDamage * DmgMult;
}

В конструкторе мы настроили захват нашего атрибута DamageMultiplier, а в CalculateBaseMagnitude_Implementation() выполняем расчет урона, перемножая базовый урон (который в данном примере я просто захардкодил) и множитель урона.

Снова создаем Gameplay Effect, в этот раз GE_Damage. Duration Policy у него оставляем Instant, добавляем Modifier, в котором Magnitude Calculation Type устанавливаем на Custom Calculation Class и выбираем созданный на предыдущем шаге MMC_Damage в качестве Calculation Class:

Таким образом, при применении GE_Damage, цели будет наноситься урон, зависящий от DamageMultiplier.

Теперь, когда нужные эффекты созданы, их нужно как-то применить.

Начнем опять с баффа. Создаем блюпринт GA_ApplyBuff, наследованный от Gameplay Ability. В нем применяем эффект GE_IncreasedDamage на владельца способности:

Теперь создаем способность GA_UseSpell, которая будет наносить урон в области. Ее код выглядит следующим образом:

В сущности, ничего сложного. Собираем всех персонажей вокруг владельца способности кроме него самого и применяем к ним эффект GE_Damage. Как я уже писал в начале, вместо визуализации тут используется дебаг-сфера, но читатель может проявить фантазию в данном вопросе.

Также, чтобы как-то ограничить применение GA_UseSpell, добавим в нее манакост. Для этого создадим Gameplay Effect GE_UseSpellCost, который будет при применении списывать 25 маны у цели:

Чтобы применить этот GE в нашей способности, нужно указать его в поле Cost Gameplay Effect Class:

Теперь, когда способности готовы, их нужно как-то применять. Для этого, во-первых, заносим их в список выдаваемых способностей в нашем персонаже (BP_ThirdPersonCharacter), который мы заблаговременно создали:

А во-вторых, активируем эти способности при вызове соответствующих функций (которые мы ранее привязывали к инпуту):

Вот и всё. Мы создали абилки, выдали их персонажу и привязали к инпуту.

Поскольку GE_Damage мгновенный, а GE_IncreasedDamage – продолжительный эффект, для них потребуются разные типы GC. Для получения урона создадим GC_ReceivedDamage, наследуемый от UGameplayCueNotify_Static. Обязательно указываем тег, по которому будем использовать эту GC:

Для _Static Gameplay Cue логику нужно вставлять в функцию OnExecute(), так что переопределяем её следующим образом:

Чтобы воспроизвести Cue при применении эффекта, в GE_Damage добавляем нужную Gameplay Cue:

Аналогично создаемGCдля баффа, только теперь наследуемся от AGameplayCueNotify_Actor. Не забываем проставить тег:

В _Actor Gameplay Cue переопределять нужно функции OnActive() и OnRemove(). В первой мы добавляем визуальный эффект, а во второй, соответственно, его удаляем:

Осталось только привязать созданный GC в GE_IncreasedDamage: