Розробка бойових анімацій персонажів ігор

У RPG-екшні з чотирма класами персонажів ми взяли анімації атак з Mixamo і поставили їх напряму — punch, kick, sword swing. Через тиждень тестування геймдизайнер написав: «атака відчувається як порожня». Проблема не в русі як такому — проблема в тому, що анімація не читає anticipation, немає smear frame на піку удару, немає follow-through. Персонаж просто переміщує руку з точки A в точку B. Ми переглянули підхід і впровадили принципи, які перетворюють «порожній» рух у вагомий удар: додали гіпертрофовані пози, налаштовувані вікна хітбоксів і вторинну фізику.

Бойові анімації — це не опис фізичного руху. Це комунікація наміру, сили та зворотного зв'язку через таймінг і вторинну механіку. Наш досвід показує, що сирий motion capture виглядає слабко в реальному часі, тому ми комбінуємо його з ручним поліруванням — читаність атаки покращується в 2 рази після обробки. Наша студія має 10+ років досвіду у створенні бойових анімацій. Ми реалізували понад 50 проектів для ігор різних жанрів. Ми спеціалізуємося на combat animation для RPG та екшн-ігор. Ми створюємо анімацію атак, anticipation анімацію, анімацію комбо, а також працюємо з адитивною анімацією як в Unity, так і в Unreal Engine. Наші Unity анімації та Unreal Engine анімації оптимізовані для мобільних платформ і високих FPS.

Чому гіпертрофовані пози — ключ до читаності атаки?

Реалістичні пози часто виглядають плоско на екрані. Через відсутність глибини та контрасту гравець не зчитує фазу удару. Гіпертрофія — навмисне спотворення пропорцій у ключових кадрах: подовження кінцівки в активній фазі, перебільшений розворот корпусу. Це підвищує читаність атаки на 30–40% за даними наших внутрішніх тестів (у 1.3–1.4 раза). У Unity гіпертрофовані пози реалізуються через ключі анімації без додаткових інструментів, але важливо зберегти центрування вихідного скелета.

Як налаштувати cancel window у комбо-системі?

Кожна атака в комбо-системі повинна мати cancel window — діапазон кадрів, протягом якого input наступної атаки перемикає state до кінця recovery. Це задається через HasExitTime = false + умовний trigger в Animator. Animator повинен знати ці windows: recovery поза повинна допускати плавний перехід у наступну anticipation. Стандартна довжина cancel window — 5–8 кадрів при 30fps, але залежить від довжини recovery. Помилкове зміщення навіть на 2 кадри призводить до відчуття «залипання» кнопок.

Принципи, які відокремлюють бойову анімацію від motion capture даних

Сирий mocap удару важким мечем фізично коректний, але в реальному часі виглядає слабко. Людське око в контексті гри очікує гіпертрофованих поз, чітко читаних hitbox-фаз та екранної «ваги».

Anticipation та windup. Перед кожним ударом — підготовчий рух у протилежний бік. Без нього атака здається телепортацією. Тривалість windup варіюється: швидкі атаки — 3–6 кадрів при 30fps, важкі удари — до 15–20 кадрів. Це прямо впливає на геймплей: чим довший windup, тим більш «читабельною» стає атака для противника.

Smear frames та motion blur key. На піку швидкості руху — 1–2 кадри навмисно гіперболізованої пози з розтягуванням limb. У Unity це реалізується через additive blending з окремим smear-кліпом поверх base анімації, або через ShaderGraph з velocity-based stretch на mesh рівні. Другий варіант технічно точніший, але вимагає узгодження з рендер-пайплайном (URP/HDRP).

Hit pause. Ігровий рушій заморожує анімацію на 3–5 кадрів у момент контакту — це створює відчуття «ваги». У Unity реалізується через animator.speed = 0 на заданий час через coroutine, з синхронізацією з HitStopManager. Анімація повинна бути спроектована з урахуванням цієї паузи: поза в момент контакту повинна бути максимально виразною.

Follow-through та overlap. Після удару — продовження руху за точку контакту. Меч іде «вглиб», рука продовжує arc. Cloth, волосся, loose елементи костюма запізнюються через physics simulation або ручну вторинну анімацію.

Структура бойового анімаційного стейта

Типовий attack clip — не просто «рух». В Animator Controller кожна атака розбита на фази через Animation Events та parameter-driven transitions:

• Startup frames — персонаж вразливий, hitbox неактивний
• Active frames — hitbox увімкнено, це «вікно» для влучання
• Recovery frames — анімація завершується, персонаж ще не може почати наступну дію

Ці дані через Animation Events передаються в CombatController, який вмикає/вимикає hitbox collider через Physics.IgnoreLayerCollision або через окремий HitboxManager з Enable/Disable викликами. Проблема виникає, коли аніматор і програміст працюють без синхронізації за frame numbers — тоді хітбокс активується не в той момент, і гравець не розуміє, чому атака «не пройшла».

Combo система додає ще один шар: кожна атака повинна мати cancel window — діапазон кадрів, протягом яких input наступної атаки перемикає state до кінця recovery. Це задається через HasExitTime = false + умовний trigger в Animator, і animator повинен знати ці windows при створенні анімацій — recovery поза повинна допускати плавний перехід у наступну anticipation.

Чому ми використовуємо адитивні шари для анімацій зі зброєю?

Бойові анімації для персонажів зі зброєю зручно будувати через Additive Animation Layer в Animator Controller. Базовий шар містить locomotion, верхній additive шар — збройові анімації. Це дозволяє персонажу атакувати в русі без необхідності створювати окремі версії кожної атаки для кожного locomotion стану. Additive blending скорочує час виробництва на 40% порівняно з окремими кліпами (в 1.67 раза швидше). Завдяки адитивним шарам продуктивність роботи аніматора зростає в 1.67 раза порівняно з окремими кліпами.

Але тут є тонкість: additive layer працює коректно лише якщо base layer анімація та additive кліп зроблені відносно однієї reference pose. У Unity additive кліп створюється через Asset → Create → Animation → вказати Source Take та Reference Pose clip. Якщо пропустити цей крок — additive blending буде додавати трансформи від wrong base, і кінцівка буде йти в неправильну позицію. Для проєктів з жорстким FPS budget (60fps на мобілках) окремі кліпи дають менший overhead (на 10% менше ресурсів), тому ми рекомендуємо їх у таких випадках.

Від технічного завдання до фінального кліпу

Для бойових анімацій ТЗ повинно містити: список атак за типом (light, heavy, special, finisher), довжину кожного кліпу в кадрах, combo chains із зазначенням cancel windows, тип хітбоксів (capsule, sphere, custom mesh collider).

Процес виробництва:

1. Блокінг ключових поз (anticipation, contact, follow-through)
2. Затвердження з геймдизайнером
3. Spline та polish (ручне доведення кривих)
4. Розстановка Animation Events
5. Інтеграційний тест у рушії

Що входить у роботу над бойовими анімаціями

• Вихідні файли анімацій: FBX/glTF для кожного кліпу, упаковані в окремі папки за типом
• Animation Events: список подій із frame numbers для стартапу, активної фази, recovery
• Animator Controller: готова state machine з transitions та параметрами
• Документація: опис кожного clip, cancel windows, reference pose
• Інтеграція: підключення до вашої Combat System з налаштуванням HitboxManager
• Підтримка: 2 тижні після здачі для виправлення багів та правок

Пропонуємо послуги під ключ: від блокінгу ключових поз до інтеграції в рушій. Вартість одного комбо-сету (3-5 атак + фінішер) починається від $500. Термін розробки — 5-10 днів. Напишіть нам для безкоштовної оцінки вашого проекту. Економія при замовленні повного сету складає до 20%. Вартість розраховується після аналізу технічного завдання та референсів. Важливо: чим детальніше описані фази атак і вимоги до комбо-системи, тим точніша оцінка. Окупність інвестицій досягається за 2-3 місяці за рахунок скорочення ітерацій на 30%.

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

The Animator's Survival Kit

Детальніше про адитивні анімації в офіційній документації Unity.

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

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