Особенности MCP Unity или как сжечь 200 баксов за 2 недели

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

Я уже две недели активно использую MCP Unity в своих проектах. MCP это мост между программами вроде Unity, Blender или Unreal и средой, где вы работаете с ИИ например Cursor, Antygravity или Claude Code. Если вы разрабатываете игру на 3D движке, MCP становится практически обязательным инструментом.

Есть исключение - движок Phaser. Это по сути библиотека для HTML5, то есть для веб приложений, позволяющая делать 2D игры. В этом случае ничего дополнительно устанавливать не нужно. Вы можете писать, запускать и тестировать игру прямо внутри Cursor. Например HEXSTORM сделан именно так.

С Unity ситуация другая. Можно работать и без MCP, но тогда многие задачи придется делать вручную. Например создавать префабы или настраивать сцену. MCP сильно упрощает этот процесс для людей без опыта.

Современные ИИ модели умеют гораздо больше чем просто писать код. Они могут зайти в Blender, создать простую модель и сразу добавить ее в сцену. Или подключиться к генераторам вроде Tripo 3.1, получить модель оттуда через API, затем почистить ее в Blender и экспортировать в сцену Unity.

Но есть важный нюанс: все это стоит денег.

Когда я работал с HTML5, мне хватало подписки Cursor Ultra на месяц и даже оставался запас. При этом я не ограничивал себя в качестве моделей.

После перехода на Unity расходы выросли в разы. Связка Opus + MCP Unity за две недели полностью съела мою Ultra подписку ($200).

Важно понимать откуда берется такой рост расходов. MCP не просто отправляет один запрос к модели. Он постоянно взаимодействует с внешними инструментами, дергает API, передает контекст сцены, ассетов и состояния проекта. В результате одно действие может разбиваться на десятки мелких операций, каждая из которых стоит деньги

Кроме того при работе с 3D движками сильно увеличивается объем контекста. Модели приходится учитывать структуру сцены, компоненты объектов, зависимости ассетов и даже данные из Blender. Все это раздувает запросы и ускоряет расход токенов, особенно если вы не ограничиваете модель в действиях и даете ей свободу принимать решения.

В общем, если у вас совершенно нет опыта работы в Unity - рекомендую начать с Phaser и HTML5.

Ставьте 🔥 если информация была полезной.

Обновление Atlas Converter.

Привет, друзья!

Я немного обновил свой инструмент для создания анимаций из видеогенераций.

Atlas Converter - инструмент для художников, которые работают со спрайтами. Он позволяет загружать видео или PNG-секвенцию, убирать хромакей (зеленый фон), подбирать нужные кадры для цикла анимаций, и получать готовый атлас с заданными параметрами сетки. Добавлена возможность выгружать PNG-секвенцию для Unity за пару кликов. Экспорт в видео тоже есть, если нужен только кеинг. Параллельно можно пакетно обработать отдельные спрайты: подогнать размер, сдвинуть, наложить на фон и экспортировать. Всё в одном окне, без установки.

Скачать Atlas Converter [Win64]

В комментариях скину Readme.

И да, всё бесплатно, я работаю за ваши огонёчки под постами🔥

3D RTS за пару часов на новеньком Opus 4.7.

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

Сделать RTS, но за 3 промпта вместо 6 и в 3D!

У меня есть всего 3 сессии, поэтому я декомпозирую задачу следующим образом:

1. Необходимо подготовить почву для будущего проекта, поэтому первый мой промпт выглядит так. На тот момент я еще не знал, что 4.7 вышел, поэтому делал в старом 4.6.

Подготовь архитектуру для будущей RTS которая полностью напишется LLM-агентом.
Стек phaser+ts+vite+three.js.
Это простая 3d RTS где все ассеты - лоуполи и генерируемые.
Cоздай необходимые claude.md и skills добавь все необходимые для работы библиотеки.
Игра называется Freeport7 и по-сути это клон Starcraft, где есть 2 рассы. Все критические решения принимай сам.

2. После того, как архитектура готова - я делаю промпт для написания ядра и MVP через PlanMode.

Начинай проект, спланируй и делай до mvp.

3. Когда был готов MVP - смотри видео, я обратил внимание, что Claude Code обновился, и появился доступ к 4.7. Чем я и воспользовался для следующего промпта:

Значительно улучши все модели игры. Добавь VFX

Результат - можете оценить на видео. Следующим этапом можно нагенерить моделек и подтянуть оптимизацию.

Ставьте 🔥и закину билд на "поиграть".

Вайбкодим по взрослому.

Привет друзья! Месяцы экспериментов, большой проект HEXSTORM, десятки MVP (минимально играбельные прототипы) и много-много-много исследований привели меня к этому посту.

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

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

- Движок Phaser 3.9 - это набор библиотек, скачать тут. Версия именно эта, а не 4, потому что LLM знает ее лучше всего.
- TypeScript - на нем LLM будет писать основной код.
- Vite - это система сборки билда, она не обязательна, но LLM очень любит с ней работать.

Именно такой стек дает LLM-агентам возможность легко, быстро и без перерасхода токенов делать наши проекты. Никаких MCP, никаких внешних тулзов, все в одном окне. Но в каком? Поговорим об нашем главном инструменте:

Мой выбор это Cursor за $60 и Claude Code за $100 . В Курсоре я дергаю маленькие модели, получаю удобный интерфейс для работы и просмотра кода, а в Claude Code - большие модели Anthropic в разы дешевле, чем по подписке Cursor.

При этом Claude Code можно запускать прямо в Cursor (в терминале) и видеть с помощью команды /ide правки кода, как если бы вы просто выбрали модель в селекторе моделей.

Но если вы хотите экономить, можно даже обойтись одной только $20 Claude Code. Но мы будем использовать модель Opus, поэтому после 2-3 запросов придется ждать пару часов до обновления лимитов.

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

1. LLM-архитектура. Удобная и понятная для ИИ среда, в которой он будет работать.
Для создания подобной архитектуры мы пишем следующий промпт №1.

2. Сама игра. Наша первая цель создать MVP - основу игры, которую позже будем улучшать.
В промпте вам необходимо заполнить пропуски, можно на русском.
Промпт №2.

3. Инструментарий для редактирования.
Вишенка на торте. Unity-ценен тем, что можно все крутить ручками, двигать и менять масштабы объектов прямо в редакторе. Но тащить ради этого свой проект в Unity - не обязательно. Давайте пойдем в обратную сторону и перетащим часть функционала Юнити в наш проект, а именно Inspector. Добавим в наш проект функцию визуального редактирования всех параметров и элементов интерефейса.
Промпт №3.

Пример готового MVP по этим трем пунктам вы можете видеть на видео.

Хотел бы я, чтобы кто-то дал мне эту информацию год назад. Накидайте 🔥 если пост был полезным.

Издание App2Top.ru взяли у меня интервью.

Я с серьезным лицом чего-то там наговорил про соло-разработку, что ИИ может, а что не может.
Вопросы были интересные, если позовут - пойду ещё🤪

Ставьте -🔥 если вам такой формат тоже интересен.
[Смотреть на Youtube]

Игра из рилса.

Я стараюсь запрещать себе просмотр рилсов и шортсов, т.к. это дико тратит время впустую. Но иногда "срываюсь". И вот вчера нахожу такой рилс. И через мгновение уже загружаю Claude Code задачей.

~2 часа разработки и игра готова.

Поиграть можно тут: https://tearevo.com/quor

В какое удивительно время мы живём🔥

UPD: Подкрутил ИИ, напишите если сможете у него выйграть.

Как выстроить архитектуру проекта, в котором LLM не теряет контекст

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

Нюанс в том, что я очень кропотливо слежу за иерархией и архитектурой проекта.

И главное слово тут - декомпозиция.
Год назад я почти не использовал это слово, а сейчас стараюсь мыслить им при решении любой задачи. И декомпозиция — это не “разложить код по файликам”. Это способ думать о системе так, чтобы каждая её часть имела свою причину существовать.
Не одна огромная система, а множество независимых систем. Поэтому задача обычно попадает в ограниченную область. Игру сложно сломать одним неверным решением, потому что по сути вся игра это множество мини-игр, которые обмениваются друг с другом данными.
Думать декомпозицией - значит искать смысловые границы. Сложно? Ща объясню.

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

Хорошая декомпозиция позволяет думать локально. Ты можешь открыть одну подсистему и понять её правила, не загружая всю игру в голову.

Для человека это снижает усталость.
Для LLM - снижает потерю контекста.
Для проекта - снижает шанс, что правка кнопки сломает босса.

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

Хороший вопрос при проектировании: “Какие процессы в игре могут меняться независимо?”
Не “какие классы мне нужны”, не “как назвать папку”, а именно процессы.

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

Чтобы этого добиться, я придерживаюсь нескольких правил.
1. Делать карту проекта.
Нужен короткий файл, который объясняет: какие системы есть, где они лежат, за что отвечают и какие правила нельзя нарушать.
Это не документация ради документации, а навигация. Особенно когда проект растёт, а контекстное окно у LLM не бесконечное.
Это может быть claude.md, система skills или простой readme.txt, где описано, что где лежит.

2. Держать в голове иерархию проекта.
Можно не помнить каждую функцию, но понимать, где что лежит, обязательно.
Это нужно, чтобы видеть, когда LLM начинает писать функцию не в том файле. Такое бывает. Уверенно, красиво, неправильно.

3. Ограничивать размер файлов.
Я стараюсь держать файл в пределах 2000 строк. Если файл становится больше — пора смотреть, не смешались ли внутри разные ответственности.
Например, combat.js можно разбить на combat_logic.js и combat_visual.js.

4. Проверять модуль одной фразой.
Файл или модуль должен легко описываться одной фразой: “управляет волнами”, “рисует интерфейс боя”, “хранит прогресс”, “считает экономику”.
Если описание превращается в “делает это, это, это и ещё немножко вот это” — система расползается.

5. Не смешивать временное и постоянное
Debug-инструменты, тестовые режимы, редакторы, cheats и автотесты нужно держать отдельно от игровой логики.

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

6. Выносить визуал отдельно от логики
Логика должна решать, что произошло. Визуал - как это показать.

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

Ставьте🔥 если такой контент вам интересен. Мне есть много чего сказать на эту тему.

Сделал порт на Steam Deck.

В официальном твитере Phaser появился пост про HEXSTORM. Ребята говорят, что это одна из первых Phaser 4 игр в стиме.

Приятно быть первопроходцем, поэтому решил закрепить результат и сделать первую в мире phaser-игру с полной поддержкой Steam Deck и Steam input API.

В этот раз работал полностью в Cursor и GPT 5.5. Последнее время Claude 4.7 что-то много ошибается.

Оказалось не просто. Ожидал справиться за вечер воскресения, но пришлось повозиться еще 2 вечера. Steam Deck работает на Linux, а windows игры эмулирует через Proton.

Эмуляция в упор отказывалась дружить с windows версией NW.js. Точнее, игра запускалась, и прекрасно работала в режиме Touch Screen, но не видела органы управления приставки. Хотя с xbox-геймпадом такой проблемы не было.

В итоге решил сделать полный linux-билд. Загрузочный дистрибутив вырос в 2 раза.
Зато теперь игру можно запустить на глюкометре😂

И да, все заработало. Верно движемся к демке 27го мая

Поддержать проект можно, добавив игру в вишлист.
Или просто поставьте огонёчек под постом. Мне будет приятно🔥