Верстка графічних елементів UI в рушії ігор

Верстка графічних елементів UI в рушіях ігор

Отримати від дизайнера красивий Figma-макет—половина роботи. Перетворити його на роботючий UI в рушієві так, щоб він коректно виглядав на 1280×720, 1920×1080, 2560×1440 та 375×812 (iPhone SE та iPhone 14 Pro)—задача інженерна, не художницька. Саме тут теряється більша частина часу при розробці інтерфейсів.

Системи верстки UI: uGUI проти UI Toolkit

У Unity два актуальних підходи до верстки. uGUI (Canvas + RectTransform)—бойова система, перевірена на тисячах проектів, з багатою екосистемою ассетів та відомими подвохами. UI Toolkit (UXML + USS)—більш нова система, натхненна веб-стандартами, з flexbox-подібним layout engine.

UI Toolkit принципово відрізняється від uGUI за архітектурою рендеринга: використовує єдиний Mesh Builder, який генерує геометрію всього UI в один проход, без поняття Canvas batch. У теорії це повинно бути швидше на складних екранах. На практиці—UI Toolkit поки не підтримує ряд можливостей uGUI (наприклад, World Space Canvas для 3D-інтерфейсів) та має обмежену підтримку анімацій (немає вбудованого аналога Animator для UI-переходів).

Вибір системи—архітектурне рішення, прийняте на початку проекту. Зміна з uGUI на UI Toolkit в середині розробки—це фактично переверстка всього інтерфейсу.

Адаптація до різних роздільностей у uGUI

Якірна система RectTransform вирішує більшість задач адаптації при правильному використанні. Елемент з якорями min(0, 0) max(1, 1) займає весь простір батьківського контейнера незалежно від роздільності. Елемент з якорями min(0.5, 0) max(0.5, 0) завжди знаходиться горизонтально по центру у нижнього краю.

Якорі у вигляді розтягнутого прямокутника (anchors min != max) замінюють поняття width/height на поняття offsets: Left, Right, Top, Bottom визначають відступи від якірних точок. Потужний механізм, але потребує розуміння: при розтягнутому якорі поле Width в Inspector показує відступи, а не розмір—плутанина гарантована у тих, хто працює з цим вперше.

Canvas Scaler у режимі Scale With Screen Size масштабує весь Canvas як єдине ціле. Це добре для фіксованих екранів (головне меню, магазин), але проблематично для HUD з елементами у краях екрана—на широких форматах (21:9, 32:9) елементи у краях уходять за межі Safe Area. Для таких випадків використовуємо Safe Area адаптацію через Screen.safeArea: створюємо проміжний Panel з RectTransform, який підгоняється під Safe Area при старті та при зміні орієнтації.

Flexbox у UI Toolkit: що це змінює

USS (Unity Style Sheets) підтримує flex-direction, flex-wrap, align-items, justify-content—ті ж властивості, що й у CSS Flexbox. Для горизонтальних та вертикальних списків значно зручніше, ніж VerticalLayoutGroup + ContentSizeFitter у uGUI. Layout автоматично адаптується під вміст без необхідності викликати LayoutRebuilder.ForceRebuildLayoutImmediate().

Для верстки UI Toolkit використовуємо UI Builder (Window → UI Toolkit → UI Builder)—WYSIWYG-редактор, що генерує UXML та USS файли. Важливий момент: UXML—це опис структури, USS—стилі. Розділення аналогічне HTML/CSS, але в ігровому контексті це означає, що темізацію (зміна візуального стилю без зміни структури) можна реалізувати через переключення USS файлів.

Верстка для кількох співвідношень сторін

Мобільний ринок—зоопарк співвідношень сторін. iPhone SE: 4:3 при 320×568. Сучасні Android-флагмани: 20:9 або 21:9. Складні телефони з 4:3 в складеному стані. Гра повинна коректно виглядати на всьому цьому.

Safe Area—обов'язкова обгортка для всіх елементів HUD у краях екрана. На iPhone з Dynamic Island та на старих Android з фізичними кнопками інтерфейс не повинен залізти в системні області. Реалізується через проміжний Panel-контейнер, який при старті підгоняє свої RectTransform offsets під Screen.safeArea прямокутник. Всі HUD-елементи розміщуються всередину цього контейнера—не зовні.

Letterbox vs Crop—два підходи до невідповідності співвідношення сторін. При Letterbox (Canvas Scaler Match = 0.5) на широких екранах з'являються бічні смуги, натомість нічого не обрізується. При Crop (Match = 1.0 з Expand) екран заповнений, але частина UI уходить за межу. Для ігор з горизонтальною прокруткою або важливими елементами у бічних краях—Letterbox безпечніше. Для атмосферних ігор з full-screen фоном—Crop зазвичай виглядає краще.

Тестувати верстку слід на реальних пристроях або через Device Simulator (Window → General → Device Simulator) з кількома попередньо встановленими профілями пристроїв. Aspect Ratio у звичайному Game View не відтворює Safe Area коректно—це поширена причина появи багів з UI саме у продакшні, а не в редакторі.

Pixel Perfect: коли пікселі важливі

Для пікс-ель-арт ігор та проектів з чіткими графічними елементами Canvas Pixel Perfect режим критично важливий. Він вирівнює UI-елементи за фізичними пікселями екрана, усуває субпіксельне розмиття. Але з ним виникає проблема: при масштабуванні Canvas (наприклад, при роздільності 2×) дрібні елементи або схлопуються (0 пікселів), або стрибають на 1 піксель при анімації.

Для пікс-ель-арт UI в uGUI правильний підхід—Reference Resolution точно збігається з нативною роздільністю гри (наприклад, 320×180 для pixel-perfect 1080p через integer scale 6×), а всі елементи вирівняні на цілі пікселі в Figma.

Кейс: верстка магазину з динамічним контентом

Завдання: екран магазину з непередбачуваною кількістю категорій (від 3 до 12) та вкладок з різною кількістю товарів. Дизайнер передав макет на 5 категорій та 8 товарів. Потрібно верстати під будь-яку кількість.

Рішення: горизонтальна ScrollView для вкладок категорій з HorizontalLayoutGroup та ContentSizeFitter—вкладки автоматично розширюються під кількість категорій. Сітка товарів через GridLayoutGroup у вертикальній ScrollView. Prefab для товара з гнучким розміром через ContentSizeFitter (текст описання може бути різної довжини). Все керується через один ShopController, який інстанціює потрібну кількість Prefabs з пулу при відкритті екрана.

Верстка зайняла 4 дні замість розрахункових 2—половину часу ушло на вирівнювання ContentSizeFitter з вкладеними Layout Groups (відома особливість: вкладені ContentSizeFitter потребують ручного виклику LayoutRebuilder у правильному порядку).

Вартість розраховується індивідуально після аналізу Figma-макетів та вимог до платформ.