Підтримка бібліотеки ассетів та версіонності графіки ігор

Поддержка бібліотеки ассетів та версіонності графіки ігор

Арт-директор просить повернути версію персонажа «як було три тижні тому, до того як художник переробив броню». Git зберігає тільки .unity файли та .prefab, а исходники у Photoshop та Substance Painter лежать у загальній папці на NAS — без історії версій. Це не рідкий сценарій. Це норма для студій, які не виробили управління ассетами з самого початку.

Чому Git не вирішує проблему ассетів

Git працює з текстом. Бінарний FBX на 80 МБ або PSD на 200 МБ — це diff, який не читається, та дельта, яка не сжимається. Репозиторій з арт-ассетами без LFS розростається до кількох гігабайтів за кілька місяців та стає непридатним для клонування.

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-файли для бінарних ассетів (художник «захоплює» файл, виключаючи паралельні правки).

Структура бібліотеки ассетів

Хаотична структура папок у 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_2024-11-15.psd — працює для малих команд. Дешево, але потребує дисципліни.

Git LFS з окремим репозиторієм під исходники — середній варіант. Розділення репозиторія двигуна та арт-репозиторія зменшує проблеми з продуктивністю.

Для будь-якого варіанту потрібен процес: художник завершив ітерацію → експортує фінальний ассет у потрібному форматі (PNG/TGA для текстур, FBX для мешей) → розміщує у Unity-проект → фіксує версію исходника з тегом. Розрив між исходником та експортованим ассетом — головна причина питання «а звідки взялась ця текстура?» через рік.

Аудит та внедрення

Починаємо з інвентаризації: скільки ассетів, яка поточна обсяг, есть ли дубли (одна і та ж текстура в трьох місцях з різними іменами — типова ситуація). Інструмент: Find References у Unity + кастомний Editor-скрипт для пошуку невикористовуваних ассетів через AssetDatabase.FindAssets.

Потім — міграція на вибраний VCS, настройка .gitattributes або Plastic SCM правил, навчання команди роботі з lock-файлами.

Терміни

Вартість визначається після аудиту поточного стану репозиторія та обсягу ассетів.