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

Кейс: редизайн інвентарю з 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 прямо зараз.

Як ми проектуємо 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) — зріла система, працює з RectTransform, багата екосистема асетів. Практично весь існуючий ігровий UI написаний на uGUI.

UI Toolkit — система на основі XML (UXML) та CSS-подібних стилів (USS). Спочатку створювалася для редакторних інструментів, після того, як отримала офіційну підтримку рантайм UI, архітектурно наблизилася до веб-розробки. Вибір залежить від специфіки проекту:

UI Toolkit підходить для наступних сценаріїв:

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

uGUI залишається кращим, якщо:

• Йде підтримка існуючого проекту
• Потрібна максимальна сумісність з асетами Asset Store
• Команда вже знає uGUI, строки стислі

Як добитися продуктивного 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 дні. Ось що ми перевіримо:

• Аналіз draw calls та батчинг (Frame Debugger)
• Перебудова Canvas (Profiler, пошук зайвих rebatch)
• Робота Raycaster (видалення зайвих)
• Адаптивність (Safe Area, Anchor Presets)
• Локалізація (тест на наддовгі рядки)
• Якість шрифтів (атласи TMP, помилки оверлапів)

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