Leveraging the Gameplay Ability System

Alex Coultas

What is this talk

• How to use the gameplay ability system
• General flow of actions and functional interactions between actors
• Level and narrative utilisation
• Not covering
• Combat
• AI
• Damage/Health systems
• Saving
• Networking

Contents

• Who am I
• Intro
• Blueprint vs C++
• Basic Usage
• Conditional Scenarios
• Modular Events
• Debugging

What have I done

Previously on

Alex Coultas

• Buildmedia
• Intermediate & Tools Lead
• VR Projects
• Large Scale Developments
• Interior Virtual Tours
• Mighty Eyes
• Gameplay and Systems Lead Developer
• Wanderer: The Fragments of Fate
• The Boundary
• Senior Unreal Engineer
• Realspace Platform App
• Digital Twins
• CI/CD

• Mythos Party
• Mythological online arena brawler
• Sky Engine
• Custom personal C++ Game Engine

Mythos Party

Skyward Studios

• Online arena brawler
• Abilities
• God mode
• Weapons
• Party Modes

Mythos Party

Skyward Studios

• Didn’t use the gameplay ability system…

Wanderer: The Fragments of Fate

Mighty Eyes

• Time travel adventure puzzle platformer VR game
• Many interactables
• Narrative driven gameplay
• Design heavy levels and gameplay

Wanderer: The Fragments of Fate

​

Mighty Eyes

• Conditional Trigger boxes
• Narrative windows conditional with gameplay for executions
• Actor driven conditions for progressing and triggering executions

What is the Gameplay Ability System?

Gameplay

Ability

System

• Tags
• Ability System Component
• Events
• Effects
• Abilities
• Cues
• Attributes

Gameplay Tags

Overview

• Agnostic to the system - Can be used independently
• Best combination of Strings and Enums
• Doesn’t lock you in like enums
• Don’t risk user error with typos like strings
• Can have parent/child hierarchy

Ability System Component

Overview

• Required for the other systems to operate
• How the system recognises an entity and passes information through
• Stores tags

Gameplay Events

Overview

• Single fire information to gameplay ability actors
• Can be used to trigger abilities, effects and cues
• Can be used as generic agnostic events between actors

Gameplay Effects

Overview

• Manages lifetimes of modifiers and attributes
• Instant, duration, or lifetime until removed
• Safety around applying tags

Gameplay Abilities

Overview

• Handle latent flow for an action
• Functional, not aesthetic
• Handle input confirmation
• Multiplayer synced/important

Gameplay Cues

Overview

• Visual only for effects (confusing name)
• Separate logic from visuals
• For multiplayer are client only

Gameplay Attributes

Overview

• Preset types, values and ranges
• Populated dynamically per actor
• Powerful for modifiers
• Affected by level of gameplay effects
• Can stack layers such as:
• Damage
• Piercing
• Armor
• Resistance
• Health

C++ vs Blueprints

Getting Started

• Enable the plugin

Blueprints

Ability Interfaces

• Not fully exposed to blueprints by default
• Base implementation required for:
• Ability System Component
• Owned Gameplay Tags
• Additional tag usage

Blueprint Limitations

• Any derived actor from plugins or c++ will need the ability system layer
• Various functions not exposed to blueprints by default
• Simple to expose in C++

Plugins

Alternatives to C++

• Not many easy to use plugins that expose the c++ to blueprints only
• Can use my in development plugin for this
• SkyAbilitySystem: https://github.com/Zeploc/SkyAbilitySystem

Blueprint Limitations

Not available by default

Blueprint Limitations

Default alternatives

• Set count not available by default
• Listen events as latent actions

C++ Usage

Interfaces

• Not full composition
• Requires base actor to implement interfaces

C++ Usage

Implementation

• Get Ability System
• Get Owned Tags

How to use it

Gameplay Tags

Agnostic Query

• Query tag state of other actors eg in a level without specific type

Gameplay Tags

Agnostic Modify

• Abstract interaction with other actors without reference type, but still specific control

Gameplay Effect

Manage Tags

• Gameplay affect applied to add tags to an actor
• Instigator controls life cycle of effect if not instant
• Removes tags when complete
• Gameplay effect owns control of that tag
• Can limit to only one gameplay effect at a time (stacks)

Gameplay Cues

GameplayCue Editor

• Cues are auto linked to an actor matching the tag
• Auto sets the cue tag when created via window

Gameplay Cues

Auto Triggered

• Automatically triggered based on tag set in effect

Gameplay Abilities

Auto Triggered

• Can be automatically triggered based on tag added or event

Gameplay Abilities

Manually triggered

• Can be applied and activated manually

Gameplay Abilities

Input triggered

• Can be triggered via input
• Additional custom input tags usage
• Override input pressed in derived ability (not BP exposed)

Code Scenarios

Gameplay Tags

Multiple source toggle

• Insteading of storing states from different instigators
• Each instigator can toggle its tag on the actor
• Actor can listen for tag event for on/off state

Gameplay Tags

Loose Dangers

• Can be directly added and removed
• Risk of removing a tag that was instigated by another actor

Gameplay Tags

Direct Set

• Can be directly set count ie Enable and Disable
• Treats it like a boolean not a count
• Only used when one object controls this actors tag for a single code path ie no other actors modify it
• Where this would be an internal bool to stop outside interference, keeping it as a tag still enables external agnostic query

Gameplay Scenarios

Single Trigger

Direct Door Example

• Single event
• One trigger
• One action

Single Trigger

Manual way

• Uses direct type reference
• Direct function call
• Alternative would be a specific interface

Single Trigger

Gamplay Event

Can pass in information

Can point to any actor and reuse

Send single fire event

• Actor listens for event
• Controls its own state instead of externally

Single Trigger

Lever State

• Enable tag on lever for state
• Single direction (Event)

• Lever on and off state toggles it tag
• Both directions (State)

Single Trigger

Tag toggling

• Can use custom tag function to set count from lever
• Confirms state on actor will be correct
• Conflicts with multiple actors

• On and off state controlled by tags on target

Multiple Triggers

Tag adding/removing

• Add and remove tags
• Trigger actor is generic
• Won’t conflict with other actors

• Will be toggled if has any number of the tag

Multiple Triggers

Tag adding/removing

• Multiple trigger
• Will be toggled if has any number of the tag

Multiple Triggers

Tag adding/removing

• Will be toggled if has required number of the tag

Multiple Triggers

Safer tags via gameplay effect

• Apply and remove infinite gameplay effect
• Gameplay Effect Handle to manage

Multiple Triggers

Remove by source effect

• Remove by source effect instead
• Instigator based on effect context
• Instigator guards against other actors applying the same effect class
• Won’t guard against multiple from this actor

Multiple Triggers

Guard against repeat

• Can check effect count per class
• Additional per instigator
• Can be used as a check to stop double application

• Can use effect handle
• Required if multiple added from this actor

Multiple Triggers

Gameplay Effect Stacking

• Instead of limiting from callsite, can limit on effect

• Eg Stops more than 1 being applied

Multiple Triggers

Tag Query

• Can handle complex tag requirements
• Expressions along with match criteria
• Doesn’t handle tag count
• Can’t extend these expressions

Multiple Triggers

Checking Tag Query

• Can check if conditions match
• Can use latent event that listens for tag changes

Multiple Triggers

Tag Query Triggers

• Trigger once for one time condition pass event

• Doesn’t have When Either
• Can use two nodes with each to trigger back and forth

Multiple Triggers

Tag Requirements

• Has additional simple fields for have and not have

Multiple Triggers

Checking Tag Requirements

• Has to check 3 conditions
• Have to manually bind events for Have Tags to listen to changes
• Not much gain to using this except speed of entering fields

Multiple Conditions

Opens when not looking

• Door opens when not looking
• Dramatic effect only open when looking

Multiple Conditions

We want this

• We have two conditions
• Have to have flicked lever and look at door

Multiple Conditions

Sight Volume

• Sight volume activates when on screen
• Basic actor target and tags to add

Multiple Conditions

Sight and Activated Check

• Door waits for query all tags match
• From lever and sight volume

Multiple Conditions

Sight and Activated Check

• This will open once and not close again

Multiple Conditions

Toggle based on query

• Handles both match and unmatch state
• Will continuously trigger
• Could make a custom latent to do this in one node

Multiple Conditions

Closes when not visible

• Will close when neither conditions match ie not looking
• Not ideal outcome design wise but works for example

Multiple Conditions

Two doors

• Scenario two doors with one lever
• We want one sight volume controlling both

​

Multiple Conditions

Lever targeting multiple

• Lever points to both
• Can expose an array of actors
• Same for sight volume
• Only the same effect can get applied

• Gives us control for effect per actor
• Still means lever controls what it affects

Multiple Conditions

Door listening to multiple

• Instead door queries interactable objects
• No modifications to actors in world to change when the door activates
• Lever and sight volume treated as read only
• Isolates logic flow between actors from modify to query

Multiple Conditions

Query when all met

• Check each query passes for each actor
• If any don’t, the conditions are not met

Multiple Conditions

Update door on query changes

• We want to listen when each actor with its query changes
• Check all queries pass each change

Multiple Conditions

Working example

• Both doors open when lever active and looking

Multiple Conditions

Visible event

• Only care about when first seen event, not state
• Send event to the volume itself

• We need to give the tag and actor information to query

Multiple Conditions

Check event

• Add the actor to listen to the event

• Listen to the actors when they fire

Multiple Conditions

Check event

• Check for all events fired as gate

• Wait for lever to be switched before listening
• Have to wait for queries before waiting for events

Multiple Conditions

Issues

• Working example with above fixed
• Getting very messy

Modular Events

Conditions and Executions

• Conditions hook into events to run once fulfilled
• Hooks into actors in different levels dynamically binding

​

Modular events

Conditions

• Conditions dynamically bind and listen for changes to check when to execute
• Built from object instances to easily build out events in levels and blueprints
• Multiple conditions combine to pass
• Can easily build more condition types

Modular events

Executions

• Run once conditions are met
• Can easily build out more execution types

Events on blueprints

Per actor instance

• Component exists to manage events
• Can bind to when these events execute for more custom logic
• Can reference owning actor for tag checking and modifying

Cross level actors

Problem

• Often actors are split across levels, meaning soft pointers need to be used
• Resolving is needed, but levels may not be loaded so we don’t know when the actor will exist
• We want to hook into events once it exists so we can set up bindings

Cross level actors

Registry

• To solve this, we can bind an event to a registry to tell us when the actor exists
• This means we need to have an ID for them, the easiest being the soft pointer to the actor in the level as this doesn’t change at runtime
• The actors then register themselves, by calling an event on begin play to the subsystem
• The subsystem then sends events to anyone who was listening

Cross level actors

Dynamically spawned

• If we want to hook into a dynamically spawned actor, it is no longer by ID, but by class
• We can filter based on tags along with class for a condition
• This still uses the registry to send an event when an actor of the chosen class is registered

Debugging

Debugging

Gameplay Tags

• AbilitySystem.DebugAbilityTags
• State maintained through PIEs

• Shows active tags
• Shows count
• Requires rendered component to display

Debugging

Gameplay Effects

• VisLog
• Tools > Debug > Visual Logger
• History of gameplay effects and abilities
• In world visual indication

Resources

https://zeploc.github.io

• Sky Ability System
• Basic exposing of various GAS systems to blueprints
• Presentation Slides
• Additional Resources
• Future Gameplay Flow Plugin
• Graph system for handling gameplay conditions and events
• More…

Questions?

• https://zeploc.github.io