# unity-game-agent > Unity Game Agent — создание Unity-игр агентом по этапам (набросок → план → реализация → проверка). Use when the user asks to build or prototype a Unity game, implement game features step-by-step, or use Unity MCP / other MCPs for scene and editor automation. - Author: DESKTOP-1DIN886\User - Repository: NeoXider/unity-game-agent - Version: 20260207172401 - Stars: 0 - Forks: 0 - Last Updated: 2026-02-07 - Source: https://github.com/NeoXider/unity-game-agent - Web: https://mule.run/skillshub/@@NeoXider/unity-game-agent~unity-game-agent:20260207172401 --- --- name: unity-game-agent description: Unity Game Agent — создание Unity-игр агентом по этапам (набросок → план → реализация → проверка). Use when the user asks to build or prototype a Unity game, implement game features step-by-step, or use Unity MCP / other MCPs for scene and editor automation. --- # Unity Game Agent Сборка Unity-игры по циклу: **набросок → этапы → реализация → проверка → отчёт**, с использованием MCP (Unity MCP и др.) где доступно. Этот файл намеренно **короткий** (экономим токены). Детали и шаблоны лежат в: - **Шаблоны файлов проекта + справка:** [reference.md](reference.md) - **Выбор режима:** [MODE_CHOICE.md](MODE_CHOICE.md), подробности: [MODE_DETAILS.md](MODE_DETAILS.md), правила: `modes/*.md` - **Инструменты/код/Unity:** `tools/*.md` - **Готовые запросы:** [PROMPTS.md](PROMPTS.md) ## Цель проекта AutoUnity **Цель текущего проекта:** сделать **набор MCP, готовые промпты/скиллы, автоматизацию (bat) и ComfyUI** для **создания автономных Unity-игр с помощью ИИ**. Ключевое правило использования инструментов: - **Файлы/папки/код**: не использовать Unity MCP. Делать через файловые инструменты (IDE/файловый MCP/патчи) или через `setup_source_folders.bat`. - **Unity Editor** (сцена/объекты/компоненты/PlayMode/скриншоты/консоль): использовать Unity MCP. - **Дизайн UI приоритетно через UI Builder** (UI Toolkit): если версия Unity поддерживает UI Builder и пользователь **явно не попросил иначе** (например, uGUI/Canvas) — всегда делать UI через UI Builder (UXML/USS). Подробности: [tools/ui-builder.md](tools/ui-builder.md). Документация Unity: [UI Toolkit](https://docs.unity3d.com/Manual/UIElements.html), [UI Builder](https://docs.unity3d.com/Manual/UIBuilder.html). При настройке и будущих обновлениях ориентироваться на эту цель. ## Настройка проекта Коротко: - Открыть проект как папку `C:\Git\AutoUnity`. - MCP настраивается в `.cursor/mcp.json`. - Подробности: [tools/unity-mcp.md](tools/unity-mcp.md) и [tools/comfyui.md](tools/comfyui.md). ## Когда применять - Запрос на создание/прототип игры в Unity. - Запрос на пошаговую реализацию механик с проверкой в редакторе. - Задачи, где нужен явный набросок и промежуточные этапы (не только финальный код). ## Старт новой игры (с нуля) - **Запрос в начале:** запрашивать у пользователя **два блока**: 1. **Настройки** — всё, что попадает в `Docs/DEV_CONFIG.md`: режим, платформа(ы), ориентация, стиль, разрешение, input, тогглы (уточняющие вопросы, поиск готовых решений, ComfyUI, Figma, **Авто-режим**). **В Стандартном и Профи обязательно спросить** про «QA на фичу». **Авто-режим (экономия времени):** спросить по желанию — при включении агент делает по максимуму автономно, уточнения и запросы проверок собирает и задаёт под конец (сводным блоком). **Если выбран стиль/UI из Figma** — дополнительно запросить ссылку. Использовать структурированный запрос (AskQuestion или чёткий список). 2. **Геймдизайн** — запрашивается отдельно: идея игры, механики, экраны (для заполнения `GAME_DESIGN.md`). - **Планирование в Plan mode:** этап планирования (набросок → план задач, фиксация в `GAME_DESIGN.md` и `DEV_PLAN.md`) выполнять в **Plan mode** Cursor: агент собирает данные, формирует план реализации, пользователь подтверждает план, затем переходить к реализации. ## Режим разработки Правило: **перед началом** всегда запросить настройки (в т.ч. режим) и показать [MODE_CHOICE.md](MODE_CHOICE.md). После выбора — прочитать файл режима из `modes/` и следовать ему. Общее для всех режимов: - **Все настройки и данные — в ScriptableObject** (NpcData, UiData, GameFightData и т.д.). - **Reuse-first (по умолчанию):** перед реализацией каждой фичи сделать поиск готового решения (приоритет: библиотека/пакет → ассет → референс-код). Если фича слишком маленькая и простая — писать код вручную. Переключатель: `DEV_CONFIG.md` → «Поиск готовых решений». - Формат логов: `Debug.Log($"[Feature.Class.Method] ...")` (подробности и объём — в [tools/code-writing.md](tools/code-writing.md)). - **Проверки агента:** агент **обязан сам проверять** фичи: запускать Play Mode, делать скриншоты игры, пробовать поиграть (нажать кнопки, пройти сценарий). В режимах Стандартный/Профи — проверка **на каждую фичу** перед переходом к следующей. В Быстром и Прототипе допускается проверка нескольких фич подряд или одна проверка под конец этапа. - QA: **финальная QA обязательна**; QA на фичу (проверка пользователем) — опционально (см. `modes/*`). Чеклист QA: не только шаги и ожидаемый результат, но и колонка **«Проверка агентом»** (агент заполняет после своей проверки) и колонка **«Проверка QA»** (оставить пустой — заполнит QA по просьбе агента). Шаблон — [reference.md](reference.md) → «Шаблон QA-чеклиста». - Уточняющие вопросы — по правилам режима (см. `modes/*`), переключатель хранить в `DEV_CONFIG.md`. ## Обязательный цикл Скелет (детали — в `modes/*` и [reference.md](reference.md)): 1. **Запрос настроек и геймдизайна** — настройки (DEV_CONFIG) и идея игры (для GAME_DESIGN), см. «Старт новой игры». 2. Уточняющие вопросы (если включено и требуется режимом). 3. Набросок → фиксируем в `GAME_DESIGN.md`. 4. **План (в Plan mode)** → формируем и фиксируем в `DEV_PLAN.md`; пользователь подтверждает план перед реализацией. 5. Реализация по задачам/фичам → обновляем `DEV_STATE.md` и итерацию лога. 6. Проверка (по режиму) + финальная QA (в конце). ## Файлы проекта Все файлы памяти и логов — **в папке `Docs/`**: `Docs/DEV_CONFIG.md`, `Docs/GAME_DESIGN.md`, `Docs/DEV_STATE.md`, `Docs/DEV_PLAN.md`, `Docs/AGENT_MEMORY.md`, `Docs/ARCHITECTURE.md`, `Docs/DEV_LOG/`, `Docs/Screenshots/`. Не создавать их в корне проекта. Порядок чтения, шаблоны и правила — в [reference.md](reference.md). Ключевой принцип: **DEV_STATE всегда маленький**, DEV_PLAN — полный план; файл лога итерации — имя **строго** с датой и временем (`iteration-NN-YYYYMMDD-HHMM.md`). ### Оформление Docs/DEV_STATE.md - **Эмодзи и структура (обязательно):** использовать разделы с эмодзи: 🧠 Контекст · ⚙️ В процессе · ⏭️ Следующие задачи · ⚠️ Блокеры · 📸 Последний скриншот · 📈 Прогресс · 📊 Общая информация. В начале файла — **Легенда** (🧭): статусы 🟦 в работе, 🟨 проверка, 🟥 блокер, 🟩 готово; метки `[x]` сделано, `[ ]` не сделано, `←` текущий шаг. - **Прогресс (обязательно):** блок **📈 Прогресс** вести всегда: **Фича (текущая)** — процент или шаги микро-плана (K / N), статус 🟦/🟨/🟥/🟩; **Проект (в целом)** — M / T задач по DEV_PLAN, процент. Можно добавлять визуальные полоски, например `|████░░░░|`. - **В процессе:** текущая задача с микро-планом (нумерованный список, шаги с [x]/[ ] и ← на текущем). Обновлять при каждом действии. - Полный шаблон — [reference.md](reference.md) → «Шаблон Docs/DEV_STATE.md». ## Использование MCP Unity MCP и ComfyUI — ускорители. **Если MCP недоступны** — уточнить у пользователя: помочь настроить MCP или начать без них (разработка через код/файлы). Не блокировать разработку: при отказе от настройки — продолжать без MCP. Подробности: [tools/unity-mcp.md](tools/unity-mcp.md), [tools/comfyui.md](tools/comfyui.md). ## Создание интерфейса (UI) **Интерфейс создаётся через UI Builder** (UI Toolkit): UXML/USS в редакторе, UIDocument в сцене; код подключает ссылки на элементы, показывает/скрывает панели и вешает обработчики. Подробности: [tools/ui-builder.md](tools/ui-builder.md). Документация Unity: [UI Toolkit](https://docs.unity3d.com/Manual/UIElements.html), [UI Builder](https://docs.unity3d.com/Manual/UIBuilder.html). Если пользователь **явно попросил** Canvas/uGUI — тогда через иерархию Canvas в сцене или префабах. Создание UI в runtime (редкий случай) — см. [tools/code-writing.md](tools/code-writing.md) по необходимости. ## Unity/C# практики Все детали по стилю/паттернам/логированию/комментариям: **[tools/code-writing.md](tools/code-writing.md)**. ## Обработка ошибок Коротко: компиляция должна быть чистой; MCP может падать; объекты в сцене проверяем через состояние редактора и скриншот. Подробности: [reference.md](reference.md) → «Обработка ошибок и типичные проблемы». ## Анти-паттерны Коротко (подробно — в [tools/code-writing.md](tools/code-writing.md) и `modes/*`): - **Не стартовать без запроса настроек** — при старте игры с нуля сначала запросить настройки и геймдизайн, только потом планирование и реализацию. - **Не создавать файлы памяти в корне** — только в `Docs/` (Docs/DEV_CONFIG.md, Docs/GAME_DESIGN.md, Docs/DEV_STATE.md, Docs/DEV_PLAN.md, Docs/AGENT_MEMORY.md). Не пропускать создание `Docs/AGENT_MEMORY.md`. - **Не создавать файл лога без времени в имени** — только `Docs/DEV_LOG/iteration-NN-YYYYMMDD-HHMM.md`, не `iteration-NN.md`. - Не хардкодить настройки — всё в SO. - Не забывать обновлять Docs/DEV_STATE, Docs/DEV_PLAN и файл итерации в Docs/DEV_LOG. - Не раздувать DEV_STATE (он должен быть маленьким). - Не блокировать разработку на отсутствии MCP; при недоступности MCP — спросить: помочь настроить или начать без них. - **Не забывать сохранять сцену** после изменений через Unity MCP (`manage_scene` action=save). - **Скриншоты:** сохранять в **Docs/Screenshots/** (подпапки iter-01, iter-02, ...). Агент **обязан просматривать** каждый сделанный скриншот (открыть изображение и проверить содержимое). Не отчитываться об успехе по скриншоту, не проверив его; если на снимке не то — зафиксировать проблему, повторить скриншот или исправить сцену. - **UI в runtime:** при создании UI из кода проверять наличие EventSystem в сцене; у кнопок добавлять компонент Button и выставлять у дочернего Text `raycastTarget = false` (см. [tools/code-writing.md](tools/code-writing.md) → «Unity UI (создание в runtime)»).