Архівування вихідників графіки та проектних файлів ігор

Чому архівація вихідників — це інвестиція, а не витрата

Ми регулярно стикаємося з ситуацією: студія закрила проект, а через пару років потрібно випустити DLC або портувати на нову платформу. Відкривають NAS — і бачать хаос: папка art_final_FINAL_v2, 12 000 файлів без дат, Substance Painter свариться на зниклі linked textures, Photoshop-файл важить 2 ГБ, половина шарів без імен. Відновити роботу можна, але це займає тижні замість годин. Наш досвід показує: правильно організована архівація на старті окупається як мінімум вдвічі швидше. Ми зберігаємо не лише файли, а й контекст: версії софту, налаштування, залежності. Це перетворює архів на робочий зліпок проекту, а не звалище бінарників. Ми стикалися з проектами, де арт-директор звільнявся і ніхто не знав, як збирати сцену.

«Хороший архів дозволяє відкрити проект через 5 років без жодного дзвінка колишньому співробітнику» — принцип інженерної збереженості.

Що загрожує за відсутності архівації

• Втрата зв'язків між вихідниками та фінальними ассетами. Наприклад, текстура в грі виглядає інакше, ніж у .spp — згадати, який матеріал використовувався, неможливо.
• Час на пошук файлів зростає до 30% від загального часу роботи. За нашими вимірами, структурований архів економить до 40% часу при поверненні до проекту.
• Критичні файли можуть не відкритися в нових версіях софту. Особливо це стосується бінарних форматів на зразок .mb.

Яку інформацію обов'язково зберігати

Substance Painter (.spp)

Найпроблемніший формат. Файл посилається на Smart Materials з бібліотеки Substance. Якщо бібліотека оновилася — зовнішній вигляд зміниться. Ми архівуємо: .spp + експортовані Baked Textures + .sbsar всіх використаних матеріалів. Це гарантує відтворюваність через будь-які оновлення.

Photoshop (.psd)

Смарт-об'єкти можуть посилатися на зовнішні .psb. Функції Package немає, тому ми вручну збираємо linked шари в одну папку або flatten. Обов'язково перевіряємо шрифти — прикладаємо OTF/TTF.

Blender (.blend)

Достатньо включити File > External Data > Pack Resources — вся картинка пакується всередину .blend. Просто, але файл стає важчим. Для довгострокового зберігання це виправдано.

Maya (.ma/.mb)

Використовуємо File > Optimize Scene Size, потім File > Archive Scene — створюється zip з усіма залежностями. Надаємо перевагу .ma (ASCII) — його можна відкрити текстовим редактором навіть без Maya.

Яку структуру архіву обрати?

Поганий архів: art/, всередині 5000 файлів в одній купі. Робочий архів від наших інженерів:

project_name/
  characters/
    hero/
      sources/          # .psd, .spp, .blend
      exports/          # .fbx, .png, .tga — те, що йшло в движок
      references/       # референси, концепти
      VERSIONS.md       # історія змін: дата, автор, що зроблено
  environments/
  ui/
  vfx/
  README.md             # версія движка, інструментів, контакти

VERSIONS.md на кожен ассет — звучить надмірно, але саме він дає відповідь «чому текстуру переробляли три рази».

Які формати обрати для довгострокового зберігання?

FBX — фактичний стандарт, але він пропрієтарний. Як доповнення використовуємо glTF 2.0 — відкритий формат, який підтримується Blender, Unity, Unreal. glTF 2.0 легший за FBX в 1.5-2 рази і краще підходить для обміну даними між пайплайнами.

Як перевірити цілісність архіву перед упаковкою?

Перед упаковкою виконуємо три кроки:

1. Перевірка broken references у Substance: File > Check Baked Maps Links.
2. Чистка невикористовуваних шарів у PSD.
3. Експорт усіх текстур з .spp.

Кастомний Python-скрипт обходить дерево папок, збирає CSV з розміром, датою, розширенням. Це знаходить дублі (одна текстура в трьох копіях), застарілі версії (_old, _backup) та файли-кандидати на оптимізацію. За статистикою наших проектів, до 20% файлів виявляються сміттям. За нашими підрахунками, правильна архівація економить до $5000 на кожному проекті середнього масштабу.

Кроки архівації

1. Інвентаризація — збір всіх вихідників, виявлення пропущених ланок.
2. Структурування — організація файлів за шаблоном: project_name/characters/hero/sources/ тощо.
3. Пакування — упаковка залежностей і конвертація в довгострокові формати (FBX/glTF, PNG, .ma).
4. Верифікація — перевірка цілісності посилань, читання файлів у свіжих версіях софту.
5. Звіт — створення CSV-інвентаризації та README.

Що входить у роботу з архівації (deliverables)

• Структурований архів за описаною схемою.
• CSV-інвентаризація з дублями та рекомендаціями.
• README з версіями інструментів та контактами.
• Запасний комплект на зовнішньому носії — гарантія від втрати.
• Консультація з вибору форматів та налаштувань проекту. Ми враховуємо особливості рендерингу, шейдерів та нормал мап, щоб архів був повноцінним.

Терміни та як ми працюємо

Вартість розраховується після первинного аудиту обсягу — це безкоштовно. Наша команда має 10+ років досвіду в геймдеві та більше 50 завершених проектів з архівації. Оцінимо ваш проект, надішлемо план і терміни. Зв'яжіться з нами, щоб не втратити роки роботи. Замовте консультацію з архівації — ми підкажемо, з чого почати.

Поширені питання про архівування графіки

На основі нашого досвіду ми зібрали відповіді на часті запитання — вони допоможуть уникнути типових помилок.

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

Студія робить реліз мобільної гри. За тиждень до дати менеджер згадує, що потрібно зібрати 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 дні. Отримайте консультацію інженера з підготовки до релізу ігор під ключ.