Ultimate Inventory System WIP

Sangemdoko said:
In the demo we use an array. You are allowed to have [empty, empty, myAttachment, myOtherAttachement, empty]. Now if you want to order your attachments I think that comes with the logic of the UI. You can take the slot array within the item, order it and then display it. You could even apply that order change to the item.

But for this specific use case, you could have two arrays: item[] and index[], where your index can be of type int, enum, etc...
Click to expand...

Okay

So in this case, when the asset is out i should extend the base inventory to make it work using the two arrays or dictionary?

Sangemdoko said:
We don't support dictionaries as attributes (our serializer won't serialize it), if you find a good use case though we may look into supporting it.
But for this specific use case, you could have two arrays: item[] and index[], where your index can be of type int, enum, etc...
Click to expand...

I don't think i can find a "good use case" or unique that only works with dicionaries, because you can always use the two arrays trick. I do think that dictionaries would help to reduce the tricks needed to implement sockets, for example in equipped items, inventory slots (as i said previously) and others.

Sometime ago, i made a simple inventory system that suits my game. It's very simple, it just have:

- AbstractContainer (extendable)
- AbstractInventoryObject (extendable)

(I'm not trying to impose my work, only make a point)

With a simple dictionary in the AbstractContainer that contains AbstractInventoryObject, you could easly transfer objects between containers and change the size of those (changing the dictionary keys).

Using List (i think that is what is used, not primitive arrays), the size should be handled with another int variable. So you will have:

- size: Integer
- index: List
- object: List

But i completly understand your point that Unity serializer don't work with dictionary. It should, but that is another discussion.

Edit: Thinking about UCC movement (Adventure & Combat), maybe it would be nice to have an:

- List inventory that works as currently, when you don't need to reorder items.
- Dictionary inventory if you want implement sockets.

So the asset will be even more agnostic and allow different types of approach.
 
Last edited:
@Haytam95
Thank you for your insight on this. I'll keep it in mind and I'll discuss with Justin to see if he can add dictionary serialization in the shared serializer.

I'm not sure we are talking about the same sockets here. I was talking about items within other items such as enchantment scrolls or magical gems that you add to your weapon.
If I understand correctly you are talking about character inventory sockets? as in headgear, armor, pants, footgear, etc.. for character equipement?

If that's the case then this is part of the ItemCollections. You can extend the ItemCollection class so that it suit your exact needs. As mentioned before you can have multiple ItemCollection in an inventory each can work differently.

I think I'll make some generic ItemCollection which could be used as-is or extended. Some generic use cases could be:
  1. for limited space (max amount 99)
  2. dictionary like collection use for character equipments mainly (i.e 1 armor, 1 weapon, 2 accessories, etc..)
  3. custom sized stack ItemCollection where you can split items in different sized stacks, instead of one stack per item
and maybe others.

If you were indeed talking about item sockets as in items within items, then I think it should also be possible. I want to make the ItemCollections serializable and if so nothing prevents you from using an ItemCollection as an attribute for your item.

You could also technically use an Attribute<MySlotsStruct> if you know in advance all the possible keys of your dictionary. Usually you'll have up to five slots, of course that depends on the game. But something around those lines could be a potential solution:

C#: 
//Pseudo code untested
[Serialiazable]
public struct MySlotStruct{

public int usableSlots;
public Item slotOne;
public Item slotTwo;
public Item slotThree;
public Item slotFour;
public Item slotFive;
}

It really depends on your game. But the point is that there are no restrictions, you should be able to use any types as attributes as long as it's serializable by our serialization class. We'll continue working on our shared serialization class so that it can serialize many types of objects.

I hope that clears any doubts you had on this matter.
 
Sangemdoko said:
@Haytam95
Thank you for your insight on this. I'll keep it in mind and I'll discuss with Justin to see if he can add dictionary serialization in the shared serializer.

I'm not sure we are talking about the same sockets here. I was talking about items within other items such as enchantment scrolls or magical gems that you add to your weapon.
If I understand correctly you are talking about character inventory sockets? as in headgear, armor, pants, footgear, etc.. for character equipement?

If that's the case then this is part of the ItemCollections. You can extend the ItemCollection class so that it suit your exact needs. As mentioned before you can have multiple ItemCollection in an inventory each can work differently.

I think I'll make some generic ItemCollection which could be used as-is or extended. Some generic use cases could be:
  1. for limited space (max amount 99)
  2. dictionary like collection use for character equipments mainly (i.e 1 armor, 1 weapon, 2 accessories, etc..)
  3. custom sized stack ItemCollection where you can split items in different sized stacks, instead of one stack per item
and maybe others.

If you were indeed talking about item sockets as in items within items, then I think it should also be possible. I want to make the ItemCollections serializable and if so nothing prevents you from using an ItemCollection as an attribute for your item.

You could also technically use an Attribute<MySlotsStruct> if you know in advance all the possible keys of your dictionary. Usually you'll have up to five slots, of course that depends on the game. But something around those lines could be a potential solution:

C#: 
//Pseudo code untested
[Serialiazable]
public struct MySlotStruct{

public int usableSlots;
public Item slotOne;
public Item slotTwo;
public Item slotThree;
public Item slotFour;
public Item slotFive;
}

It really depends on your game. But the point is that there are no restrictions, you should be able to use any types as attributes as long as it's serializable by our serialization class. We'll continue working on our shared serialization class so that it can serialize many types of objects.

I hope that clears any doubts you had on this matter.
Click to expand...

Thank you Sangemdoko for the explaining.

Yes, you're right i was talking about ItemCollections.

Sangemdoko said:
As mentioned before you can have multiple ItemCollection in an inventory each can work differently.
Click to expand...

Oh ok, so in an inventory you could have for example 5 ItemCollections that allows only one object each one, and that act like inventory sockets. And if you want to rearrange them, you swap ItemCollections position. I'm understanding right?

And if i wanted to have just one ItemCollection, i could extend that class and make it work with a dictionary. So in the end i will have:

- Without dictionary: Inventory script with (n slots) * ItemCollections. Each ItemCollection allows only one item.
- With custom dictionary: Inventory script with 1 ItemCollection that uses dictionary.

Am i right?
 
ItemCollections can have any amount of multiple items. example:

3x apple
1x iron sword
6x potions
etc...

So if you want to have sockets you could have a custom ItemCollection in which you restrict the type of items that can be added. I will look into adding a generic ItemCollection where you define item sockets, out of the box. I think it will be useful for a lot of people.

It would be an extension of ItemCollection called something like "EquipmentItemCollection" and you would give it an "EquipmentSetSettings" scriptableObject as reference. In that "EquipmentSetSettings" you would have a list/dictionary of (string, ItemCategory). Example:

RightHandSlot , Weapon
LeftHandSlot , Weapon
HeadSlot , HeadGear
FootSlot , FootGear
etc...

Then using that information, the "EquipmentItemCollection" should know what type of items can be added, removed, etc... and you could use the names of the slots as keys to get the item of a specific slot.


So your character would have an Inventory with two ItemCollections:
  1. (LimitedItemCollection) Main collection: the ItemCollection with all the character items, with a limited amount of different item 'M' and a stack limit 'N'.
  2. (EquipmentItemCollection) Equipment collection: The ItemCollection with the items that are equipped on your character, with slots restricting the amount and type of items allowed.
This should allow for easier use for non-programmers and gives a good example use-case for ItemCollections.
Thank you for the feedback!
 
@Sangemdoko ,

I thought of some other miscellaneous things, albeit minor.

In terms of functionality with loot tables, you've got your default weightings but I am presuming/checking these default weightings can be shunted or modified by other Item Attributes or otherwise ie. with a 'lucky' character etc? You probably have an idea how that could be implemented.

In terms of ItemAttribute types as standard - obviously Bool, Int, Float, String, GameObject, Prefab GameObject?, Color32. What about Image, Texture2D, Material, Sprite, Mesh, Vector2, Vector3, Rect, Text, AudioClip, AnimClip (could be useful), Particle Effects, Enums (which are 'loaded' in)? What about something similar to Kryzarel's CharacterStat (free Asset, Asset Store)? What sort of other types are in 'as standard'?

Will the example scene and UI show how to filter Items by ItemCategory (including Items say which have more than one ItemCategory in nest)?

Finally, nesting, well, nested Categories, how nested? Can you have X Category which is a child of Categories A, B and C and Category C is a child of Categories D, E and F. In that example, will X Category have the default Category ItemAbilities of A, B, C, D, E and F, if you see what I mean? How deep does the nesting go? (to be fair 4 or 5 deep should be more than enough for most things..>!)
 
Last edited:
@Duffer123
For attributes we are looking into automatically creating all the possible attribute types automatically in your project, using Reflection. This would allow you to not need to write attributes manually for each type.

That means if you create a new class "MyClass" a new Attribute "AttributeMyClass" will be available. Note that this is still in the works, we're not quite there yet.

And if you want a custom attribute with a modify expression function slightly different than default then you can create your own by inheriting Attribute<MyClass>. So you can add all the types and functionality you want.

Yes I will show how to filter per category in the demo. In the gifs for the shop you can see tabs for different categories. You can decide to filter by "direct" category or "inherit" category. "direct" means the parent of the itemDefinition is the category. "inherit" means the category is one of the parent or any ancestor category of the itemDefinition.


Nesting is Infinite (within reason). Categories can have multiple parents and multiple children. Example:

Sellable
Buyable
Viewable
Dropable
Standard (Sellable, Buyable, viewable, Dropable)
Weapon (Standard)
Armor (Standard)
Sword (Weapon)
Bow (Weapon)
Consumable (Standard)
etc...

each category defines what the items within have as attributes and actions.

In this example if sellable has a "Sell Price" attribute all the children categories must have a "Sell Price" attribute, it is required (We take care of automatically adding and removing attributes that should or shouldn't be there)
Therefore Consumable just like Bow will have a "Sell Price" attribute

I hope that clears all your doubts
 
@Sangemdoko , you know how you have that nice search by name or id edit box for ItemCategories wizard and ItemDefinitions wizard editors - do you have a similar one for ItemAttributes?
 
@Duffer123 , I'm currently refactoring some of the core code to make it easier to use and more readable.

We are discussing with Justin and Sarah on planning the demo scene (which I am very excited about, but it will take a long time to get it to a polished state). We are scrapping the "demo" scene I showed in the previous update and we'll start from scratch, once we have decided on our scope and plan.

We are still discussing the UCC integration with Justin. We'll actively work on it once the demo scene has already progressed significantly.

Apart from that, we need to make the editor window more user-friendly... and better looking. Then there's the usual bug fixing, documentation, refactoring, etc...

So in summary development is going well, but there is still a lot to do before we can put it in your hands. So you'll have to be a bit more patient.
 
@Sangemdoko , thanks for the update! I'm assuming in all the above that the essential core framework (classes structure) remains much the same. If you do take a different tack on that, do let us know. Aside from that, I'll try and be as patient as possible (!), and look forward to the next update. That new demo scene sounds (a way off but) very promising...
 
Hello, I wanted to ask if the first release of the Inventory System is still planned for this year?
We very much hope that you are still working on a small but nice solution and then extend it later.
(Its nice to have a polished demoscene, but not strictly necessary for a release)

There is currently no useful inventory solution in the Asset Store and we all hope for a release soon.
 
Hi @Dragonflame I'm sorry but the Inventory System was never planned for this year. We are working extensively on the asset and we hope to release it sometime Q1-Q2 2020. That could change at any time though, we will only release the asset once we believe it is ready.

To give you an indication of our progress, I am currently refactoring the core components and changing some functionality to make it easier to understand and use while making it more performant.

Apart from refactoring, there are four big things that will take a lot of time:
  1. A new demo scene built from the ground up which can showcase all the best features of the asset. The demo scene I showed in the posts will be scrapped completely, so expect something different. We are about to start working on this new demo very soon though, I'm quite excited about it.
  2. The Editor window needs a revamp. It's functional but the layout is inconsistent with the rest of the Opsive library. So it will be remade at some point.
  3. The Opsive UCC integration, It was made clear that a majority of the people want the integration at launch, or at least soon after. We've just thrown some ideas around with Justin but we haven't come up with a concrete plan just yet.
  4. Documentation and videos. I've been writing bits and pieces for the documentation, but putting everything in one document and making it easy to understand takes time. And of course the videos are the same. I assume that we could make most of the videos after the release.
I know its a long wait but hopefully, it will be worth it.
 
Last edited:
Sangemdoko said:
Hi @Dragonflame I'm sorry but the Inventory System was never planned for this year. We are working extensively on the asset and we hope to release it sometime Q1-Q2 2020. That could change at any time though, we will only release the asset once we believe it is ready.

To give you an indication of our progress, I am currently refactoring the core components and changing some functionality to make it easier to understand and use while making it more performant.

Apart from refactoring, there are four big things that will take a lot of time:
  1. A new demo scene built from the ground up which can showcase all the best features of the asset. The demo scene I showed in the posts will be scrapped completely, so expect something different. We are about to start working on this new demo very soon though, I'm quite excited about it.
  2. The Editor window needs a revamp. It's functional but the layout is inconsistent with the rest of the Opsive library. So it will be remade at some point.
  3. The Opsive UCC integration, It was made clear that a majority of the people want the integration at launch, or at least soon after. We've just thrown some ideas around with Justin but we haven't come up with a concrete plan just yet.
  4. Documentation and videos. I've been writing bits and pieces for the documentation, but putting everything in one document and making it easy to understand takes time. And of course the videos are the same. I assume that we could make most of the videos after the release.
I know its a long wait but hopefully, it will be worth it.
Click to expand...
@Sangemdoko , I don't mind the wait... Sure it will be well worth it. But do keep posting any old clip, snippet or update here as often as you can as it will keep we paying punters from getting twitchy! ;)
 
@Sangemdoko Thank you for letting us know. Yes, the integration of Opsives UCC is very important indeed!
@Justin please help with the integration!

I hope there is also a localization option ;-)
We really hope the release date will be Q1....

Documentation is needed at the release, but in my opinion videos and demo scenes could be done later.
Cheers for working so hard on this asset!
 
Hi @Dragonflame , The localization feature is planned for later after release. We haven't looked into how we could implement it but there is no reason that it could not be done.

As a little update I spent the last month refactoring, documenting and writing unit tests of the core features. We are just about to start working on the new demo this week. I'm really excited about it!

We'll also start working on the integration soonish.
And then another thing that will take a lot of time is refactoring the Editor code... it really needs it.

I hope that answers all your questions :)
 
Last edited:
You must log in or register to reply here.
Top