Консультування з питань візуальної оптимізації графіки ігор

Frame time 28ms на Samsung Galaxy A53 при цільових 16.6ms. Unity Profiler показує Camera.Render, що займає 18ms з них. Розробник дивиться у Frame Debugger — 340 draw calls, половина з яких це UI Canvas у режимі Screen Space - Overlay з Rebuild кожен кадр. Ми вирішуємо такі проблеми за день, але без точної діагностики ітерації розтягуються на тижні. Наш досвід — понад вісім років у геймдеві, більше 50 проєктів, де ми домагалися стабільних 60 FPS на середньому залізі.

Консультування з візуальної оптимізації — це діагностика вузьких місць та план конкретних дій, а не «використовуйте менше полігонів». Ми передаємо команді не лише звіт, а й розуміння, як самостійно знаходити та усувати проблеми в майбутньому. Гарантуємо скорочення часу на баг-фікс у 2–3 рази після нашої консультації.

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

CPU side. UnityEngine.Rendering.RenderPipeline.Render у Profiler — перша точка входу. Якщо там > 10ms на мобілці при простій сцені — дивимося далі. Canvas.SendWillRenderCanvases — флаг проблемного UI. ShadowCaster.Render — тіней занадто багато або занадто великий shadow distance. Animator.Update з великою кількістю активних аніматорів у сцені — кожен активний Animator тратить CPU незалежно від видимості.

GPU side. Snapdragon Profiler для Android, Xcode GPU Frame Capture для iOS — точніше Unity Profiler для GPU-аналізу. Fillrate overdraw видно через Unity Scene View у режимі Overdraw — червоні зони це багаторазова перемальовка. Типова проблема: партикл-системи з Additive blending малюють по 15–20 шарів поверх фону — кожен шар повний fillrate pass.

Memory. Memory Profiler package — не вбудований Profiler. Снапшот купи показує конкретні текстури, що займають VRAM. Нестиснена 4K текстура = 64 МБ VRAM, без міпмапів ще гірше — при віддаленні об'єкта GPU все одно читає повне розширення.

Чому Dynamic Batching підводить на мобільних?

Dynamic batching автоматично батчить меші з однаковим матеріалом якщо вони <= 900 вершин і 300 трикутників. Але якщо в об'єктів різні MaterialPropertyBlock значення (наприклад, колір через скрипт) — батчинг ламається. GPU Instancing у 3 рази ефективніший на мобільних GPU, оскільки знижує кількість draw calls за рахунок одного виклику рендерингу для множини об'єктів. Перехід на GPU Instancing — одна з найефективніших змін.

Які типові проблеми ми знаходимо?

• Canvas Rebuild кожен кадр. Canvas.willRenderCanvases спрацьовує при будь-якій зміні дочірнього елемента — зсув, колір, текст. Якщо в HUD оновлюється таймер кожну секунду, весь Canvas перераховується. Рішення: поділ Canvas на статичні та динамічні частини. Анімовані елементи на окремий Canvas.
• Shadow Distance. На мобільних платформах Shadow Distance = 150 (дефолт) малює каскадні тіні для всього що в 150 юнітах від камери. Реальна потреба — зазвичай 20–40 юнітів. Різниця в shadow render time — 3–4x.
• MipMap Streaming не налаштований. Без QualitySettings.streamingMipmapsActive = true всі текстури завантажуються в повній роздільній здатності при старті сцени. Для мобілок з 3–4 ГБ RAM це критично — сцена з 200 текстурами може зайняти 600 МБ VRAM при старті.

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

1. Аудит. Запускаємо проєкт на цільовому пристрої з прикріпленим Profiler, знімаємо кілька характерних сцен. Аналізуємо frame breakdown, draw calls, fillrate, memory snapshot. Результат — список вузьких місць з оцінкою потенційного приросту.
2. План дій. Пріоритезуємо за співвідношенням «складність виправлення / приріст продуктивності». Прості перемоги (shadow distance, canvas split, texture compression) — спочатку. Архітектурні зміни (перехід на GPU Instancing, реорганізація LOD) — з оцінкою трудозатрат.
3. Підтримка реалізації. Ми реалізуємо зміни самі або консультуємо команду при самостійному виправленні. Для другого варіанту: письмовий технічний гайд з конкретними налаштуваннями та очікуваними результатами.

Що входить у консультацію з візуальної оптимізації?

• Документація: звіт з графіками, скріншотами Profiler та Frame Debugger, рекомендації за пріоритетами.
• Код оптимізацій: готові шейдери, скрипти для налаштування Instancing, конфіги для Addressables.
• Доступ: тимчасовий доступ до нашого демо-стенду з еталонними рішеннями.
• Навчання: 2-годинна сесія з розбором типових помилок та відповідями на питання команди.
• Підтримка: консультації по виниклих складностях протягом місяця після завершення основного етапу.

Ми використовуємо комбінований підхід: спочатку CPU-профілювання для пошуку логічних вузьких місць, потім GPU-деталізація через RenderDoc і Snapdragon Profiler. Це дозволяє знайти як очевидні, так і приховані проблеми — наприклад, неправильне налаштування LOD або неефективне використання шейдерів.

Інструменти, які використовуємо

Терміни та економія

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