Introduction

The GameplayAbilities plugin has been heavily expanded by GGA and is divided into different blueprint function libraries.

This means that for the most part:

1. You don't need to write C++.

2. With the libraries, most of the functionality does not require you to change the already existing GameplayAbility parent class.

Blueprint function library

Many of the extensions I wrote in the function library were possible, which means you don't need to Cast to a specific AbilitySystemComponent in the GGA in order to use these features.

Most of what isn't readily accessible in the Blueprint has been expanded and exposed to the Blueprint.

These expansion libraries will be added over time, so the actual expansions are more than just what the screenshots show.

Ability System Function Library

This library of functions, focuses on extensions to AbilitySystemComponent, as well as some global extensions to the plugin GameplayAbilities.

Gameplay Ability Function Library

Gameplay Effect Function Library

Gameplay Attribute Helper.

This belongs to the Attribute System,Check it for more.

AbilityTask

The following are just some screenshots. The tasks provided will be added gradually.

Custom AbilityTasks

Advanced features of GAS, such as custom AbilityTasks, still require you to use C++, but GGA already includes common AbilityTasks that are more generic, so you don't need to customise them for most of the common functions.

Custom GameplayEffectContext

The GameplayEffectContext is used to pass some extra data during the skill/effect execution cycle and supports network synchronisation, but can only be done in C++.

A lot of existing GAS instructions tell you that this is the best way to pass information, but it's not.

Take my own combat system, for example:

I handle all attribute changes in my in blueprints (it happens server-side, as well as predicting client-side.), and put the Ability/Effect information itself, the attribute change information, along with additional information (attack requests, attack results, etc.) into a custom structure that is deposited into my combat system component, and replicated to the client via that component. It meets all my needs and I don't need to customise the EffectContext, it's all done in the blueprint.