Програмування логіки відображення UI в іграх

Уявіть: гравець натискає кнопку в меню, а інтерфейс зависає на секунду — затримка через невдало написану прив'язку даних. Або при перетягуванні предмета в інвентарі ghost-іконка не слідує за курсором, тому що RectTransformUtility неправильно спроектував координати. Такі баги не впадають в очі на ранніх етапах, але на етапі збору зворотного зв'язку від тестувальників перетворюються на головний біль. Логіка відображення UI — це не просто візуал, а зв'язка патернів, подій та асинхронних операцій, яка займає до 30% часу розробки всього інтерфейсу. За 5 років ми реалізували UI-логіку для 40+ проєктів — від мобільних казуалок до PC-екшенів, і накопичили набір перевірених рішень, які скорочують час розробки на 20-40% та знижують GC Alloc на 60-80%. Оцініть бюджет вашого UI за 30 хвилин консультації — зв'яжіться з нами.

Програмування логіки відображення графіки інтерфейсу

Головний архітектурний вибір — як UI дізнається про зміни в стані гри. Три основні підходи:

Observer / Event System — UI підписується на події ігрової системи: HealthSystem.OnHealthChanged += UpdateHealthBar. Слабкий зв'язок, можна легко переключати UI-реалізації. Проблема: при знищенні об'єкта до відписки — NullReferenceException. Обов'язково відписуватися в OnDisable() або OnDestroy(). Це реалізація Observer pattern.

MVP (Model-View-Presenter) — Presenter відповідає за зв'язок між даними (Model) і відображенням (View). View не знає про ігрову логіку, тільки про свої візуальні компоненти. Presenter знає обидві сторони. Добре масштабується, добре тестується. Типова реалізація в Unity — абстрактний клас BaseView з методами Show(), Hide(), Bind(IModel model), і конкретні Presenter'и під кожен екран.

ScriptableObject-based подійна система — всі події як ScriptableObject з методом Raise() і списком слухачів. Популяризовано Ryan Hipple на Unite кілька років тому. Зручно для невеликих команд, легко дебажити в Inspector. Мінус: при великій кількості подій стає складно керувати залежностями.

Для більшості проєктів рекомендую MVP з EventSystem для крос-модульної комунікації. Це дає читабельний код, передбачувану поведінку та хорошу тестованість UI без запуску сцени.

Як керувати станами екранів?

Screen Manager — типова система, яка контролює, який екран відкрито, і керує переходами. Мінімальна реалізація: стек екранів (для Back navigation), словник screenId → IScreen, методи Push(), Pop(), Replace().

Для мобільних платформ Android Back Button повинен коректно оброблятися через Application.exitCancellationToken або через Input.GetKeyDown(KeyCode.Escape) — при натисканні повинен закриватися верхній екран у стеку, а не виходити з гри. Це те, що часто забувають при розробці та помічають при здачі в Google Play.

CanvasGroup — інструмент для керування видимістю та інтерактивністю групи елементів (див. документацію Unity). canvasGroup.alpha = 0 приховує візуально, але елементи продовжують отримувати події. Обов'язково також виставляти canvasGroup.interactable = false та canvasGroup.blocksRaycasts = false при приховуванні — інакше невидимі кнопки перехоплюють кліки крізь них.

Кейс з нашої практики: інвентар з drag & drop — програмування логіки відображення

Задача: drag & drop перетягування предметів між слотами інвентаря з підтримкою геймпада. На мишці — IBeginDragHandler, IDragHandler, IEndDragHandler. На геймпаді — зовсім інша логіка: курсорний режим навігації з вибором джерела та цілі через кнопки.

Реалізація drag & drop в uGUI вимагає створення ghost-об'єкта — копії перетягуваної іконки, яка слідує за курсором через RectTransformUtility.ScreenPointToLocalPointInRectangle(). Ghost повинен знаходитися в окремому Canvas поверх усього іншого (окремий Canvas з Sort Order вище основного) — інакше іконка буде перекриватися іншими елементами при перетягуванні.

Для геймпада реалізували окремий режим: перше натискання A вибирає слот (підсвічується selected state), навігація D-pad переміщує віртуальний курсор між слотами, друге натискання A завершує перетягування. Два режими керування — два різні кінцеві автомати в одному InventoryController.

Як async/await спрощує UI-логіку і в чому підводний камінь?

Сучасна Unity-розробка все активніше використовує async/await замість корутин. Для UI-логіки це особливо зручно при роботі з мережевими запитами, завантаженням даних, очікуванням анімації перед переходом екрана.

Головна пастка async в Unity: операції продовжуються навіть після знищення об'єкта. await Task.Delay(2000) в методі кнопки — і через 2 секунди код продовжує виконуватися, звертаючись до вже знищених компонентів. NullReferenceException гарантовано. Рішення: перевірка this == null після кожного await (Unity перевизначає оператор == для UnityEngine.Object), або використання CancellationToken, який скасовується в OnDestroy.

Другий нюанс: async-метод, кинутий без await (fire-and-forget), не обробляє виключення. LoadUserData() без await — виключення всередині методу просто проковтується, користувач бачить порожній екран, логів немає. Для fire-and-forget методів обов'язково додаємо глобальний обробник через TaskScheduler.UnobservedTaskException або обгортаємо виклик в try-catch всередині самого методу.

UniTask (Cysharp/UniTask) — суттєво кращий варіант, ніж стандартний Task для Unity. Працює без heap allocation для більшості операцій, інтегрується з PlayerLoop Unity, підтримує UniTask.Delay з прив'язкою до PlayerLoopTiming (Update, FixedUpdate, LateUpdate) та коректно обробляє cancellation при знищенні об'єкта через destroyCancellationToken. На проєктах з активним використанням async це знижує GC Alloc на 60–80% порівняно з System.Threading.Tasks — тобто в 2–3 рази ефективніше.

Як покроково реалізувати Screen Manager для навігації

1. Визначте інтерфейс IScreen з методами Show() та Hide().
2. Створіть ScreenManager як синглтон або сервіс в DI.
3. Зберігайте стек екранів для підтримки Back.
4. Реалізуйте методи Push() (відкрити новий екран, приховавши поточний) та Pop() (закрити поточний, повернути попередній).
5. Для мобільних пристроїв підпишіться на кнопку Back та викликайте Pop().
6. Додайте Replace для випадків, коли не потрібно повертатися до попереднього екрана.

Порівняння підходів до зв'язку UI та логіки

Логіка відображення даних: типові проблеми

Оновлення UI кожен кадр — антипатерн. healthBar.fillAmount = player.health / player.maxHealth в Update() працює, але перестворює mesh для Image компонента кожен кадр навіть якщо значення не змінилося. Правильно: оновлювати тільки при зміні даних через event або property з setter.

Рядкова конкатенація в Update — гірше. levelText.text = "Level: " + player.level створює новий рядок кожен виклик, провокуючи GC Allocations. Використовуємо string.Format() або StringBuilder для часто оновлюваних текстів. У TextMeshPro є SetText(string, float) — перевантаження з float-аргументом, яке форматує число без GC allocation.

Z-fighting кнопок: два Button'и з однаковим Sort Order в одному Canvas, один поверх іншого. EventSystem надсилає подію на верхній за ієрархією, але якщо Raycast Target увімкнено в обох — кліки можуть провалюватися. Перевіряємо через UI Debugger (правий клік в EventSystem → UI Debug).

Відображення Loading State: при очікуванні відповіді від сервера UI повинен блокувати повторні натискання. Типова помилка — просто показати Spinner і забути вимкнути кнопку. Правильно: блокуємо CanvasGroup.interactable = false для всього екрана + показуємо Loading Overlay + в finally блоці async-методу відновлюємо interactable = true. Інакше при повільному з'єднанні користувач встигає натиснути кнопку кілька разів.

Що входить в роботу

• Архітектурне рішення патерну зв'язку UI з ігровою логікою
• Реалізація Screen Manager та навігації
• Логіка кожного екрана з юніт-тестами Presenter'ів
• Інтеграція з ігровими системами (події, дані)
• Налаштування CanvasGroup, обробка введення (миша, геймпад)
• Вирішення проблем з async/await та корутинами
• Тестування на цільових пристроях та профілювання

Процес та терміни

Розробка починається з архітектурного рішення: вибір патерну зв'язку з ігровою логікою, визначення Screen Manager архітектури, узгодження інтерфейсів між UI та ігровими системами. Потім — реалізація базової інфраструктури (Screen Manager, Base View, Event Bus). Далі — поекранна реалізація з юніт-тестами для Presenter'ів. Фінал — інтеграційне тестування на пристроях.

Ми гарантуємо, що 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, архітектурно наблизилася до веб-розробки. Вибір залежить від специфіки проекту:

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