Верстка интерфейсов игр в Unity UI (uGUI)

Верстка интерфейсов игр в Unity UI (uGUI)

Вы открываете инвентарь на мобильном устройстве, и FPS падает на 15%. Frame Debugger показывает 214 draw calls для одного экрана. Знакомая ситуация? Мы сталкиваемся с этим регулярно и исправляем за неделю. Unity UI (uGUI) — мощная система, но её производительность закладывается на этапе архитектуры Canvas, а не в количестве элементов. За 5 лет работы мы оптимизировали UI более чем в 50 проектах — от инди до AAA. Расскажем, как избежать типовых ошибок.

Unity UI Optimization Guide помогает понять базовые принципы: Canvas собирает UI-элементы в batch, если одинаковый материал и одна текстура из Sprite Atlas.

Почему uGUI может тормозить?

Canvas собирает UI-элементы в batch — группу с одним draw call. Условие батчинга: одинаковый материал, одна текстура (Sprite Atlas), без перекрытий с чужеродными элементами. Разрушают батчинг три вещи:

1. Смешение текстур. Иконка из Атласа A, кнопка из Атласа B, текст через TextMeshPro — каждое переключение текстуры даёт новый draw call. Решение: все визуальные элементы одного экрана в один Sprite Atlas. TextMeshPro-тексты — отдельный batch, но хотя бы один.
2. Вложенные Mask. Каждый Mask добавляет 2 stencil-прохода и разрывает батч снаружи и внутри. Для статичных элементов с обрезанными углами проще нарисовать текстуру с нужной формой, чем ставить Mask.
3. Неправильный порядок Sibling Index. Если Image A и B перекрываются и из одного атласа, батч всё равно может разорваться из-за z-порядка. Unity batches работают только если нет перекрытий между элементами из разных атласов.

Диагностика: Frame Debugger → Enable → ищем секцию UI. Хорошая цифра для HUD — 5–15 draw calls. Больше 50 — повод для оптимизации.

Как мы уменьшаем draw calls: кейс из нашей практики

Пришёл проект с жалобой на 15% просадку FPS при открытии инвентаря. Frame Debugger показал 214 draw calls для 48 слотов. Каждый слот — отдельный Prefab с иконкой из PNG (не атлас), TextMeshPro-количеством, фоновой рамкой из другого PNG и Outline-компонентом (генерирует дополнительную mesh).

Решение: упаковали все иконки в два Sprite Atlas (предметы и UI-хром раздельно), заменили TextMeshPro Outline на SDF Outline в материале TMP, добавили Virtual Scroll List (pool-based) для сетки предметов. Итог: 22 draw calls на том же экране. FPS вернулся к норме. Выгода: экономия до 40% времени рендеринга. Гарантируем аналогичный подход для вашего UI.

Что входит в нашу работу по верстке UI

• Аудит текущего UI: Frame Debugger, Profiler, анализ архитектуры Canvas.
• Оптимизация атласов: нарезка, объединение, настройка Fallback Fonts.
• Верстка RectTransform с привязкой якорей для адаптации под разрешения.
• Настройка Canvas Scaler под целевые платформы.
• Реализация виртуального скролла для динамических списков (ScrollView с pool).
• Интеграция анимаций (DoTween, Animator) без потери производительности.
• Документация по UI-архитектуре и стилю кода.
• Обучение команды работе с батчингом и профилированием.

RectTransform: правила, которые спасают от боли

Якоря (Anchors) и Pivot — не одно и то же. Якорь определяет точку привязки к родителю, Pivot — точку вращения и масштабирования элемента. Типичная ошибка: якоря выставлены в левый верхний угол, а элемент должен быть по центру. При смене разрешения элемент уезжает. Правильно: якорь → center/middle, anchored position = (0, 0).

Для адаптации используем Canvas Scaler с Scale With Screen Size. Reference Resolution 1920×1080 и Match = 0.5 — рабочая база. Для мобильных с Match = 0.8–1.0 (в пользу Height) UI не расплывается на узких экранах.

ContentSizeFitter + VerticalLayoutGroup — удобно для динамических списков, но каждое изменение вызывает Layout Rebuild. Для ScrollView с сотнями элементов применяем Virtual Scroll List: держим в памяти только видимые — до 10–15 активных объектов вместо сотен.

Как настроить Canvas Scaler для мобильных устройств?

Для мобильных с разными соотношениями сторон Match лучше поднять до 0.8–1.0 в пользу Height. Иначе на iPhone с 19.5:9 UI расплывается по горизонтали. Мы также настраиваем Reference Resolution под целевое разрешение — обычно 750×1334 (iPhone 6/7/8) с режимом Scale With Screen Size. Подробности — на официальной документации Canvas Scaler.

TextMeshPro: шрифты и производительность

TextMeshPro — стандарт для текста. Использует SDF рендеринг, что даёт чёткость на любом масштабе. Для локализации кириллицы или CJK настройте Fallback Font Asset: основной шрифт для латиницы с прописанным Fallback на нужный язык. TextMeshPro автоматически подгружает недостающие глифы, и текст остаётся в 1-2 draw calls.

Atlas Population Mode: Dynamic добавляет глифы по мере встречи — хорошо для dev, плохо для релиза (микрофризы при первом рендере). Для продакшна используем Static с предварительно заполненным атласом через Font Asset Creator.

Процесс верстки

Начинаем с получения Figma-макетов с размерами, отступами и правилами адаптации. Определяем структуру Canvas и атласов. Верстаем базовый layout на RectTransform, подключаем шрифты и текстуры. Настраиваем EventSystem и навигацию для геймпада/клавиатуры. Тестируем на нескольких разрешениях через Game View. Профилируем Frame Debugger.

Стоимость рассчитывается индивидуально после анализа Figma-макетов и технических требований. Свяжитесь с нами для предварительной оценки. Получите консультацию по оптимизации вашего UI.

Опыт показал: правильная архитектура Canvas и атласов окупается на этапе оптимизации. Мы гарантируем результат — снижение draw calls до 5–15 на HUD без потери визуального качества.

Прототипирование и UX/UI для игр: архитектура, производительность, локализация

Открываете чужой Unity-проект — и видите: один Canvas на всю игру, сотня вложенных панелей, Layout Groups внутри Layout Groups, профайлер показывает 4 ms только на пересчёт UI в каждом кадре. Это не редкость. За 10+ лет работы мы разобрали сотни UI-систем — почти все страдали от отсутствия архитектуры с самого начала. В результате к середине разработки UI становится узким местом: каждый новый экран добавляет баги, производительность падает, правки занимают часы. Мы проектируем и реализуем игровой UI: от вайрфреймов до готовых компонентов в движке, с прицелом на производительность и поддерживаемость. Наш подход к прототипированию игрового интерфейса позволяет выявить 80% UX-проблем до написания кода. Свяжитесь с нами для консультации — оценим ваш проект.

Прототипирование и проектирование

Любой UI начинается с понимания информационных потоков: что игрок должен видеть в каждый момент, какие действия доступны, как переходить между экранами. Без этого разработка превращается в серию итераций «сделали — не то — переделали». Инструмент для прототипирования — Figma. Причина выбора не в моде, а в конкретных возможностях:

• Компонентная система с вариантами — позволяет проверить кнопку в состояниях Normal/Hover/Pressed/Disabled
• Auto Layout — честная симуляция поведения UI при разных размерах текста (критично для мультиязычных игр)
• Прототипы с переходами — тестируйте навигационный флоу до первой строки кода

На этапе прототипа выявляется большинство UX-проблем: неочевидные переходы, перегруженные экраны, неверная иерархия информации. Исправить это в Figma — 15 минут. Исправить в готовом проекте — полдня. Мы гарантируем, что каждый прототип сопровождается техническим заданием для разработчиков — это исключает двусмысленность при передаче в движок.

uGUI против UI Toolkit: что выбрать для нового проекта

В Unity сейчас два фреймворка для UI, и выбор между ними не очевиден. uGUI (Canvas-based) — зрелая система, существует с ранних версий Unity. Работает с RectTransform, богатая экосистема ассетов. Практически весь существующий игровой UI написан на uGUI.

UI Toolkit — система на основе XML (UXML) и CSS-подобных стилей (USS). Изначально создавалась для редакторных инструментов, с версии 2021 официально поддерживается для рантайм UI. Архитектурно ближе к веб-разработке.

UI Toolkit подходит для следующих сценариев:

• Новый проект, команда готова к обучению
• Нужна сложная система тем и скинов
• Активно разрабатываются кастомные редакторные инструменты

uGUI остаётся предпочтительным, если:

• Идёт поддержка существующего проекта
• Нужна максимальная совместимость с ассетами Asset Store
• Команда уже знает uGUI, сроки сжатые

Wikipedia: Unity (game engine) – UI подтверждает, что оба подхода активно используются в индустрии.

Как добиться производительного UI в Unity?

Это та область, где игровой UI кардинально отличается от UI в обычных приложениях. В игре UI обновляется каждый кадр, и неэффективная реализация может съедать 3–5 ms из бюджета кадра — напрямую влияя на FPS.

Как работает батчинг в Canvas

Unity объединяет элементы одного Canvas в единый draw call, если они используют одинаковый материал и текстурный атлас. Нарушение батча означает дополнительный draw call, что бьёт по производительности.

Батчинг ломают следующие факторы:

• Разные текстуры у соседних элементов (решение: спрайтовый атлас через Sprite Atlas)
• Mask компонент создаёт стенсил и разрывает батч (альтернатива: RectMask2D — работает дешевле)
• Canvas с разными Render Mode — батчинг работает только внутри одного Canvas
• Любой Graphic Raycaster добавляет overhead — ставьте его только на интерактивные Canvas

Разделение Canvas по типам контента

Главная рекомендация: разделяйте статичный и динамичный контент. Когда хоть один элемент в Canvas изменяется, Unity перестраивает геометрию всего Canvas. Если на одном Canvas живут статичная рамка HUD и анимированная шкала здоровья — каждую секунду Canvas перестраивается полностью. Это может снижать FPS на 15-20%.

Правильная структура:

Canvas (Screen Space - Overlay)
├── Canvas_Static     — фоны, рамки, иконки без анимации
├── Canvas_Dynamic    — HP-бары, таймеры, счётчик ресурсов
└── Canvas_Popup      — модальные окна, уведомления

Каждый дочерний Canvas изолирует ребилд от родительского. Изменение в Canvas_Dynamic не трогает Canvas_Static.

Пошаговая настройка раздельного Canvas:

1. Создайте корневой Canvas с Render Mode = Screen Space Overlay
2. Внутри создайте пустые объекты GameObjects, каждому назначьте компонент Canvas
3. Назовите их Static, Dynamic, Popup
4. Перенесите существующие UI-элементы в соответствующие группы
5. Убедитесь, что компонент Canvas Scaler настроен только на корневом Canvas (дочерние наследуют настройки)

Результат: сокращение времени перерисовки UI до 60% в сценах с динамическими HUD.

TextMeshPro и текстовые батчи

TextMeshPro — стандарт для текста в Unity. В отличие от старого Text, использует SDF-рендеринг: текст остаётся чётким при любом масштабе. Но у TMP есть нюанс: каждый уникальный шрифтовый атлас — отдельный материал, то есть отдельный draw call. Если в игре используется три варианта шрифта (основной, заголовочный, цифровой) плюс версии для каждого языка — батчинг текста разваливается. Решение: TMP Font Asset Creator с объединением глифов нужных языков в один атлас. Для кириллицы + латиницы + цифр обычно хватает одного атласа 2048×2048 — это сокращает draw calls на тексте до 1-2.

Как адаптировать UI под разные экраны?

Мобильные платформы добавляют задачу, которой нет на PC: UI должен корректно работать на 16:9, 18:9, 19.5:9, 4:3 и iPad-соотношениях одновременно. Ошибка в адаптации — одна из частых причин переделок, съедающих до 30% бюджета.

Инструменты:

• Canvas Scaler с режимом Scale With Screen Size — базовая настройка. Reference Resolution 1080×1920 для мобильных, Match параметр 0.5 (баланс между шириной и высотой)
• Anchor Presets — каждый элемент должен быть привязан к правильному краю или центру
• Safe Area — на устройствах с вырезом и скруглёнными углами кнопки не должны попадать в недоступную зону. Решение: Screen.safeArea в коде, корректирует RectTransform корневого элемента

Проверка делается не только в редакторе Game View — нужно физическое тестирование на устройствах или Device Simulator (встроен в Unity). Закажите аудит текущего UI — мы выявим узкие места за 2-3 дня.

Локализация UI

Это не отдельная задача, а требование к архитектуре с первого дня. Типичная проблема: UI спроектирован под русский текст, который занимает N символов. Немецкий перевод в полтора раза длиннее. Кнопки ломаются, текст вылезает за границы. На этапе проектирования мы выполняем:

• Все текстовые поля с Auto Size в TMP или явно заданными минимальным/максимальным размером
• Кнопки с Horizontal Layout Group + Content Size Fitter вместо фиксированной ширины
• Иконки и декоративные элементы не вставляем в строку с текстом через конкатенацию

Для реализации локализации используем Unity Localization Package (официальный) или I2 Localization (ассет, более гибкий для сложных случаев). Экономия времени на переделку при таком подходе — до 40%.

Что входит в услугу

• Проектирование навигационной структуры и флоу экранов
• Прототипирование игрового интерфейса в Figma с передачей макетов в разработку
• Реализация UI-компонентов в Unity (uGUI или UI Toolkit)
• Аудит существующего UI по производительности: анализ draw calls, Canvas rebatch, лишних Raycaster
• Настройка системы локализации и проверка на длинных переводах
• Адаптация под мобильные соотношения сторон и Safe Area

Сроки: от 5 рабочих дней на аудит до 4 недель на полный цикл. Стоимость рассчитывается индивидуально — пишите, получите коммерческое предложение. 10+ лет в геймдеве, более 200 реализованных проектов гарантируют результат.