𝚈 🎲 (✇/_\✇)

Как я строю UE проект чтобы с ним мог работать и я, и нейронка

2026-03-25T14:24:39.394Z

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

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

Сорс контроль

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

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

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

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

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

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

Overview (Обзор)
- Название проекта, тип, движок
- Ключевые принципы архитектуры
- Диаграмма слоёв
Project Structure (Структура проекта)
- Дерево директорий
- Соглашения об именовании (Naming Conventions)
Core Systems (Основные системы)
- Описание главных систем (Character, Weapon, AI)
- Композиция компонентов
Design Patterns (Паттерны)
- Какие паттерны используются
- Примеры кода
Data Flow (Потоки данных)
- Как данные проходят через систему
- Диаграммы
Component Architecture
- Таблица компонентов и их responsibilities
Coding Standards (Стандарты кодирования)
- Стиль именования
- Правила
Extension Guidelines (Руководство по расширению)
- Как добавлять новые фичи

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

State Machine (конечный автомат) — это способ организации логики, когда объект может находиться в одном из нескольких состояний и переключаться между ними по определённым правилам.

Аналогия

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

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

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

Зачем нужен?

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

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

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

Компоненты внутри моего персонажа

Аналогия

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

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

Зачем нужен?

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

Interface Segregation (разделение интерфейсов) — это принцип, при котором объект не обязан знать о чужих возможностях. Он описывает только минимальный контракт: "что ты умеешь делать", без лишних деталей.

Аналогия

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

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

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

Зачем нужен?

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

Observer (наблюдатель) — объект сообщает другим что что-то произошло, не зная кто именно будет слушать. Подписался — получаешь уведомления, отписался — нет. Источник об этом даже не знает.

Аналогия

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

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

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

Зачем нужен?

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

Зачем нужен?

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

Coordinator (координатор) — это как понятно из названия, объект, который не делает работу сам, а управляет взаимодействием между несколькими подсистемами. В моем прокте такими объектами выступают, сложные системы по типу дверей или того же персонажа, которые иначе могут превратиться в God Object что плохо и для чтения и для работы и для контекста нейросетей, у меня в целом все объекты и классы строяттся так, что бы избегать хардкода и всего что с ним связанно.

Аналогия

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

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

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

Зачем нужен?

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

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

Список моих Data Driven компонентов

Содержание Data Asset

Аналогия

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

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

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

Зачем нужен?

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

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

NO MAGIC NUMBERS — никакого хардкода с установленными значениями прямо в коде. Например вместо того чтобы писать float movementSpeed = 10.f прямо в методе — выносим это в Constants файл и обращаемся к нему: movementSpeed = MOVEMENT_SPEED. Чисто, красиво, не нужно бегать по тысяче строк в поисках одной цифры — и гарантия что нигде в проекте не окажется 10.f в одном месте и 10.5f в другом.
АНГЛИЙСКИЙ ЯЗЫК КОММЕНТАРИЕВ — я вот не озоботился прописать это сразу и теперь где-то английский, а где-то русский, так что сразу обозначьте этот момент. Проект на английском, нейронка лучше понимает английский контекст, и не будет каши когда код читает кто-то другой
SOFT POINTERS ДЛЯ АССЕТОВ — Data Assets всегда через TSoftObjectPtr, никаких TObjectPtr. Hard pointer держит ассет в памяти всегда, даже когда он не нужен. Soft pointer загружает только тогда, когда реально используется — это важно когда ассетов много.
UPROPERTY/UFUNCTION МАКРОСЫ — нейронка часто забывает их или ставит неправильные спецификаторы. Без UPROPERTY переменная невидима для Blueprint и не защищена от сборщика мусора. Без UFUNCTION метод недоступен из Blueprint вообще.

Debug Code — всё в #if WITH_EDITORчто бы при сборке билда, все это игнорировалось компилятором
ПОРЯДОК ИНКЛЮДОВ — *.generated.h всегда последний. IntelliSense и нейронки тащат инклюды наверх автоматически — проверяй, иначе проект не скомпилируется.
SUPER:: ВЫЗОВЫ — всегда вызывай Super:: в переопределённых методах жизненного цикла. Нейронка легко забывает, логика родительского класса тихо ломается и найти это потом хер найдешь.
ДОКУМЕНТАЦИЯ — после любых изменений в архитектуре или системах обновляй ARCHITECTURE.md и соответствующие гайды. Нейронка работает с тем что написано, а не с тем что у тебя в голове.
NO TICK БЕЗ ПРИЧИНЫ — по дефолту bCanEverTick = false на всех компонентах и акторах. Tick вызывается каждый кадр — это дорого, и в большинстве случаев просто не нужен. Вместо него три альтернативы:

Делегаты — если нужно среагировать на событие
Таймеры — если нужно что-то сделать через время или с интервалом
Кеш — если нужна ссылка на компонент, кешируем в BeginPlay а не ищем каждый кадр

Все рулсы должны быть на английском*

Есть еще такой момент с документами, сам ARCHITECTURE.md со временем раздувается шо ппц, поэтому можно создать компактный контекст для агента вместо того чтобы скармливать весь ARCHITECTURE.mdможно для определенной задачи дать:
ARCH_AI_Map.md — быстрый обзор, зависимости, ссылки на файлы ARCH_AI_CPP.md — для работы с C++
ARCH_AI_Content.md — для работы с контентом
Агент берёт только нужный файл под задачу — контекст не раздувается

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

MCP (Model Context Protocol)

2026-03-14T20:19:57.750Z

Это такой локальный сервер, через который агент управляет вашим софтом по API. Обычно его настройка максимально простая, и разберем мы её на примере MCP для UE5.7.

Давай сначала установим плагин внутрь 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 или вашего аналога настроить всё за вас.

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

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

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

Устанавливаем и настраиваем Google Antigravity IDE и Antigravity Tools

2026-03-11T12:11:30.102Z

Настройка Google Antigravity и установка ИИ-агентов

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

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

Большим плюсом для нас является возможность даже на бесплатном аккаунте использовать Claude Opus и Sonnet 4.6 с жесткими лимитами. Но даже так — это отличное предложение. Для подписок PRO и ULTRA доступны расширенные лимиты и почти неограниченная возможность использовать Gemini. Ну и никто не запрещает (пока) абузить кучу акков.

Окно Antigravity

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

Так выглядит корневая папка моего проекта

В эксплорере вы увидитн ваш проект

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

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

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

Окно расширений

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

Окно агента и иконка вызова

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

Окно Kilo Code

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

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

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

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

Окно Antigravity Tools

Установка

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

Bash

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

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

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

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

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

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

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

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

Установка и настройка Visual Studio 2022 для Unreal Engine 5

2026-03-09T16:14:11.130Z

Для чего это нужно? Мы будем использовать ИИ-агентов для написания C++ кода. Любой написанный код необходимо компилировать. Visual Studio (VS) — идеальный инструмент для нашей задачи: у нее есть бесплатная версия, она относительно легко настраивается и содержит всё необходимое для связи между Unreal Build Tool (UBT) и редактором UE.

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

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

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

окно 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 нужно явно указать движку использовать именно её.

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

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

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

Пункт 3. Окно редактора после его вызова из UE

Пункт 4. Build Solution или Rebuild Solution

Пункт 5. Сообщение о сборке

Ограничения и варианты решения проблем при компиляции

При работе с кодом (особенно сгенерированным ИИ) или при переносе старых проектов вы почти наверняка столкнетесь с ошибками компиляции. Как действовать:

Проблема: Ошибки при переводе старого Blueprint-проекта на C++ Можно попытаться сгенерировать C++ классы прямо в старом проекте, но часто это приводит к конфликтам модулей и крашам при сборке.

Самый надежное: Создать чистый новый C++ проект (как описано в Шаге 4) и сделать Migrate (миграцию) всех нужных ассетов из старого проекта в новый. Продолжать работу там.
Рискнуть и чинить на месте: Если нужно оставить старый проект, и сборка сломалась — закрой UE и VS. Зайди в папку проекта, удали папки Binaries, Intermediate и файл .sln. Кликни правой кнопкой мыши по файлу .uproject, выбери Generate Visual Studio project files. Открой появившийся .sln файл и снова запусти Rebuild Solution.

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

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

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

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

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

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

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

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

Live Coding

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

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