Верстка графічних елементів UI у рушії ігор
Дизайнерський макет у Figma — лише відправна точка. Коли гра запускається на iPhone SE з 4-дюймовим екраном, а потім на iPad Pro 12.9", один і той самий UI може або акуратно підлаштуватися, або роз'їхатися, налізти на системні кнопки чи обрізатися. Без правильної архітектури верстки адаптація під мультиплатформу перетворюється на нескінченне редагування префабів. Наша команда з досвідом понад 7 років та 30+ проєктами допомагає уникнути цих проблем. Ми гарантуємо якість верстки та адаптивність на всіх пристроях.
Системи верстки UI: uGUI проти UI Toolkit
В Unity два актуальних підходи: uGUI (Canvas + RectTransform) — перевірена роками система, та UI Toolkit (UXML + USS) — сучасний flexbox-підхід. UI Toolkit використовує єдиний Mesh Builder, що на складних екранах може бути до 2x швидшим, але поки не підтримує World Space Canvas та вбудовані анімації переходів.
| Характеристика |
uGUI |
UI Toolkit |
| Layout-модель |
RectTransform + Layout Groups |
Flexbox (USS) |
| Рендеринг |
Canvas batching |
Єдиний Mesh Builder |
| Підтримка World Space |
Так |
Ні |
| Тематизація |
Через зміну спрайтів |
Через перемикання USS-файлів |
| Крива навчання |
Низька |
Середня |
Згідно з офіційною документацією Unity, вибір між системами — архітектурне рішення, яке приймається на початку проєкту. Зміна системи в середині розробки фактично означає переверстку всього UI.
Як адаптувати UI до різних роздільностей у uGUI?
Якірна система RectTransform — основний інструмент адаптації. Елемент з якорями min(0,0) max(1,1) розтягується на весь батьківський контейнер. Canvas Scaler у режимі Scale With Screen Size масштабує весь Canvas як єдине ціле — зручно для статичних екранів, але для HUD біля країв потрібна Safe Area адаптація.
Для мобільних пристроїв критично правильне налаштування Safe Area через Screen.safeArea. Проміжний Panel-контейнер підганяє відступи, і всі HUD-елементи розміщуються всередині. Тестувати верстку слід на реальних пристроях або через Device Simulator — простий Game View не відтворює Safe Area коректно. Ми гарантуємо, що UI буде коректно відображатися на всіх поширених пристроях.
Чому Safe Area критична для мобільних UI?
Мобільний ринок — це зоопарк співвідношень сторін від 4:3 до 21:9. Без Safe Area елементи інтерфейсу можуть опинитися під системною панеллю або Dynamic Island. Реалізація через Screen.safeArea обов'язкова для всіх елементів HUD біля країв екрана. При Letterbox (Canvas Scaler Match = 0.5) на широких екранах з'являються смуги, але нічого не обрізається; при Crop (Match = 1.0 з Expand) екран заповнюється, але частина UI може вийти за межу — вибір залежить від дизайну.
Кейс з нашої практики: верстка магазину з динамічним контентом
Наш клієнт звернувся з екраном магазину, який мав непередбачувану кількість категорій (від 3 до 12) та товарів. Рішення: горизонтальна ScrollView з HorizontalLayoutGroup для вкладок, сітка товарів через GridLayoutGroup у вертикальній ScrollView. Prefab товару з ContentSizeFitter для адаптації тексту. Половина часу пішла на вирішення проблеми вкладених ContentSizeFitter — вони вимагають ручного виклику LayoutRebuilder. У підсумку верстка зайняла 4 дні, а завдяки оптимізації batching draw calls скоротилися на 40%.
Що входить у роботу
- Аналіз Figma-макетів та вимог до платформ
- Вибір оптимальної системи верстки (uGUI / UI Toolkit)
- Створення префабів та налаштування адаптивності
- Адаптація під Safe Area та multiple aspect ratios
- Інтеграція з геймплеєм та прив'язка даних
- Оптимізація продуктивності (draw calls, batching)
- Тестування на пристроях (мінімум 5 різних роздільностей)
Як ми верстаємо UI: покроковий процес
- Аналіз макетів — виявлення проблем верстки (плаваюча довжина тексту, різна кількість елементів).
- Вибір архітектури — визначення системи та підходу до адаптації.
- Створення префабів — гнучкі компоненти з правильними якорями та layout groups.
- Адаптація під роздільності — налаштування Safe Area, Letterbox/Crop, тестування на симуляторах.
- Інтеграція та тестування — прив'язка UI до геймплею, запуск на реальних пристроях.
| Тип задачі |
Терміни |
Орієнтовна вартість |
| 1 статичний екран (меню, налаштування) |
1–2 дні |
$200–$400 |
| 1 складний динамічний екран (інвентар, магазин) |
3–7 днів |
$500–$1000 |
| Повний UI-комплект (10–20 екранів) |
3–8 тижнів |
$3000–$8000 |
| Адаптація до Safe Area + мультиплатформа |
+3–7 днів до будь-якого обсягу |
+$500–$1000 |
Вартість розраховується індивідуально після аналізу Figma-макетів та вимог до платформ. Наша команда — 7+ років на ринку геймдеву, 30+ виконаних проєктів. Якщо вам потрібна якісна верстка 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, архітектурно наблизилася до веб-розробки. Вибір залежить від специфіки проекту:
| Критерій |
uGUI |
UI Toolkit |
| Продуктивність |
Ефективний батчинг, але потребує ручного розподілу Canvas |
Автоматичне дерево елементів, менше overhead на перебудову |
| Підтримка асетів |
Максимальна сумісність з Asset Store |
Обмежена, більшість асетів не адаптовано |
| Складність тем/скінів |
Через атласи та кастомні шейдери |
USS-стилі, легко перевизначити візуал |
| Навчання команди |
Низький поріг, багато документації |
Потрібен час на освоєння UXML/USS |
| Ідеальний сценарій |
Підтримка старого проекту, стислі строки |
Новий проект з кастомними інструментами |
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:
- Створіть кореневий Canvas з Render Mode = Screen Space Overlay
- Всередині створіть пусті об'єкти GameObjects, кожному призначте компонент Canvas
- Назвіть їх Static, Dynamic, Popup
- Перенесіть існуючі UI-елементи у відповідні групи
- Переконайтеся, що компонент 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 реалізованих проектів гарантують результат.