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

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

Арт-директор просит вернуть версию персонажа «как было три недели назад, до того как художник переделал броню». 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-файлами.

Сроки

Стоимость определяется после аудита текущего состояния репозитория и объёма ассетов.