Дневник разработки Erra: Exordium #2: Покадровая анимация, код и велосипед

Всем привет. На связи Fair Pixel. В этот раз мы расскажем про анимации в проекте Erra: Exordium. О том как они повлияли на геймплей и на каком велосипеде мы едем.

Поначалу мы хотели видеть игру неспешной, в угоду эксплорингу. Первый год разработки мы шли по этому пути, попутно создавая внутри игры различные ситуации. Это позволяло понять какие геймплейные ситуации мы хотим дать игроку.

Но с каждым новым механом ускорялся темп геймплея. Приходилось вносить изменения в анимации главного героя. Менялся персонаж. А его визуальное поведение начинало влиять на буквально всё.

С чего мы начали...

...и к чему пришли.

Вслед за героем претерпели видимых изменений противники, как в плане движений, так и в плане видимой атаки. Но о противниках мы расскажем в другом выпуске нашего дневника.

Это лишний раз показывает важность предпродакшна и четкого видения геймплея.

Без купюр и возможно с позором. В главных ролях: Unity Animator, программисты Fair Pixel.

За кулисами эволюции персонажа, а именно анимациями, есть небольшая история технической части проекта. Так как каждая наша анимация состоит из полностью прорисованных кадров, а в анимациях нет вращений объектов, мы решили, что управлять этим будет проще паренной репы. Ведь есть Animator и всякие там связи, переходы, вызовы методов класса. Вы и сами знаете, как это всё работает.

Дневник разработки Erra: Exordium #2: Покадровая анимация, код и велосипед

Первый Pipeline был следующим: художник давал кадры программисту или сам собирал их в анимацию в Unity (просто набор последовательных кадров, иногда с разным межкадровым интервалом), а программист добавлял анимацию в аниматор и настраивал связи.

Количество анимаций росло. Усложнялись состояния. Увеличивалось количество переходов. Это привело нас к тому, что кадры анимаций стали анимациями в аниматоре. И тут ты наверное крутишь палец у виска?!

То ли из-за отсутствия опыта, то ли из-за страха перед увиденным, мы решили, что для нас стандартный Unity Animator слишком шикарен.

Во-первых, мы начали тратить на это много времени. Настройка, отладка - это ещё полбеды. Расширение анимации, логики, вызовы кода, более сложные штуки - вот это была боль.

Во-вторых, мы решили отделить руки с огнестрельным оружием от тела, чтобы не рисовать всего персонажа целиком с оружием на каждый вид состояния. Представь себе, что персонаж с пистолетом может целится стоя, сидя, в движении. И оружие при этом не крутится как объект. Отдельное положение оружие - это конкретный кадр. Типа трупиксель! А потом ещё доставать оружие, прятать, перезаряжать и опять стоя, сидя, в движении… Прогрессия!

Поэтому было решено написать свой велосипед. Который был бы проще в настройках и решал бы вот всё выше написанное. В итоге информация про анимацию хранится в контейнере (благодаря ScriptableObject) и описана тремя полями: идентификатор, межкадровый интервал и набор спрайтов.

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

С появлением новых требований, менялась архитектура. На данный момент часть архитектуры выглядит так:

AnimationManager находится в каждом персонаже. Он хранит и управляет слоями анимации. LayerController содержит в себе перечень всех анимаций слоя. Анимацией управляет AnimationController. Таким образом, данные анимаций из ScriptableObject превращаются в AnimationController, в котором присутствует набор команд и событий.

Приведем пример на псевдокоде.

В классе CharacterExample показана инициализация аниматора. AnimationManager получает доступ к компоненту объекта (SpriteRenderer) и данные анимации. StateManager сегодня мы обсуждать не будем, кратко скажем, что это машина состояний для разных живых объектов в игре.

public class CharacterExample : IActor { private AnimationManager _animations; private SpriteRenderer _sr; private StateManager _states; public AnimationManager Animations { get { return _animations; } } public StateManager State { get { return _states; } } public CharacterExample(Animation[] animations) { _animations = new AnimationManager(_sr, animations); _states = new StateManager(); _states.Add(States.IDLE, new IdleState(this)); _states.Add(States.JUMP, new JumpState(this)); } public void Update() { _animations.Update(); _states.Update(); } }

Класс IdleState демонстрирует простой вызов смены анимации при старте состояния Idle.

public class IdleState : State { private CharacterExample _character; public IdleState(CharacterExample character) : base(character) { _type = States.IDLE; } public void Start() { _character.Animations.ChangeAnimation(AnimationsLayers.BASE, Animations.IDLE); } public void Update() { if (Input.Jump.Down) { _character.State.Set(States.JUMP); } else if (Input.Horizontal != 0f) { _character.State.Set(States.WALK); } } }

Класс JumpState демонстрирует варианты вызовов и события анимаций. При запуске состояния, аниматор переключится на анимацию JUMP. Затем произойдет переключение на анимацию JUMP_MOTION, когда сработает условие в событии FrameHandler. По завершению той или иной анимации, сработает переход в состояние IDLE. Ещё раз повторим, что это псеквдокод… Простая демонстрация некоторых возможностей.

public class JumpState : State { private CharacterExample _character; private AnimationController _animationJump; private AnimationController _animationJumpMotion; public JumpState(CharacterExample character) : base(character) { _type = States.JUMP; _animationJump = _character.Animations.Get(AnimationsLayers.BASE, Animations.JUMP); _animationJump.FrameHandler += AnimationJump_FrameHandler; _animationJump.EndHandler += AnimationJump_EndHandler; _animationJumpMotion = _character.Animations.Get(AnimationsLayers.BASE, Animations.JUMP_MOTION); _animationJumpMotion.EndHandler += AnimationJump_EndHandler; } public void Start() { _character.Animations.ChangeAnimation(Characters.AnimationsLayers.BASE, Characters.Animations.JUMP); } private void AnimationJump_FrameHandler(AnimationController controller) { if (controller.CurrentFrame > 2) { _character.Animations.ChangeAnimation(AnimationsLayers.BASE, Animations.JUMP_MOTION); } } private void AnimationJump_EndHandler(AnimationController controller) { _character.State.Set(States.IDLE); } }

Таким образом, нам удалось получить полный контроль над анимациями, их отображением и корректировкой геймплея, чтобы не происходило “разрывов” и прочих неприятных вещей.

И вот мы "победили", казалось бы, такую небольшую, но такую важную вещь. Зато теперь живем в мире и согласии с кодом и анимациями.
Нам будет очень интересно выслушать ваши примеры решения собственных велосипедов. А может у вас есть советы как можно было решить нашу проблему.
Будем рады услышать каждого!

#девлог #будетполезно #личныйопыт

Дневник разработки Erra: Exordium #2: Покадровая анимация, код и велосипед

А теперь про велосипед “Аниматор”