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.

Почему 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 дня. Получите консультацию инженера по подготовке к релизу игр под ключ.