Малювання 2D-елементів UI графіки ігор
Іконки, кнопки, рамки, індикатори здоров'я, панелі інвентаря—все це UI-графіка. Її якість або занурює гравця в атмосферу, або заважає. Погано намальована іконка меча в RPG руйнує враження більше, ніж середня текстура на стіні, тому що на іконки гравець дивиться сотні разів за сесію.
Малювання UI-елементів для ігор відрізняється від веб-дизайну за кількома принципіальними параметрами: вимоги до форматів та роздільностей інші, робота строго в межах технічних обмежень рушія, і фінальний результат оцінюється не в браузері, а на різних екранах з різними dpi.
Технічні обмеження, які визначають стиль
Спрайт-атлас (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 текстури конвертуються залежно від платформи (ETC2 для Android, ASTC для iOS, DXT5 для PC). Альфа-канал—окремий PNG або через RGBA в одному файлі, залежить від налаштувань проекту. Прозорість через окремий маск-канал іноді дає кращу якість при стисненні.
Шари та overrides у Figma—стандарт підготовки UI-графіки. Кожен елемент—окремий компонент з варіантами станів (normal, hover, pressed, disabled). При підсумковому експорті всі варіанти автоматично нарізаються через Figma-плагіни типу Spriter Pro або ручний експорт через Assets → Export.
Що входить у малювання UI-елементів
Іконки—найтрудомісткіший тип. RPG-ігри часто мають 200–500+ іконок предметів. Стандартний конвеєр: style-guide на 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 базових силуетних форм (меч, щит, лук, зелля, броня, аксесуар, ресурс, квестовий предмет) та style-guide з правилами накладення кольору, бліків та тіней. Кожна іконка будувалась на основі силуету з варіацією деталей. Це знизило середній час малювання з 45 до 25 хвилин при збереженні стилістичної єдності.
Читаємість іконок на різних фонах
Іконку потрібно перевіряти не тільки на нейтральному сірому фоні в Figma. У грі вона з'являється на фоні інвентарної панелі, на фоні динамічної сцени через напівпрозорий HUD, на темних та світлих варіантах теми, якщо гра підтримує кілька колірних схем. Іконка, яка чудово читається на темному фоні, може повністю втратитись на світлому.
Стандартний прийом—обводка (outline) з контрастним кольором. Для темних іконок—світла обводка 1–2 пікселя. Для світлих—темна. Але outline у uGUI через стандартний Outline компонент генерує додаткові копії mesh та погано працює з TextMeshPro. Для іконок правильніше випекти outline прямо в текстуру або використовувати SDF-підхід через ShaderGraph: іконка рендерится як SDF текстура, обводка додається через шейдерний параметр без зміни mesh.
Інший прийом—Drop Shadow під іконкою. М'яка тінь діаметром 4–6 пікселів відділяє іконку від будь-якого фону. Це один з найнадійніших методів для UI з динамічним фоном (коли іконки HUD накладаються на ігрове оточення).
Взаємодія з програмістами та художниками
UI-графіка завжди робиться в тісному контакті з програмістом, який верстає інтерфейс. До початку малювання узгоджуємо: розміри атласів, правила найменування файлів (convention для Sprite Atlas автоматичної упаковки), потрібна підтримка кількох роздільностей (x1/x2/x3), формат передачі вихідників.
Зміни в розмірах або формах елементів після початку верстки—дорогостійні правки. Тому фінальний специфікаційний документ (розміри в пікселях, правила 9-slice, колірні коди) узгоджується до експорту, а не після.
| Обсяг роботи | Строки |
|---|---|
| 20–50 іконок (серійне малювання за стилем) | 1–2 тижні |
| Повний UI-кіт: кнопки, рамки, іконки (до 100 елементів) | 3–5 тижнів |
| 200–400 іконок предметів | 6–12 тижнів |
| Редизайн існуючого UI з новим стилем | 4–8 тижнів |
Вартість розраховується індивідуально залежно від кількості елементів, унікальності кожного та вимог до якості.