Керування бібліотекою асетів та версійність графіки в іграх

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

Як забезпечити стабільність збірок?

Використання CI/CD з автоматичним тестуванням та контролем версій знижує ризик людських помилок та гарантує відтворюваність збірок.

Чому 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.

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

Ручний реліз мобільної гри коштує значних коштів (зарплата інженера на 2–3 дні, тестування, переробки). Автоматизація CI/CD окупається в перші два місяці — знижує витрати на реліз на 40–60%. Тобто кожен наступний реліз обходиться значно дешевше.

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

Як автоматизація впливає на якість релізу?

Автоматизація усуває людський фактор, забезпечує послідовність збірок та дозволяє швидше виправляти помилки.

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

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

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

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

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