Thank you for taking the time to check out my Attribute 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 Attribute System in action 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 Attribute System Plugin to your project
To add the Attribute 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\AttributeSystem
Heads up
If you’re using the Shooter Sandbox version of the Attribute 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 Attribute 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 Attribute 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 Attribute System doesn’t require more than a few assets.
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, AttributeSystemTags, simply 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.
Attribute Terminology
There is potentially a lot of baggage and meaning behind the term ‘Attribute’, and it could mean different things depending on your experience. This is especially true if you’re coming from an all-encompassing system like Epic’s Gameplay Ability System.
My Attributes are discrete objects that hold a number of of replicated values that can be referenced by other Actors. Each Shooter Sandbox Attribute has a Gameplay Tag identifier and a current, default, minimum, and maximum float value.
The Attribute Struct also contains a reference to a child class that can be used to extend an Attribute’s functionality. You can find examples of this in the Shooter Sandbox where additional logic is fired whenever the value is changed.
Adding Attributes
To start adding Attributes to your game, each Actor that you intend to store them will need to have a BP_AttributeSystem_AC Actor Component. This Blueprint is responsible for the creation and tracking of all Attributes attached to that specific Actor.
You can add the Component manually, or create it at runtime like I do for the characters and weapons in the Shooter Sandbox.
You can use BP_AttributeSystem_AC to automatically add any number of Attributes, set their values, and confirm that they’re all initialized before returning that the system is ready for play.
Adding and initializing Attribute Components in BP_ActionSystem_AC.
Modifying Attributes
Using the BPI_AttributeSystem Blueprint Interface any Actor can reach out and modify any Attribute’s value at runtime. This can be a local change or one that is replicated from the server.
In this example from the Shooter Sandbox the Magazine Capacity Attribute is decremented each time a weapon is fired.
I would warn against directly referencing the Attribute Components from outside the ecosystem set up by Attribute System Component. It has the potential to get messy and become harder to track where changes are being made.
Frequently Asked Questions
Is this system a good solution for single player games or just multiplayer?
The Attribute 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 Attribute 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 Attribute System but also for the Attributes 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 Attributes 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.
