Налаштування тригерів запуску анімації в коді ігор

Настройка триггерів запуску анімації в коді ігор

Animator.SetTrigger — один з найбільш частих джерел трудноуловимих анімаційних багів. Той самий сценарій: персонаж атакує, ви викликаєте SetTrigger("Attack"), але анімація не воспроізводиться. Або воспроізводиться з кадровою затримкою. Або запускається двічі підряд. І все це тому, що trigger в Animator Controller має специфічну поведінку: якщо його некому «потребити» в поточному кадрі, він залишається в черзі і вистрілює в наступному стані — там, де ви його вже не чекаєте.

Це не баг Unity, це архітектурне рішення. Але воно потребує розуміння, інакше Animator State Machine превращається в джерело непередбачуваної поведінки.

Чому SetTrigger ломається в типових сценаріях

Trigger + Any State перехід. Якщо у вас є Any State → Attack з Trigger "Attack", і персонаж знаходиться в стані Stunned, який також має Any State → Stunned з більш високим пріоритетом — SetTrigger("Attack") буде потреблений переходом в Stunned, якщо обидва триггери виставлені в один кадр. Порядок пріоритетів переходів з Any State критичний та часто не документуватиметься в проекті.

ResetTrigger в неправильний момент. Якщо код викликає animator.ResetTrigger("Attack") в OnStateEnter атакуючого стану «для надійності» — ви гарантованого теряєте повторний запит на атаку, якщо гравець встив натиснути кнопку під час анімації. Правильне місце скидання — кінець анімації через StateMachineBehaviour.OnStateExit.

Animator не активний або culled. Якщо Animator.cullingMode = AlwaysAnimate вимкнено і об'єкт вийшов за межи Camera Frustum — Animator перестає оновлюватися. SetTrigger не теряється, але застосовується з затримкою при повернення в frustum. Для персонажів за краєм екрана, які повинні реагувати на гравця — це неочікувана поведінка.

Правильні паттерни запуску анімацій

Bool замість Trigger для довготривалих станів. Стрільба, біг, прицілювання — не Trigger, а Bool. SetBool("IsRunning", true/false) дає передбачувану поведінку та не теряється при зміні стану. Trigger використовуємо тільки для одноразових імпульсних подій: стрибок, удар, смерть.

Integer-параметри для комбо. Якщо у персонажа є ланцюжок атак, ComboIndex: int — надійніше набору триггерів Attack1/Attack2/Attack3. Перехід перевіряє ComboIndex == 1, ComboIndex == 2. Код інкрементує лічильник та скидає за timeout. Це усуває цілий клас проблем з «втраченими» триггерами.

Animation Events для синхронізації геймплею. Запуск хітбокса, звуку удару, спавну снаряда — через Animation Event, а не через coroutine з таймером. Animation Event гарантує привязку до конкретного кадру анімації незалежно від швидкості воспроізведення. Якщо ви множите animator.speed для slow-motion — подія все одно спрацює в правильний кадр.

Реальний кейс: файтинг, 6 персонажів, у кожного по 3–5 атак з різними хітбоксами. Першопочаткова реалізація через SetTrigger + coroutine-таймери для хітбоксів. Проблема: при зміні швидкості анімації (через animator.speed) хітбокс активувався в неправильний момент — раніше або пізніше удару. Перехід на Animation Events + StateMachineBehaviour для активації/дезактивації хітбоксів повністю усунув рассинхронізацію. Бонус: стало можливим легко настроювати timing хітбоксів через Animation Window без правки коду.

Animator vs Playables API

Для складних сценаріїв — кат-сцени, процедурні анімації, динамічний blend — Unity Playables API дає більше контролю, ніж Animator State Machine. AnimationMixerPlayable дозволяє мікшувати кілька анімацій з явними вагами в коді. AnimatorControllerPlayable дозволяє використовувати існуючий Animator Controller всередині Playables графа.

Це не означає, що потрібно переписувати все під Playables. Але для системи кат-сцен або кастомного IK-рішення — Playables API правильніше, ніж спроби ламати Animator State Machine.

Інструменти діагностики

Animator Window в Play Mode — базовий інструмент. Показує поточний стан, активні переходи, значення параметрів в реальному часі. Включаємо через Window → Animation → Animator.

Profiler → Animation module — показує, скільки CPU часу витрачає Animator на оновлення. Якщо Animation Evaluation > 3 мс з 10 персонажами — проблема в архітектурі: занадто складна State Machine, занадто багато Layers з full-body масками.

Frame Debugger — для перевірки, що анімація застосовується в правильний кадр рендера.

Процес настройки системи анімаційних триггерів

Аудит існуючої State Machine: кількість станів, переходів, параметрів, Layers. Документування логіки переходів (часто її нема — тільки в голові розробника). Виявлення проблемних місць через Play Mode тестування з включеним Animator Window.

Розробка специфікації: які параметри, які типи (Trigger/Bool/Int/Float), хто та коли їх встановлює, де скидає. Це запобігає конфліктам між різними системами (AI, Input, Network).

Вартість визначається після аналізу складності персонажів та вимог до анімаційної системи.