Створення анімацій користувальницького інтерфейсу ігор
Анімація UI—це не прикраса. Це сигнальна система: відкриття екрана, підтвердження дії, отримання награди, попередження про помилку. Правильна анімація скорочує когнітивне навантаження—гравець розуміє, що сталося, без прочитання тексту. Неправильна анімація сердить: занадто повільна затримує геймплей, занадто різка пропускається непомітно.
Інструменти анімації UI в Unity: три підходи
Animator + Animation Clips—класика. Працює через Animator Controller на Canvas-об'єкті. Плюс: видимість у Unity Animator, підтримка Blend Trees, легко керувати через SetTrigger/SetBool. Мінус: важко керувати динамічно (якщо потрібно анімувати елемент в довільну позицію, відому тільки під час гри—Animator не допоможе прямо). Підходить для фіксованих переходів: відкриття/закриття екрана, pulse-ефект на кнопці, idle-анімація елемента.
DOTween—де-факто стандарт для code-driven UI анімацій у Unity. RectTransform.DOAnchorPos(), CanvasGroup.DOFade(), Image.DOColor()—все це через fluent API з можливістю sequencing. DOTween.Sequence() з .Append(), .Join(), .InsertCallback() дозволяє будувати складні скоординовані анімації з коду без візуального редактора. Важливий момент: DOTween працює в Update-циклі, що означає—при Time.timeScale = 0 (пауза гри) анімації UI зупиняються теж, якщо не використовувати SetUpdate(UpdateType.Normal, true) для ignoreTimeScale.
UI Toolkit Transitions—CSS-подібні transitions через USS: transition-property: translate; transition-duration: 300ms; transition-timing-function: ease-out;. Найбільш декларативний підхід, але з обмеженими можливостями порівняно з DOTween—тільки трансформації, непрозорість та колір. Добре працює для hover-ефектів та простих переходів станів.
Timing та easing: фізика анімації UI
Діапазони тривалості, які працюють:
- Мікро-зворотна связь (hover, press): 80–120 мс
- Появлення/скриття малого елемента (tooltip, badge): 150–200 мс
- Перехід екрана (відкриття інвентаря, меню): 250–350 мс
- Награди та fanfare-анімації: 600–1200 мс
Все, що більше 400 мс для утилітарних переходів—дратує при повторних відкриттях. Гравець відкриває інвентар сто разів за сесію. 600 мс перехід = хвилина потраченого часу тільки на очікування відкриття.
Easing функції не симетричні за призначенням. Ease Out (швидкий старт, повільний кінець)—для елементів, що з'являються: елемент вилітає швидко та м'яко приземлюється на місце, створюючи відчуття «приземлення». Ease In (повільний старт, швидкий кінець)—для елементів, що зникають: елемент повільно починається та швидко улітає. Ease In/Out—для переходів між станами, де немає чіткого «звідки» та «куди». Linear easing у UI майже ніколи не потрібен—виглядає механічно.
Overshoot та spring: коли фізика працює
Overshoot (анімація, яка трохи переходить за цільове значення та повертається) додає «ваги» та «характеру» елементу. DOTween надає Ease.OutBack та Ease.OutElastic. OutBack з strength 1.5–2.0 добре працює для pop-up сповіщень: елемент «випрригує» трохи за межі фінального розміру та повертається. OutElastic—для ігрових наград, лут-боксів, крітичних попаданнь, де потрібна енергійна реакція.
Важливе обмеження: overshoot анімації на великих екранних елементах (full-screen панелі) виглядають дивно. Це працює тільки для компактних елементів—іконок, кнопок, pop-up сповіщень.
Кейс: сповіщення про отримання предмета
На проекті потрібна була анімація всплюючого сповіщення при отриманні предмета: іконка + назва + опис. Анімація повинна була з'являтися без зупинки геймплею, утримуватися 2 секунди та зникати.
Реалізація через DOTween Sequence: іконка вилітає знизу з Ease.OutBack за 200 мс, одночасно (.Join()) фейд CanvasGroup.alpha з 0 до 1. Через 200 мс текст з'являється через DOFade за 150 мс (.AppendInterval(0.2f).Append(...)). Утримання—.AppendInterval(2f). Зникнення: зсув вправо + фейд за 200 мс з Ease.InCubic. Вся послідовність—15 рядків коду, переиспользується через NotificationController.Show(item).
Окремо вирішували проблему: при швидкому отриманні кількох предметів підряд нове сповіщення повинно було витіснити старе, а не накопичуватися в чергу. Рішення: при виклику Show() перевіряємо, є активний tween, убиваємо його через DOTween.Kill(targetTransform) та запускаємо нову анімацію.
Продуктивність UI-анімацій: де непомітно теряється FPS
Анімації в Canvas часто викликають Canvas Rebuild—перерахунок всієї UI-геометрії. Це відбувається кожен раз, коли змінюється щось у ієрархії Canvas: позиція, розмір, непрозорість. CanvasGroup.alpha не викликає Rebuild геометрії (тільки перерахунок непрозорості), а ось зміна RectTransform.position через DOTween—викликає.
Для анімацій переміщення це означає: анімувати через DOAnchorPos (зміна AnchoredPosition) безпечніше, ніж через DOMove (зміна World Position). AnchoredPosition працює в локальному просторі Canvas та викликає Rebuild тільки для змінного елемента та його батьків, World Position може потягнути за собою перерахунок всієї ієрархії.
Для scale-анімацій: transform.DOScale() на дочірньому об'єкті Canvas не викликає Canvas Rebuild взагалі—масштаб обробляється на рівні Transform, а не Layout системи. Це найдешевший тип UI-анімації. Саме тому pulse-ефект (легке збільшення/зменшення масштабу) такий популярний для call-to-action кнопок.
Розбивайте анімовані елементи на окремі Canvas'и. Якщо іконка в кутку екрана мигає для привернення уваги—вона повинна бути в своєму Canvas, щоб її Rebuild не перебудовував геометрію всього HUD кожен кадр.
Анімація станів кнопок: нюанси
Стандартна Button у uGUI з ColorTween анімує Highlight/Pressed/Disabled стани через Color. Це працює, але обмежено. Для кастомної поведінки краще використовувати DOTween-based UIAnimation компонент або переопредилити IPointerEnterHandler, IPointerExitHandler, IPointerDownHandler.
Scale-анімація на кнопці при нажатті (Press: scale 0.95, Release: scale 1.0)—один з найпростіших та ефективних тактильних відгуків. 80 мс з Ease.OutQuad. Для мобільних платформ це особливо важливо, тому що тактильної вібрації під пальцем немає, а візуальний зворотний зв'язок критичний.
| Тип роботи | Строки |
|---|---|
| Анімації одного екрана (5–10 переходів) | 2–5 днів |
| Повна анімація UI-комплекту (10–15 екранів) | 2–5 тижнів |
| Складні fanfare-анімації (наград, рівнів) | 1–2 тижні |
| Анімаційна система з керуванням з коду | 1–3 тижні |
Вартість визначається індивідуально після аналізу вимог до анімацій.