Арт-директор просит вернуть версию персонажа «как было три недели назад, до того как художник переделал броню». 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 недели |
Стоимость рассчитывается после аудита текущего состояния репозитория и объёма ассетов. Получите консультацию — обсудим детали.