Верстка графических элементов 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, который инстанциирует нужное количество Prefab'ов из пула при открытии экрана.

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

Стоимость рассчитывается индивидуально после анализа Figma-макетов и требований к платформам.