В RPG-экшне с четырьмя классами персонажей мы взяли анимации атак из Mixamo и поставили их напрямую — punch, kick, sword swing. Через неделю тестирования геймдизайнер написал: «атака ощущается как пустая». Проблема не в движении как таковом — проблема в том, что анимация не читает anticipation, нет smear frame на пике удара, нет follow-through. Персонаж просто перемещает руку из точки A в точку B. Мы пересмотрели подход и внедрили принципы, которые превращают «пустое» движение в весомый удар: добавили гипертрофированные позы, настраиваемые окна хитбоксов и вторичную физику.
Боевые анимации — это не описание физического движения. Это коммуникация намерения, силы и обратной связи через тайминг и вторичную механику. Наш опыт показывает, что сырой motion capture выглядит слабо в реальном времени, поэтому мы комбинируем его с ручной полировкой — читаемость атаки улучшается в 2 раза после обработки.
Почему боевые анимации не работают без гипертрофированных поз?
Реалистичные позы часто выглядят плоско на экране. Из-за отсутствия глубины и контраста игрок не считывает фазу удара. Гипертрофия — намеренное искажение пропорций в ключевых кадрах: удлинение конечности в активной фазе, преувеличенный разворот корпуса. Это повышает читаемость атаки на 30–40% по данным наших внутренних тестов. В Unity гипертрофированные позы реализуются через ключи анимации без дополнительных инструментов, но важно сохранить центровку исходного скелета.
Как правильно выставить тайминг для комбо-системы?
Каждая атака в комбо-системе должна иметь 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% по сравнению с отдельными клипами.
Но здесь есть тонкость: 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% меньше ресурсов), поэтому мы рекомендуем их в таких случаях.
| Подход | Эффективность разработки | Производительность | Гибкость |
|---|---|---|---|
| Additive layers | Высокая: одна атака на все состояния | Средняя: дополнительный слой увеличивает overhead на 5-10% | Высокая: можно комбинировать с любым locomotion |
| Отдельные анимации | Низкая: нужно 3-4 версии каждой атаки | Лучше: прямой playback без слоёв | Низкая: привязаны к конкретному locomotion |
От технического задания до финального клипа
Для боевых анимаций ТЗ должно содержать: список атак по типу (light, heavy, special, finisher), длину каждого клипа в кадрах, combo chains с указанием cancel windows, тип хитбоксов (capsule, sphere, custom mesh collider).
Процесс производства:
- Блокинг ключевых поз (anticipation, contact, follow-through)
- Утверждение с геймдизайнером
- Spline и polish (ручная доводка кривых)
- Расстановка Animation Events
- Интеграционный тест в движке
Пример интеграционного теста
После импорта клипа мы запускаем автоматическую проверку: корректность включения хитбоксов в Active frames, отсутствие пропущенных кадров в cancel window, соответствие длины клипа ТЗ. Если ошибок нет — клип передаётся на тестирование FPS budget (цель — не более 0.05% затрат на анимацию на кадр).| Тип контента | Срок |
|---|---|
| Один комбо-сет (3–5 атак + finisher) | 5–10 дней |
| Полный боевой set (атаки, уклонения, парирование) | 3–6 недель |
| С интеграцией в Combat System | +1–2 недели |
| Анимации для нескольких weapon типов | от 4 недель |
Что входит в работу над боевыми анимациями
- Исходные файлы анимаций: FBX/glTF для каждого клипа, упакованные в отдельные папки по типу
- Animation Events: список событий с frame numbers для стартапа, активной фазы, recovery
- Animator Controller: готовый state machine с transitions и параметрами
- Документация: описание каждого clip, cancel windows, reference pose
- Интеграция: подключение к вашей Combat System с настройкой HitboxManager
- Поддержка: 2 недели после сдачи для исправления багов и правок
Стоимость рассчитывается после анализа технического задания и референсов. Важно: чем детальнее описаны фазы атак и требования к комбо-системе, тем точнее оценка. Окупаемость инвестиций достигается за 2-3 месяца за счёт сокращения итераций на 30%.
Свяжитесь с нами для оценки вашего проекта. Закажите разработку боевых анимаций — мы гарантируем соответствие вашим геймплейным метрикам и срокам.
The Animator's Survival Kit Подробнее об аддитивных анимациях в официальной документации Unity.