Ultimate Inventory System WIP

@Sangemdoko ,

I'm presuming you can use similar code to construct an item from several item categories and several item definitions?

Also, I was just wondering about Item Categories and Item Definitions cumulatively and on their own:-

- can an Item Category or an Item Definition in itself be an Item Attribute?;

- If an added Item Definition seeks to amend / re-calculate (not override or create fresh) an Item Attribute but that Item Attribute is not yet created in the cumulative Item Attributes (from existing Item Categories/Definitions) for an Item before that, what happens then?
 
Last edited:
@Duffer123
You cannot create one item out of multiple item definitions.

Think of itemDefinitions as a mold that is used to create your item.
The categories are like tags that define what the ItemDefinitions are.

ItemCategories can be nested with multiple parents,
ItemDefinitions can have a single ItemCategory and can also be nested but with a single parent
Items must have a single ItemDefinition.

But... since an Item can have custom attributes it can technically contain anything it wants, including other items, itemDefinitions and ItemCategories.
And that's how item containers works, they are items that contain other items in their attributes.

I hope that makes sense, if not you can read back the previous post where I explained in detail how the Attribute, ItemCategory, ItemDefinition and Item relationship works
 
@Sangemdoko ,

Thanks, yes, that makes sense. It's all about multiple inheritance down to the current Item Category and Item Definition (with its ancestors) for an Item...

What about Item Category or Item Definition AS an Item Attribute?

Presumably an Item Attribute can only calculate from or effect Item Attributes within the same Item?
 
Yes, Attributes start searching their value from the bottom on the hierarchy and then go up the chain.

So for example if you ItemCategory1 -> ItemCategory2 -> ItemDefinition1 -> Item1 & Item2

ItemCategoy1 : attributeInt(Override) -> 5
ItemCategory2 : attributeInt(Inherit) -> 5
ItemDefinition1 : attributeInt(Override) -> 10
Item1 : attributeInt(Inherit) ->10
Item2 : attributeInt(Override) -> 15

As you can see depending where you get the attribute value in the hierarch it may be different. But thanks to the hierarchy you know for a fact that Item1 & Item2 will have an attribute with the name attributeInt.

Item categories and definition AS attributes does not affect the hierachy in any way, it's the same as referencing a gameobject in a field. Categories and definition are ScriptableObjects
 
@Sangemdoko , here's an interesting one for you, largely prevalent on MMORPGs and ARPGs, perhaps some open-world WRPGs...

'Item Sets' - so having the complete set of say gloves, jacket, trousers, boots, helm gives you some enhanced bonuses.

I suppose that could be achieved through judicious use of the Item Attribute?
 
@Duffer123
There are many ways you could approach this. If I had to do something similar I'd either have a category for each item set or I'd have an ItemDefinition attribute with an ItemSet ID. Then have a custom inventory that checks if all equipped items are from the same itemset, so that I know whether to apply the stat boost or not. The stat boost could be set as an ItemDefinition attribute on one of the itemDefinitions of each set)

This goes out of scope though, so it won't be available out of the box, but as you can see it's definitely something that can be done with our design.
 
@Sangemdoko ,

Thanks that all makes sense. Shows again the flexibility.

I'm not sure whether you've decided yet on what's in and out of scope in the first release demo(s) and manual / documentation and commented code, but it would be really helpful to show how both item containers are done AND how the variant of attachments (attach socket or inscription sub items) are done, and affixes/prefixes/suffixes with item renaming... Suspect that will be useful to the wider community too.

In terms of Inventory ui it would be great in the demo(s) to show items being filtered by category and, if possible, ancestor category?

When you next can, looking forward to some more piccies of the asset in action... ;)
 
@Duffer123
Right now we've decided that we are not going to add anything more to the current features until we release the asset. We are focusing on getting what is already there as polished as possible.
Some of the things you mentioned will be in the demo so you'll able to go through the code and see how it was done, and then you could always ask me any questions if there is anything that does not make sense.
Note that there is no need to do it the same way I did, maybe you can find your own way that makes more sense for your own game. The asset is very flexible so you can use it to your advantage.
I am guessing that some things will change early as I get feedback, so I don't want to make a full detailed tutorial right at the start. Most likely I'll start with overview tutorials and then gradually go into more detailed stuff once they have been completely fleshed out.
 
@Sangemdoko ,

Again, that makes sense and suspect the first release demo and a little support will be plenty enough for me and most.

Sorry, I've got to ask, how close is first release, even in general terms? And do you need any eagre alpha or beta testers before that? ;)
 
@Duffer123
The release date is still Q1/Q2 (With how things are progressing I assume it'll be more around Q2 though...)
The asset will be released first on the Opsive website for early adopters and a few weeks after on the Unity asset store (The asset validation process takes a while).
 
I just want to say the inventory system I built for my MMORPG was way more work then I ever thought it would be. I had to rewrite the server side logic 2 times to make it perfect. All the polishing on the client side was insane. When I first started it I never thought it would be that many man hours to build. Took me like 3 months 16 hours a day and it didn't use Opsive controller item system. A lot of reason for that though is the MMO I'm making your character doesn't pick up weapons so I had no need of it. Wouldn't take much to add though.

When you get really deep into it the coding logic starts getting pretty intense too lol. The code has to be the most organized code you have ever written lol. Other wise you gonna have a heck of a time thinking past some complexity issues that you will come across.
I'm not even sure id feel comfortable using a inventory system that someone else built. You have to really really polish it. You can't have any bugs in it.

I think the largest issues you will have is networking. If you finish a great client side inventory system but it will be useless for server side. There would need to be some sort of server side attachment to it. My inventory system runs on PHP and Mysql.
If I had to build one for the public. I would make one that uses SQL. This way making a server side version would be much easier.
Another option would be to just build your own database from scratch maybe with limited API. Thats probably a better idea honestly.


  • Bags
  • Item linking
  • Stackable Items
  • Groupable items
  • Armor
  • Mailing items in the in game message system.
  • Overflow inventory
  • Trading items between two players
  • Item restriction (based on levels,class etc..)
This video shows it off a little bit. My system does everything except the type of inventory where items has different sizes to them.

 
Hi Everyone,

It has been a while but I can finally show you the new editor we have been working on for the inventory system. Below I will showcase only the editor side of things, I won’t show the inspectors or runtime views simply because they are not yet ready to be shown.

In this showcase I will go through an example of how someone may want to set up a few items. And we’ll do so starting from scratch.

We’ll create a potion, and a big potion
We’ll also create some currencies bronze, silver and gold.
And finally we’ll create some recipes

  1. Create Database
  2. Create ItemCategories
  3. Create Currency
  4. Create ItemDefinition
  5. Create CraftingCategories
  6. Create CraftingRecipes


As shown above when creating a new database both ItemCategory and CraftingCategory are given an Uncategorized category. These cannot be removed. By design an ItemDefinition and a CraftingRecipe MUST have a category. When an ItemDefinition is created it will be given the Uncategorized category and you will be able to change it.

Once a database is created the first thing to do is create some categories. In this simple example we want 3 ItemCategories.
  1. Base : The base ItemCategory which we will use for all out items
  2. Consumable : The ItemCategory for the potions
  3. Materials : The ItemCategory for our crafting materials used to make out potions

For this example I want all the Items to have an icon and a price. In addition to that Consumable items will have a baseHeal.
For showcase purposes I’ll also add a CategoryIcon to Base and a bonusHeal to Consumables.


It is important to understand the difference between the Attribute tabs:
  • Category attributes : Attributes that are defined in the category are the same for all the items in that category. For example “CategoryIcon” would be used in an inventory UI where items are split in category tabs, with each tab button being a “Category Icon”
  • Item Definition attribute : Attributes that are defined in the ItemDefinition are the same for all items that share the same ItemDefinition. For example “baseHealAmount” will be the same for all “Potions”.
  • Item attribute : Attributes that are defined in the Item are unique to that item instance. For example you can have two “Potions” with different “bonusHealAmount”

The magic of being able to set any attribute type you want was implemented by Justin. You can specify which assemblies and Types are shown in the type search field within a special window which is shared by Behavior Designer 2 and the inventory system.

You also saw that I specified the Base category as “abstract”, this prevents the Base category from having ItemDefinitions. When adding ItemDefinitions you’ll see that Base won’t appear as an option when changing the ItemDefinition category.

As a reminder, Mutability is set for items that should be able to change Item attributes after they are created. In our simple example that is not the case so I set them as immutable.

Since we have a price attribute of type CurrencyAmounts, I’ll first create the Currencies I want before the ItemDefinitions.


The order In which I set the values is important as there are conditions which prevents a currency to fraction to another currency which is more valuable, similarly for overflow the currency cannot be less valuable.

Fraction and Overflow currencies are set for automatic currency conversion so that a currency that will go above its max value, in this case 99, will then convert to the overflow currency.
Example 1: 55 Silver + 50 Silver => 1Gold | 5Silver
Example 2: 2 Silver - 50 Bronze => 1Silver | 50Bronze

Now that we have our currencies set up we can set up some ItemDefinitions.


With that we have created a Potion, a big Potion , a HealWeed and a Spring Water. As you would expect all attributes set in the category are available in the Definition once the ItemCategoryField is set.
As shown we inherited the icon from Potion to Big Potion by making Big Potion a child of Potion. When setting the Override value the Variant Type is changed automatically for ease of use. We also show the attribute values in the list when possible so that you can easily view what the values are.

With the ItemDefinition done, it is time to show the CraftingCategories. In this case I want Two recipes. One will have ItemDefinition ingredients only and the other will have ItemDefinitions + Currencies Ingredients. To differentiate them I’ll create two CraftingCategories


Setting a custom CraftingRecipe Type will allow people to create their own complex crafting system. Out of the box we will have two CraftingRecipe types, the base one and the one with currency.

The difference will be obvious when we create the recipes.


PS: At the end of recording everything I thought of swapping out the colored boxes by the “Icon” and “CategoryIcon” attributes if they are available.

To finish up this showcase here is the magic of the colored boxes (which can now also be icons)



I hope that you will find the editor to be very easy to use and especially very efficient. The goal is to allow designers to make a lot of items very fast while keeping everything very organized.

It is not shown in the gifs but the editor has a validation process that checks all objects in the database when the editor is opened. If something is wrong (i.e you deleted a category manually) the editor will auto fix as many things as possible.

If you have any questions or feedback on the things you see above please let us know. There are still things that we are working out but we are getting closer to a fully functional system.

For the next few months we will focus our time on bug fixing, polish, documentation and getting the demo scene ready.
We have a lot of plans for new features and improvements but they will have to wait for after the initial release.

I’m really excited for the next update when I’ll be able to showcase the demo. We’ve been working a lot on it but there is still a lot to do.
 
Last edited:
@Sangemdoko , thanks for the big update! Just now reading in!

[edit]

Really nice vids showing off the new UI which really shines.

Looking forward to the next update too!
 
Last edited:
Hi, Sangemdoko, thanks for the update. It looks pretty good and intuitive to use. Good job!
I guess I'll have a better idea when it release but before then, I have a couple of questions.

As you know, I'm interested in a shooter inventory system and I'm curious how you can extend it to support the attachment system to the current inventory system. I guess anything is possible with coding but I was wondering if the attachment system can be added as a natural layer on top of the current inventory system without modifying existing code heavily. Modifying existing code means, I'll have to patch it every time there is an update and I'm trying to avoid it as much as possible. To support attachments, you will need a concept of sockets(physical placement) and a list of acceptable slots(logical relationship).
Have you given some thoughts about it? and hopefully have some examples later on.

And is there any info on how the inventory system will integrate with UCC? I believe Justin mentioned that there will be only one inventory and I'm really curious what that means. Having one inventory probably means UCC inventory, i.e., ItemSet, ItemSetManager and etc will be removed. And UCC will directly access the new inventory system. Am I right? Or they will remain as is but there are facade classes that pass information back and forth. I hope it's not the case because it's means there will two inventory systems and one is just proxy of the other. It will make things really complicated because you have to learn two inventory systems and it will probably be a nightmare to have it work well in a Multiplay environment. UCC inventory system is not really a well-designed component and it's better just remove it. Or share some components as common, such as ItemDefinition and ItemCategory. I guess this my last chance to ask just to remove the UCC inventory system and replace it with the new inventory system.


Thanks for your work and I'm really looking forward to testing it when it becomes available.

Cheers!
 
Hi @chrisk

>To support attachments, you will need a concept of sockets(physical placement) and a list of acceptable slots(logical relationship)

At release we won't have a support for this use case. You'll most likely have to create something yourself. That being said with the new Inventory system I don't see any reason you would need to modify any existing code to make this work.
If I had to do something similar I would create a new monobehavior called something like "AttachmentsManager" and add it to your Item gameobject. Then I'd create some sort of Dictionary<ItemCategory,Transform> or Dictionary<int,Transform> that would hold the information of which attachement should go where. Then when you equip or spawn your item you could listen to an event and add any attachement that would be on the Item as ItemAttributes. I hope that makes sense.
If possible I'd like to make sure that these sort of use cases can be achieved by each user without needing to change the source code.

>I believe Justin mentioned that there will be only one inventory

I do not remember Justin mentioning that at all. The UCC inventory system is still its own thing, and the inventory system I am working on is a separate asset. That being said we are making some strategic changes to UCC so that the integration can be really smooth. UCC and my inventory will share some interfaces and base classes to achieve that.

UCC will focus on the equipping and using of weapons and other hand-held items. For that, it still requires ItemSets and ItemSet Managers. Without them you wouldn't know what combination of items are allowed or what animation to play when dual wielding vs using a sword, etc...

My inventory system allows for item management, none equipable items, visual only (cloth) items, equipment slots, etc... But it does not take care of character using complex weapon combinations (although it allows simple use cases).

So both systems are independent and can work on their own. They both have strengths and the goal is for the integration is to take the best of both worlds and make it so that it feels like one big system.
And even though we'll try our best to get it right on the first try, there will always be ways to improve. The release of the new inventory system is just the start, as mentioned before I have a lot of ideas on how it can be expanded and I'm sure the community will come up with even more ideas. So I hope you look forward to it
 
@Sangemdoko ,

I know, I keep harping on about socketing and attachments.... but if I understand your post above correctly (and I can code, a little) and the general design themes of this asset, you can add additional ItemAttribute(s) to a mutable Item in runtime - so child GameObjects carrying say immutable different sub-categories of item (attachments - sockets, inscriptions, affixes) could be 'read', an event could trigger it, (say equipping or unequipping or using or whatever) and each in turn add ItemAttributes to the 'parent' GameObject/Item... Unequipping could remove these additional ItemAttributes. Also, running this method, you could also change perhaps a calculable set of sub 'names' for the item and create in runtime an expanded name for the parent item too in the same manner...

The central point being even after all the pre-runtime construction work with ItemCategories and ItemDefinitions (and with all the ItemAttributes that come with that) you can STILL add yet further ItemAttributes in isolation to created runtime Items anyway - and all saveable and loadable.

In other words, yes, I can see readily how this and much much more could be easily achieved. In time, perhaps in a not-much-later release you could post a demo scene with that sort-of-a-thing going on but my preference would be rather an earlier 1st release without (in case you didn't already guess!).
 
@Sangemdoko ,

Looking at the above, some really nice API methods and classes will be handy determining whether Item Attribute(s), Item Category(s) (perhaps also ancestry checks?) and/or Item Definition(s) (again ancestry checks too?) are present in an Item? Also, easy to use methods/classes to add in Item Attributes to any ole Item at runtime? Methods/Classes to get value of an Item Attribute, also to get the Type of an Item Attribute or to check if an Item Attribute has type X? Lots of useful stuff like that?
 
Top