Inventory systems quickly become complex: free slots, stack sizes, sorting, weight limits, and separate equipment spaces. For this prototype, I chose the opposite approach. Every item category receives exactly one fixed slot.
The Enum Defines the Layout
ItemType contains categories such as Weapon, Armor, Potion, Bow, Key, and Coin. Because enum values start at zero and increment sequentially by default, they can be used directly as positions in an array.
int slotIndex = (int)item.Type;A Weapon item therefore always occupies the weapon slot, while a Bow always occupies the bow slot. The mapping is deterministic and requires no additional configuration.
Keeping the Slot Count in Sync
The inventory creates a nullable array whose length is derived from the enum:
public Item?[] Slots { get; }
public Inventory()
{
Slots = new Item?[Enum.GetValues<ItemType>().Length];
}When a category is added, the inventory automatically grows the next time it is created. null represents an empty slot, while an Item represents an occupied one.
Collisions Are Part of the Rule
Before inserting an item, AddItem checks whether the calculated slot is free. A second sword cannot silently replace the first. The existing state remains unchanged, and the application reports the slot, current item, and rejected item.
RemoveItem resets the assigned slot to null. ShowInventory iterates over every position and converts each index back to ItemType, displaying the category alongside its contents.
Strengths and Limitations
The approach is small, fast, and easy to reason about. It fits equipment systems with one item per category or adventure inventories built around a fixed set of tools.
It would be too restrictive for a conventional grid inventory. Multiple weapons of the same type, stacks, and freely assignable slots require a different data structure. The enum order also becomes part of the storage format: rearranging values later changes their indices.
Next Iteration
Next, I would make AddItem and RemoveItem return an operation result instead of writing directly to the console. A console interface, graphical UI, or test could then decide how to present that result.
Other useful additions include unit tests for occupied slots, lookup by ItemType, and a clear rule for whether removal must match only the type or the exact item instance.
The Project
The project page contains the features, technical overview, and current status: