Создание боевых и уникальных анимаций персонажей

Наша компания по разработке видеоигр ведет независимые проекты, совместно с клиентом создает игры и оказывает дополнительные операционные услуги. Опыт нашей команды позволяет нам охватить все игровые платформы и разработать потрясающий продукт, соответствующий видению клиента и предпочтениям игроков.

От иммерсивных приложений до игровых миров и 3D-сцен

Наша выделенная команда для VR/AR/MR-разработки, Unity-продакшна и 3D-моделирования и анимации с собственными кейсами и презентациями.

Посетить персонализированный сайт
Показано 1 из 1Все 242 услуг
Создание боевых и уникальных анимаций персонажей
Сложный
от 3 дней до 2 недель
Часто задаваемые вопросы

Наши компетенции

Какие этапы разработки игры?

Последние работы

  • image_games_mortal_motors_495_0.webp
    Разработка игры для компании Mortal Motors
    1421
  • image_games_a_turnbased_strategy_game_set_in_a_fantasy_setting_with_fire_and_sword_603_0.webp
    Пошаговая стратегия в фэнтези сеттинге With Fire And Sword
    954
  • image_games_second_team_604_0.webp
    Разработка игры для компании Second term
    575
  • image_games_phoenix_ii_606_0.webp
    3D-анимация — тизер для игры phoenix 2.
    637

Мы часто сталкиваемся с ситуацией, когда боевые анимации — самая трудоёмкая часть пайплайна. Не потому что сложнее технически, а потому что требования к ним размытые до тех пор, пока не запущен игровой прототип. «Сделайте хороший удар мечом» превращается в пять итераций, когда геймдизайнер наконец видит, как анимация взаимодействует с хитбоксом, hitlag, cancel window и системой комбо. Правильная структура с самого начала экономит до 40% времени на переделках и сокращает количество итераций в два раза.

Фазы боевой анимации

Боевой удар в игре состоит из трёх фаз: anticipation (замах), active (активная фаза с хитбоксом), recovery (выход из анимации). Аниматор должен знать длину каждой фазы в кадрах — это не художественное решение, это геймдизайнерская спецификация. Без неё анимация будет красивой, но нефункциональной: хитбокс включится раньше, чем оружие визуально достигнет цели, или игрок застрянет в recovery и не сможет отменить атаку.

В Unity эти фазы управляются через Animation Events. На нужных кадрах проставляются события: OnAttackStart, OnAttackEnd, OnHitboxEnable, OnHitboxDisable. Скрипт Combat Controller подписывается на эти события и управляет коллайдерами оружия. Это стандартная схема; без неё хитдетекция либо висит на таймерах в C#, что ломается при изменении анимации, либо на физических триггерах, что даёт ложные срабатывания. Подробнее — Animation Events.

Cancel window — момент, когда игрок может прервать текущую атаку и начать следующую. В Animator Controller это реализуется через Transition с условием canCancel == true, которое устанавливается через Animation Event в нужном кадре анимации. Если cancel window не совпадает с ощущением от геймплея — возвращаются к аниматору, не к программисту.

Motion Capture против ручной анимации

Для уникальных анимаций (смерти, добивания, кат-сцены) вопрос стека зависит от бюджета и стиля. Motion Capture даёт органику, которую крайне сложно воспроизвести вручную — инерция, мелкие смещения веса, микродвижения кистей. Минус — raw mocap данные требуют ретаргетинга и чистки: джитер, артефакты на суставах, несоответствие пропорциям игрового персонажа.

Hand-keyed анимация в Maya или Blender медленнее, но даёт полный контроль над тайминг-спейсингом. Для стилизованных игр с преувеличенными движениями — часто предпочтительнее. Hand-keyed занимает в 3-5 раз больше времени, чем обработка mocap, но исключает артефакты ретаргетинга. Workflow: blockout по кривым Bezier, затем refinement с breakdown-ключами, финальная правка Euler Rotation для устранения gimbal lock.

Gimbal lock в Maya — частая проблема при анимации вращений более 180°. Лечится: переключить Rotation Order на ZXY или XZY в зависимости от направления основного вращения кости. Для запястий при пронации — обязательно, иначе кривые Euler уходят в flip. Сертифицированные специалисты нашей команды знают эти нюансы и гарантируют отсутствие артефактов.

Как реализовать комбо-систему в Animator Controller?

Комбо из трёх ударов реализуется пошагово:

  1. Создайте Sub-State Machine с тремя состояниями: Attack1, Attack2, Attack3.
  2. Настройте параметр NextAttack типа Trigger.
  3. В каждом состоянии на кадре cancel window через Animation Event вызовите animator.SetTrigger("NextAttack").
  4. Настройте переходы: Attack1 → Attack2, Attack2 → Attack3, Attack3 → Idle. Условие перехода — NextAttack.
  5. После третьего удара — возврат в Idle или Run через Exit.

Альтернатива — Animation Layer с Override и собственным State Machine для атак поверх базового локомоционного слоя. Это удобно, если атаки должны работать на ходу, но требует правильного Avatar Mask: только верхняя часть тела плюс оружие, нижние конечности продолжают локомоцию.

Blend дерево для атак с весовой интерполяцией используется реже — только для анимаций, зависящих от направления (атака влево/вправо), где Blend Tree по 2D позволяет интерполировать между четырьмя направлениями удара.

Какие типичные ошибки допускают при создании боевых анимаций?

  • Анимация без Export Root Motion. Если удар содержит лунж вперёд, Root Motion должен быть явно настроен, иначе персонаж телепортируется в начало при переходе обратно в Idle.
  • Отсутствие Additive Layer для реакции на попадание. Hit Reaction накладывается поверх любого состояния через Additive Layer — не прерывает атаку, но даёт визуальный отклик. Без этого слоя придётся делать отдельные версии каждой анимации с реакцией.
  • Игнорирование Secondary Motion. Плащ, волосы, свободные элементы одежды — без вторичного движения анимация выглядит «деревянной» вне зависимости от качества основного кейфрейминга. В Unity это Physics Bone через Animation Rigging или Spring Bone из VRM-пайплайна.

Сравнение подходов к созданию анимаций: Mocap vs Hand-keyed

Характеристика Motion Capture Hand-keyed
Время создания (на 10 сек анимации) 2-4 дня после обработки 10-20 дней
Контроль над таймингом Ограничен (требуется чистка) Полный
Артефакты (gimbal lock, джитер) Часто присутствуют Минимально
Идеально для Реалистичных игр Стилизованных игр

Что входит в работу по созданию боевых анимаций

  • Разработка структуры анимаций (фазы, события)
  • Создание исходных анимаций в Maya/Blender (mocap или hand-keyed)
  • Интеграция в Unity/Unreal Engine с настройкой Animation Events
  • Настройка Animator Controller (переходы, cancel windows, комбо)
  • Добавление Secondary Motion (Physics Bone, Spring Bone)
  • Тестирование в игровом прототипе и правка по фидбеку
  • Итоговый пакет: FBX, конфиги, документация по событию
  • Поддержка после передачи (2 недели)

Настройка Export Root Motion

Для корректного Export Root Motion в Unity необходимо в модели установить Root Transform Position (Y) и Root Transform Rotation на None, а Root Transform Position (XZ) на Bake Into Pose. В противном случае персонаж будет смещаться при каждом ударе. Детальная документация по Root Motion.

Процесс и сроки

Тип работы Ориентировочный срок
Один стандартный удар (3 фазы, Animation Events) от 4 до 8 часов
Комбо из 3 атак с интеграцией в Animator от 1 до 2 дней
Полный боевой пакет (удары, блок, уклон, смерть) от 5 до 10 дней
Уникальная кат-сцена (15–30 секунд) от 3 до 7 дней

Стоимость формируется после обсуждения количества анимаций, сложности комбо-системы и требований к Secondary Motion. Если вам нужен такой пакет, получите консультацию у наших специалистов — мы гарантируем профессиональный подход и соблюдение сроков. Свяжитесь с нами для обсуждения вашего проекта.

Почему риггинг персонажей для игр часто ломает анимационный пайплайн?

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

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

Какие требования к скелету для 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.

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

Анимация velocityX velocityZ
Idle 0 0
Walk Forward 0 0.5
Run Forward 0 1.0
Walk Backward 0 -0.5
Run Backward 0 -1.0
Strafe Left -0.5 0
Strafe Right 0.5 0

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).

Проблемные зоны и решения:

Проблема Причина Решение Экономия бюджета
«Конфетный обёрточный» артефакт в подмышках Стандартное скиннинг-решение Добавление corrective shape keys (blend shapes), срабатывающих при угле плеча Снижение артефактов на 90%
Скручивание коленей/локтей Отсутствие twist-костей Twist-кости распределяют деформацию на три сустава (shoulder twist, elbow, forearm twist) Устранение «скручивания цилиндра»
Искажение при ретаргетинге Неправильная ориентация костей в T-pose Проверка через Unity Avatar Tester Экономия 60% времени на доработки анимаций

Правильный скиннинг с первого раза экономит до 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 и транзишнами.
  • Документацию по структуре контроллера и использованию в коде.
  • Поддержку на этапе интеграции – отвечаем на вопросы, правим неточности.

Ориентировочный срок: от 5 до 15 рабочих дней в зависимости от сложности (количество анимаций, тип рига, наличие Spine 2D). Стоимость рассчитывается индивидуально после оценки объёма – свяжитесь с нами для консультации и примерной сметы. Закажите риггинг персонажей для игр — и ваши персонажи оживут без багов анимации.