Створення циклів ходьби та бігу персонажів ігор

Створення циклів ходьби та бігу персонажів ігор

Ми часто стикаємося з ситуацією, коли walk cycle — перша анімація, яку бачить гравець — стає джерелом проблем за тиждень до релізу. Переробляти доводиться тому, що цикл зроблений як завершений ролик, а не як ігровий ассет, який працюватиме в Blend Tree, накладатиметься через Avatar Mask і переходитиме зі стану Idle в стан Run через Animator Controller. Наш досвід показує, що правильне налаштування Root Motion та Blend Tree скорочує час ітерацій на 40%. Гарантуємо: кожен цикл проходить перевірку на коректну інтерполяцію.

На одному з проектів ми зіткнулися з тим, що персонаж ковзав по підлозі, хоча NavMeshAgent рухався з нормальною швидкістю. Причина виявилася в неправильному налаштуванні Root Motion: аніматор «вшив» переміщення в Hip-кістку, а не в Root. Після переналаштування та налаштування Blend Tree час налаштування анімації скоротився з 8 годин до 2 годин, а персонаж почав рухатися плавно. Root Motion скорочує час налаштування анімації в 4 рази порівняно з ручним переміщенням.

Чому цикл не збігається з рухом капсули

Класична проблема: персонаж візуально ковзає по підлозі, хоча NavMeshAgent або CharacterController рухається з нормальною швидкістю. Root Motion не підключений, або підключений неправильно.

В Unity Root Motion читається з кореневої кістки анімації — тієї, що позначена як Root в Avatar. Якщо аніматор «вшив» переміщення в Hip-кістку напряму, а не в Root, Root Motion дасть нуль. Персонаж буде тупцювати на місці, поки контролер тягне його куди треба.

Правильна схема: Root-кістка рухається вперед строго по осі Z на відстань одного кроку за півциклу. В кінці циклу Root повертається у вихідну точку — інакше анімація не зациклюється без телепортації. В Blender це налаштовується через NLA Editor: ключові кадри Root-кістки на початок і кінець циклу мають бути ідентичні за позицією X/Y, з потрібним зміщенням по Z.

В Unity: Animator → Apply Root Motion = true, в Import Settings анімаційного кліпу — Root Transform Position (XZ) = Based on Original. Швидкість руху в грі має збігатися зі швидкістю Root Motion — інакше ковзання знову. Для Blend Tree з переходом Walk→Run використовують два кліпи з різними Root Motion швидкостями, а Blend Tree інтерполює між ними за параметром Speed. Детальніше про Root Motion читайте в офіційній документації Unity.

Які технічні вимоги до циклу як до ігрового ассету?

Довжина циклу в кадрах впливає на плавність переходу. Walk cycle на 30 fps: стандарт — 30 кадрів (1 секунда), ліва нога починає крок на кадрі 0, права — на кадрі 15. Цикл на 24 кадри буде мерехтіти при переходах. На 60 кадрів — надлишковий для більшості проектів, але потрібен для мобільних ігор з низьким frame budget, де інтерполяція між кадрами анімації вимкнена. При налаштуванні Root Motion важливо враховувати анімаційний дельта-змін у часі та коректну інтерполяцію ключових кадрів.

Run cycle: 20–24 кадри на 30 fps. Більш агресивна фаза польоту (обидва контакти підняті), виражений нахил торсу вперед. Важливо: вертикальне зміщення Hip-кістки має відповідати швидкості. Якщо персонаж біжить зі швидкістю 6 м/с, а bounce голови мінімальний — виглядає як ковзання по льоду, а не біг.

Foot IK. Walk і run cycle в більшості проектів працюють спільно з Animation Rigging або з Foot IK з Humanoid Avatar. Для коректної роботи Foot IK у основи ноги (Toe-кістка) потрібна правильна вага в Left/Right Foot IK параметрі Avatar. Якщо Foot IK увімкнено в Animator → IK Pass, а аніматор не налаштував OnAnimatorIK у скрипті, кадри будуть ігнорувати контакт з підлогою — персонаж піде крізь пандуси. Згідно з Unity Manual, це одна з частих причин багів з анімацією. Використання Animation Rigging з Foot IK підвищує реалістичність контакту з поверхнею.

Чому State Machine не підходить для локомоції, і як Blend Tree вирішує проблему?

Для локомоції State Machine з прямими переходами Walk → Run — джерело постійних проблем. Перехід через Has Exit Time з фіксованим часом 0.25s виглядає нормально на рівній поверхні і смикається при різкій зміні швидкості гравця. Blend Tree вирішує це інтерполяцією за float параметром Speed. Blend Tree забезпечує на 30% більш плавні переходи, ніж State Machine.

Мінімальна схема Blend Tree для локомоції:

• 0.0 — Idle
• 1.5 — Walk (Root Motion швидкість ~1.5 м/с)
• 5.0 — Run (Root Motion швидкість ~5.0 м/с)
• 7.0 — Sprint (опціонально)

Compute Threshold → Compute from Root Motion Speed в Blend Tree автоматично виставляє пороги за швидкістю Root Motion кліпу. Після цього залишається тільки переконатися, що параметр Speed в Animator оновлюється через animator.SetFloat("Speed", currentSpeed) з dampTime 0.1–0.15 для згладжування.

Avatar Mask дозволяє застосувати walk/run тільки до нижньої частини тіла, залишивши верхню для анімації прицілювання або взаємодії. Mask створюється в Project → Create → Avatar Mask, відключаються верхні кінцівки і голова. В Animator Controller — шар поверх базового з заданим Mask і Additive або Override blending.

Поетапне налаштування Root Motion

1. В Blender: виділіть кореневу кістку, задайте ключові кадри на початку і в кінці циклу з однаковою координатою X/Y і потрібним зміщенням по Z.
2. Експортуйте FBX з налаштуванням Bake Animation і Key Reduce > 1.0.
3. В Unity: в Import Settings кліпу встановіть Loop Time і Loop Pose.
4. Налаштуйте Root Transform Position (XZ) = Based on Original.
5. В Animator увімкніть Apply Root Motion.
6. Створіть Blend Tree і встановіть Compute from Root Motion Speed.
7. Оновлюйте параметр Speed в коді через animator.SetFloat("Speed", currentSpeed) з dampTime.

Терміни та вартість

Стоимость одного walk/run cycle з Root Motion — від $400 для стандартного гуманоїда.

Аніматор працює в Maya або Blender, експорт в FBX з налаштуваннями під Unity. Фінальна інтеграція в Animator Controller з Blend Tree — частина задачі, якщо це прописано в ТЗ.

Вартість розраховується після уточнення кількості персонажів, вимог до Root Motion та платформи (мобайл/PC/консоль). Наша команда має 7+ років досвіду в ігровій анімації, реалізовано понад 30 проектів з локомоцією персонажів.

Пропонуємо налаштування анімації під ключ: від моделювання до інтеграції в Unity за 5–7 днів. Входить: Root Motion, Blend Tree, Foot IK, Avatar Mask. Пишіть у Telegram або на пошту для безкоштовної оцінки проекту. Зв'яжіться з нами, щоб обговорити деталі. Замовте налаштування анімації локомоції для вашого проекту.

Чому ріггінг персонажів для ігор часто ламає анімаційний пайплайн?

Модель готова, текстури на місці — але в Unity вона стоїть дерев'яною лялькою. Кістки виставлені довільно і не мапляться в Humanoid Avatar. Програміст підключає готовий Animator Controller з Asset Store — блендинг анімацій ламає позу, тому що root motion налаштовано невірно. Це типова ситуація, коли ріггінг персонажів для ігор не проєктувався під рушій з самого початку. Помилка на етапі ріггінгу тягне години переробок з боку аніматора та програміста, а бюджет проєкту збільшується на 30–50%.

Ріггінг — це не просто «додати кістки». Це проєктування системи управління, яка повинна працювати всередині конкретного рушія з конкретними вимогами до формату даних. Ми гарантуємо, що після нашої роботи персонаж готовий до анімації без переробок: всі кістки мапляться в Humanoid, ваги розподілені без артефактів, а Animator Controller спроєктований під конкретний геймплей. Наша команда займається ріггінгом персонажів для ігор понад 7 років і виконала роботи для 150+ персонажів у проєктах різних жанрів — від мобільних RPG до PC-екшенів. Ми на ринку геймдев-аутсорсингу 5+ років. Замовте ріггінг у нас — і отримайте скелет, готовий до анімації з першого імпорту.

Які вимоги до скелету для Humanoid Avatar?

Unity працює з двома типами ригу: Generic та Humanoid. Вибір впливає на весь анімаційний пайплайн.

Generic rig — довільна ієрархія кісток. Анімації прив'язані до конкретної моделі, ретаргетинг неможливий. Підходить для неперсонажної анімації (техніка, двері, істоти з нестандартною анатомією).

Humanoid rig — Unity маппить кістки на стандартну схему з 17 обов'язкових кісток (хребет, голова, руки, ноги) та до 32 опціональних. Після цього будь-яка Humanoid-анімація застосовна до будь-якого Humanoid-персонажа. Це основа для ретаргетингу та Animator Controller з Blend Tree. Humanoid-риг прискорює створення анімацій у 2–3 рази порівняно з Generic, оскільки готові анімації з Asset Store працюють без адаптації.

Помилки, які ламають Avatar mapping:

• Неправильна орієнтація кісток. Unity очікує, що вісь X направлена по кістці в бік дочірньої кістки. Якщо рука дивиться по Z або -Y — Avatar згенерується зі спотвореною T-pose.
• Зайві проміжні кістки в ланцюжку хребта. Якщо між Spine та Chest стоїть проміжна кістка без маппінгу — вона втрачається при ретаргетингу, анімація хребта виглядає дерев'яно.
• Roll-кістки (twist bones) — кістки для розподілу скручування передпліччя та стегна. У Humanoid їх потрібно додавати як додаткові (не обов'язкові) кістки та коректно налаштовувати ваги. Без twist-кісток передпліччя при повороті кисті складається некрасиво.

T-pose vs A-pose

Unity рекомендує T-pose як біндингову. A-pose (руки опущені під ~45°) технічно працює, але ретаргетовані анімації будуть давати невеликі помилки в плечовому суглобі — до 5° відхилення. Для персонажів з бронею або широкими плечима A-pose іноді кращий: менше розтягнення мешу при ретаргетингу. Рішення приймається на етапі ріггінгу, переробити потім дорого.

Avatar Mask

Avatar Mask — інструмент для часткового застосування анімацій. Наприклад: нижня частина тіла грає анімацію бігу, верхня — анімацію стрільби. Без Avatar Mask ці стани конфліктують. Правильна структура Animator Controller для шутера:

Base Layer (Full Body weight: 1.0)
  └── Locomotion Blend Tree (idle / walk / run / sprint)

Upper Body Layer (Avatar Mask: верхня частина, weight: 1.0)
  ├── Idle_upper
  ├── Shoot
  ├── Reload
  └── Aim_offset (2D Blend Tree по pitch/yaw)

Additive Layer (Avatar Mask: spine, weight: по параметру)
  └── Lean_left / Lean_right

Приклад налаштування Avatar Mask: в інспекторі Unity виберіть Animator Controller, відкрийте Layer -> Add Layer -> виберіть Avatar Mask. Для Upper Body створіть маску, що дозволяє кістки плечового поясу, рук та голови. Для Additive — лише хребет. Зніміть галочки з ніг.

Additive layer для нахилу — типова оптимізація: замість 8 окремих анімацій (run_left, run_right, walk_left...) один additive lean застосовується поверх будь-якого стану. Економія часу на створення кліпів — до 40%. Для складних проєктів це знижує бюджет анімацій на 15–20%.

Як налаштувати Blend Tree для локомоції?

Blend Tree — система змішування анімацій за одним або двома параметрами. Для локомоції персонажа стандарт — 2D Freeform Directional з параметрами velocityX та velocityZ.

Мінімальний набір кліпів для базової локомоції:

Freeform Directional інтерполює між кліпами за кутом та магнітудою вектора швидкості. При velocity (0.35, 0.35) змішуються Walk Forward та Strafe Right з вагами, обчисленими за відстанню до кожної точки в 2D-просторі.

Root Motion vs. In-Place анімації

Root Motion — рух персонажа керується зміщенням рут-кістки в анімаційному кліпі. Аніматор «вшиває» швидкість руху в анімацію. Unity читає це зміщення і рухає Transform персонажа. Плюс: анімація та рух завжди синхронізовані (кроки збігаються з переміщенням). Мінус: складніше керувати швидкістю через код, вимагає коректного налаштування в Animator (Apply Root Motion: true).

In-Place — кістка тазу залишається на місці, переміщення керується кодом (CharacterController або Rigidbody). Простіше інтегрувати у фізичну систему, але ризик розсинхронізації кроків зі швидкістю руху (slipping feet).

In-Place анімації з Foot IK через Animation Rigging пакет (Unity) краще підходять для ігор зі складним ландшафтом, оскільки забезпечують точне приземлення стоп на нерівній поверхні, економлячи 15–20% часу на коригування анімацій вручну.

Чому виникають проблеми зі скінінгом і як їх вирішити?

Скінінг (прив'язка мешу до кісток через ваги) — найбільш трудомісткий етап ріггінгу органічних персонажів.

Інструменти: Maya (Weight Paint tool + Component Editor), Blender (Weight Paint mode + Vertex Group Editor), 3ds Max (Skin modifier + Weight Table).

Проблемні зони та рішення:

Правильний скінінг з першого разу економить до 60% бюджету на доробки анімації. Wikipedia: Rigging — і ми додаємо до цього математику ваг та blendshapes, щоб рухи виглядали природно. Щоб уникнути подібних проблем на вашому проєкті, отримайте консультацію з ріггінгу прямо зараз.

Бойові анімації та стани

Бойова анімаційна система — це не просто набір кліпів. Це граф станів з транзішн-умовами та interrupt priorities.

Типова помилка: транзішн з Idle → Attack з Has Exit Time: true та Exit Time: 0.9. Це означає, що атака почнеться тільки коли idle відіграє 90% (0.5 секунди). Гравець натиснув кнопку атаки і чекає півсекунди. Рішення: Has Exit Time: false, транзішн по trigger, Interruption Source: Current State з пріоритетом.

Структура бойових станів:

Any State → Hit Reaction (trigger: onHit, interrupts current)
Any State → Death (trigger: onDeath, interrupts all)

Attack Layer:
  Idle → Attack1 (trigger: attack)
  Attack1 → Attack2 (trigger: attack, exit time: 0.6)
  Attack2 → Attack3 (trigger: attack, exit time: 0.6)
  Attack1/2/3 → Idle (no trigger, exit time: 1.0)

Combo-window відкривається на ~40% довжини анімації і закривається на ~80%. Це створює відчуття responsiveness без руйнування анімації.

Коли варто використовувати Spine 2D?

Spine — стандарт для 2D-анімації в mobile RPG, idle games, action-platformers. Меш персонажа розбивається на частини, прив'язані до 2D-скелету. Анімація — трансформації кісток, mesh deformation через weighted vertices.

Переваги перед frame-by-frame:

• Файл анімації важить кілобайти замість мегабайт (спрайтлісти). Типова економія — 80–90% місця в збірці.
• Ретаргетинг: одні анімації атаки працюють на різних персонажах з ідентичною скелетною структурою.
• Змішування анімацій та IK — ті ж концепції, що в 3D.

Інтеграція в Unity: офіційний Spine Runtime для Unity. Компонент SkeletonAnimation керує відтворенням, SkeletonMecanim дозволяє використовувати Animator Controller поверх Spine-скелету. Для програмної анімації — пряме управління через API: skeletonAnimation.AnimationState.SetAnimation(0, "walk", true).

DOTween часто використовується в зв'язці з Spine для управління не-скелетними анімаціями UI-елементів, прив'язаних до персонажа (health bar, damage numbers) — не для самого скелету, а для синхронізації UI з ігровими подіями.

Як ми працюємо

1. Аналітика — розбираємо геймплей, визначаємо список анімацій, тип ригу (Humanoid/Generic), вимоги до IK та шарів.
2. Проєктування скелету — створюємо ієрархію кісток у Maya/Blender з урахуванням Humanoid Avatar, додаємо twist-кістки, corrective shapes.
3. Скінінг — ручне доведення ваг у проблемних зонах, перевірка через Unity Avatar Tester.
4. Створення анімацій — локомоція, бойові, реакції, сінематики. Налаштування Animator Controller з Blend Tree та Avatar Mask.
5. Тестування та оптимізація — перевірка в цільовій сцені, профілювання draw calls, усунення stutter, налаштування asset streaming.
6. Деплой — передача проєкту з документацією та підтримкою.

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

• Скелетна модель з коректним Humanoid Avatar (або Generic) – файл FBX/glTF.
• Набір анімаційних кліпів – FBX з AnimationClips.
• Animator Controller з налаштованими шарами, Blend Tree та транзішнами.
• Документація за структурою контролера та використанням у коді.
• Доступи до репозиторію проєкту (Git), консультації по інтеграції — відповідаємо на питання, виправляємо неточності.
• Гарантія на коректну роботу анімацій протягом 30 днів після передачі — якщо виникають артефакти, правимо безкоштовно.

Орієнтовний строк: від 5 до 15 робочих днів залежно від складності (кількість анімацій, тип ригу, наявність Spine 2D). Вартість розраховується індивідуально після оцінки обсягу. Зв'яжіться з нами для консультації та приблизного кошторису. Замовте ріггінг персонажів для ігор — і ваші персонажі оживуть без багів анімації.