Арт-директор просить повернути версію персонажа «як було три тижні тому, до того як художник переробив броню». Git зберігає тільки .unity та .prefab файли, а вихідники в Photoshop і Substance Painter лежать у спільній папці на NAS — без історії версій. Це не рідкісний сценарій. Ми стикалися з цим десятки разів у студіях різного розміру. Досвід показує: без вибудованого управління асетами з першого дня такі проблеми гарантовані. Давайте розберемо, як це виправити системно.
Чому Git не вирішує проблему асетів
Git працює з текстом. Бінарний FBX на 80 МБ або PSD на 200 МБ — це diff, який не читається, і дельта, яка не стискається. Репозиторій з арт-асетами без LFS розростається до кількох гігабайтів за декілька місяців і стає непридатним для клонування. У проекті з 5000+ асетами пошук потрібного файлу займає до 15 хвилин.
Git LFS вирішує проблему зберігання, але не версійності з точки зору художника. Трекінг *.psd *.fbx *.png через .gitattributes — це мінімум. Проблема: LFS не показує прев'ю ревізій без git lfs fetch, художники не звикли до git checkout для перегляду попередніх версій текстури.
Професійна альтернатива — Perforce Helix Core або Plastic SCM (тепер Unity DevOps Version Control). Plastic SCM інтегрований в Unity Editor нативно, вміє показувати візуальний diff для .unity і .prefab файлів, підтримує lock-файли для бінарних асетів (художник «захоплює» файл, виключаючи паралельні правки). Perforce, у свою чергу, забезпечує централізоване зберігання з продуктивністю, що перевершує Git LFS у задачах з тисячами асетів.
Як обрати VCS для графіки?
| Система | Версійність бінарних | Lock-файли | Інтеграція з Unity | Складність впровадження |
|---|---|---|---|---|
| Git + LFS | Часткова (тільки зберігання) | Немає | Середня | Низька |
| Plastic SCM | Повна + візуальний diff | Є | Нативна | Середня |
| Perforce Helix Core | Повна | Є | Через плагін | Висока |
Perforce в 5 разів швидше обробляє коміти з великими файлами порівняно з Git LFS. Для малих команд до 10 осіб Git LFS з дисципліною може бути достатнім. Але для проектів з 50+ художниками Perforce — стандарт індустрії, який використовують AAA-студії.
Як організувати бібліотеку асетів?
Хаотична структура папок в Assets/ вбиває час команди. Знайти потрібну текстуру в проекті з 3000+ файлами без нормальної ієрархії — це 10–15 хвилин пошуку. Правильна структура залежить від типу гри, але базовий принцип: за фічами, не за типами.
Погано:
Assets/Textures/characters/hero_diffuse.png Assets/Models/characters/hero.fbx Assets/Materials/hero_material.mat Добре:
Assets/Characters/Hero/Textures/hero_diffuse.png Assets/Characters/Hero/Models/hero.fbx Assets/Characters/Hero/Materials/hero_material.mat При видаленні фічі — видаляється одна папка цілком. При пошуку — все в одному місці.
Для текстурних атласів: чітка система іменування з суфіксами _D (diffuse/albedo), _N (normal), _M (metallic), _R (roughness), _AO (ambient occlusion) — критично для правильного імпорту в Unity. TextureImporter автоматично визначає тип за суфіксом при правильному налаштуванні.
Де зберігати вихідники асетів?
Вихідники (.psd, .spp Substance, .blend, .ma) не входять до Unity-проекту. Їх зберігання — окрема задача. Варіанти:
- Artefactory/Nexus як бінарне сховище з метаданими — підходить для великих студій. Кожен вихідник має версію, тег релізу, зв'язку із задачею в Jira.
-
Google Drive / SharePoint з строгими угодами про іменування —
hero_armor_v003.psd— працює для малих команд. Дешево, але потребує дисципліни. - Git LFS з окремим репозиторієм для вихідників — середній варіант. Розділення репозиторію двигуна і арт-репозиторію зменшує проблеми з продуктивністю.
Для будь-якого варіанту потрібен процес: художник завершив ітерацію → експортує фінальний асет у потрібному форматі (PNG/TGA для текстур, FBX для мешів) → поміщає в Unity-проект → фіксує версію вихідника з тегом. Розрив між вихідником і експортованим асетом — головна причина питання «а звідки взялася ця текстура?» через рік.
Що входить в аудит і впровадження?
- Аудит поточної бібліотеки: інвентаризація, пошук дублів (типова ситуація — 10–15% дублікатів), оцінка об'єму.
- Вибір та налаштування VCS (Plastic SCM/Perforce/Git LFS) з правилами структури.
- Міграція асетів до нової системи зі збереженням історії (де можливо).
- Налаштування CI-пайплайну для перевірки битих асетів та невикористовуваних файлів.
- Навчання команди: lock-файли, commit-повідомлення, робота з прев'ю.
- Документація з процесу управління асетами.
- Пост-релізна підтримка 1 місяць.
Як відбувається аудит?
Починаємо з інвентаризації: скільки асетів, який поточний об'єм, чи є дублі (одна і та ж текстура в трьох місцях з різними іменами — типова ситуація). Інструмент: Find References в Unity + кастомний Editor-скрипт для пошуку невикористовуваних асетів через AssetDatabase.FindAssets. Потім — міграція на обрану VCS, налаштування .gitattributes або Plastic SCM правил, навчання команди роботі з lock-файлами. Весь процес займає від 1 до 3 тижнів залежно від об'єму. Зв'яжіться з нами для аудиту — ми запропонуємо оптимальний план.
Скільки часу займає впровадження?
| Робота | Термін |
|---|---|
| Аудит та реструктуризація бібліотеки асетів | 3–7 днів |
| Налаштування Git LFS + правила + CI-інтеграція | 2–5 днів |
| Впровадження Plastic SCM / Unity DevOps | 1–2 тижні |
Вартість розраховується після аудиту поточного стану репозиторію та об'єму асетів. Отримайте консультацію — обговоримо деталі.