Thank you for taking the time to check out my Action System Plugin. On this page you’ll find a breakdown of each of the Blueprints contained within the project, how they’re intended to be used, and how you can integrate them into your own game.
You can find a number of examples of the Action System being used with a range of Actors in my Shooter Sandbox project.
Need help?
If you have any questions or concerns you may find them addressed in the Frequently Asked Questions section at the bottom of this page. If you can’t find what you’re looking for you can reach me at [email protected] and in the techarthub Community Discord server.
Adding the Action System Plugin to your project
To add the Action System to your project you will need to copy it into your project’s plugins folder, which is located in the root project directory. If this is your project’s first plugin you may need to create this folder yourself.
[YourProject]\Plugins\ActionSystem
Heads up
If you’re using the Shooter Sandbox version of the Action System you will also require the Shooter Sandbox Utilities plugin. This is just a common library of useful functions and macros that are shared across all of the Shooter Sandbox systems. The utilities are already packaged with the Action System, but if you need to download it again you can find it here.
When you open your project for the first time after adding the plugin it will prompt you to rebuild the module. This is expected behavior and shouldn’t take long as the Action System uses minimal C++.
What’s inside the plugin
You’ll know the plugin has been added correctly when you can see the following assets inside your plugins folder. If you’re using the standalone version you’ll have a few additional libraries as well.
The Action System includes three assets, two Actor Components and a Blueprint Interface.
Adding Gameplay Tags via C++
It’s always been my goal for all components of the Shooter Sandbox to be fully exposed to Blueprint and to have minimal C++ code. Unfortunately, adding Gameplay Tags from a plugin is something that can only be done in a C++ class. This is what you’re compiling when you first add the plugin to your project.
The class, ActionSystemTags, adds a selection of gameplay tags that are used by the system to return the result of various actions in a human-readable way.
The Gameplay Tags that come with the plugin.
What is an Action?
If you’re coming from a similar ecosystem like Epic’s Gameplay Ability System there might be some existing baggage and/or meaning behind the term ‘Action’.
Within this plugin and the Shooter Sandbox at large, an Action is a discrete object that can contains its own logic hooks that can be triggered using Gameplay Tags. These events can be called from any Actor via the Action System Component.
Similar in design intent to the Gameplay Abilities found in GAS, Actions are a lot less complicated, easier to extend, and created entirely in Blueprint.
The default Action Component class has three events, OnActionStarted, OnActionStopped, and OnActionUpdated.
Adding Actions
To add Actions to an Actor you’ll need to first add a BP_ActionSystem_AC Actor Component. This Blueprint handles the creation of each Action, as well as providing a single reference point from which to trigger their events. A single Action System Component needs to be present on each Actor that needs to store Actions.
This Component can be added manually, or created at runtime like I do for the characters and weapons in the Shooter Sandbox. On initialization any number of Action classes can be automatically created.
In this example from the Shooter Sandbox these classes are stored in a Data Asset.
Referencing Actions
The Blueprint Interface BPI_ActionSystem can be used to quickly reach out and access an Actor’s Action System, and it’s through this Component that Action Commands can be sent. These are specific Gameplay Tags that will tell an Action what/when events should be triggered.
The Action Command that triggers the Crouch Action from the Shooter Sandbox Player Controller.
I would warn against directly referencing the Action Components from outside the ecosystem set up by Action System Component. It has the potential to get messy and become harder to track where changes are being made.
Configuring Actions
Each Action comes with a number of configuration settings that determine when and how its logic is fired, as well as what impact it may have on other Actions that belong to the same Action System.
| Action Tag | A tag by which this Action can be referenced. Duplicates within a single Action System may result in unexpected behavior. |
| Blocked by Tags | Active State Tags applied to the Action System that will prevent this Action from firing. |
| Tags to Apply on Start | Tags to add to the ActiveStateTags container on the Action System Component when this Action receives a Start Command. |
| Tags to Remove on Stop | Tags to add to the ActiveStateTags container on the Action System Component when this Action receives a Stop Command. |
| Cooldown Tag | A Gameplay Tag that determines Cooldown behavior. By default this is limited to Min, Max, and Add. |
| Cooldown Duration | The duration of this Action’s Cooldown in seconds. |
The settings from the Shooter Sandbox’s Jump Action.
Adding Logic to Action Events
To extend the base Action you’ll need to create a child class of the BP_Action_AC Blueprint, override any one of the events that are fired on Start, Stop, or Update, and then append your own gameplay logic. It’s as simple as that!
Don’t forget to add a call to the parent function before you add your own logic.
Cooldown options
When an Action’s OnActionStarted event is triggered, an optional cooldown timer can be set which will prevent other Actions on the same System from firing. This will only happen if the Action’s CooldownDuration value is greater than zero.
Depending on the Action’s CooldownTag, there are a number of ways the CooldownDuration can be applied.
| Add | The CooldownDuration value will be added to the System’s current cooldown time. |
| Max | The maximum value between the System’s current cooldown time and the CooldownDuration will be selected. |
| Min | The minimum value between the System’s current cooldown time and the CooldownDuration will be selected. |
Frequently Asked Questions
Is this system a good solution for single player games or just multiplayer?
The Action System has been designed to work for both multiplayer and single player games. During its development a lot of focus has been placed on the multiplayer aspect, but that’s only due to its comparative complexity.
I personally look forward to using the Action System in my own game Fires Farther Afield, which is ostensibly a single player experience with an additional (and optional) layer of asynchronous multiplayer.
Will you be expanding this to be more like the Gameplay Ability System?
Yes and no. I would very much like to expand this system into something as useful as possible for as many different types of projects as I can. However, the Shooter Sandbox and GAS have very different top-level goals and I have no intention to keep pace or try to match its capabilities feature-for-feature.
I expect both systems to continue to diverge in functionality and intended utilization, and to serve a unique role amongst the tools available to you.
Why are you using Actor Components?
You may have noticed that I’m using Actor Components not just for the Action System but also for the Actions themselves. I decided on this approach because I found Actor Components to be the easiest way to create/modify replicated sets of information without needing to manage multiple arrays of structs, something I tried in an earlier iteration of the system which was a lot harder to work with.
In an ideal world I would be using the base Object class instead of an Actor Component, as the Actions themselves don’t need transform information so it’s a bit of a waste of resources. Unfortunately Objects can’t be replicated without modification in C++, and Actor Components are the next best alternative.
