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

Привет, SE7EN! На связи Андрей Макар-Уваров, Head of Frontend в Surf. Недавно я решил провести эксперимент: выяснить, насколько далеко можно продвинуться в разработке с помощью ИИ, если взяться за задачу, в которой у тебя нулевой опыт.

Для проверки гипотезы выбрал создание микро-игры. Концепция незамысловатая: рыжий кот с фонариком исследует мрачный лабиринт, встречает других обитателей и «делится» с ними светом. Можно подсветить путь зайчику, чтобы он стал ориентиром, или забрать свет обратно, сделав собственный фонарь ярче. По задумке, это должен был быть атмосферный пазл о балансе света и тени.

Стек проекта:

• ИИ-модель — Grok;

• Игровой движок — Godot;

• Генерация графики — fal.ai.

На старте всё выглядело оптимистично: за один вечер удалось настроить базовую логику, интерфейс и сам лабиринт. Возникло обманчивое ощущение, что теперь достаточно лишь озвучивать идеи, а код будет «писаться» сам. Однако эйфория мгновенно испарилась при взгляде на первые результаты.

Мы в Surf регулярно делимся результатами подобных ИИ-экспериментов в нашем Telegram-канале «Директорат Surf обсуждает». Там мы разбираем кейсы проектирования, разработки и тестирования мобильных решений — заходите, будет полезно.

Этап 1: когда всё идёт «слишком гладко» — жди подвоха

Вскоре начали возникать досадные проблемы: спрайты окрашивались в розовые квадраты, свет отказывался корректно работать, камера улетала в «бесконечность», а источники освещения оказывались вне границ сцены.

Через пару часов стало ясно: проблема не в нейросети, а в моём непонимании GDScript. При работе с незнакомым стеком отличить программный баг от «галлюцинации» ИИ практически нереально. В итоге я просто перевел проект на C# — движок Godot отлично его поддерживает, а привычный синтаксис сразу привел систему в порядок.

Этап 2: подбор оптимальной модели

Я протестировал целый ряд инструментов: Minimax, Codex, DeepSeek и GLM. У каждой свои особенности:

• GLM частенько зависал прямо в процессе генерации ответа.

• Minimax и Codex раз за разом наступали на одни и те же грабли.

• DeepSeek был скорее неплохим «психологом», чем эффективным кодером.

Наилучшим выбором оказался Kimi. С ним создать главного персонажа было довольно легко, однако сохранить стилистику и консистентность котика в разных ракурсах оказалось куда сложнее — модель не справлялась с задачей. Дополнительно возникла проблема с прозрачным фоном на fal.ai, которую пришлось «лечить» написанием простенького Python-скрипта для постобработки. В конечном счете, игра обрела нужный уютный визуал.

Фундамент был заложен, но впереди маячил самый сложный этап.

Этап 3: АНИМАЦИЯ!

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

План А: «быстрые спрайты»

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

Почему ИИ «буксует» в динамике?

Я осознал качественную разницу между задачами:

1. Генерация одного кадра — это создание образа, фиксация статичного состояния.

2. Генерация анимации — это удержание идентичности персонажа в пространстве и времени. Нужно сохранять пропорции, силуэт и логику движения лап от кадра к кадру. ИИ пока что крайне плохо справляется с этим «временным контролем».

План Б: видео и Blender

Я решил зайти с другого края. Существуют видео-модели вроде Runway или Pika, которые действительно обеспечивают плавность движения. Котик шагал натурально! Однако возникла проблема стилизации: у них нет встроенного понимания LoRA, и вместо моей акварельной графики я получал «глянцевый 3D-пластик». Никакие «negative prompts» не спасали ситуацию — я получил смурфиков вместо уютного кота.

План В: скелетная анимация

Последний рубеж — встроенная в Godot 2D-скелетная анимация. Суть проста: «разбираем» персонажа на части, цепляем на скелет и двигаем кости. Это дает абсолютную визуальную стабильность. Но тут начались проблемы уже не с ИИ, а с моей компетенцией: создание «рига», настройка привязок (weights) и понимание того, как конечности деформируются при движении — это полноценный навык, а не просто кнопка «сделай красиво».

Что в сухом остатке?

В игре остались статичные персонажи, которые просто перемещаются по лабиринту. Однако, как ни странно, атмосфера не пострадала: механика света и звук работают на погружение даже без плавной анимации. Проект не стал идеальным «полированным» продуктом, но он вполне жизнеспособен.

Выводы для разработчиков

1. ИИ — отличный ускоритель для формализуемых задач. Если вы можете четко описать словами то, что нужно получить — нейросеть сэкономит вам массу времени.

2. ИИ не заменит фундаментальное ремесло. Там, где требуется насмотренность, чувство формы и понимание принципов движения (анимация, дизайн, 3D), ИИ пока остается лишь вспомогательным инструментом, а не полноценным исполнителем.

3. Цена ошибки при незнании стека возрастает многократно. Нейросеть лучше всего работает в руках эксперта, который может верифицировать результат. Если вы не понимаете пайплайн, вы будете бесконечно гадать, кто допустил ошибку: вы или алгоритм.

Что дальше? Либо глубокое погружение в Blender, либо делегирование анимации профи, либо решение оставить всё «как есть» в рамках минималистичного стиля. Скорее всего, выберу третий вариант.

Еще больше размышлений и прикладных лайфхаков от нашей команды ищите в Telegram-канале «Директорат Surf обсуждает». Пишем по делу, без «воды» и лишнего пафоса.

 

Источник