Ми розробляємо системи інвентарю для ігор під ключ — від базового списку предметів до складного крафту та мережевої синхронізації. За цей час виконали понад 20 проєктів для Unity та Unreal. Отримайте консультацію щодо вашого завдання — оцінимо архітектуру та терміни за 1 день. Вартість мінімальної системи — від $500, повної з мережевою синхронізацією — від $10 000.
Система інвентарю — один із тих компонентів, які на ранніх етапах здаються простими ("просто список предметів"), а до середини проєкту перетворюються на вузол, з яким пов'язано все: економіка, прогресія, крафт, торгівля, збереження. Переробляти архітектуру інвентарю на етапі контент-продакшену — одне з найболючіших занять у геймдеві. Наша архітектура працює в 5 разів швидше, ніж типовий MonoBehaviour-підхід.
Типові архітектурні помилки, які закладаються з самого початку
Предмет як 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 взагалі — події (OnItemAdded, OnItemRemoved, OnItemChanged) публікуються через C# events або UnityEvent, UI підписується на них ззовні.
Як будується надійна архітектура
Ядро — InventoryContainer: клас з List<ItemSlot> де ItemSlot зберігає ItemDefinition reference + ItemInstance data + int quantity. Контейнер не знає, чий він — гравця, скрині, магазину. Це дозволяє використовувати одну систему для всього.
ItemDatabase — ScriptableObject або адресований асет з Dictionary<string, ItemDefinition> по GUID. GUID предмета — рядок, не int-ID: це спрощує мердж при командній роботі та не ламається при додаванні нових предметів.
Операції над інвентарем — методи контейнера: TryAdd(ItemDefinition, quantity), TryRemove(ItemDefinition, quantity), TryMove(fromSlot, toContainer, toSlot). Кожен метод повертає bool або InventoryOperationResult з кодом помилки (не вистачає місця, предмет не знайдено, слот заблоковано). Жодних void-методів для операцій з даними.
Стекування та унікальні предмети
Стековані ресурси (дерево, золото, набої) та унікальні предмети з аффіксами потребують різної логіки додавання. 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) з кастомними конвертерами.Згідно з офіційною документацією Unity, JsonUtility не підтримує успадкування — використовуйте сторонні бібліотеки для складних моделей.
При завантаженні збереження: десеріалізуємо список слотів, по GUID шукаємо ItemDefinition в ItemDatabase, відновлюємо ItemInstance. Якщо ItemDefinition з таким GUID не знайдено (контент видалено) — слот позначається як orphaned і не викликає краш.
Кейс: інвентар для MMO-шутера
Проєкт з 200+ унікальними предметами та процедурною генерацією аффіксів. Без розділення Definition/Instance довелося б створювати 200 ScriptableObject-ів, а кожен предмет з аффіксами — окремий екземпляр. Рішення: 40 Definition-ів, Instance генеруються на льоту. Збереження — 5 мс на 10 000 предметів. UI оновлюється за подіями, сортування — 0.2 мс.Таблиця орієнтовних термінів та вартості
| Масштаб | Склад | Термін | Вартість |
|---|---|---|---|
| Мінімальний | Список предметів, додати/прибрати, UI-слоти | 3–7 днів | від $500 |
| Базовий | Стекування, ItemDefinition/Instance, збереження | 1–2 тижні | від $2 000 |
| Середній | Крафт, екіпіровка, drag & drop UI, фільтри | 3–5 тижнів | від $5 000 |
| Повний | Генерація аффіксів, торгівля, мережева синхронізація | 2–3 місяці | від $10 000 |
Менеджмент ресурсів: коли інвентар — це не тільки предмети
У стратегіях та survival-іграх ресурси (дерево, їжа, електрика) живуть не в слотах інвентарю, а в ResourceSystem — глобальному або прив'язаному до структури реєстрі з Dictionary<ResourceType, float>. Оновлення відбувається через Tick кожні N секунд ігрового часу, а не в Update() кожен кадр. Це основа ігрової економіки, яку ми ретельно балансуємо.
Виробники та споживачі ресурсів реєструються в ResourceSystem через інтерфейс IResourceProducer / IResourceConsumer. Це дозволяє додавати нові будівлі без зміни ядра системи. Баланс ресурсних потоків перевіряється в редакторському інструменті ще до запуску — таблиця з поточним виробництвом та споживанням за типами оновлюється в custom Editor Window через EditorApplication.update.
Скільки коштує розробка системи інвентарю?
Вартість залежить від складності: мінімальна система — від $500, базова — від $2 000, середня з крафтом — від $5 000, повна з мережею — від $10 000. Ми надаємо гарантію на код 6 місяців. Досвід команди — 10+ років, 50+ виконаних проєктів. Сертифікація Unity.
Що входить в розробку системи інвентарю
- Архітектура:
ItemDefinition/ItemInstance,InventoryContainer,ResourceSystem - Реалізація операцій: додавання, видалення, переміщення, сортування, стекування
- Серіалізація та збереження: JSON, бінарний варіант, стиснення
- UI: кастомні слоти, drag & drop, фільтри, категорії (якщо потрібно — під геймпад або мобільне керування)
- Оптимізація: object pooling, адресація асетів, асинхронне завантаження
- Інтеграція з крафтом, торгівлею, екіпіровкою, мережевою синхронізацією
- Юніт-тести: покриття всіх операцій, включаючи граничні випадки
- Документація: опис архітектури, інструкція з конфігурації, керівництво для контент-мейкерів
- Деплой та підтримка: допомога при інтеграції у вже існуючий проєкт
Процес роботи
Етапи розробки: 1) аналіз вимог, 2) проектування ItemDefinition/ItemInstance, 3) реалізація контейнера, 4) тестування, 5) UI, 6) інтеграція з іншими системами. Проектування починається з таблиці всіх типів предметів та їх властивостей — до написання коду. Скільки унікальних предметів планується? Чи є генеровані? Чи потрібен крафт? Це визначає глибину архітектури. Прототип InventoryContainer без UI пишеться першим і покривається юніт-тестами в Unity Test Runner — додавання, видалення, переповнення, збереження/завантаження. UI підключається останнім.
Зв'яжіться з нами, щоб обговорити ваш проєкт. Отримайте оцінку архітектури та термінів за один робочий день.