Розробка UX/UI для ігор
Ігровий UI — це не веб-дизайн та не мобільний додаток. HUD шутера обробляється боковим зором під час перестрілки. Меню інвентаря відкривається кілька секунд за сесію, але запам'ятовується надовго. Різні задачі, різні вимоги до проектування та реалізації.
Технічні грабли ігрового UI
Canvas з Overlay на мобільному — класичний джерело проблем. Unity перерисовує весь Canvas при зміні будь-якого дочірнього елемента: анімація лічильника монет перебудовує батч для всього HUD кожен кадр. Рішення — розділяти Canvas на статичні та динамічні частини, ставити Canvas компонент на часто оновлювані елементи окремо.
Масштабування під різні коефіцієнти сторін. Canvas Scaler у режимі Scale With Screen Size з Reference Resolution 1920×1080 та Match = 0.5 — стандарт, але не панацея. На iPad (4:3) або складних пристроях з нестандартним коефіцієнтом UI розв'язується. Якорі в RectTransform потрібно проставляти усвідомлено для кожного елемента, не спиратися на дефолтні значення.
TextMeshPro та Dynamic Font Atlas. Якщо в грі кілька мов з кирилицею, грецькою, арабською — одного атласа не вистачить. При рантаймовому додаванні символів Unity перепікає атлас, що дає фриз на 2-5 мс. Для критичних до продуктивності екранів використовуємо статичні атласи з явно заданим набором символів.
Як проектуємо ігровий UI
HUD: інформація без відволікання
Хороший HUD робить інформацію доступною, не вимагаючи від гравця фокуса на ньому. Працюємо за принципами ambient інформації: HP-бар змінює колір по мірі убування, пульсує при критичному рівні — гравець лічить загрозу боковим зором. Видаляємо числа там, де достатньо візуального стану.
Для кожного HUD-елемента визначаємо частоту оновлення: HP змінюється при кожному хіті, мініَ-карта — кожні 0.5 сек, таймер — кожну секунду. Update() з Time.deltaTime накопителем замість прямого оновлення кожен кадр — знижує навантаження на Canvas rebuild.
Екрани меню та навігація
Навігація через NavigationGraph у Unity UI — для геймпада та клавіатурної підтримки. Часто забувають про консолі та Steam Deck, де миш недоступна. Прописуємо explicit navigation для кожної кнопки в критичних екранах, не лишаємо на automatic.
Transition-анімації між екранами — через DOTween або LeanTween, не через Animator для простих випадків. Animator overhead для fade-in/fade-out нецілеспрямований. Для складних sequence-анімацій (onboarding, cutscene-інтерфейси) — Animator + AnimationEvent для синхронізації з геймплеєм.
Інвентар та drag-and-drop
Drag-and-drop у Unity UI реалізується через інтерфейси IBeginDragHandler, IDragHandler, IEndDragHandler. Головна проблема — поведінка при виході за межі ScrollRect. Якщо ScrollRect містить draggable елементи, потрібно явно керувати подіями через EventSystem.current та розділяти скроллінг та перетаскування по threshold'у смщення.
Віртуалізація довгих списків — через Pooling + ScrollRect. Відображати 500 ячейок інвентаря як 500 GameObject об'єктів неможливо — тільки видимі елементи, з переиспользованием через ObjectPool<T> (вбудований у Unity з 2021 LTS).
Процес роботи
UX-аудит або проектування з нуля (3-5 днів). Якщо UI вже є — аудит з конкретними знахідками: де користувач гублиться, що перевантажено, що не масштабується. З нуля — користувацькі сценарії, wireframes, інформаційна архітектура.
Дизайн у Figma (1-2 тижні). Компонентна бібліотека для Unity UI: кнопки, панелі, іконки — з варіантами станів (normal, hover, pressed, disabled). Розміри та відступи одразу в dp/Unity units, не в px.
Реалізація (1-3 тижні). Збірка в Unity, анімації, інтеграція з геймплеєм. Адаптація під дозволи та коефіцієнти сторін.
QA на пристроях. Обов'язково: iOS (безпечна зона notch), Android (різні щільності екрана), ПК (1280×720, 1920×1080, 2560×1440, ультраwide).
Терміни — від 1 тижня для простого HUD до 1+ місяця для повного UI-кіта зі всіма екранами. Вартість після аналізу обсягу та вимог до платформ.