Создаём .gitignore, чтобы git игнорировал тяжёлые и ненужные файлы типа кешей, всяких объектов и прочего при коммите, обычно вот таких: Binaries, Build, Intermediate, Saved, DerivedDataCache и т.д. В целом я советую сделать это через ИИ агентов, пусть он посмотрит структуру проекта и сделает gitignore на его основе.

Наш проект будет модульным и больше напоминать фреймворк. Держим в уме, "а ничё тот факт что", контекст нейронок не бесконечный и при работе с какими-то классами и объектами, он может сразу переполняться и начинать сессию по новой, где снова будет читать всё заново. Так же если какие-то траблы с классами или системами, он не положит весь наш проект и в случае чего, такую проблемную хрень, можно будет легко изолировать и работать с ним отдельно

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

Поэтому будем следовать несложным правилам:

1. State Machine — управление состояниями.
2. Component — декомпозиция функциональности в компоненты.
3. Observer — делегаты для событий
4. Interface Segregation — разенлннные интерфейсы
5. Coordinator — координируют подсистемы
6. Data-Driven — DataAssets для конфигурации оружия, предметов и т.д.

С документами у нас также довольно важная и сложная работа. Многие агенты имеют набор для работы с UE, который по дефолту что-то подобное включает, но тут я лучше вручную задам всё.

Аналогия

Представь дверь с замком:

• Дверь может быть в состояниях: Закрыта, Открыта, Заперта
• Из состояния "Закрыта" можно перейти в "Заперта" (повернуть ключ)
• Из "Заперта" можно перейти в "Открыта" (правильный ключ)
• Из "Открыта" можно перейти в "Закрыта"

Дверь не может быть одновременно "Открыта" и "Заперта" — только в одном состоянии. Каждое состояние имеет свою логику.

Зачем нужен?

1. Чёткая логика — нет запутанных if-else.
2. Нельзя сделать невозможное — персонаж не может бежать и целиться одновременно например.
3. Легко добавить новое — просто создать новый класс состоянияю

Так-же это позовляет работать с выделеным компонентом отдельно, т.е. опять-же нейронки не запутаются и не переполнит контекст.

Аналогия

Представь смартфон:

• Камера отвечает только за съёмку
• Батарея отвечает только за питание
• Динамик отвечает только за звук
• Wi-Fi модуль отвечает только за связь

Зачем нужен?

1. Изоляция изменений — правишь логику инвентаря, не боясь сломать камеру или здоровье персонажа.
2. Переиспользование — UHealthComponent просто вешается и на игрока, и на врагов. Код написан один раз.
3. Лёгкое расширение — новая механика (например, система шума для AI) — это просто новый компонент, который цепляется к актору без изменения существующего кода.

Аналогия

Представь пульт от телевизора и пульт от кондиционера:

• Оба устройства управляются пультом — но у каждого свой, заточенный под него
• Телевизору не нужна кнопка "температура", кондиционеру — кнопка "канал"
• Ты не обязан знать, как устроен телевизор внутри — тебе достаточно знать, что у него есть кнопки включить, переключить канал, громкость

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

Зачем нужен?

1. Слабая связность — код взаимодействует не с конкретным классом, а с контрактом. Можно подменить реализацию, не меняя того, кто её использует.
2. Один интерфейс — много реализаций — дверь, ящик, NPC могут быть разными объектами, но все реализуют IInteractable. Код игрока работает одинаково с любым из них.
3. Минимальная зависимость — компоненты знают друг о друге ровно столько, сколько нужно. Не больше.

Аналогия

Представь YouTube-канал:

• Автор просто выкладывает видео — он не знает кто подписан
• Подписчики сами решают подписываться или нет
• Вышло видео — все подписчики получили уведомление автоматически, автор никого не обзванивал

Подписалось ещё сто человек — автор ничего не менял, всё работает само.

Зачем нужен?

• Слабая связность — источник события не знает ничего о тех кто реагирует. Добавляешь новых слушателей не трогая источник.
• Один сигнал — много реакций — враг умер, и на это реагируют сразу UI, счётчик убийств и система лута. Каждый сам подписывается.
• Никакого опроса — не нужно каждый кадр проверять "а не умер ли враг?". Событие прилетит само когда нужно.

Зачем нужен?

1. Слабая связность — код взаимодействует не с конкретным классом, а с контрактом. Можно подменить реализацию, не меняя того, кто её использует.
2. Один интерфейс — много реализаций — дверь, ящик, NPC могут быть разными объектами, но все реализуют IInteractable. Код игрока работает одинаково с любым из них.
3. Минимальная зависимость — компоненты знают друг о друге ровно столько, сколько нужно. Не больше.

Аналогия

Представь диспетчера в аэропорту:

• Он не пилотирует самолёты
• Он не заправляет их
• Он не продаёт билеты

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

Зачем нужен?

1. Разгрузка компонентов — каждая система делает своё дело и не лезет в чужое. Координатор берёт на себя логику "кто с кем и когда".
2. Единая точка управления — вместо того чтобы системы общались друг с другом напрямую и запутывались, все вопросы идут через координатора.
3. Легко контролировать сложное поведение — например, чтобы враги не атаковали все одновременно.

Data-Driven — это подход, при котором поведение объектов настраивается не в коде, а в данных. Хочешь поменять урон оружия — не лезешь в C++, просто меняешь значение в файле. Получается что бы ты не лез в код или блюпринт, создаешь Data Asset файл с параметрами которые можно менять без компиляции, а многие из них можно менять даже в рантайме, у меня это довольно важная часть, т.к. тот же геймфил настравиать крайне комфортно

Аналогия

Представь рецепт в ресторане:

• Повар готовит по рецепту — он не меняется
• Но шеф-повар может поменять рецепт: больше соли, другой соус, новый ингредиент
• Повар об этом даже не знает — он просто читает новый рецепт и готовит

Код — это повар. DataAsset — это рецепт. Логика одна, данные меняются.

Зачем нужен?

1. Не трогаешь код — баланс, звуки, дальность атаки, урон — всё меняется без перекомпиляции.
2. Легко добавлять контент — новое оружие это не новый класс, а новый DataAsset с заполненными полями.
3. Дружит с нейронкой — агенту не нужно лезть в логику, чтобы добавить новый предмет. Просто создаёт новый файл данных.

Ну я думаю с базой, разобрались, перейдем к ФУНДАМЕНТУ кода, давайте с ходу определим что мы стараемся не говнокодить, определять мы это будем с нейронкой, добавим в рулсы ей такое:

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

Давай сначала установим плагин внутрь UE5. Это будет мой личный «монстр Франкенштейна», собранный из двух MCP: [Первый] и [Второй].

Этот модифицированный MCP может читать и изменять Animation Graph в том числе. Добавляем папку с плагином в проект, конечный путь должен быть приблизительно таким: X:\Unreal_Engine_Projects\[projectName]\Plugins

Включаем сам плагин.

{
  "mcpServers": {
    "unrealMCP": {
      "command": "uv",
      "args": [
        "--directory",
        "Ваш путь к MCP",
        "run",
        "unreal_mcp_server_advanced.py"
      ]
    }
  }
}

Также можно попросить саму нейронку внутри Antigravity или вашего аналога настроить всё за вас.

После этого пингуем сервер — попроси агента получить список объектов в сцене.

По сути, это вся настройка.

*Текст редактирован с помощью нейронки

Мой основной IDE — Google Antigravity. Это форк VS Code, из-за чего на нем заводятся практически все плагины от оригинала. К тому же он изначально отлично заточен под работу с ИИ-агентами.

Для начала скачиваем его с официального сайта и устанавливаем.

Теперь нам нужно просто открыть проект. Жмем File -> Open Folder..., находим нужную директорию и выбираем корневую папку проекта (в моем случае — файлы моего сурвайвл-хоррора).

По сути, мы уже можем работать непосредственно с агентами внутри Antigravity. Но дальше, как говорится, начинаются нюансы!

Установка сторонних агентов

Давайте добавим еще агентов в нашу IDE. Отлично подойдет Qwen.

Теперь на любой вкладке доступен вызов нашего агента. Достаточно выбрать его один раз, и дальше он работает по всему проекту.

Таким же образом ставим расширение Kilo Code. Там частенько дают промки: например, на момент написания статьи уже месяц бесплатно дают юзать MiniMax M2.5.

Логинимся в каждом расширении и пользуемся. В каждом агенте можно (и нужно) настраивать workflows, skills и rules под свои задачи.

Дополнительно я скачал плагин markdownlint для чтения и подсветки .md файлов. В работе с логами и документацией от агентов — вещь очень полезная. Всякие зависимости, связанные с Python, редактор должен предложить скачать сам — просто соглашайтесь.

Antigravity Tools: Ультимативный менеджер аккаунтов

Разберем инструмент, который станет вашим основным помощником в работе. Это стороннее решение, но оно отрабатывает на все 100%, к тому же проект полностью open-source — Antigravity Tools.

Установка

Для установки выполните следующую команду в терминале:

Bash

irm https://raw.githubusercontent.com/lbjlaq/Antigravity-Manager/main/install.ps1 | iex

Почему это маст-хэв?

Основная проблема Google в том, что он часто ограничивает возможности «агентской» (командной) работы для определенных типов подписок.

Если вы приобрели студенческую или семейную подписку (например, на маркетплейсах вроде Plati), Google может не дать вам использовать все «плюшки» напрямую. Antigravity обходит это ограничение: он позволяет войти в аккаунт внутри менеджера и использовать функционал подписки на полную мощность без лишних костылей.

Ключевые возможности:

• Мониторинг ресурсов: удобный просмотр доступных лимитов и точного времени обновления квот.
• Smart Switching: автоматическое переключение на следующий аккаунт, если на текущем закончились лимиты.
• Мгновенная навигация: очень быстрое переключение между десятками профилей в один клик.
• Изоляция: возможность настройки индивидуальных прокси для каждого отдельного аккаунта.

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

Текст редактировал и форматировал нейронкой для комфортного чтения

Шаг 1: Установка Visual Studio

Для Unreal Engine 5 (включая версии 5.2 и, как в нашем случае, 5.7) стандартом является Visual Studio 2022.

1. Скачай установщик Visual Studio 2022 (версия Community бесплатна) с официального сайта Microsoft.
2. Запусти Visual Studio Installer.

Шаг 2: Выбор рабочих нагрузок (Workloads)

Это самый важный этап установки. В установщике на вкладке «Рабочие нагрузки» отметь следующие пункты:

• Разработка игр на C++ (Game development with C++)
• Разработка классических приложений на C++ (Desktop development with C++) — опционально, но помогает избежать проблем с отсутствующими базовыми библиотеками в дальнейшем.

Нюанс, на который стоит обратить внимание: Выбрав «Разработку игр на C++», обязательно разверни список дополнительных компонентов в панели деталей справа. Проверь наличие галочек на следующих пунктах (если их нет — добавь вручную):

C++ profiling tools

C++ AddressSanitizer

Windows 10 SDK или Windows 11 SDK (выбирай самую последнюю версию из списка)

Unreal Engine installer

MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest)

Шаг 3: Интеграция в Unreal Engine 5

После установки VS 2022 нужно явно указать движку использовать именно её.

1. Открой свой проект в Unreal Engine.
2. Перейди в Edit -> Editor Preferences.
3. В поиске слева введи Source Code.
4. В поле Source Code Editor выбери Visual Studio 2022.
5. Перезапусти редактор UE.

Шаг 4: Подготовка проекта и первая сборка

1. Создай новый проект. Можно использовать готовые пресеты, главное условие — проект должен быть на C++ (а не просто Blueprint).
2. В редакторе UE нажми Tools -> Refresh Visual Studio Project. Это обновит файлы решения и подтянет зависимости.
3. Затем нажми Tools -> Open Visual Studio. Проект откроется внутри IDE.
4. В самой Visual Studio в верхнем меню нажми Build -> Build Solution (или Rebuild Solution).
5. Дождись окончания процесса. Внизу должно появиться сообщение об удачной сборке.

Важное ограничение: Конфликт сборки и Live Coding

При попытке собрать проект (Build Solution) в Visual Studio, когда у вас параллельно открыт редактор Unreal Engine, вы почти гарантированно получите ошибку компиляции (ошибку прав доступа).

Это происходит из-за включенной по умолчанию функции Live Coding в UE5, которая блокирует файлы кода во время работы движка. Поскольку при работе с ИИ-агентами мы часто будем генерировать новые классы и менять заголовочные файлы, Live Coding будет только мешать. Эту функцию лучше сразу отключить, чтобы избежать постоянных конфликтов при сборке.

Как отключить Live Coding:

1. В Unreal Engine перейди в Edit -> Editor Preferences.
2. В строке поиска введи Live Coding.
3. Сними галочку с пункта Enable Live Coding.

[Место под скриншот: Окно поиска Live Coding со снятой галочкой]

Короткий комментарий по нюансу работы: После отключения Live Coding правило сборки становится максимально строгим. Если ИИ-агент написал код, который меняет архитектуру или заголовочный файл (добавил новые переменные UPROPERTY, новые компоненты или функции UFUNCTION), вам обязательно нужно закрыть редактор Unreal Engine, нажать Build Solution в Visual Studio, дождаться завершения и запустить движок заново.

Если же вы (или агент) просто поменяли логику внутри уже существующей функции (например, изменили цифру урона или скорости), закрывать движок не нужно — можно просто нажать кнопку Compile (иконка кубиков) в самом редакторе UE в правом нижнем углу.

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

Текст редактировал и форматировал с помощью нейросети, что бы он был читабельный.