Розробка системи інвентаря і менеджменту ресурсів у іграх
Система інвентаря — один з тих компонентів, які на ранніх етапах видаються простими («просто список предметів»), а до середини проекту перетворюються у вузол, з яким завязано все: економіка, прогресія, крафт, торгівля, збереження. Переробляти архітектуру інвентаря на етапі контент-продакшену — один із найбільш болючих занять у розробці ігор.
Типічні архітектурні помилки, які закладаються з самого початку
Предмет як MonoBehaviour на сцені. Поширена помилка новачків: ItemComponent на GameObject, Inventory як List<ItemComponent>. Це означає, що кожен предмет у інвентарі існує як об'єкт Unity — неможливо серіалізувати без хаків, складно клонувати, неможливо передати по мережі. Правильний шлях: предмет у інвентарі — це дані, а не об'єкт сцени.
Відсутність розділення між ItemDefinition і ItemInstance. ItemDefinition — це ScriptableObject, що описує тип предмета: назва, іконка, базові стати, stackable або ні, максимальний розмір стека. ItemInstance — структура або клас з runtime-даними: кількість, durability, випадкові афікси, enchantment. Один ItemDefinition може породити тисячі різних ItemInstance. Без цього розділення неможливо нормально реалізувати ні модифікатори предметів, ні їхню генерацію.
Жорстка прив'язка UI до даних інвентаря. Якщо InventorySlot безпосередньо читає Item.name і оновлює Text.text, то при будь-якому рефакторингу даних ламається UI. Інвентар повинен працювати без UI взагалі — eventos (OnItemAdded, OnItemRemoved, OnItemChanged) публікуються через C# events або UnityEvent, UI підписується на них ззовні.
Як будується надійна архітектура
Ядро — InventoryContainer: клас з List<ItemSlot> де ItemSlot зберігає ItemDefinition reference + ItemInstance data + int quantity. Контейнер не знає, чий він — гравця, скрині, магазину. Це дозволяє використовувати одну систему для всього.
ItemDatabase — ScriptableObject або addressable asset з Dictionary<string, ItemDefinition> за GUID. GUID предмета — рядок, не int-ID: це спрощує merge при командній роботі і не ламається при додаванні нових предметів.
Операції над інвентарем — методи контейнера: TryAdd(ItemDefinition, quantity), TryRemove(ItemDefinition, quantity), TryMove(fromSlot, toContainer, toSlot). Кожен метод повертає bool або InventoryOperationResult з кодом помилки (недостатньо місця, предмет не знайден, слот заблокований). Ніяких void-методів для операцій з даними.
Стекування і унікальні предмети
Stackable ресурси (дерево, золото, патрони) і унікальні предмети з афіксами вимагають різної логіки додавання. TryAdd перевіряє itemDef.isStackable — якщо так, шукає існуючий слот з тим же ItemDefinition і заповнює до maxStackSize, залишок кладе в новий слот. Якщо !isStackable — кожен екземпляр займає окремий слот з власним ItemInstance.
Сортування інвентаря — алгоритм, який переставляє слоти за категоріями та всередину категорії за назвою. Реалізується через List.Sort() з користувацьким IComparer<ItemSlot> і анімується через coroutine з поступовим свопом позицій — інакше візуально неможливо розрізнити, що сталося.
Збереження стану інвентаря
Серіалізація — окрема задача. ItemInstance повинен серіалізуватися у JSON-friendly структуру: { "defGuid": "abc123", "quantity": 5, "durability": 87, "affixes": [...] }. Unity JsonUtility погано працює з поліморфізмом — для складних ItemInstance з наслідуванням краще Newtonsoft.Json (через com.unity.nuget.newtonsoft-json) з користувацькими конвертерами.
При завантаженні збереження: десеріалізуємо список слотів, за GUID шукаємо ItemDefinition в ItemDatabase, відновлюємо ItemInstance. Якщо ItemDefinition з таким GUID не знайдений (контент видалений) — слот позначається як orphaned і не викликає краш.
Орієнтовні строки
| Масштаб | Склад | Строк |
|---|---|---|
| Мінімальний | Список предметів, додати/видалити, UI-слоти | 3–7 днів |
| Базовий | Стекування, ItemDefinition/Instance, збереження | 1–2 тижні |
| Середній | Крафт, екіпіровка, drag & drop UI, фільтри | 3–5 тижнів |
| Повний | Генерація афіксів, торгівля, мережева синхронізація | 2–3 місяці |
Менеджмент ресурсів: коли інвентар — це не тільки предмети
У стратегіях та survival-іграх ресурси (дерево, їжа, електроенергія) живуть не у слотах інвентаря, а в ResourceSystem — глобальному або прив'язаному до структури реєстрі з Dictionary<ResourceType, float>. Оновлення відбувається через Tick кожні N секунд ігрового часу, а не в Update() кожен кадр.
Виробники і споживачі ресурсів реєструються в ResourceSystem через інтерфейс IResourceProducer / IResourceConsumer. Це дозволяє додавати нові будівлі без змін до ядра системи. Баланс ресурсних потоків перевіряється в редакторському інструменті ще до запуску — таблиця з поточним виробництвом і споживанням за типами оновлюється в custom Editor Window через EditorApplication.update.
Процес роботи
Проектування розпочинається з таблиці всіх типів предметів та їхніх властивостей — до написання коду. Скільки унікальних предметів планується? Чи є генеровані? Потрібен ли крафт? Це визначає глибину архітектури. Прототип InventoryContainer без UI пишеться першим і покривається unit-тестами в Unity Test Runner — додавання, видалення, переповнення, збереження/завантаження. UI підключається останнім.