Developing Inventory and Resource Management Systems
An inventory system is one of those components that in early stages seems simple ("just a list of items"), but by mid-project becomes a hub everything else connects to: economy, progression, crafting, trading, saving. Rebuilding inventory architecture during content production is one of the most painful activities in game development.
Typical Architectural Mistakes Laid from the Start
Item as MonoBehaviour on scene. A common beginner mistake: ItemComponent on GameObject, Inventory as List<ItemComponent>. This means every item in inventory exists as a Unity object—can't serialize without hacks, hard to clone, impossible to network. The correct way: an item in inventory is data, not a scene object.
Missing separation between ItemDefinition and ItemInstance. ItemDefinition is a ScriptableObject describing the item type: name, icon, base stats, stackable or not, max stack size. ItemInstance is a structure or class with runtime data: quantity, durability, random affixes, enchantments. One ItemDefinition can spawn thousands of different ItemInstance. Without this separation, you can't implement item modifiers or generation properly.
Tight UI binding to inventory data. If InventorySlot directly reads Item.name and updates Text.text, any data refactoring breaks UI. Inventory should work without UI at all—events (OnItemAdded, OnItemRemoved, OnItemChanged) are published via C# events or UnityEvent, UI subscribes from outside.
Building a Reliable Architecture
The core is InventoryContainer: a class with List<ItemSlot> where ItemSlot holds ItemDefinition reference + ItemInstance data + int quantity. The container doesn't know whose it is—player, chest, or shop. This allows one system for everything.
ItemDatabase is a ScriptableObject or addressable asset with Dictionary<string, ItemDefinition> by GUID. An item GUID is a string, not an int ID: this simplifies merges in teamwork and doesn't break when adding new items.
Inventory operations are container methods: TryAdd(ItemDefinition, quantity), TryRemove(ItemDefinition, quantity), TryMove(fromSlot, toContainer, toSlot). Each method returns bool or InventoryOperationResult with error code (not enough space, item not found, slot locked). No void methods for data operations.
Stacking and Unique Items
Stackable resources (wood, gold, ammo) and unique items with affixes need different add logic. TryAdd checks itemDef.isStackable—if yes, looks for existing slot with same ItemDefinition and tops up to maxStackSize, remainder goes to new slot. If !isStackable—each instance occupies separate slot with own ItemInstance.
Inventory sorting is an algorithm that reorders slots by category and within category by name. Implemented via List.Sort() with custom IComparer<ItemSlot> and animated via coroutine with sequential position swaps—otherwise visually indistinguishable what happened.
Saving Inventory State
Serialization is a separate task. ItemInstance must serialize to JSON-friendly structure: { "defGuid": "abc123", "quantity": 5, "durability": 87, "affixes": [...] }. Unity JsonUtility handles polymorphism poorly—for complex ItemInstance with inheritance, Newtonsoft.Json (via com.unity.nuget.newtonsoft-json) with custom converters is better.
On save load: deserialize slot list, search ItemDatabase for ItemDefinition by GUID, restore ItemInstance. If ItemDefinition with that GUID isn't found (content deleted)—slot is marked orphaned and doesn't crash.
Approximate Timeline
| Scale | Components | Timeframe |
|---|---|---|
| Minimal | Item list, add/remove, UI slots | 3–7 days |
| Basic | Stacking, ItemDefinition/Instance, saving | 1–2 weeks |
| Medium | Crafting, equipment, drag & drop UI, filters | 3–5 weeks |
| Full | Affix generation, trading, network sync | 2–3 months |
Resource Management: When Inventory Isn't Just Items
In strategy and survival games, resources (wood, food, electricity) don't live in inventory slots but in ResourceSystem—global or structure-bound registry with Dictionary<ResourceType, float>. Updates happen via Tick every N seconds of game time, not Update() every frame.
Resource producers and consumers register in ResourceSystem via IResourceProducer / IResourceConsumer interface. This allows adding new buildings without changing core. Resource flow balance is checked in editor tool before launch—a table with current production and consumption by types updates in custom Editor Window via EditorApplication.update.
Workflow
Design starts with a table of all item types and properties—before writing code. How many unique items planned? Are any generated? Do you need crafting? This determines architecture depth. Prototype InventoryContainer without UI is written first and covered with unit tests in Unity Test Runner—adding, removing, overflow, saving/loading. UI connects last.