AI-GameDev: Учим нейросеть основам левел-дизайна в Unity

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

Как и многие, кто с детства увлекается видеоиграми, я всегда мечтал создать собственный проект. Причем не просто очередной типовой инди-платформер, а что-то с близким нам колоритом и атмосферным сеттингом. У меня есть базовое понимание C#, опыт работы в Unity, навыки 3D-моделирования в Blender и работы с текстурами в Photoshop. Тем не менее, из-за высокой рабочей нагрузки и отсутствия свободного времени браться за многолетний долгострой вручную у меня нет никакого желания.

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

В чём заключается идея проекта?

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

Выбор в пользу полноценного 3D обусловлен несколькими критическими техническими факторами:

• Трехмерное пространство: В 2D-играх физика и перемещение ограничены двумя осями. Расстояния между объектами рассчитываются элементарно, а проблемы с масштабированием по высоте отсутствуют. В 3D-среде именно позиционирование становится главным камнем преткновения для нейросетей.
• Сложность мешей и коллизий: Низкополигональные или плоские модели легко генерируются сервисами вроде MeshyAI. Но при работе с детализированными персонажами и объектами окружения возникают артефакты: пересечение геометрии, некорректная подгонка одежды или проваливание сквозь текстуры.
• Автоматизация рутины: Если решить фундаментальные пространственные ошибки ИИ на старте, можно полностью сфокусировать агент на сборке геймплейных механик и настройке игрового баланса.

Инструментарий и технологический стек

Для реализации этой задумки я сформировал следующий набор инструментов:

• Игровой движок: Unity свежей версии с использованием официального MCP (Model Context Protocol) и интеграцией через Unity CLI.
• 3D-генерация: Сервис MeshyAI для создания базовых трехмерных моделей по текстовым описаниям и референсам.
• Обработка моделей и риггинг: Blender с аддоном Rigify для правки геометрии и настройки скелета.
• Анимации: Комбинация встроенных возможностей MeshyAI и каталога Mixamo.
• ИИ-архитектор и кодер: Среда Cursor, выступающая в роли виртуального разработчика, работающего с проектом в режиме 24/7. В дальнейшем я планирую также протестировать Codex и специализированные автономные harness-системы.

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

Проблемы совместимости и подготовка ассетов

В процессе первых тестов проявился целый пласт технических сложностей:

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

2. Визуальный рассинхрон: Сборка локации из разнородных готовых ассетов приводит к каше из стилей и разному качеству текстур. Попытка применить нейросетевой апскейл и стилизацию через Nano Banana улучшила чёткость картинки, но разрушила карты PBR (Physical Based Rendering). Модель сгенерировала новые трещины на текстуре, но не обновила карты высот и шероховатости, из-за чего свет начал отражаться некорректно.

3. Бутафорская геометрия: Многие готовые ассеты зданий внутри оказались пустыми оболочками со стенками толщиной в один полигон. Для экстерьера это допустимо, но сделать такие зоны интерактивными или доступными для входа игрока невозможно без полной переработки.

Главное препятствие: пространственное мышление ИИ

Первый эксперимент я провел в режиме минимального вмешательства. Написал развернутое ТЗ через Perplexity с описанием прототипа survival-horror в обстановке спального района и передал его в Cursor.

За один промпт Cursor создал базовый рабочий проект: разместил игрока, простых врагов, сформировал карту с домами и расставил интерактивные триггеры. Однако сразу же выявилась фундаментальная проблема: нейросеть абсолютно не понимает 3D-пространство. Она видит координаты в коде, но не способна визуализировать и соотнести их с реальной топографией. В результате здания хаотично накладывались друг на друга, блокируя проходы.

Опыт с геоданными и реальной топографией

Чтобы задать логику застройки, я решил передать нейросети точную структуру реального пространства. Через API OpenStreetMap я экспортировал детальный GeoJSON-файл с координатами зданий, дорог, высотностью и типом объектов, предварительно адаптирав его через Gemini в понятный для Cursor формат:

{
  "environment": {
    "water_bodies": [
      {
        "id": "river_aurajoki",
        "name": "Аурайоки",
        "type": "river",
        "width_avg_m": 15.0,
        "coordinates_local_xy": [
          [-427, 600], [-390, 550], [-237, 160], [-8, -250], [210, -580], [550, -620]
        ]
      }
    ]
  },
  "road_network": [
    {
      "name": "Советская улица",
      "class": "residential_main",
      "surface": "asphalt",
      "width_m": 7.0,
      "points_local_xy": [
        [-220, 153], [-200, 206], [48, 206], [67, 209]
      ]
    }
  ],
  "buildings": [
    {
      "id": "bld_residential_busalova_block",
      "name": "Жилой дом (ул. Бусалова)",
      "category": "residential_apartment",
      "floors": 3,
      "height_m": 10.5,
      "roof_type": "gabled",
      "material": "brick",
      "footprint_local_xy": [
        [635, 132], [643, 125], [653, 136], [646, 143]
      ]
    }
  ]
}

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

Масштабирование и классификация объектов

Во второй итерации я уменьшил тестовую сцену до небольшого участка: 10–15 построек, брошенные автомобили и один проработанный интерьер. Но без принудительного контроля Cursor снова начал путаться в габаритах: машины оказывались размером с дом или врастали в стены.

Для решения этой проблемы я применил два ключевых инструмента:

1. Скрипт позиционирования: Написание C#-модуля, который при спавне любого объекта автоматически рассчитывает его баундинг-бокс и минимальный отступ от соседних мешей.

2. База данных и таблица классификации ассетов: Строгий регламент назначений и допустимых зон для каждого элемента.

Благодаря такой структуре Cursor перед установкой объекта обращается к базе знаний, сверяет габариты и проверяет, предназначен ли предмет для улицы или для интерьера. В дополнение я подключил суб-агента, который ведет подсчет размещенных объектов, не допуская замусоривания сцены.

Первые успешные результаты и ключевые выводы

После настройки правил и базы ассетов ИИ быстро связал контроллер движения Unity с набором анимаций. В результате первая же сборка выдала полностью функциональных NPC.

По заданному ТЗ Cursor автоматически выстроил следующую логику:

• Интерактивные зоны диалогов с персонажами.
• Динамический спавн врагов в строго отведенных триггерных зонах.
• Базовую систему выживания: шкалы усталости, голода и жажды, расходуемые в зависимости от активности персонажа.
• Торговую зону и интерфейс покупки ресурсов за найденные предметы.

На основе этого эксперимента я сформулировал три главных правила AI-геймдева:

1. Строгая документация и классификация: ИИ не умеет додумывать контекст. Ему необходим четкий реестр объектов с их габаритами, назначением и зонами применения.

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

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

Новый этап в индустрии: почему свой продукт становится реальным

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

Однако эта трансформация открывает невероятные возможности для одиночек. Если раньше создание трехмерной игры требовало целой команды 3D-художников, аниматоров и C#-программистов, то сегодня при грамотной настройке связки Unity, Cursor и генеративных нейросетей запуск собственного продукта становится вполне выполнимой задачей.

Источник: habr.com