Применение агентских пайплайнов в игровой разработке

Краткая историческая справка

Я аналитик в веб-разработке, а в свободное время уже несколько лет делаю собственную игру на Unity.

Это изометрический симулятор строительства и управления, чем-то напоминающий Project Hospital и The Sims. В игре есть строительство зданий, размещение объектов, персонажи со своим поведением, взаимодействия между ними и прочие механики, которые постепенно превращают небольшой пет-проект в довольно сложную систему. как-то работающую систему.

Буквально год назад я как сейчас помню, я кодил, используя помощь обычных чатов. Типа копируешь кусок кода или несколько файлов, вставляешь в ChatGPT и он тебе помогает решить твою проблему. Это работало, прирост был зачастую что-то типа 100-200 осмысленных строчек кода в день. Это где-то около 1 полноценно нормально работающей фичи в неделю.
Фича тут это типа добавить статы к персонажам (голод, усталость) и заложить интерфейсы систем, которые будут их менять.
Что-то глобальное типа поиска пути делалось около 2 месяцев где-то. Ну сам алгоритм быстро пишется, а вот его оптимизация – нет.

Тогда я писал в одной из своих статей про то, что использование вайб кодинга – это ай-яй-яй. Ты сейчас накодишь, потом хрен разберешься, что и как там работает и ошибку решить не сможешь. Ага.

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

Получается так

Это еще одна статья из цикла про разработку игр без прикладного опыта. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ-канал Homemade Gamedev, где посты выходят чаще, и я пишу про текущие задачи в проекте и уже про AI задачи в целом.

Нюансы

Я вынужден сказать пару слов про нюансы, а то вся суть-то в деталях. Чтобы не сложилось впечатление, что ниже пойдет речь про то, как я просто пишу свои хотелки, а агент сам создает решение такой чик-чик, все готово. Успевай только принимать фичи. Любой сходу сделает также. Дааа, но есть нюансы и вот они:

1. Я умею писать код. Ну типа научился уже, плюс у меня 10+ лет в бизнес/системном анализе. Я понимаю ответственность сервисов и как именно система должна работать. Знание синтаксиса тут вторично, его мне может объяснить агент.

2. Я спроектировал основную архитектуру. Сейчас каркас игры в целом готов, нет контента. А база под механики уже заложена – проработаны очереди, структуры данных. Понятен сам механизм их расширения. Игра разделена на игровую часть и так называемый “движок” поверх юнити, который работает на чистом C# без примеси специфичных данных от игровых движков и он занимается базовыми механиками – перемещением, очередями, событиями и т.д. Основные игровые системы тоже есть, строительство, сама симуляция, классы NPC, их взаимодействие. Короче база. А вот “контента” – нет. В этом-то соль, понимаете, да? Поначалу агент делал криво и не понимал мою архитектуру и тк я создал ее сам, я смог оформить для него правила, чтобы он в ней нормально разбирался и только после этого пустил его в огород.

3. Я в параллель создаю еще один веб-продукт и у меня сложились определенные подходы к тому, как именно ставить задачи агентам, чтобы они делали норм.

Виртуальная команда

За основу я взял уже знакомый подход Superpowers (это плагин такой для агентов – крайне рекомендую), но добавил несколько ролей, которые обычно существуют в полноценной продуктовой команде.

Сейчас в моей фабрике есть:

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

• Гейм-дизайнер — оценивает механику с точки зрения игрового процесса, ограничений и поведения игрока.

• UX/UI-дизайнер — прорабатывает взаимодействие, интерфейсные состояния и визуальные компоненты.

• Аналитик — формализует требования и подготавливает концепцию реализации.

• Архитектор — определяет, какие системы потребуется менять, и следит за архитектурными ограничениями.

• Агенты разработки и тестирования — реализуют и проверяют результат.

Разумеется, это не шесть независимых искусственных интеллектов с собственной волей. Это агентные роли с разными инструкциями, контекстом и зонами ответственности. Даже llm пока что одна и та же у них. Точнее как это сказать – провайдер один и тот же. Сами модели все же чуть разные, тк иначе бюджет сгорает.

Выглядит процесс примерно так:

Идея фичи → продуктовая проработка → гейм-дизайн → UX/UI при необходимости → аналитика и архитектура → реализация → проверка результата.

Причём процесс не обязан быть строго линейным. Если фича не требует интерфейса, дизайнер не нужен. Если речь идёт о техническом рефакторинге без изменения поведения игры, можно пропустить продуктовую проработку. Если нужно согласовать визуал, агент приходит ко мне за решением, а не молча выбирает вариант. Это все решает главный оркестрационный агент. От меня здесь по-прежнему требуются две вещи: принимать решения, которые нельзя надёжно вывести из требований, и контролировать архитектуру. И вот тут мы возвращаемся к нюансам. Я долго думал, можно ли прям масштабировать это так, что ну вот реально абсолютно любого ставишь вместо меня и результат получается тот же… Кажется, пока это не достижимо, в любом случае, если чел не шарит в том, КАК должна работать система, то продукт будет деградировать (причем вместе с этим челом, тк он не будет разбираться в том, что делает).

Пайплайны и скиллы

Здесь полезно разделить три понятия. (это моя интерпретация, пожалуйста, простите, если я технически что-то напутал, можете меня поправить, я так вижу)

Агент – исполнитель с определённой ролью, набором инструкций и доступными инструментами.

Скилл – переиспользуемый пакет инструкций, знаний и, при необходимости, вспомогательных скриптов и ресурсов. Например, правила проектирования Unity UI, проверки ассетов или написания тестов.

Пайплайн – процесс, который определяет последовательность этапов, их зависимости, условия переходов и ожидаемые результаты.

То есть скилл объясняет агенту, как выполнять определенный вид работы, а пайплайн – когда эта работа должна выполняться и что произойдет после.

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

Эксперимент №1. Может ли ИИ стать игровым UI-дизайнером?

Одной из первых задач для нового процесса стала переработка интерфейса.

У меня уже был рабочий HUD и набор интерфейсов для строительства. Но визуально всё это выглядело довольно посредственно. И я стал пытаться заюзать для этой цели llm. На тот момент я работал с Claude Code, и это было….ну посредственно.
Для понимания того КАК он рисует, я прикрепил ниже иллюстрацию мозга в неоновом стиле, которую мне сделал Chat GPT и “такую же иллюстрацию”, которую сделал Claude

Он зачем-то пририсовал ему пипиську, хотя в исходном варианте ее не было. Да и сама картинка…я даже не знаю как ее прокомментировать

Ладно пиписька, зачем там вот эти зеленые точки. Это созвездие какое-то что ли?

Потом в начале октября антропики забанили мой акк, я мигрировался на экосистему OpenAI и, решил заюзать ее именно для геймдева

Вначале дизайн-система

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

Решил перенести тот же подход в Unity. Оказалось, что подход очень похож по духу (кто бы мог подумать, да?)

Агент помог собрать локальный стенд с дизайн-системой — по сути, каталог интерфейсных компонентов, в котором можно посмотреть различные элементы и их состояния:

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

Все, что вы видите на скрине выше было сделано за 2 вечера взаимодействия с агентом (с учетом нюансов, конечно же, о которых я писал выше)))

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

Итоги первого эксперимента

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

Что меня еще порадовало – это вот это “оттенение” спрайтов при разных углах поворота.

Для меня, если работать “по классике” – это прям космический объем работы. Даже просто спрайт нарисовать и размножить его – уже квест. Скачать готовые ассеты можно, но они между собой не всегда бьются – тоже проблема.

По моей субъективной оценке за ночь он сделал сопоставимый объем с тем, который в прежние времена я бы делал где-то около месяца так же по вечерам.

Ну да, минус 20% от недельного лимита подписки. Ну да и хрен с ним.

Эксперимент 2. Создание объектов под ключ

Следующей задачей стала механика размещения объектов непосредственно на стенах.

Тут опять же важен нюанс – базовая механика строительства и валидации у меня уже была. Мне надо было в ней сделать расширение для того, чтобы некоторые объекты (двери и окна, а потом и часы, доска и т.д.) могли бы крепиться только на стены. Типичная фича на пару вечеров или даже недельку “по классике”.

Агент расширил существующую функциональность, добавив поддержку объектов вроде дверей и окон. Само по себе это меня не особо удивило в конце 2026го, но мне понравилось другое – появился формализованный процесс создания ассетов. Поэтому идея использования llm-ки для создания согласованного набора игровых ассетов мне зашла.

Важно, что речь не просто о генерации отдельных картинок – тут нужен именно процесс, который выдает результат в форме, пригодной для дальнейшего использования в проекте. Например: спрайт с нужными размерами и прозрачностью, соответствующий визуальному стилю (а стиль-то откуда? – а из дизайн-системы). Дальше, если надо, агент сам свяжет спрайт с префабом, разложит файлики по папочкам по согласованной структуре ресурсов проекта. Огонь.

Эксперимент 3. Автоматизированное создание 3D-персов.

Несмотря на изометрический формат игры, для персонажей я использую 3D-модели и анимации, которые затем обрабатываются для эффективного отображения в Unity.

И создание каждого нового персонажа раньше было отдельным небольшим проектом.

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

Генерация модели → FBX → Mixamo → анимации → Blender → запекание → Unity → конфигурация клипов.

Модель могла оказаться не того размера. Анимация не подходила к скелету. При импорте возникали проблемы с ориентацией или настройками. Иногда модель проще было перегенерировать. А и еще. Допустим засунули модель, сгенерили анимации, запекли их, а потом такие…аааа нет, давай-ка ей немного волосы другие сделаем – и все по новой))) Это цена запеченных анимаций (зато производительность огонь).

В результате на одного персонажа под ключ уходило около четырёх часов активной работы.

Сама по себе каждая операция несложная. Проблема в их количестве.

Я решил попробовать собрать отдельный пайплайн и попросил GPT Sol 6.1 подготовить модель первоклассника-пухляша, такого откормленного деревенского мальчика, создать FBX, анимировать персонажа и выполнить необходимые операции подготовки. Имея опыт с Claude (мозг с пиписькой), я думал, что будет ну кринж очередной какой-то

Типа такого

Но, вот результат сразу с первой попытки

Всего-то около 3000 полигонов. Как по мне, результат для первого раза – потрясающий. Да, можно придраться к тому, что у него воротник рубашки какой-то не такой, руки не оттуда растут, выглядит как маньячелло, но это не существенно для экономического симулятора – там масштаб не такой, чтобы это все разглядывать.

Ну да ладно, я думал – собрать анимацию это одно, а вот запечь ее и закинуть конфиг в Unity – другое. Но нет, с этим он тоже справился. Затупил только в одном месте, у меня координаты перепутаны и я поленился их править и ручками обычно конфиг меняю. Он это не увидел и у меня моделька двигалась задом наперед, но я это сразу пофиксил и все.

Агент автоматизировал практически всю рутину, которая раньше требовала моего непосредственного участия: подготовку модели, работу с анимациями в Blender, корректировку размеров, запекание, импорт в Unity и создание конфигурации клипов.

В итоге я получил набор артефактов:

• Статический FBX.

• Анимационные клипы.

• VAT-текстуру.

• Данные, необходимые для расшифровки координат.

Весь проход занял около часа без моего участия. А раньше на ту же самую тему я тратил около 4 часов (это прям полный вечер после рабочего дня). А сейчас час работы агента (не моей).

Зачем вообще VAT?

VAT (Vertex Animation Texture – вершинная анимационная текстура) – подход, при котором данные анимации вершин запекаются в текстуру. Вместо того, чтобы проигрывать анимацию стандартным способом, можно использовать предварительно подготовленные данные для изменения положения вершин на GPU. По своей сути это перевод 3D анимации в 2D вид, когда мы для каждой координаты (x, y, z) сопоставляем цвет (RGB) и даем файл с расшифровкой. Получается такая полоса, где по горизонтали пиксель, соответствующий позиции вершины фигурки, а по вертикали – кадры. Соот-но, прогон анимации – это просто чтение построчно этого файла.

Почему мне это актуально – персонажей дофига, а стоимость рендеринга скелета в Unity колоссальная.

Есть и обратная сторона медали – так называемые накладные расходы – с одной стороны рутина для формирования этого файла. С другой – волна изменений, если модельку надо поменять. Еще год назад это была прям боль. Сейчас – просто задача агенту на 15-20 минут.

Именно такие этапы особенно хорошо подходят для автоматизации: агент не “думает”, а просто выполняет небольшие, хорошо формализованные операции.

Пайплайны

Тут идея какая. Окей, один-два раза это прокатило, а что делать, если тебе надо выпускать этот контент сотнями единиц? У меня же ничего нет – пару тайлов поверхности, говношкафчики какие-то, пару дверей, стены, окна и 3 модельки с 4 анимациями. Т.е. по сути весь контент надо выпустить.

И тут тоже могут быть проблемы. Например, у меня ограниченное кол-во полигонов у моделей (до 3к) – это требование производительности.

Анимации должны быть определенной продолжительности, я не делаю их слишком короткими, например, и они не должны быть “рваными” – есть порог максимального расстояния телепорта точки между соседними кадрами, чтобы для глаза это не выглядело рваным (обратите внимание, что пухляш немного дергается при ходьбе – отсюда как раз и вырос этот порог). Ну и конечно, я не хочу руками потом все это настраивать в Unity, тк это тоже мутотень. Поэтому мне нужен какой-то настраиваемый конфиг, в котором я задал бы требуемые параметры и на выходе получил готовый результат в своем проекте. Это и есть агентский пайплайн. Он отличается от простого скилла тем, что на выходе каждого шага я могу ввести так называемые “гейты”, которые будут проверять предварительный результат шага как раз по обозначенным выше проверкам. Или по любым другим провекам.

В этом случае, процесс можно представить следующим образом:

Генерация модели → проверка геометрии → подготовка анимаций → проверка анимаций → запекание VAT → проверка результатов → импорт в Unity.

Если какая-то из проверок не пройдена, пайплайн не идет дальше. Он либо прерывается с ошибкой, либо передает ошибку llm и повторяет шаг еще раз. И важное уточнение – не все проверки требуют участия LLM. Более того, зачастую это просто код, детерменированный алгоритм, который проверяет данные по определенной методологии. Все, что можно формализовать лучше формализовать, а llm отдать именно интеллектуальную часть (желательно, чтобы она еще была связана с преобразованием текста в текст – это ее конек)

Что есть сейчас

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

Именно её автоматизация оказалась особенно ценной.

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

Ну и просто ради прикола я подключил эти агентские пайплайны в свою агентскую платформу, пока она не выпущенна, я заодно тестирую ее вот такими сценариями. Кмк факт того, что в нее получилось подключить пайплайн из кардинально другой сферы – уже показатель ее работоспособности

Вместо заключения

Когда я впервые начал пользоваться кодинговыми агентами, основной ценностью казалось то, что теперь можно гораздо меньше писать кода вручную. Через некоторое время оказалось, что не это ценно

Ценность в том, что меняется характер работы и то, как именно он меняется. Раньше я думал так: нужно реализовать фичу. Ага, сейчас я сяду попроектирую ее, обсудили с llm-кой архитектуру, реализацию, типичные подходы. Так, теперь пишем код (естественно я пишу его либо сам, либо кусочки отдаю “на подряд”). Потом рисую интерфейс, ищу ассеты, добавляю их в редактор, делаю конфиги и так далее.

Сейчас подход совсем другой – я определяю рамки того, что является результатом, описываю ограничения, выбираю производственный процесс и организую его выполнение. Где-то процесс требует LLM, где-то это чисто детерменированные операции, где-то нужно мое участие. Именно в этом мне кажется сейчас основная ценность. Не в создании какого-то супер-агента, которому ты пишешь типа “создай мне игру” и пошел катать вату, а в том, что ты ведешь себя как “продуктолог”, а основные организационные операции у тебя выполняются пайплайнами. Только бы токенов хватило)))