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

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

Ви відкриваєте інвентар на мобільному пристрої, і FPS падає на 15%. Frame Debugger показує 214 draw calls для одного екрана. Знайома ситуація? Ми стикаємося з цим регулярно і виправляємо за тиждень. Unity UI (uGUI) — потужна система, але її продуктивність закладається на етапі архітектури Canvas, а не в кількості елементів. Ми маємо понад 5 років досвіду та 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-проходи та розриває batch ззовні та всередині. Для статичних елементів з обрізаними кутами простіше намалювати текстуру з потрібною формою, ніж ставити Mask.
3. Неправильний порядок Sibling Index. Якщо Image A і B перекриваються та з одного атласу, batch все одно може розірватися через z-порядок. Unity batches працюють лише якщо немає перекриттів між елементами з різних атласів.

Діагностика: Frame Debugger → Enable → шукаємо секцію UI. Оптимізований UI з одним атласом працює в 3 рази швидше, ніж з розрізненими текстурами. Хороша цифра для 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% часу рендерингу, що дозволяє заощадити до $2000 на місяць на хмарних ресурсах за рахунок зменшення навантаження на GPU. Гарантуємо аналогічний підхід для вашого 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 активних об'єктів замість сотень. Virtual Scroll зменшує споживання пам'яті в 5 разів порівняно зі звичайним ScrollView.

Як налаштувати 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 на предмет overdraw та брейків батчингу.

Вартість розраховується індивідуально після аналізу Figma-макетів та технічних вимог. Зв'яжіться з нами для попередньої оцінки. Отримайте консультацію з оптимізації вашого UI.

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

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