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

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

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 недель в зависимости от объёма. Свяжитесь с нами для аудита — мы предложим оптимальный план.

Сколько времени занимает внедрение?

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

Когда ручная подготовка к релизу игр превращается в проблему?

Студия делает релиз мобильной игры. За неделю до даты менеджер вспоминает, что нужно собрать AAB, подписать, загрузить в Google Play. Сборщик вручную запускает билд, ждёт час, забывает включить IL2CPP, билд крашится на Android 12. Пересборка — ещё час. Параллельно надо переделать иконку под новые требования Google. В итоге релиз сдвигается на три дня. Наш опыт показывает: ручная подготовка к релизу игр — главный источник задержек и багов, которые не проявляются на машине разработчика.

Как настроить CI/CD для сборок мобильных игр?

Инструменты пайплайна

GameCI — open-source Docker-образы для Unity-сборок, работающие поверх GitHub Actions, GitLab CI или любого другого CI-провайдера. Ключевые компоненты: unity-builder (собирает под нужную платформу), unity-test-runner (запускает Unity Test Framework перед сборкой), unity-return-license (возвращает лицензию — критично для Pro). Unity Cloud Build проще, но менее гибок и дорог при частых сборках. Fastlane — стандарт для финальных шагов: подпись, загрузка в магазины, метаданные.

Типовой пайплайн

jobs:
  test:
    name: Run Unity Tests
    uses: game-ci/unity-test-runner@v4
    with:
      unityVersion: 2022.3.20f1
      testMode: playmode

  build-android:
    name: Build Android
    needs: test
    uses: game-ci/unity-builder@v4
    with:
      targetPlatform: Android
      androidKeystoreBase64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
      androidKeystorePass: ${{ secrets.KEYSTORE_PASSWORD }}
      androidKeyaliasPass: ${{ secrets.KEY_PASSWORD }}

  upload-to-play:
    name: Upload to Google Play (Internal Track)
    needs: build-android
    uses: r0adkll/upload-google-play@v1
    with:
      serviceAccountJsonPlainText: ${{ secrets.SERVICE_ACCOUNT_JSON }}
      packageName: com.yourcompany.yourgame
      releaseFiles: build/Android/*.aab
      track: internal

Секреты, не переменные — все ключи в secrets CI. AAB вместо APK обязателен уже несколько лет. Треки: internal → closed → open → production. Продвижение — ручное или Fastlane supply promote.

iOS-специфика. Unity собирает Xcode-проект, затем xcodebuild. Нужны Distribution Certificate и Provisioning Profile (App Store). Fastlane Match решает проблему синхронизации сертификатов в команде:

lane :build_ios do
  match(type: "appstore", readonly: true)
  build_app(workspace: "Unity-iPhone.xcworkspace",
            scheme: "Unity-iPhone",
            export_method: "app-store")
  upload_to_testflight
end

App Store Connect API Key заменяет логин/пароль, не ломается при 2FA.

Почему App Store отклоняет около трети первых сабмишенов?

Apple отклоняет 30–40% первых сабмишенов новых студий. Частые причины:

Практика: перед сабмишеном пройти App Store Review Guidelines от начала до конца — 2–3 часа, экономящие 2–3 недели.

Google Play более лоялен: типичные причины — устаревший targetSdkVersion, избыточные разрешения, несоответствие Data Safety Form.

Что включает подготовка к релизу игр?

Автоматизация пайплайна заменяет ручную работу целого отдела. Например, настройка Continuous Integration через GameCI и Fastlane сокращает время подготовки к релизу игр втрое — с 8 рабочих часов до 2,5.

Как автоматизация пайплайна влияет на сроки и бюджет?

Ручной релиз мобильной игры стоит примерно $1200–$1500 (зарплата инженера на 2–3 дня, тестирование, переделки). Автоматизация CI/CD окупается в первые два месяца — снижает затраты на релиз на 40–60%. То есть каждый следующий релиз обходится на $500–$900 дешевле.

Сравнение подходов:

Результат: мы сокращаем цикл от коммита до публикации в 6–8 раз. Для проектов с частыми хотфиксами это разница между недельным ожиданием пользователей и исправлением за день.

После релиза: мониторинг и обновления

Краш-рейт < 1% (Firebase Crashlytics), ANR-рейт < 0.47% (Play Console) — иначе ограничения видимости. Phased rollout обязателен: сначала 10%, затем 50%, затем 100% пользователей.

Наш опыт — 30+ релизов мобильных игр, 5+ лет на рынке, более 50 проектов. Автоматизация CI/CD окупается в первые два месяца, снижая затраты на релиз на 40–60%.

Оставьте заявку — мы проанализируем ваш пайплайн и предложим решение за 2 дня. Получите консультацию инженера по подготовке к релизу игр под ключ.