Thank you for taking the time to check out my Inventory 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.
For a practical example of the Inventory System in action, check out its implementation into my Shooter Sandbox project. It includes a range of items with different attributes and behaviors.
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 Inventory System Plugin to your project
To add the Inventory System to your project you’ll need to copy it into your project’s plugins folder, which is located in your root project directory. If this is your project’s first plugin you may need to create this folder yourself.
[YourProject]\Plugins\InventorySystem
Heads up
The Inventory System comes bundled with the Shooter Sandbox Utilities, a common library of useful functions and macros that are utilized across all Shooter Sandbox plugins.
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 Inventory System uses minimal C++.
What’s inside the plugin
You’ll know the Inventory System has been added to your project correctly when you can see the following assets in your Content Browser. You will need to have ‘Show Plugin Content’ enabled in the Browser’s settings to see them.
The plugin’s content is split across three folders; Core, Item, and Spawner.
Core
| BP_InventorySystem_AC | The main Component of the Inventory System plugin. Manages switching between Inventory Sets and handles external commands like the picking up/dropping of Items. |
| BP_InventorySet_AC | A predefined collection of Inventory Slot Components, all of which can be active at the same time. |
BP_InventorySlot_SC | A Scene Component attached to the Inventory’s owner that can store an Item, some of which will require multiple compatible Inventory Slots. |
| BPI_InventorySystem | A Blueprint interface that facilitates communication between the Inventory System and its owner. |
| SActiveInventorySet | A struct that contains gameplay tags used to reference the current/previous Inventory Set. |
| SDominantSlot | Struct that contains gameplay tags used to reference the current/previous Dominant Slot. |
A note on Structs
You might have noticed that a number of the values that get communicated between Inventory System Components are stored as structs, like SActiveInventorySet. This is to facilitate more consistent replication, ensuring that the data in the struct will always travel over the network together.
Item
| BP_Item | An Actor in the world that can be stored and manipulated via the Inventory System. |
| PDA_ItemSettings | The Primary Data Asset for all Items, and the template from which their values are derived. |
| SAttachedItem | A struct that contains gameplay tags used to reference the current/previously attached Item. |
Spawner
| BP_ItemSpawner | An Actor that can spawn a predefined Item archetype. |
| M_Spawner | The Material applied to the in-Editor preview of the spawned Item. |
Further reading
If you’re interested in further unpacking the terminology and/or design choices I have made while creating the Inventory System, you can find more context in this devlog post.
As well as exploring the concept in more detail, I’ve also included examples of games with different approaches to their inventory systems and some guidance as to how my Shooter Sandbox version can be used to reproduce them.
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, InventorySystemTags, 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.
Using the Inventory System
The Inventory System can be added to any Actor in the same way you’d add any Actor Component, including at runtime.
If you need the owner of the Inventory to be able to receive messages from the system you’ll also need to add the BPI_InventorySystem interface to your Actor. This isn’t strictly necessary, but is very useful if you need to add in your own logic that responds to Inventory events like picking up, dropping, switching etc.
The Shooter Sandbox character uses this Blueprint Interface to fire off changes to both animation and interface state when the player switches between Inventory Sets.
Inventory Configuration
The Inventory System expects at least one Inventory Set to which Items can be added. These are created and initialized in the System’s own ‘Initialization’ function.
To create new Inventory Sets/Slots, you’ll need to create a child class of BP_InventorySet_AC or BP_InventorySlot_SC respectively.
Inventory Sets
| Tag | A gameplay tag identifier for the Inventory Set. Must be unique or the system might get confused. |
| Default Slots | An array of Inventory Slot classes. These are created when the Component is initialized. |
An example of the ‘Primary’ Inventory Set from the Shooter Sandbox, intended for two-handed weapons like rifles and shotguns.
Inventory Slots
| Tag | A gameplay tag identifier for the Inventory Slot. Must be unique or the system might get confused. |
| World Parent Tag | The Component Tag that identifies a Skeletal Mesh that the Inventory System will treat as its owner’s World Parent. |
| View Parent Tag | The Component Tag that identifies a Skeletal Mesh that the Inventory System will treat as its owner’s View Parent. |
| Attachment Bone | The bone or socket on the World/View Parent to which the Inventory Slot will be attached. |
| Offset | An optional transform to offset your Inventory Slot from the Attachment Bone. This is useful to tweak the position of your Item if the animations aren’t exactly lining up. |
World vs. View meshes
The Inventory System was designed first and foremost to support first-person gameplay as part of the Shooter Sandbox game template. As a consequence it supports different meshes for world, objects that are seen by everyone but the player, and view, those seen only in first person by the Item’s owner.
This allows for variants of each Item to have far greater detail when held in first-person right up close to the camera.
The Shooter Sandbox has a number of custom Inventory Slots, but so far it mostly just uses the left and right hands.
Creating new Items
The BP_Item Blueprint is the base class for all Items, containing a range of configuration values stored in a Data Asset. To create a new type of Item, simply create a new Data Asset using PDA_Item as its base.
If you want to add additional Components or logic to your Items I would recommend creating a child class of BP_Item. You can find examples of this in the Shooter Sandbox’s BP_Item_Gun and BP_Item_Utility classes, which handle firearms and deployables respectively.
| Nice Name | The player-facing name of the Item. |
| Inventory Set Tags | A gameplay tag container of all valid Inventory Sets for the Item. |
| Inventory Slots Required | The number of Inventory Slots required for this Item to be stored. |
| Carry Limit | The maximum number of this Item that can be held by one Inventory System. |
| Drop Distance | The distance from the camera the Item will be placed when dropped. |
| Drop Force | The force of the physics impulse when the Item is dropped. |
| World Mesh | A Static Mesh that represents the Item in the world. |
| View Mesh | A Skeletal Mesh that represents the Item in first-person view. |
| Pick Up Cue | The sound that plays when this Item is picked up. |
| Impact Cue | The sound that plays when this Item impacts with the environment. |
| Min Impact Sound Velocity | The minimum velocity required for an impact to play the Impact Cue. |
| Max Impact Sound Velocity | The maximum velocity used by the Impact Cue volume calculation. Velocities at or beyond this value will play the cue at maximum volume. |
| Impact Attenuation Settings | Sound Attenuation Settings for the Impact Cue. |
Spawning Items in the world
Although the BP_Item Blueprint can be placed into the world like any other Actor, the Inventory System plugin also comes with BP_ItemSpawner. This simple Actor handles the creation, setup, and initialization of an Item on demand.
Item Spawners are used extensively in the Shooter Sandbox, activated by the Game Mode when a round begins.
Frequently Asked Questions
Why doesn’t your Inventory System have X feature?
I would be the first to acknowledge that the Inventory System is missing a number of ‘must have’ features that are common amongst other systems you can find online.
Like most of the other systems contained within the Shooter Sandbox, the Inventory System is still in beta. I am working diligently to fill these gaps, but I am trying to prioritize the more interesting/uncommon ones first.
Although I can’t make any promises, if you have a specific feature in mind that you’d like to request I’d love to hear from you!
When will you add Dual Wielding?
As soon as possible. It’s the feature I’m most excited about, and it’s one I rarely see in first-person shooter systems available on Fab.
Unfortunately there is still significant groundwork to establish first, and before dual wielding can be released as part of the Shooter Sandbox I have some two-handed animations to create!
I have a bad track record at setting due dates, so I hope you can be patient with me.
Why are you using Actor Components?
You may have noticed that the Inventory System and Set are using Actor Components. 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 these elements 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.
