Самодельный воксельный редактор с иерархией, префабами, импортом популярных форматов и MCP-интеграцией вырос до 301 коммита, 839 C#-файлов и примерно 130 тысяч строк кода. Но инструмент для ручной сборки ассетов оказался в странной позиции: пока автор решал привычные проблемы геймдев-инструментов, ИИ стал заметно лучше справляться с исходной задачей — созданием моделей.
Историей разработки, по данным Habr / Новости, поделился автор под ником Geek_and_Cat. Он делает неанонсированную игру с кубической стилизацией и хотел собрать для неё модель маневрового тепловоза ЧМЭ3. В статье слово «воксельный» используется скорее как описание визуального языка: кубы в игре и редакторе рисуются обычными мешами, а не как строгая техническая воксельная сцена.
Сначала автор попробовал обойтись готовыми инструментами. Для ручной работы он выбрал бесплатный открытый Goxel: тот показался ему ближе к инженерному подходу, чем MagicaVoxel. Однако быстро проявились ограничения: нельзя было загрузить полигональную модель как основу для обводки, материалы и слои работали неочевидно, а стабильность вызывала вопросы. Главным же был не набор отдельных недочётов, а разница в модели мышления. Goxel и MagicaVoxel устроены как трёхмерные графические редакторы со слоями и группами, тогда как автору, привыкшему к Unity, нужны были иерархия объектов, компоненты и префабы.
Можно было освоить существующий софт или посмотреть в сторону Qubicle, который ближе к такой логике. Но у Qubicle есть лицензионные ограничения, а часть нужных возможностей поставляется отдельными платными модулями. На этом месте в проект вошёл агентный ИИ: автор решил не приспосабливаться к чужому редактору, а собрать свой под конкретный производственный процесс.
Перед разработкой он проверил и альтернативный сценарий: попросить нейросеть сделать сам ассет. Ранние эксперименты с Claude Opus 4.5 и Haiku 4.5 строились вокруг Python-скрипта, генерирующего модель. Запрос «сделай воксельный локомотив ЧМЭ3» дал лишь очень приблизительные результаты: одна модель выдала похожий на капотный тепловоз объект, другая — нечто вроде электрощита, лежащего на боку. Уточнение размера вокселя до 45 мм ситуацию почти не исправило.
Даже фото и 3D-модель со Sketchfab не дали точного результата. Opus стал ближе к референсу, но не воспроизвёл ЧМЭ3; Haiku ушёл в более абстрактную геометрию. Попытки просто превратить готовую полигональную модель в воксельную тоже, по оценке автора, давали «кашу». Это важная оговорка: решение написать воксельный редактор не было самоцелью. На момент первых экспериментов генерация не обеспечивала нужную управляемость и качество.
Основой собственного приложения стал Godot. Выбор выглядел прагматично: лёгкий движок и знакомый автору C#. Архитектуру он задал в стиле привычного игрового проекта — MVP, разделённые слои, модель, которая сообщает о событиях, не зная деталей представления. Затем начался характерный для агентной разработки этап: задачи формулировались для ИИ, а код зачастую не требовал постоянного ручного чтения, потому что функции появлялись быстро.
Узким местом оказался уже не темп написания кода, а проектирование поведения самого продукта. Автору приходилось решать вопросы, которые агент не снимет готовой реализацией: сколько режимов нужно трансформации, что означает привязка к целым клеткам при повороте модели на 37 градусов, куда девать воксели при уменьшении сцены, что именно выделять кликом внутри префаба — вложенную модель или родительский объект. ИИ ускоряет реализацию решения, но не формулирует продуктовую семантику за владельца инструмента.
В итоге редактор получил иерархию, префабы, симметрию, материалы, несколько режимов полей трансформации, импорт из MagicaVoxel и Qubicle, экспорт в OBJ, STL, FBX и vox, собственный рендеринг и консольный режим. Это уже не набросок на выходные. Отдельный рабочий журнал, который вёл агент, занял 5 886 строк: в нём фиксировались ошибки, причины и результаты проверок.
Особенно показателен подход к MCP. Работая с агентами в Unity, автор столкнулся с банальной, но болезненной проблемой совместного доступа: человек и агент одновременно управляют одним редактором, и непонятно, завершилась ли задача или процесс завис. В собственном приложении это заложили в интерфейс: во время работы агента появляется статусная плашка с темой задачи, окно затемняется и блокирует ручные действия. Остаётся аварийная остановка, а при бездействии агента срабатывает тайм-аут. Для команд, которые постепенно пускают ИИ в рабочие IDE и редакторы, такая деталь может оказаться ценнее очередной кнопки генерации.
История не доказывает, что каждому игровому проекту нужен свой воксельный редактор. Скорее она показывает сдвиг в экономике внутренних инструментов: агентный кодинг сделал создание специализированного софта дешевле, но одновременно улучшил альтернативу — генерацию контента. В результате главным активом становится не количество написанных строк, а понимание, какую часть процесса ещё действительно нужно фиксировать в интерфейсе, а какую уже выгоднее отдать модели.
