2D UI-графика для игр: иконки, кнопки, HUD и атласы

В RPG плохо нарисованная иконка меча разрушает погружение — игрок смотрит на неё сотни раз за сессию. Некачественный UI убивает иммерсию. Поэтому отрисовка 2D-элементов для игр — инженерная задача: вписаться в технические ограничения движка, форматы, разрешения и сохранить читаемость на любых экранах.

Наша команда имеет 8+ лет опыта в игровой UI-графике, выполнила более 50 проектов для мобильных, PC и консолей. Атласная упаковка сокращает draw calls в 10 раз по сравнению с отдельными текстурами — каждый атлас = один batch.

Почему важно планировать атласы до отрисовки?

Спрайт-атлас (Sprite Atlas) — базовый инструмент упаковки UI-графики в Unity. Все иконки и элементы интерфейса упаковываются в один или несколько атласов, чтобы минимизировать количество draw calls при отрисовке Canvas. Один атлас = один batch. Если иконки разбросаны по отдельным текстурам — каждая иконка на экране = отдельный draw call.

Из этого следует ограничение на размер и количество атласов: обычно 2048×2048 пикселей максимум для мобильных, 4096×4096 для PC. Всё UI одного экрана — в один атлас. Это значит, что дизайнер должен заранее знать: все иконки инвентаря помещаются в 2048×2048? При 64×64 пикселей на иконку — 1024 иконки. При 128×128 — 256. Планирование атласов начинается на этапе технического задания, а не после финальной отрисовки.

Форматы экспорта: PNG без сжатия для исходников, внутри Unity текстуры конвертируются в зависимости от платформы. Согласно документации Unity, для Android используем ETC2, для iOS — ASTC, для ПК — DXT5. Альфа-канал — отдельный PNG или через RGBA в одном файле, зависит от настроек проекта. Прозрачность через отдельный маск-канал иногда даёт лучшее качество при сжатии.

Слои и overrides в Figma — стандарт подготовки UI-графики. Каждый элемент — отдельный компонент с вариантами состояний (normal, hover, pressed, disabled). При итоговом экспорте все варианты нарезаются автоматически через Figma-плагины типа Spriter Pro или ручной экспорт через Assets → Export.

Как добиться читаемости иконок на любом фоне?

Иконку нужно проверять не только на нейтральном сером фоне в Figma. В игре она появляется на фоне инвентарной панели, на фоне динамичной сцены через полупрозрачный HUD, на тёмных и светлых вариантах темы если игра поддерживает несколько цветовых схем. Иконка, которая отлично читается на тёмном фоне, может полностью потеряться на светлом.

Стандартный приём — обводка (outline) с контрастным цветом. Для тёмных иконок — светлая обводка 1–2 пикселя. Для светлых — тёмная. Но outline в uGUI через стандартный Outline компонент генерирует дополнительные копии mesh и плохо работает с TextMeshPro. Для иконок правильнее выпекать outline прямо в текстуру или использовать SDF-подход через ShaderGraph: иконка рендерится как SDF текстура, обводка добавляется через шейдерный параметр без изменения mesh.

Другой приём — Drop Shadow под иконкой. Мягкая тень диаметром 4–6 пикселей отделяет иконку от любого фона. Это один из самых надёжных методов для UI с динамическим фоном (когда иконки HUD накладываются на игровое окружение).

Отрисовка в Figma vs игровой экран — разница может достигать 30% потери контраста из-за пост-эффектов движка. Наш опыт показывает, что лучший способ — тестировать на целевой платформе с реальными настройками камеры.

Что входит в отрисовку UI-элементов?

Иконки — самый трудоёмкий тип. RPG-игры часто имеют 200–500+ иконок предметов. Стандартный пайплайн: стиль-гайд на 10–20 референсных иконок → утверждение → серийная отрисовка по шаблону. Каждая иконка при серийном производстве занимает 30–60 минут, уникальная «showcase»-иконка — 2–4 часа.

Рамки и панели — декоративные обрамления для окон, диалогов, инвентаря. Критически важна поддержка 9-slice (NineSlicedSprite в Unity): рамка должна корректно масштабироваться без растяжения угловых декоративных элементов. При отрисовке углы и края рамки должны занимать ровно столько пикселей, сколько нужно для правила 9-slice — это документируется в передаточных материалах.

HUD-элементы — health bar, mana bar, таймеры, маркеры. Здесь важна читаемость при анимации: заполняющийся health bar должен быть виден даже при быстром движении. Тестируем на реальном разрешении целевой платформы, не на Figma-превью.

Кнопки и элементы навигации — все состояния (normal/hover/pressed/disabled/focused для геймпада). Focused-состояние часто забывают при отрисовке под мобилку и вспоминают только при портировании на console.

Кейс: редизайн инвентаря с 300 иконками

Из нашей практики: на одном проекте мы выполнили редизайн системы предметов для action-RPG — смена визуального стиля с реалистичного на стилизованный. 312 иконок, дедлайн 6 недель. Решение через шаблонизацию: разработали 8 базовых силуэтных форм (меч, щит, лук, зелье, броня, аксессуар, ресурс, квестовый предмет) и стиль-гайд с правилами наложения цвета, бликов и теней. Каждая иконка строилась на базе силуэта с вариацией деталей. Это снизило среднее время отрисовки с 45 до 25 минут при сохранении стилистического единства.

Взаимодействие с программистами и художниками

UI-графика всегда делается в тесном контакте с программистом, который верстает интерфейс. До начала отрисовки согласовываем: размеры атласов, правила именования файлов (convention для Sprite Atlas автоматической упаковки), нужна ли поддержка нескольких разрешений (x1/x2/x3), формат передачи исходников.

Изменения в размерах или формах элементов после начала вёрстки — дорогостоящие правки. Поэтому финальный спецификационный документ (размеры в пикселях, правила 9-slice, цветовые коды) согласовывается до экспорта, а не после.

Этапы работы над UI-графикой

1. Анализ требований — определяем платформы, стиль, количество элементов.
2. Создание стиль-гайда — 10–20 референсных иконок.
3. Отрисовка элементов по согласованному пайплайну.
4. Проверка в движке — тест читаемости, 9-slice, анимаций.
5. Упаковка в атласы и передача программисту.

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

Прототипирование и 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 реализованных проектов гарантируют результат.