Ultimate Inventory System WIP


Staff member
Hello Everyone,

I would like to announce that Opsive has put me in charge of making a stand-alone Inventory System asset. The goal is to have a seamless integration between this inventory asset and character controller assets that are part of the Opsive family.

This is a stand-alone asset, which means it will be usable on its own and will compete with the other inventory solutions on the asset store. I believe that our solution will offer features that are currently not offered by the current assets on the asset store.

I will personally use this asset for my own game, which will be focused on gathering, crafting and upgrading items, so be assured that this asset will be tested in real-world scenarios and not just in a demo.

To make sure this is the best, most flexible, scalable and modular Inventory system I need your feedback and comments on the design we came up with. I need as many people as possible to tell me what they want, what they need, what their concerns are, etc… If you have concrete examples of what you want to achieve, that’s even better. Also, tell me if the name of the components makes sense to you.

With that out of the way please let me introduce the Inventory System plan:

Inventory System

The Inventory system is an asset made by Opsive that will help developers create their own inventory system for their game. Inventories can vastly change from one game to another. We do not plan on creating all possible inventory systems, instead, we give a powerful modular and scalable framework that can enable anyone to make a complex inventory system in no time.

Key information

Our goal:
Make an inventory framework that is modular and scalable. We are aiming at enabling our customers to create all types of inventories with ease. The asset should be usable by non-programmers to create standard inventories you find in popular games. But the true value comes from being able to extend the framework to create your very own unique inventory system.

I believe the best way to achieve this goal is to create a framework and from this framework create a few mini-game demos and inventory UI templates of popular game genre. This will ensure that the framework is flexible, modular and scalable. I truly believe that the only way to know that a tool is good is by using it in multiple real-world scenarios. I am thinking something similar to how Unity deals with the scriptable render pipeline having both HDRP and LWRP.

Target audience :
Non-programmers for people who just want to use our templates. Experienced programmers and beginner programmers who are dedicated to reading our documentation and follow our tutorials to extend a template or write their own from scratch using the inventory system framework.

Unity Version :
The latest stable release. Unity 2017.4 should be the minimum version required by this inventory system.

Our Core (subject to change):


This architecture enables us to have the following features:

  • Category:
    • Nested Categories
    • Multiple Categories per ItemDefinition
    • Same actions for all Items in a Category
      • Item Definitions part of a Category must have their matching Item subscribe to the ItemAction interface
  • ItemDefinition
    • Nested ItemDefinitions
      • Inherit, override or modify values in the parent item definition
  • Item
    • Constant data inherited from the ItemDefinition
    • Custom data unique to this Item instance
      • Enables each Item to be unique and customisable.
  • ItemObject
    • The Monobehavior that has a reference to an item
    • Used when the item needs to be part of the game world
  • ItemAction
    • Enables item to have any type of actions: Equip, use, consume, drop, etc…
    • Actions are defined in the Category and are implemented by each Item type.

We will offer a few templates with the general data used on items for people who need a standard inventory. For the others, they can make their very own inventory by using the core framework. Only need to write the Item, ItemDefinition, and ItemAction extensions and you're good to go. Example: ConsumableItem, ConsumableItemDefinition, ConsumeItem, could be used for your potions, food, and consumables.

Other Main features (subject to change) :
  • Inventory system Database Editor window
  • Modular UI system (Mouse&Keyboard, Joystick/gamepad and touch support)
  • Templates for popular inventory systems and UI
  • Shops/Vendors/Buyers
  • Crafting system
Other Additional features (subject to change) :
  • Save/Load system (for scene transitions)
  • Import/export database
  • Multi-language support (simply swap the database before loading the save)
  • Event system shared with UCC
  • Object Pool shared with UCC


So why are we making our own Inventory System?

Simply because I personally tried to use a few inventory solutions on the asset store and none of them were flexible enough for the game I am making. The current inventory system for the Character Controllers is also quite limiting. To make the seamless integration with the Inventory System it will need some refactoring. This will also help the Character Controllers to be integrated more easily with third-party Inventory assets, which you might already own.

Why am I making this asset instead of Justin?

I am working with Justin to make this asset. He simply does not have enough time to work on the Inventory system, but a lot of people (including me) were asking for a more flexible inventory system from Opsive. Although I am the one to do the actual implementation, we came up with the structure together and we bounce of ideas from one another. He also makes sure that the solution has the same quality and format as the rest of the Opsive family.

How long until the asset is released?

Well, we haven’t really started the actual implementation yet. And take into account that I am working on this asset part-time, while I work on my other jobs and on my game. You can expect this to take a few months if not a year. It is hard to tell until we lock down what features will be included in the first release.


Active member
Hi, Sangemdoko,
This is pretty awesome, and it looks pretty flexible to me. I really hope to see it sooner than later, although I understand it's your part-time project, a year from now will probably not relevant to my game, unfortunately. :(
If you plan on doing this on part-time, perhaps you can setup GitHub project so that we can engage early on.

I know that the UCC Item system is not designed with many items, especially, there must be ItemType for each item and they are directly required in many places, including Animator for animation. I'm not sure how you will get around that. My recommendation is not to use ItemType at all but just use simple ItemID in Item class. And use ItemCategoryID in Animator and so on, so that many items can be added later on.

This obviously requires some modification from UCC and I'm not sure if Justin will agree with it or not.
Have you talked to Justin about this? Just adding a layer on top of existing UCC item system will not give us a clean system and that's what I'm afraid of.

But it's really a good start. Please keep the good work!



Staff member
@chrisk Yes, I have discussed about this with Justin. The current barebones Inventory solution that is offered by UCC has some flaws. Justin is prepared to make the necessary modifications to make it as flexible as possible. Before that though, I need to make sure the new stand-alone Inventory has a structure set in stone. This will make sure that we won't have to change the UCC inventory ever again (hopefully). Of course, we will take a look at popular third-party inventory assets to make sure our solution is at least as flexible as theirs. After that change making UCC integration with any inventory system (not just ours) should be easy.


Active member
Sure, after the Discord discussion, I feel at ease that Justin will support whatever necessary to make a flexible system.
I think above Core design is pretty solid and we can easily build stuff on top of it. One thing I would like to make sure is that we need to assume that there will 100s of items and they can be hierarchical. (I see Category and I guess that what it is for exactly ^^ )

When you have many items, it's a good idea to clearly separate Item DB from the Runtime Items. UCC Item is the front-end and it will have runtime inventories, and Item DB the back-end and provide storages and services to the front-end system, like queries. At runtime, we don't need to know the Item DB. It will just get information on-demand through queries. This way, at the runtime, we don't need to load the whole ItemDB to save startup time.

I think your diagram shows what DB is and what runtime is already. Making a clear distinction will help the separate the functionality such as for query, making tools, storages, and etc. ScriptableObject might be just one type of storage system and later we can directly store them on real DB, like SQLite or the upcoming Addressables.

Having said that, we have to start somewhere. First things first and we need to talk about what needs be changed on UCC so that we can start building stuff.

To continue what I mean,
We need to figure out a way to implement the Core into UCC.
Before adding stuff, I think there two things need be done first.
The first thing is to remove ItemCollection from the runtime in UCC. They are really the Item DB and Runtime doesn't really need to have it all the time but instead just query them when necessary as I explained above. Right now ItemCollection is used to just verify if the Item is valid. Removing it will not break UCC, however, it's used in many places and it just gets in the way. Remove it first and later support query API to the new Item Db.

Second thing is to merge ItemType into Item itself. ItemType is merely an Item ID and your new Class already have Item ID and Category ID and it's redundant. Merging ItemType into UCC Item.cs will help you add Core classes. This will probably require quite a bit of change in UCC as well but it's the necessary fist steps.
Yeah, ItemType is used for Animator too. We can just replace it with ItemAnimationType or ItemAnimationCatetory that has the same value as ID in ItemType. Why? It's impossible to provide different animation for each item. Unique animation for each ItemAnimationType will be enough. It will be then unnecessary to create ItemType from the Tool. Until we provide a new Item Generator, just type unique Item ID by hand(since there aren't many) or use GUID.

I can think of the above the two needs be done first so that we can start building the new inventory system on top of it.

Hope it makes sense and please let me know what you think after discussing with Justin.

With these changes in-place, I think it will be easier for other Inventory Asset deveopers to make the integration.



Staff member
Hi @chrisk,

I read your post and forgot to answer, sorry.

Thank you for your advice and for expressing your concerns.

I agree with most of your ideas.

I am thinking that the queries part is something that each developer should do themselves. For example, if you used asset bundles to organize your ItemDefinitions, you might want to bundle them by Category, by item definition with the same root, or maybe by a certain attribute value that is common between many ItemDefinitions. It is too specific to each game so it should be implemented by the developer.
I will make sure to make an interface so that it is easy to swap the default "load everything at the start" or "load all itemDefinition within a category" by a "query specific bundles during runtime when you need it" system. It is too soon to know how exactly I will implement this, but I am definitely thinking about it since optimization is something important to many game developers.

Your idea of having the item animation ID be specific to certain category makes complete sense to me.
I do not think the ItemCollection is needed either and I think the ItemType and Item class in UCC have design flaws. Now, how we will fix these flaws will depend on a few things.
My idea is to make the stand-alone inventory system as flexible as possible without thinking about UCC. Once both Justin and I are happy with the framework we will work together and use all the knowledge we have obtained from making the stand-alone inventory system to change the UCC inventory/Items so that it integrates seamlessly. Inherently these changes will help anyone integrate their own or any Inventory system with UCC. We won't do it the other way around because if by inadvertence we missed a necessary feature in the core changing UCC multiple times is too risky, time consuming and will affect too many people. On the other hand, iterating on the stand-alone inventory is fine since no one will be using it until it is released, by then we will have thoroughly tested the framework to make sure it won't need any big changes.

I hope that was helpful.

I'm working hard on this and once I have enough progress I will post an update of the core framework and ask for more feedback.


Active member
Hi, Singemdoko,
Thanks for the answer. Your approach, making the stand-alone example is plausible but it will take a really long time and I don't think my project can wait that long. I was asking some obvious things like ItemCollection and ItemType needs to be refactored so that others can start the integration without waiting for a year.
Knowing that there is a design flaw and it's a necessary fix, why wait for such a long time.

The way I look at it, it's almost impossible any Asset to extend the inventory system and we probably won't see any integration as is.
My point is, let's try to make UCC so that it's extensible while we wait for the next best thing.

If you think about it, removing ItemCollection is harmless, and merging ItemType into Item.cs won't break any existing system, we just need ItemID from the ItemType and pass it around instead of ItemType. But right now, ItemType is used everywhere that makes the integration really hard.
ItemType is also a misnomer and I had a hard time understanding at the beginning.

Anyway, that's my thought and if it's not going to happen, I'll have to work around it, although it's going to be really a pain.



Staff member
Hi @chrisk,

I discussed it again with Justin. He made clear that he has no intention on refactoring this twice because it would mean changing the documentation and videos twice in a one year span. And more than anything it would be taking time working on something that will be replaced when he could be working on something else that is just as important.

So Unfortunately you will have to work with the current implementation of the UCC inventory. Since I had to do the same thing before, I can give you some pointers that I used. Create a class that has an ItemType and your itemData (name it "InventoryItem" or something), create an ItemType extension that has an "InventoryItem". You can then create itemTypes at runtime using ScriptableObject.CreateInstance<ItemTypeExtension>() and feed it the data from your "InventoryItem". In your inventory use InventoryItem class to organize your items. Whenever you need to equip the item then create an ItemType from the InventoryItem. As long as you are clever as how you convert the InventoryItem id and the ItemType id then you should be fine. Think about what your UCC character needs to know from your inventory (equiped weapons and ammo) and what he does not need to know about (consumable, other weapon in bag, etc..).

I hope this points you in the right direction and that you will be able to implement your inventory system in the time frame you were given.


Active member
Thanks for trying to help. I tried to help make UCC better but it's really difficult to make any changes other than bug fixes. I did my best explaining stuff but it feels like wasted efforts.
I think we both know that the current Item system is not very extendable outside of UCC. ItemType is deeply rooted into UCC and I'm afraid that you will also have to work around as you mention above and it will be a mess. Please make sure Justin will make the changes necessary before you begin the long journey. If he is not going to do it now, he will probably not going to do it later as ItemType will be more widely used as time goes on, and especially when the multiplayer is added.

One more thing. The Core diagram above is not much different from RuckSack core concept and why you want to create a stand-alone inventory system?
RuckSack is already a stand-alone inventory system and quite extendable.
Honestly, I think it will be reinventing a new wheel and it will hard to make something better than RS less than a year of time by alone, and part-time.

Is it possible we start integrationg RuckSack first so that people can start using the inventory system and make a better inventory system with new knowlege we learn afterward?
The inventory core system is quite simple. It basically consists of Item, and generic ItemCollection and that all Justin has to support in UCC, and the rest are independent of UCC. I think that's all Justin has to support and leave the rest to us and I don't think Justin will work twice. It's very unlikely that Item, ItemCollection will change. Even if it changes, it will not be a structural change but adding additional functionality not related to UCC.


Staff member
I tried to help make UCC better but it's really difficult to make any changes other than bug fixes. I did my best explaining stuff but it feels like wasted efforts.
I really do appreciate your suggestions, but I'm not able to implement things as quickly as I would be able to if I was working on my own game. Extra care needs to be taken in order to implement each feature because any single feature can affect so many people. I then have to ensure it is documented if the feature is exposed to the user. I also have a list of features that I'd like to implement that I have to prioritize against every other feature.

This inventory use case is a perfect example of this. I only want to make the inventory change once because it is going to be a good amount of work to convert everything over. I then need to redo the UCC documentation and videos because ItemType is used in a lot of places. Thus we are only going to do this once and I want to ensure it is done correctly. This does mean that it may not fit to your time schedule but in the long run it'll be better. If it doesn't fit your schedule you can either start on a workaround similar to what @Sangemdoko suggested or make the changes directly to the controller.

I believe that the features that we have planned for this inventory system will be able to differentiate it from the existing Asset Store (or the upcoming Unity) solutions. We wouldn't be developing it if that wasn't the case.


Active member
Hi, Justin, I fully understand that things take time, I think I've been very patient waiting for the stuff. I don't ask you twice unless you answer but many times I'm in the void not knowing what's going on.

That's why I asked you if you have a place where you keep your todo/progress notes so that I know it's not forgotten.
I think it will make us much less stressful if you share it and update it once in a while.

In the case of the Inventory system, it is also the perfect example of explaining I'm trying to help but it's not getting anywhere.
My suggestion is simple. If you look at it from an external point of view, it's hard to extend the Inventory system because UCC has its own inventory system, namely, ItemCollection and ItemType, do you agree?
They must be created in order for the game to work.

ItemCollection is Item DB, ItemType is Item ID.

Looking at as an external developer, I have my own Item DB and ItemID and in order to support UCC, I need to deal with UCC Item DB and Item ID at the same time. Without ItemCollection and ItemType, it will simply not going to work. On the other hand, it will just work if there are no ItemCollection and ItemType.

Currently, ItemCollection is used to verify that if the Item is valid or not. We can just get rid of ItemCollection, meaning, we skip the item validation and it won't break UCC. The validation can be implemented by the external developer.
If we get rid of ItemCollection, ItemType(ID) can go inside of Item itself and the external developer will inherit from the Item to add more functionalities. This way, we don't have to create ItemType whenever we create a new item and manage ItemCollections. In order words, the external developer is free to do whatever he wants.

But ItemType is deeply rooted in UCC and it will require quite a bit of change and more so as time goes on. It will be even more difficult and your recommendation, I'm afraid, will be to work around it again. Given how busy you will after having so many assets and how UCC is matured by then, I bet more on the workaround. This won't give us a clean system and external developer will not going to easily integrate. I think this is what exactly happening to Rucksack. He wants to integrate it but it's simply not possible without your help and I bet it has to do with ItemCollection and ItemTypes, plus how Item properties are stored.

By making the external Inventory to handle ItemCollections and having an Item class to hold ItemID, I really don't see how it's going to change again because it can't get any simpler than this.

If you make the two changes, everything else is just a layer on top of it and the external inventory system can start working right away without the special requirement.
Sure, there might be some adjustments but it's not going to be a structural change but adding functionalities to the existing classes.

As a starter, removing ItemCollection can be done first as it won't break the things and it will remove one hurdle.
To be more specific, you can still have ItemCollection for the management purpose to list all items in one place but don't make it a runtime requirement. This way, your tutorial video is still valid and I don't expect this to take it a long time to do it since it's removing the validation code.
Just make the validation as virtual function just to return true for now. And let the external inventory system to override it.
I think you will agree to this at least.

And then, we can discuss how to remove ItemType. (ItemType is directly used by Animator and it's a misdesign. AnimationTypeID would be much better for extending)

I hope things make sense and I believe everyone will benefit now instead of years later.

Last edited:


Staff member
@chrisk I understand how you feel but our decision is final. We discussed it extensively with Justin and we truly believe that in the long run, it is definitely the right decision.

These changes you talk about might help you but it might break someone else's game. Justin cannot carelessly start changing part of the design of UCC. Making these changes take time and extreme attention. That's why doing this progressively is not a good idea, we might miss something and need to backtrack, which will be a pain for everybody using the latest version of UCC. If we do it once and tell everyone in advance that it is coming they can prepare for the changes or wait until they are ready to make the big update or decide to not do it at all.

As Justin said you can change the source code to fit your needs. If taking out the validation of ItemCollection will help you progress then you should remove it. If ItemType is causing you issues you can avoid it. If you want to replace ItemType by an int ID in the Item class then you should. You will need to be extra careful when updating UCC, making sure to have version control and keeping track of what changes you made. But maybe you might be in a point in your development cycle where you should not update UCC anymore, except for major releases.

We will do our best to help you answer any questions you have, whether you make a bridge or change the source code. I would suggest you create a new thread and ask those questions on there or use the thread where this all started: https://opsive.com/forum/index.php?...y-and-itemtype-category-system.749/#post-4095.

We really appreciate your feedback and the fact that you want to make UCC better. Once we start making the changes to UCC we will make sure to come back to the comments you made above. You pointed out some good things, which we will most definitely take into account. Until then I will work extra hard on the stand-alone inventory and do my best so that it is of utmost quality comes out sooner rather than later.

I hope you understand our decision and that you will be able to overcome your problems asap.


Active member
I appreciate you are trying to relay the information but I have to say I rather want to hear it from Justin.
I tried to write in length explaining why it helps to it rather now than later.
I hope to be proven my suggestion has some flaws but I don't hear anything about it.
The only argument I hear is that it might break someone else's code and Justin doesn't want to touch the code twice. How can you develop good software with that mentality? If he is afraid now, how could he ever change anything?
I tried to explain removing ItemCollection will not break anything but it's like talking to a wall, and he doesn't even want to discuss it.
Too bad..and good luck to your Inventory System. I hope you get the necessary support you need.
I have just seen this thread and wanted to mention how excited I am to see this coming. My game currently relies on just a few items for each character, so an item system will not be useful my current project. However, what I am excited about is to see for the first time that a community member is overtaking an extension (I know it is standalone, but technically a UCC born asset) that would not be possible to be considered given the amount of time other Opsive projects take to maintain.

Given the fact that TPC and BD filled out a great gap in asset store, and UCC moved it to the next level, I would really love to see the initiative can go beyond what only a team of two can achieve, but can grow into a more corporate body in the long term, that can give greater access to non-programmers (such as myself) high end game making capabilities.

I do appreciate the scrutiny, though, as not to rush into implementation right away. From where I look at this, what UCC tries to achieve is the work of a middle sized team in a game studio, during a several year production line. Moreover, UCC does not try to align its features and architecture for a single game, but for effectively an infinite number of types of games that the developers can manifest from it. Therefore, the caution to structure the architecture properly before moving forward sounds very reasonable, regardless of the time it would require.

Despite being a non-programmer, I know that the inventory structure improved immensely from TPC to UCC, as TPC caused so many issues and conflicts, since the scenarios I deemed necessary for my project were not considered. I am really looking forward to seeing this project grow, and many others to follow it in other fields of integration, such as RPG components.


Active member
UCC inventory system is really difficult to extend and it's probably the worst part of UCC system. It's very complicated but at the same time very limited.
I tried to work around it but I concluded that it's impossible without rewriting it.

This new inventory system sounds nice but I cannot wait for a year, thus, I have started rewriting the inventory system.
I try to workaround it first but right now, it's pretty clear to me that the good integration cannot be done without rewriting the many parts of UCC.
There are just too tightly integrated into UCC.

The biggest limitation is that UCC assumes that you will have a handful of items. This will not scale to a large number of items and dynamically loading/unloading of items are necessary for most of the games.

The first thing I did was to remove, ItemCollection. ItemSet, ItemSetManager and move them over to the new system.
As far as UCC is concerned, it knows nothing about the inventory and the new inventory system manages everything.
UCC character basically picks up an item and plays equip and unequip animation. The clear separation of responsibility makes the system very clean.

ItemType is a ScriptableObject, and currently used as ID but I expanded it to contain all static item data. The static data is shared among the same type of the item and I only store dynamic data(unique to each item) in the Item itself. This will make the system memory efficient and editing the item data easier at the same time. When you think about it, most of the item data are static and it's important that it is well structured in order for it to be extended easily. In this sense, ItemType is a misnomer, it should be more like ItemDefinition or ItemTemplate.

I hope it helps when you implement the new system.



Staff member
Thank you for sharing your experience!
It is somewhat similar to what I currently have for my own game, which is a system I wrote before starting this new inventory asset. We will most definitely take note of your suggestions for the time when we start the integration of UCC and this asset.
Right now all I can say is that I am hard at work on the stand-alone inventory and I am quite pleased with the progress so far. As soon as I have a solid/tested design of the core functionality I will share it here so that you can all give me more feedback.


Active member
That sounds good. I just want to tell you the clean system is not possible without rewriting many parts of UCC.

Here is the problem I see. UCC needs to work without the new inventory system. So, UCC will probably stay as is and you will have to work around it. This cannot give the clean system and it is probably not we want.

To make the clean system, UCC needs to incorporate at least the runtime portion of your new inventory system. I'm not sure how this is possible with an add-on package to replace many parts of the source code. This will make the patch very difficult also. To save much troubles, it's probably the best to make the new inventory system as the default inventory system and you get some royalties from Justin instead.

Anyway, I'll be very happy if the end result is clean, and very extensible so that everyone can use in their game.

I'll also let you know as I make some more progress as well.




I feel very sad to know that this asset doesn't support inventory. For any game, I believe inventory is necessary thing to add.
@Sangemdoko Can you tell approx time, when can it be ready to use?

If this take several months/year to produce then @Justin do atleast work on integrating third party inventory asset like inventory pro.

There are many people like me stuck at inventory :(, I'm sure it will help to everyone if you find workaround on this.