Ultimate Inventory System WIP

>I believe Justin mentioned that there will be only one inventory
I do not remember Justin mentioning that at all.

Below is what I read and I'm not sure if I misinterpreted.
I think it's best to put all inventory related stuff to the new inventory system for the clear separation.
As far as inventory code is concerned, UCC only needs to know what it currently holds.

The problem with the current ItemSet and ItemSetManager is that you have to pre-configure all possible combinations and if the number of item increase, it will become unmanageable quite quickly. It may work for 5 items but not for 50 items. I'm not sure how the new system will work.
Thanks.

1580785997975.png
 
Hi @Duffer123

Just to clarify, you cannot Add Item Attributes to items directly. You can change values of existing ones if the item is mutable.
The reason we have this restriction is so that all items from the same Category will have the same name/type attributes which means you can perform a group operation safely.
From a design point of view, it makes sense if all items of the same ItemDefinition to behave in a similar manner. Of course, if you plan in advance you can add a few Item attributes in the ItemCategory, like a GameObject[] for attachments or string for prefix/suffix. Maybe just a handful of items will use those attributes but that's perfectly fine.

The save feature will save any serializable data that is part of the Item attributes. For example saving strings, int, etc.. is fine, but saving GameObjects attributes which are not prefabs may be out of scope.

The item has a reference to its ItemDefinition and ItemCategory and those have functions to find parents/children, know if it "DirectlyContains" or "InherentlyContains" another object, you can find the root, etc... When you get an attribute you need to know its type in advance, you can get its value directly or get the attribute and change it (if the item is mutable), you can loop through attributes, try get attributes from Item, ItemDefinition and ItemCategory from the Item directly, etc...
If there is any useful function like that missing I'll add it
 
Hi @chrisk

In the quote above Justin means there is a single Inventory Component as in the Inventory Monobehavior attached to the character. This component is from my inventory system. As he mentions there is a "bridge" component that allows you to equip weapons in a UCC way, which still uses ItemSet and ItemSetManagers. So both systems work toghether. UCC does equiping and using weapons, and my inventory system does the item management and other things.
In terms or scalability, I agree that setting ItemSets and ItemSetManagers manually takes a lot of time. We are looking into ways to hopefully simplify this process using categories. We'll letyou know once we have more details on this.
 
Hi @chrisk

In the quote above Justin means there is a single Inventory Component as in the Inventory Monobehavior attached to the character. This component is from my inventory system. As he mentions there is a "bridge" component that allows you to equip weapons in a UCC way, which still uses ItemSet and ItemSetManagers. So both systems work toghether. UCC does equiping and using weapons, and my inventory system does the item management and other things.
In terms or scalability, I agree that setting ItemSets and ItemSetManagers manually takes a lot of time. We are looking into ways to hopefully simplify this process using categories. We'll letyou know once we have more details on this.

I see. Thanks for the clarification. Yeah, I think using ItemCategories instead of the actual item in ItemSet and ItemManager may work. Still unclear but I believe you can come up with something reasonable. ^^
Please keep the good work. Cheers!
 
@Sangemdoko ,

Understood. So the moral of the story is include all those ItemAttributes you might possibly need in the 'final product' items through use of Item Definition and ItemCategory.

Thinking again of the API, a method to ascertain whether an ItemAttribute value is Null would be useful or indeed whether an ItemAttribute (named as a string as well) exists.

Also, I recall way back you mooted the idea of one of the default/regular ItemAttribute types being a mutable array/list of Items? Could that be done as it would no doubt make all sorts of attachment/socketing/affixes/naming issues a whole lot easier?
 
ItemAttributes are never null, their values can be though. To get an attribute you most of the time will do so by name.

Here is snip of one of the tests to give you an idea of how to get attribute values:

C#:
//option1 (get the base class)
Assert.IsTrue(itemCategory.TryGetAttribute(attribute.Name, out var requiredAttribute1));
Assert.AreEqual(requiredAttribute1.GetValueAsObject(), 42);
//option2 (get exact value check for null)
var requiredAttribute2 = itemCategory.GetAttribute<AttributeInt>(attribute.Name);
Assert.NotNull(requiredAttribute2);
Assert.AreEqual(requiredAttribute2.GetValue(), 42);
//option3 (one line if not checking if null)
Assert.AreEqual(itemCategory.GetAttribute<AttributeInt>(attribute.Name).GetValue(), 42);
//option4 (get the value directly)
Assert.IsTrue(itemCategory.TryGetAttributeValue<int>(attribute.Name, out var requiredAttributeValue));
Assert.AreEqual(requiredAttributeValue, 42);

Here I do it on an ItemCategory but it works the same on the Item and ItemDefinition

Also, I recall way back you mooted the idea of one of the default/regular ItemAttribute types being a mutable array/list of Items? Could that be done as it would no doubt make all sorts of attachment/socketing/affixes/naming issues a whole lot easier?

As shown in the editor videos you can make the attribute of any type you want. I have special type ItemAmounts, ItemDefinitionAmounts, ItemCategoryAmounts, etc... that can be used exactly for that purpose and they have custom drawers. Of course, you can create your own type and use it as an attribute.
 
@Sangemdoko ,

Yeah sorry, I meant to say null values. The code above is suitably reassuring.

I suppose in terms of a collection, ItemDefinitions will be absolutely fine for the purposes of attachments etc. If they are 'solid' attachments you can always bring them in to being later anyway if unsocketed or whatever.
 
Last edited:
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.
Hi, how are you?
Really amazing, good work ;)
 
Yeah, I think using ItemCategories instead of the actual item in ItemSet and ItemManager may work.
The Item Set Manager now uses Item Definitions. When a new item is added it'll place that item in the order of the definitions. If the item definition is nested then it'll use the parent(s). If no definitions are found that match the item then it'll be added to the end.
 
The Item Set Manager now uses Item Definitions.

If I understand correctly, each item will have a unique ItemDefinition, right?
If so, does that mean we will still have to list each ItemSet in the ItemSetManager as before? The biggest concern I have is that this scheme will not scale up to a large number of items.

Instead of using an ItemDefinition, using ItemCategory may simplify quite a bit.
For instance, let say you have Primary, Secondary, Melee, Throwable, Shields, and Potion ItemCategories, each weapon will fall under one of the categories.

For switching items, you press a number key. Each category is mapped to each key, for example, Primary->1, Secondary->2, Melee->3, Throwable->4, Shield->5, Potion->6, and lastly, BareHand->0 so that you can unequip too. The key mapping will be assigned in the ItemCategory.

Let say, you have several Primary weapons in your inventories. Instead of specifying an order for each weapon manually, the weapon will be chosen by preference value. The preference value is specified in the ItemDefinition. The higher the value, the higher the preference. If you press the same key twice, it will cycle through in the order of the preference.

The default slot for each item is specified in the ItemDefinition, Rifle->RHand, Pistol->RHand, Shield->LHand and so on.
If a weapon is equipped to the same slot, it will replace the previous weapon.
And if you want to equip the weapon to the different slot, you will press Shift+<number>.
If a certain weapon cannot be equipped to the different slot, you will set off a flag, "Equippable to Alternate Slot" in the ItemDefinition.

This way, you can control what weapon to equip/unequip without specifying orders in ItemSetManager.

I hope it helps simply setting things up.

Thanks.
 
If I understand correctly, each item will have a unique ItemDefinition, right?
No - you can have a single item definition for multiple items.

Instead of using an ItemDefinition, using ItemCategory may simplify quite a bit.
For instance, let say you have Primary, Secondary, Melee, Throwable, Shields, and Potion ItemCategories, each weapon will fall under one of the categories.
On the category item within the inventory system you can specify it should be an equip set. This will then expose it to the item set manager. You could set it up as you mentioned by having a category for each type of weapon.
Let say, you have several Primary weapons in your inventories. Instead of specifying an order for each weapon manually, the weapon will be chosen by preference value. The preference value is specified in the ItemDefinition. The higher the value, the higher the preference. If you press the same key twice, it will cycle through in the order of the preference.
Having an ordering is an interesting idea. This would be pretty easy to add, and would actually be similar to how the category is setup with being exposed or not. The underlying item set manager structure wouldn't really change though, it would just change the order that the item gets added to the item set. Right now if an item shares the Item Definition then it gets added to the end of the list for that item definition. If you had an order specified then that item would not be added to the end of the list.
The default slot for each item is specified in the ItemDefinition, Rifle->RHand, Pistol->RHand, Shield->LHand and so on.
If a weapon is equipped to the same slot, it will replace the previous weapon.
And if you want to equip the weapon to the different slot, you will press Shift+<number>.
If a certain weapon cannot be equipped to the different slot, you will set off a flag, "Equippable to Alternate Slot" in the ItemDefinition.
I haven't gotten to the part of the integration that would limit the number of weapons to a particular slot but definitely plan to have a use case demonstrated with it in the demo scene.

All in all I continue to want to use the existing equip abilities as those are working really well. I think that these changes to the item set manager will make adding a large set of weapons a lot easier.
 
@Sangemdoko ,
I have two questions :
1. An item can be set with the required materials ,But what if I break up this item, and the object I get is different from the object I made ,For example, I made a chair use board, but when I break it down I just get wood.Can it be achieved?

2. Can you read the excel sheet and create the database automatically ?

3. Sorry, my English is not very good, I hope I've made myself clear .

4. I'm really looking forward to the plugin launch . ❥(^_-)
 
@Sangemdoko , I think what @Zyuan is getting at in point (1) above is salvaging down one or more items from an original item. I don't know what you think, but I see this as rather the parent item (that can be broken down or salvaged down in to constituent part items) having an array of salvageable items or item definitions and, perhaps, reference to the ability(s) and/or stat(s) needed (and scores/levels required)?

p.s. how's it coming along, particularly the demo?
 
Hi @Zyuan and @Duffer123
For now you cannot create a database from an excel sheet. I don't think we'll have supprot for that because the item structure with the custom attributes is too complex for a simple table. In the future we will look into ways to export and import databases, I'm not sure about the file format we will use. It will probably be Json, XML or something similar. Note that I'll look into this after the initial release.

For breaking items in smaller parts, Duffer idea can work well using an ItemDefinition attribute. If it's simple I would do it that way. If it's more complicated and if it's a two way thing, for example 2 wood = 1 chair and 1chair = 2 wood, you could create a crafting recipe and cache all the recipes the itemDefinition is part of. Then make a dictionary itemDefinitiom -> recipes.

It really depends on your use case.

Right we are working on the custom inspectors for the important components. We're trying to make them as easy and efficient to use. Once that is done we'll do more with saving/loading save data... which I had a solution for but it needs quite a lot changes and polish. Then we'll have a ton of tiny things to polish and tweak all over the place. The asset has grown to be very big.

I'm glad you are looking forward to it
 
@Sangemdoko , Hi. Been thinking about runtime functionality again. I've been thinking about a topic you did look at earlier... new runtime-created ItemDefinitions and ItemCategories. As far as I thought both are otherwise created outside runtime as Scriptableobject assets? Are they? However, you were thinking about ways to create new ItemDefinitions and/or ItemCategories in runtime. Functionality to say create a new ItemDefinition (obviously couldn't be a scriptableobject) at runtime by also defining parent hierarchies of ItemDefinitions and ItemCategories from which the new ItemDefinition inherits would be a wonderful thing, assuming also saveable and loadable? Will this be possible? What's your thinking on that?
 
@Duffer123 , as you say itemCategories and itemDefinitions are scriptableObjects. There is nothing preventing you from creating them at runtime
myCategory = ItemCategory.Create("MyCategory");
MyDefinition = ItemDefinition.Create("MyDefinition", myCategory)
Etc...

In the create function you can pass in the attribute values you want and the parent/s if you want.

Now as you say making those saveable is a bit more complicated, but it should be possible. To be faire I do not see many use cases for it. It should possible by serialing the scriptableObjects created at runtime and creating them again when loading a save. So to get things srarted as fast as possible I think I won't support runtime saveable ItemDefintion and ItemCategories just yet within the context of the database. If the community asks for it after I'll look into solution for it.

I hope that helps
 
@Sangemdoko , thanks, yes that makes sense. Definitely skip any direct implementation/support for saving loading runtime instances of ItemDefinitions though to get this Asset to first release quicker... ;)
 
Hi @Duffer123 ,
I just added the save/load feature back on the demo scene. And it works! ... almost. I still have to figure out some tiny issues that popup with some items not loading correctly because they were not saved in the correct order. And I haven't tested nested item saves with the new system but I doubt it'll work right now. So I'll have to figure out something for that too.
Apart from that I'm currently fixing a lot of bugs in the demo scene and it's slowly starting to all fit together.
At the end of the week I will work closely with Justin to work out some cool features that will be especially useful for the Integration demo.
I know its all very exciting but I will have to ask you to be a bit more patient as we haven't even reached the polish phase yet
 
Top