AI-геймдев в Unity: как собрать играбельную 3D-сцену с Cursor, Meshy AI и Blender

Можно ли собрать игру уровня AA только с ИИ-инструментами?

Нет, полностью автоматизировать сборку играбельной 3D-сцены уровня AA в Unity силами одних ИИ-инструментов не получается. Эксперимент с игрой от третьего лица, которую планировалось собрать без собственного кода и ручных моделей, упёрся в одно ограничение: агент не видит сцену и не понимает 3D-пространство. Он уверенно жонглирует координатами, трансформами и именами компонентов, но не замечает, что дом врос в соседний, забор прошёл сквозь дорогу, а персонаж стоит по колено в асфальте. Масштаб плывёт по той же причине: модели приходят из генератора в произвольных единицах, и в цепочке нет никого, кто знает, что жилой дом занимает около 12 метров по фасаду, а не 40.

Результат первой попытки - неиграбельный город: объекты врезаются друг в друга, проходы перекрыты, навигационная сетка не строится, персонаж застревает между геометрией. Отдельный слой проблем ждал на уровне движка и материалов: старые ассеты и контроллеры несовместимы с Unity 6, NavMesh приходится менять на AI Navigation, а стилизация текстур через Nano Banana уносит с собой PBR-карты.

Обходной путь нашёлся не в промптах, а в отказе от сочинения геометрии агентом. Вместо свободной расстановки по описанию вроде «сделай квартал с магазинами» сцена строится по реальным данным: geojson-выгрузка из OpenStreetMap, классификация ассетов по зонам и назначению, C#-скрипт, который считает позиции объектов относительно соседей.

Стек выглядел так: Unity с официальным MCP как среда сборки и точка подключения агента, Cursor как основной агент, Meshy AI для генерации моделей, Blender с аддоном Riggify для правки и авторига, Mixamo для анимаций.

Ниже - разбор по этапам. Что уже работает без человека, что требует скрипта и что по-прежнему делает человек руками.

Стек инструментов: что выбрано и почему

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

Цель формулировалась как игра от третьего лица уровня AA без собственного кода и ручных моделей. На практике «без собственного кода» превратилось в «код пишет агент, а человек объясняет, что именно считать». Скрипт расстановки объектов пришлось ставить как задачу: агент сам её не придумывает, он выполняет сформулированное правило. Узкое место смещается с написания кода на проектирование системы, и это заметно на любом агентном пайплайне - подробнее о том, почему проектирование становится ключевым навыком разработчика.

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

Как ИИ не понимает 3D-пространство и что с этим делать

Cursor не видит сцену. Через MCP он получает доступ к редактору: создаёт объекты, меняет компоненты, запускает скрипты. Восприятия объёма при этом нет. Агент рассуждает о координатах как о числах, а не как о телах, которые занимают место. Две модели с близкими значениями position пересекаются без единого предупреждения: с точки зрения кода всё корректно, объект создан, позиция присвоена.

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

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

Загрузка geojson из OpenStreetMap

OpenStreetMap хранит город в структурированном виде: узлы с координатами, линии дорог с тегом highway, полигоны зданий с тегом building, зелёные зоны с landuse и leisure. Выгрузка нужного района в geojson даёт готовый план местности, где у каждого объекта есть положение и тип.

Дальше работает скрипт на стороне Unity. Он читает geojson, разбирает geometry (Polygon, LineString, Point), переводит координаты WGS84 в локальную систему сцены через плоскую проекцию относительно центра района, чтобы метры оставались метрами, и раскладывает объекты по слоям: здания, дороги, зелёные зоны.

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

Классификация ассетов по зонам и назначению

Модели от Meshy AI приходят без семантики. Файл не знает, что это аптека, а не жилой дом, и не хранит габариты в метрах. Классификация связывает теги OSM с категориями ассетов: building=residential идёт в жилые модели, building=commercial и shop - в магазины, highway - в дорожное полотно, landuse=grass и leisure=park - в растительность. Тег определяет, какой префаб подставлять и какие размеры считать допустимыми.

На практике это словарь соответствий в C#: ключ - комбинация тегов, значение - категория и набор префабов. Обязательна резервная категория generic для тегов, которых нет в словаре, иначе кварталы остаются с дырами, а сцена теряет целостность.

C#-скрипт для расчёта позиций относительно соседей

Скрипт решает две задачи: не даёт объектам пересечься и приводит их к правдоподобному масштабу. Схематично логика выглядит так:

foreach (var feature in osmFeatures) {
    var footprint = BoundsFromGeoJson(feature);      // ширина и глубина в метрах
    var size = new Vector3(footprint.width, height, footprint.depth);
    var pos = ToUnityXZ(feature.Centroid);           // WGS84 -> локальные X/Z

    if (OverlapsNeighbours(pos, size, occupied))     // проверка пересечений
        pos = PushOut(pos, size, occupied);          // сдвиг по оси с меньшим перекрытием

    occupied.Add(new Rect(pos, size));
    Spawn(PrefabFor(feature.Tags), pos, size);       // масштаб под footprint
}

Ключевая деталь: габариты берутся не из модели, а из данных OSM, где ширина и глубина здания уже даны в метрах. Меш от Meshy AI масштабируется так, чтобы его bounding box совпал с этим footprint. Дальше идёт проверка занятости: прямоугольники соседей лежат в списке occupied, новый объект сравнивается с ними и при пересечении сдвигается по оси с наименьшим перекрытием. Только после этого объект создаётся в сцене.

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

Грабли при переходе на Unity 6: несовместимость и замена NavMesh

Миграция на Unity 6 добавила отдельный слой проблем. Старые ассеты и контроллеры оказались несовместимы: часть не компилируется, часть теряет ссылки на компоненты, часть ведёт себя иначе в рантайме. Пришлось заменять или обновлять зависимости, а часть готовых решений проще было выбросить, чем чинить.

Отдельная история - навигация. Классические компоненты NavMesh в Unity 6 заменяет пакет AI Navigation: поверхности, агенты и модификаторы переехали в него, старые компоненты в сцене не работают. Навигацию пришлось перестраивать с нуля: заново печь поверхности по геометрии города и переводить агентов на новые компоненты. Процесс оказался чувствителен к качеству геометрии: чем больше объектов врезается друг в друга, тем хуже строится сетка и тем чаще агент застревает.

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

Стилизация текстур через Nano Banana и потеря PBR-карт

Nano Banana приводит текстуры к единому стилю: генерирует новое изображение на основе исходного. Побочный эффект - PBR-карты. Инструмент работает с цветом и освещением в картинке, но не сохраняет связку albedo, metallic, roughness, normal и height. После прохода стилизации у материала остаётся одна картинка: блики и микрорельеф теряются, металл перестаёт отличаться от пластика, поверхность выглядит плоской и «мультяшной» там, где нужна была шероховатость.

Что можно сделать и чем это оплачивается. Стилизовать только albedo, а остальные карты генерировать или восстанавливать отдельным проходом: дольше, зато материалы остаются физически корректными. Ограничить стилизацию объектами, где PBR не критичен: дальний план, фоновые здания, декорации. Заранее копировать исходные карты до любого прохода стилизации, потому что вернуть их из результата нельзя.

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

Что в итоге получилось и какие выводы

Полного автомата не вышло. Уже работает без человека: генерация моделей в Meshy AI, авториг и правка в Blender с Riggify, анимации из Mixamo, написание кода агентом через MCP. Требует ручной работы или отдельного скрипта: расстановка объектов, контроль масштаба, навигация, текстуры с сохранением PBR.

Уровень AA в этой попытке не достигнут. Сцена стала играбельной за счёт данных OSM и расчёта позиций относительно соседей, но наполнение и качество до полноценного проекта не дотягивают. Пайплайн работает частично: контент генерируется быстро, а пространство, навигация и материалы остаются зоной контроля.

Границы применимости ИИ в геймдеве выглядят так. Агент ускоряет рутину: генерацию ассетов, каркас кода, тексты, однотипные правки. Пространственное мышление он не заменяет. Пока агент не умеет проверять сцену глазами и строить внутреннюю карту пространства, расстановка и навигация остаются там, где человек задаёт правила. Разговоры о скорой замене разработчиков агентами стоит мерить задачами, а не демонстрациями - о том, почему выводы о «смерти» программистов преждевременны.

Если хочется проверить этот пайплайн на своём проекте, начинать разумно с малого: взять один квартал из OSM, поднять его в Unity, написать скрипт расстановки с проверкой пересечений и только потом расширять площадь. ИИ-инструменты в геймдеве дают результат там, где рядом есть измеримое правило: на открытых джемах по AI-геймдеву заметно, что выигрывают проекты с узкой и понятной механикой, а не попытки автоматизировать весь продакшен целиком.

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

Подписаться на канал