Tech Art Bible для Unity: стандарти графіки та автоматизація пайплайну

Вступ

Ми часто стикаємося з ситуацією, коли новий художник приходить в команду і запитує: «У вас полігональний бюджет на персонажа — скільки?» Тімлід відповідає: «Ну, приблизно від 5 до 15 тисяч, залежить від важливості». Це не стандарт. Це усна домовленість, яку кожен розуміє по-своєму, і яка ламається при кожному новому співробітнику або підряднику. Без чітко задокументованих стандартів команда витрачає до 30% часу на переробку ассетів. Наш досвід показує: після впровадження Tech Art Bible кількість переробок знижується в 3 рази в порівнянні з усними домовленостями. Економія бюджету на арт-продакшн досягає 30%. За понад 5 років роботи ми створили Tech Art Bible для десятків проектів — від мобільних ігор до AAA-консолей. Документ фіксує числа, формати та процедури, виключаючи різночитання. Автоматизовані перевірки в пайплайні працюють в 5 разів швидше ручного рев'ю та скорочують кількість артефактів на 40%. Отримайте консультацію з впровадження стандартів у ваш пайплайн.

Чому «очевидні» стандарти потрібно документувати?

Розрив між тим, що вважається «само собою зрозумілим» всередині команди, і тим, що реально роблять художники — величезний. Приклади реальних розбіжностей:

• Текстурні роздільності: один художник робить 2K під фонові об'єкти, інший — 4K. У VRAM це одразу видно — профілювання показує Texture Memory 800 МБ замість планових 400. А в документі написано тільки «використовуй розумні роздільності».
• Іменування: hero_body_d.png, Hero_Body_Albedo.png, character_1_diffuse_final.png — три текстури одного типу від трьох художників в одному проекті. AssetDatabase.FindAssets по паттерну не працює, автоматичний імпорт по суфіксу не працює, CI-перевірки на naming convention не працюють.
• Pivot points в FBX: один Blender-художник експортує з півотом в геометричному центрі, інший — в Origin світу. Розробник отримує об'єкт, який при transform.Rotate() обертається навколо несподіваної точки.

Що входить в Tech Art Bible

Полігональні бюджети

Таблиця за категоріями об'єктів з розбивкою по платформам:

Текстурні стандарти

Роздільності за категоріями, формати (PNG для вихідників, TGA для normal maps при імпорті в Unity — не PNG, BC7 як цільовий формат компресії для PC, ASTC для Android/iOS), обов'язкові канали (Albedo, Normal, Metallic/Roughness, AO — окремо або упаковані).

Система іменування

Конвенція з прикладами. Для текстур — {object}_{part}_{type}_{resolution}.ext, наприклад hero_body_albedo_2k.png. Для мешів — {category}_{name}_{LOD}.fbx. Документуємо не тільки правило, але й чому воно таке — це знижує опір при впровадженні.

UV-стандарти

Tile розмір, допустиме UV-overlapping для lightmap UV (тільки LOD0, UV channel 2), вимоги по seam placement (не на видних кромках, не на суглобах).

Процедури експорту з кожного інструменту

Blender FBX export settings (Apply Transform, Forward axis, Units), Substance Painter export template для Unity (саме з якими каналами в які слоти), Maya export checklist. Дотримання процедур скорочує кількість помилок при імпорті в 3 рази в порівнянні з ad-hoc налаштуваннями.

Як розробляється Tech Art Bible для вашого проекту?

Починаємо з аудиту існуючих ассетів: що вже використовується в проекті, які де-факто застосовувані значення. Документ повинен відображати реальність + покращення, а не ідеальний стандарт з нуля — інакше команда його проігнорує.

Інтерв'ю з художниками: які питання задають найчастіше, де виникають конфлікти при рев'ю ассетів, що доводиться переробляти. Це найкраще джерело для визначення пріоритетів в документі.

Формат: Confluence або Notion — інтерактивні, підтримують вкладені таблиці та скріншоти. Не PDF — PDF ніхто не читає через півроку. Структура: зміст з якірними посиланнями, «Quick Reference» на першій сторінці (найчастіше потрібні дані), повні розділи нижче.

Версіонування документа — дата останнього оновлення та changelog. Стандарт без версії втрачає довіру: «а це актуально для нашої поточної платформи?»

Як автоматизувати дотримання стандартів?

Документ не працює без автоматичних перевірок. Unity Editor-скрипти для валідації:

• Перевірка імпортованих текстур на відповідність naming convention через AssetPostprocessor.OnPreprocessTexture()
• Перевірка max resolution при імпорті: якщо текстура > 4096 для категорії background — Warning в консолі
• Mesh validator через AssetPostprocessor.OnPostprocessModel(): перевірка polycount по імені категорії з імені файлу

Це не заміна документу, але зворотний зв'язок при порушенні стандартів в реальному часі — до code review. Замовте інтеграцію валідаторів у ваш проект — гарантуємо зниження часу на рев'ю ассетів. Докладніше про підходи до автоматизації читайте в документації AssetPostprocessor.

Строки впровадження

Вартість розраховується після аудиту поточних практик команди та цільових платформ проекту. Зв'яжіться з нами для безкоштовної попередньої консультації та отримайте комерційну пропозицію протягом дня. Ми гарантуємо скорочення переробок на 30% та прискорення онбордингу нових художників.

Чому обирають наші стандарти?

Понад 5 років на ринку геймдев-документації. Ми допомогли десяткам студій уніфікувати пайплайни — від інді до AAA. Наші клієнти відзначають зниження часу code review на 40% та підвищення якості ассетів на першому чекпойнті. Замовте аудит поточних практик — отримайте план впровадження Tech Art Bible вже завтра.

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

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