Inventory system with both dynamic and static sized partitions

[spice compass]

Hey Devs!
I am currently working on the inventory system in my game.
It is based on 'partitions', each inventory has a static sized partition, which is an array of ItemStack, the holder for items in the game world (handles count, damaging, destruction, ...) and a unlimited amount of dynamic sized partitions in form of a Dictionary<int, InventoryPartition> where the int is just an identifier. InventoryPartition is just a struct with a List<ItemStack> and a int which determines the current maximum size.

The Inventory class is in the attachments.

I would like to hear some more opinions on my approach, so what do you think? Is it too complected? Do you have an idea for improvements?

Disclaimer: the code is a prototype and has not been tested, optimized or checked for mistakes yet

[hearty thistle]

So... you have an Inventory that contains an array of stacks, and a dictionary, that's also essentially an array of arrays of stacks?
For me, this poses the question... why?

But assuming you do need that:
I would advocate that you move the logic for managing a list of stacks (whether or not the size of that list can change) into its own class (i.e. Container). Then your Inventory could simply contain one or multiple Containers and would be easier to manage.
It would also give you the advantage of being able to internally associate stack Guids with indices for faster lookups (assuming the number of items per container becomes so large that stack lookup time gets relevant)

[spice compass]

The question is very valid, items that the player picks up are stored in a per type system, armor to armor, arrows to arrows, etc. the size of these item type bound partitions can be changed over time by lets say a bigger bag that the player gets. Because these sizes can change they cant be made with arrays or the arrays would need to be reinitialized when changing the size.
On the other hand there are fixed slots like an slot for the shield or slots for the armor, which need to have a fixed identifier for a specific slot, for that arrays seem like an obvious choice.

I had the idea of making an class for handling the list logic too, but because every class only needs one static sized partition I placed the logic in the inventory class.
For the list based partitions however I could put their logic into the InventoryPartition struct, but that could go at risk of loosing readability, because code that does the same thing (in two different ways: one for the static, one for the dynamic) are placed in two different classes.
A work-around would be to make one class that can either be static or dynamic, that are based only on arrays, with the tradeof of having to copy the array when changing its size.

[hearty thistle]

code that does the same thing (in two different ways: one for the static, one for the dynamic) are placed in two different classes
That is exactly what I would put in my proposed Container; So logic does not get duplicated.

A work-around would be to make one class that can either be static or dynamic, that are based only on arrays, with the tradeof of having to copy the array when changing its size.
Again, Container.
Except you don't need to base it around an array. Just use a List and tell the wrapper class in its constructor whether it can resize.

There are fixed slots like an slot for the shield or slots for the armor, which need to have a fixed identifier for a specific slot, for that arrays seem like an obvious choice.
Slot by type seems like you'd rather want a dictionary than an array to me - using the type as a key.

Because these sizes can change they cant be made with arrays or the arrays would need to be reinitialized when changing the size.
To be clear, I'm not criticizing that you are using Lists.
But to be clear; reinitializing arrays is exactly what those do under the hood when their Count exceeds their Capacity.

[spice compass]

Telling the Container in the constructor whether it is an static of dynamic sized was actually my first approach of the problem, but I dont know if we are talking about the same thing in terms of the fixed slots. I think what you mean is placing items of a common type in a collection, correct me if Im wrong. I mean that you have possibly some slots which need to be identified by an index or some other unique identifier, for example: the shield slot the player coresponds to the stack at index 0, the helmet slot of the player coresponds to the stack at index 1, chestplate -> index 2, ...