Весело, конечно же, из-за встроенного в Unity аниматора, который часто пытаются использовать с ней. В каком-то смысле он слишком умный. Он отлично подойдёт для костной анимации и вообще, чего угодно, но не для кадровой анимации. Даже если всё-таки создать контроллер, импортировать правильно ассеты и настроить правильно клипы, то встреча с этой гигантской стейт-машиной, которая вынуждает писать очень странную и не всегда вразумительную логику в скриптах всё равно неизбежна.
Используем приблизительно такой же подход в Erra: Exordium. Недавно писали статью в инди группе.
За обновление аниматора отвечает уже сам скрипт, который управляет той или иной сущностью. Например, враг создаёт в себе аниматор и в своем методе Update вызывает метод Update аниматора, а тот уже сам считает межкадровый интервал, чтобы сменить спрайт. Ну и спойлер, мы не используем нигде в скриптах стандартный метод Update Моно, вопрос оптимизации. Используем только один Update. Как и метод Start.
В адрес поддержке данной статьи скажу так, свой аниматор для простой замены спрайтов это вопрос получаса. Расширять его можно на протяжении хоть всего проекта по факту конкретной задачи. Но вот выбирать такой подход нужно взвешено.
Мы приняли решение не сразу. В итоге полностью отказавшись от стандартного аниматора. А со временем наш функционал оброс слоями, событиями и всяким. Но повторюсь, решение было принято осознано, шанс аниматора в коробке мы давали много раз.
Спрошу здесь: в чем преимущества аниматора Unity перед, скажем, созданием и добавлением анимаций из blender?
Ну дык вопрос не корректный, что-то вроде "чем преимущество приготовления борща, над копанием картошки".
В блендере ты создаешь свои анимации, а в аниматоре юнити ты строишь FSM для управления ими.
Animator это стейт машина, а в блендере анимируются сами состояния этой стейт машины, как я понимаю. Соответсвенно, не совсем корректное сравнение
Если сравнивать анимирование самих состояний, то да, в Юнити можно делать свои анимации костные (и не только). Тогда можно будет не только мэшем оперировать, но и переменными внутри компонентов Юнити, дочерними элементами и всем-всем-всем. Другое дело, что аниматор (в смысле человек) должен будет освоить инструментарий Юнити
Писать свой аниматор - довольно спорное решение. Если все анимации, которые будут в игре, требуют лишь простой смены спрайтов по времени - тогда вопросов никаких. В это случае намного лучше и проще написать маленькое решение, с которым будет намного проще работать, нежели с неудобным стандартным от Unity. Однако как только в ваших анимациях появляются дополнительные объекты, необходимость в прерываниях, переходах по условиям, событиях и прочем, то время затраченное на написание своей системы анимации далеко не факт что окупится в итоге. Потому что это все потребует и своих форматов, и системы работающей с этими форматами, так еще и UI для этого дела. Не "вручную" же эти все вещи создавать. А с UI и общим пайплайном становится все еще хуже, если работать с этим инструментом будет не только автор.
Поэтому в конце расписал другие варианты
Но в целом именно с покадровый анимацией писать все переходы становится предельно неудобно, потому что см. картинку сверху (хоть она и гипертрофированна)
Дополнение для работы с покадровой анимацией от создателя Crawl https://youtu.be/2_3xrqjTyes
https://assetstore.unity.com/packages/tools/sprite-management/powersprite-animator-71177