ч. 18 — ИИ + человек создают 2D анимации для онлайн игр с доставкой до клиента

от автора

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

Коротко о проекте

Уже 18 частей с 2022 года я веду дневник разработки авторитарного сервера для 2D MMO RPG — игры с открытым бесшовным миром, где сотни игроков и существ живут в реальном времени. В прошлой части ИИ впервые получил «руки»: начал собирать игровую механику из одного текстового описания. Оставалась витрина, которую я обещал, — как в эту игру попадают анимированные персонажи. Об этом — восемнадцатая часть.

Анимация — это не картинка, а скелет

Первое, что я решил: персонаж в игре — не заранее нарисованный «мультик», а скелет. Плоская картинка режется на части (голова, торс, руки, ноги), части сажаются на кости, а движение задаётся поворотами костей — походка, атака, ожидание.

Страница анимации в кабинете: слева спрайт разобран на части под кости, справа — привязка к действиям и сторонам света.

Страница анимации в кабинете: слева спрайт разобран на части под кости, справа — привязка к действиям и сторонам света.

Кости нужны не ради красоты. Они дают главное — экипировку. Меч висит на кости руки, броня — на торсе, и когда персонаж двигается, снаряжение едет за костью само.

Скелет из Spine и Spriter: экипировка — часть анимации, поэтому одного героя можно одеть по-разному.

Скелет из Spine и Spriter: экипировка — часть анимации, поэтому одного героя можно одеть по-разному.

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

Предметы и броня сгруппированы по сторонам и накладываются на аватар поверх скелета — кастомизация без перерисовки.

Предметы и броня сгруппированы по сторонам и накладываются на аватар поверх скелета — кастомизация без перерисовки.

Действия, стороны и типы существ

Скелет — половина дела. Вторая половина — как игра понимает, какую анимацию и когда проигрывать. Для этого у существа есть набор действий: ходьба, атака, ожидание. Действие запускает свою анимацию. Сами действия я задаю в кабинете — там же справочник, по которому анимации сопоставляются с игрой.

Справочник действий существ: по нему действия сопоставляются с анимациями.

Справочник действий существ: по нему действия сопоставляются с анимациями.

У каждой привязки я отдельно указываю сторону, в которую смотрит анимация. Так на одно действие вешается сразу несколько направлений — персонаж идёт влево, вправо, вверх и вниз своими кадрами, а действие остаётся одно.

Тип существа — это префаб. В нём я закладываю базовые характеристики: кто это, какие у него параметры. Справочник префабов работает сразу как бестиарий игры и как техническое задание для ИИ — по нему он и связывает, и создаёт анимации.

Справочник префабов — одновременно бестиарий игры и ТЗ для ИИ на связку и создание анимаций.

Справочник префабов — одновременно бестиарий игры и ТЗ для ИИ на связку и создание анимаций.

Дальше две стороны сходятся. В анимации клип — это наше действие, а сущность — наш префаб. Мелочь, о которую спотыкаешься на практике: в Spriter один файл может нести несколько сущностей, в Spine — только одну. Знать это нужно, чтобы связка не разъехалась при импорте.

Конвейер: картинка → скелет → игра

Дальше — конвейер, в котором ручной работы почти нет.

На входе — картинка персонажа. Её по строгим правилам генерирует внешний ИИ-сервис арта (например, PixelLab или ChatGPT): строго фронтально, симметрично, части тела не перекрывают друг друга. Правила не случайны — если руки закрывают торс, автоматическая нарезка на скелет разваливается. Эти рамки задаю я; сервис рисует внутри них.

Дальше картинка режется на части, из них собирается скелет и расставляются ключевые кадры — ожидание, ходьба. Весь этот конвейер — генерация арта, нарезка, риг, импорт — ИИ водит удалённо через MCP-сервер, о котором была прошлая часть: готовую анимацию он одним файлом ставит прямо в игру, через веб-кабинет, без правки кода.

Готовая анимация загружается одним файлом через веб-кабинет.

Готовая анимация загружается одним файлом через веб-кабинет.

И вот тут срабатывает решение из ранних частей: обновление контента доходит до игроков, не требуя переустановки клиента. Новый анимированный персонаж появляется в живой игре как обычное обновление данных — тем же путём, что новые карты и баланс.

Тот же файл — и персонаж уже в игре на Unity, клиент не пересобирали.

Тот же файл — и персонаж уже в игре на Unity, клиент не пересобирали.

Пример: гигант, который пошёл

Как это выглядит на деле. Беру картинку гиганта, прогоняю через конвейер — на выходе скелетная анимация: гигант идёт, части тела двигаются по костям. Импортирую одним файлом — и в игре появляется новый анимированный персонаж. Правок клиента — ноль.

Анимации оживают на карте

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

Редактор баланса: расставляю монстров и объекты прямо по карте.

Редактор баланса: расставляю монстров и объекты прямо по карте.

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

Импорт карт задаёт бесшовный мир и точки, куда встают монстры.

Импорт карт задаёт бесшовный мир и точки, куда встают монстры.

Сами карты собраны из открытых ассетов The Mana World и правятся в редакторе Tiled. Старые карты я ещё и улучшаю с помощью ИИ и держу под контролем версий.

Карты из The Mana World, сделанные в Tiled: ИИ дорабатывает их и отправляет в общий репозиторий.

Карты из The Mana World, сделанные в Tiled: ИИ дорабатывает их и отправляет в общий репозиторий.

Каталог: собери игру как конструктор

Весь этот контент — анимации, карты, существа, предметы, библиотеки с механиками — складывается в единый каталог. Из него игра собирается как конструктор: добавляешь нужные блоки — и получаешь свою сборку, не трогая код.

Контент как конструктор: анимации, карты, предметы и библиотеки механик добавляются в игру блоками.

Контент как конструктор: анимации, карты, предметы и библиотеки механик добавляются в игру блоками.

А в следующей части — как над этим каталогом работать вдвоём и не мешать друг другу. Человек правит механики и контент через админ-панель, ИИ — через тот же MCP-сервер, а git хранит историю и бэкап. Контент разложен на отдельные элементы, у каждого может быть свой репозиторий; каждый участник дорабатывает игру в своей песочнице, и правки собираются вместе через git — с проверкой перед выходом в игру.

Где ИИ пасует

Не хочу создавать впечатление, что тут всё само. ИИ отлично делает рутину — режет, ригует, расставляет кадры. Но он не держит цельность.

Стиль всего ростера — что новый персонаж выглядит из той же игры, что и остальные, — держу я: одна камера, одни пропорции, одна толщина контура. Уберите эту рамку — и ИИ выдаст десять хороших, но разных по духу спрайтов, которые не склеиваются в один мир.

И честно про ограничение: автоматическая нарезка отдаёт цельные руки и ноги — кости получаются односегментными, мах от плеча, без сгиба локтя. Настоящий сгиб требует большего. Пока это компромисс, а не магия.

Пару лет назад такой конвейер означал бы аниматора и риггера в штате. Сейчас внешние ИИ-сервисы арта плюс автоматический риг дают анимированного, экипируемого персонажа силами одного человека — а то, что конвейер свой и не завязан на зарубежные ассет-магазины, для проекта здесь и сейчас скорее плюс.

Вопрос к вам

И вопрос к вам. Во-первых: какими ИИ-сервисами и рабочими схемами для создания и оптимизации анимаций пользуетесь вы — что посоветуете кроме тех, что я назвал? Во-вторых: какие игры с открытым исходным кодом вы знаете — из них мы с ИИ могли бы брать и знания для обучения, и готовый контент. Поделитесь в комментариях — из этого соберётся следующая часть.

История

  1. Введение

  2. Масштабируемость и асинхронность

  3. WebSocket

  4. Redis

  5. LUA и JavaScript

  6. Выбор технологий, протокола и шаблон ECS

  7. Игровые локации (тайловые карты)

  8. Клиентская часть на Unity

  9. Игровые серверные механики

  10. Открытый бесшовный мир в 2D игре

  11. FPS, Ping, паузы между командами, интерполяция и экстраполяция

  12. Очереди и параллельное программирование на CPU

  13. Event-driven паттерн, JSON-RPC и почему не сервисная архитектура

  14. Сетевая карта и задержка кадра по RFC 2544

  15. Игровой авторитарный сервер на процессах

  16. MVP готов

  17. Внедряю ИИ: механики из одного описания

  18. ИИ оживляет персонажей: скелетная анимация (эта статья)

ссылка на оригинал статьи https://habr.com/ru/articles/1060484/