С экспортом анимации работа аниматора не закончена. Конечно, некоторые аниматоры выполняют исключительно художественные задачи и после экспорта анимации в движок уже ничего не трогают, но такая роль сегодня встречается редко. Игровой аниматор должен следить за соблюдением всех технических требований к каждой созданной им анимации, будь то поддержка организации системы анимации, над которой он работает, контроль времени смешивания между анимациями или доведение анимации до играбельного состояния с помощью машин состояний или высокоуровневых скриптов.
Как минимум игровой аниматор должен поддерживать тесный контакт со всеми другими специалистами, работающими над анимацией в движке, и обмениваться с ними информацией о таких переменных, как тайминг, прерываемость (возможность отмены анимации), необходимые эффекты и т. д. Наиболее технические аспекты, выходящие за рамки знаний аниматора, часто реализуют дизайнеры или программисты, но лучше всего, когда аниматор активно делится идеями и желанием довести анимацию до готового, пригодного к отправке состояния.
Теги событий
Иногда игровым аниматорам приходится добавлять в анимацию теги (метки), вызывающие определенные события в кадре. К ним могут относиться любые события, которые желательно контролировать аниматору, особенно если предполагается часто менять тайминг анимации.
• Прерывание: до этого кадра нельзя прервать анимацию другой анимации. Благодаря этому тегу анимацию не нужно проигрывать полностью, и ее можно прервать анимацией, быстрее заканчивающей какое-то действие.
• Мимика: когда для нескольких персонажей назначены общие анимации, но они имеют разные лица, то такими тегами можно задавать уникальные выражения лиц.
• Реквизит: прикрепление или отсоединение объекта, перекладывание из руки в руку, перемещение в кобуру и т. д. – все, что может потребоваться в течение одного кадра.
• Хит-фрейм: кадр (или диапазон кадров), когда анимация боевой атаки должна зафиксировать контакт.
• Визуальные эффекты: обычно добавляются художниками по визуальным эффектам, но аниматоры могут изменять тайминг при редактировании длительности анимации.
• Звуковые эффекты: то же, что и выше, но в сотрудничестве со звукорежиссером или дизайнером по звуку; опять же полезно, чтобы аниматоры могли изменять тайминг анимации.
Подобные теги можно добавлять в самой программе DCC с помощью скрипта или отдельного инструмента, а также внутри машины состояний. Первый вариант часто предпочтительнее, так как кадры можно выбирать визуально, но изменения обычно требуют повторного экспорта и, следовательно, увеличивают время итераций. Независимо от метода, аниматору важно посмотреть, как события отображаются в игре, особенно при настройке временных параметров, влияющих на игровой процесс.
Редактор анимационных событий в движке
Тайминг смешения
В настоящее время движки обычно предлагают некий инструмент визуального редактирования для обработки различных состояний и способностей игрового персонажа, которые могут проявляться в разное время. Положительная сторона этого заключается в том, что окончательный контроль над смешением и подобными действиями часто возлагается на аниматора, а отрицательная – в том, что это требует времени, которое можно было бы потратить на собственно анимацию. Однако разница в несколько ключевых кадров анимации может нарушить баланс между плавностью анимации и геймплейной реакцией, и поэтому эти настройки следует тщательно выверять.
Дерево смешений внутри движка
Даже если работа ведется не в визуальном редакторе, очень важно, чтобы как можно больше относящихся к игровой анимации переменных оставались открытыми для редактирования либо через код, либо через скрипты и никогда не были жестко закодированы программистом, потому что в процессе разработки их обязательно придется редактировать. Независимо от метода аниматор должен иметь доступ к этим переменным или поддерживать тесный контакт с ответственным за них дизайнером или программистом, обеспечивая тем самым плавность анимации.
Программные сценарии (скрипты)
Подобно машинам состояний визуальные редакторы базовых функций сценариев (скриптов) сегодня присутствуют во многих игровых движках, открывая аниматорам возможность управлять всеми аспектами воспроизведения анимации. Аниматор, обладающий определенными техническими знаниями может создавать собственные системы и тестовые сценарии, пользуясь даже простым текстовым вводом команд.
По крайней мере, знания в этой области помогут аниматорам общаться с дизайнерами или программистами, которые будут заниматься окончательной реализацией или отладкой системы. Умение говорить на одном языке – это всегда преимущество. Аниматоры, владеющие хотя бы основами составления скриптов, – это весьма ценные члены команды, потому что, как и в случае с предварительной визуализацией, они могут сами создавать прототипы своих идей. Даже простой запуск анимации по какому-то условию (например, при нажатии кнопки или при входе в регион на уровне) может прекрасно проиллюстрировать концепцию и показать ее суть другим членам команды.
Тестовые уровни
Вместо того чтобы дожидаться окончания разработки для тестирования анимации в игре, аниматоры могут создавать тестовые уровни для проверки тех анимаций, над которыми они работают в текущее время. Например, для системы навигации в стиле паркур очень полезно будет создать полосу препятствий, содержащую все возможные виды препятствий разных размеров; преодолевающий эти препятствия персонаж будет демонстрировать все виды анимаций данной системы.
Тестовый уровень для проверки атаки в движении
Вместе с тем, хотя тестовые уровни и очень важны для разработки и точной настройки различных анимаций, это всего лишь временный инструмент, и они не должны заменять собой тестирование на настоящих уровнях игры. Часто бывает так, что тщательно выверенные на тестовых уровнях в «идеальном сценарии» движения оказываются не вписывающимися в окончательный дизайн игрового окружения. Многие системы, прекрасно работавшие в тестах, в реальных игровых уровнях разваливаются, и не в последнюю очередь потому, что некую систему (например, инверсную кинематику ступней на склонах) разрабатывают только для того, чтобы оправдать выделенные на анимацию затраты, а о реальном ее использовании почти не задумываются.
Упорядоченная система хранения ассетов
Если сетевые папки с ассетами могут содержать временные файлы или старые и неработающие анимации, то систему движка в целях экономии памяти нужно очищать от ненужных анимаций.
Точно так же следует придерживаться установленных правил именования файлов, чтобы любой специалист, которому потребуется какой-то ассет, смог легко найти его в списках экспортированных анимаций, тем более что эти списки бывают довольно длинными. К тому же единая система наименований помогает поддерживать связь между экспортированными ассетами и файлами анимированных сцен в программах DCC. Порядок внутри движка значительно ускорит процесс, когда настанет пора отладки и исправления ошибок на завершающих этапах проекта.
Инструменты создания анимации в программах DCC
Разные студии пользуются не только разными игровыми движками, но и разными средствами создания цифрового контента (DCC), то есть программами по созданию анимации с разными наборами инструментов. Некоторые из инструментов входят в стандартную комплектацию, но многие создаются самой студией на заказ или загружаются в виде найденных в Интернете «плагинов». Ниже приведен список наиболее удобных инструментов для ускорения рабочего процесса, полезных для повседневной работы; если их нет в самой программе DCC, то стоит поискать соответствующие плагины в Интернете. Обновленный список инструментов анимации можно найти на сайте этой книги: www.gameanim.com/book.
• Инструмент сохранения/загрузки/копирования/вставки поз: возможность вставлять позы из других сцен полезна не только для подбора общих для разных персонажей поз, например «позы ожидания», но и для вставки «разности» («дельты») позы на слои при работе с захватом движения.
• Инструмент сохранения/загрузки/копирования/вставки анимации: то же самое, что и для поз, только для анимации (обычно эти функции совмещены в одном инструменте). Нужен для переноса анимации между сценами.
• Библиотека поз/анимации: нужна для хранения базы данных заранее созданных поз, повторное создание которых требует больших затрат, например поз рук или мимики лица, а также для того, чтобы все аниматоры придерживались единого стиля. Сохранение в визуальной библиотеке всех предыдущих анимаций или записанных движений существенно сэкономит бюджет и позволит избежать лишних работ.
• Инструмент отладки траекторий: возможность визуализации траекторий очень важна для отладки неприглядных отклонений на траекториях и дугах анимации. Продвинутые инструменты позволяют даже изменять положение точек траектории.
• Инструмент динамической привязки: часто аниматору бывает нужно передать движение от одного объекта к другому в мировом пространстве, независимо от иерархий (поэтому копирование/вставка анимации не работает). Огромную помощь при этом окажет привязка объекта к другому по ряду клавиш.
• Инструмент управления временем: возможность повторного воспроизведения сложных движений, таких как записанные движения, с неоднородным ходом времени (с разной скоростью для разных участков) – невероятно полезный инструмент для создания «ощущения» от игры и настройки темпа игровой анимации, особенно при захвате движений.
(Публикуется с разрешения Sony Interactive Entertainment.)