Как я за 4 дня собрал 3D-игру с помощью нейросетей: пошаговый кейс от идеи до рабочей версии

За четыре дня с перерывами я собрал рабочий прототип кооперативной 3D-игры — космическую ферму, которую игроки должны защищать от монстров.

Причём сам игрок в бою не стреляет.

Он собирает ресурсы, носит воду, устанавливает растения, следит за базой и пытается успеть всё сделать до начала очередной волны.

Главный эксперимент был не в самой игре.

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

В результате я использовал несколько разных инструментов:

1. ChatGPT — для концептов, изображений и работы с идеей;
2. нейросеть для генерации и переработки визуальных материалов;
3. Tripo — для создания 3D-моделей;
4. Claude — для написания и ревью кода;
5. Godot — как игровой движок;
6. Python — для обработки файлов и генерации части звуков.

А сам я выступал скорее в роли продюсера и тестировщика: ставил задачи, принимал решения, проверял результат и исправлял то, что ИИ не мог оценить самостоятельно.

Именно это оказалось самым интересным.

Переключаться между разными сервисами не удобно, поэтому для тестов я использовал единый интерфейс, который работает в России и без всяких обходов, где доступны GPT Image 2, Claude, ChatGPT, Nano Banana Pro и другие модели в одном месте. 

Воспользовался токенами для теста и так же пользовался через интерфейс бота с телефона.  

Сначала я не стал писать код

Самая большая ошибка при работе с ИИ над сложным проектом — сразу написать:

«Сделай мне игру».

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

Поэтому первым этапом я сформулировал не техническое задание, а идею игры.

За основу взял смесь нескольких знакомых механик: ферма, выживание и кооператив.

Но добавил одно жёсткое ограничение:

Игрок не использует оружие. Всю оборону выполняют растения. Игрок занимается логистикой.

Это сразу создало игровой цикл.

Днём игрок:

1. собирает ресурсы;
2. покупает растения;
3. устанавливает их на ферме;
4. распределяет воду и энергию;
5. готовится к атаке.

Ночью появляются монстры.

И тут начинается самое интересное: игроку приходится бегать по базе и решать, куда сейчас важнее отнести ресурс.

Например, одно растение осталось без энергии, второе почти уничтожено, а третье находится на дальней части фермы.

Можно побежать чинить базу.

Можно зарядить сильное растение.

Можно попытаться спасти растение, которое вот-вот украдут.

То есть вместо привычного «персонаж стреляет во врагов» получается игра про приоритеты и управление ресурсами.

И это хороший пример того, где нейросеть полезна только после того, как человек сформулировал нормальную идею.

Шаг 1. Я попросил ИИ разложить идею на игровые системы

Вместо огромного запроса я дал нейросети задачу сначала спроектировать игру.

Пример промпта:

«Разложи эту игру на независимые системы разработки. Не пиши код. Сначала определи игровой цикл, ресурсы, типы объектов, экономику, врагов, растения, магазин, кооператив и условия победы/поражения. Разбей разработку на последовательные этапы так, чтобы после каждого этапа можно было запустить игру и проверить результат».

В результате идея превратилась из одного большого проекта в несколько блоков.

Например:

1. управление персонажем;
2. карта;
3. ресурсы;
4. растения;
5. враги;
6. строительство;
7. магазин;
8. интерфейс;
9. кооператив;
10. звук;
11. баланс.

Это принципиально изменило работу.

Вместо:

«Сделай игру»

получается:

«Сделай систему ресурсов → проверь → добавь растения → проверь → добавь врагов → проверь».

Именно такой формат оказался наиболее эффективным.

Шаг 2. Создаём визуальный стиль

Следующая проблема — графика.

Я не 3D-художник, поэтому делать десятки моделей вручную было бы бессмысленно.

Но и генерировать каждую модель независимо друг от друга нельзя.

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

Поэтому сначала я определил единый визуальный стиль.

Например:

«Stylized 3D sci-fi game, colorful low-poly environment, slightly exaggerated proportions, clean shapes, soft lighting, playful cartoon aesthetic, consistent materials, game-ready concept art».

После этого уже создавал отдельные объекты, используя предыдущие изображения как референсы.

Это важный принцип:

Сначала стиль → потом объекты.

А не наоборот.

Если делать наоборот, потом приходится переделывать половину проекта.

Шаг 3. Из 2D-концепта делаем 3D-модель

После того как подходящий персонаж или объект готов в 2D, я переводил его в 3D.

Для этого использовал Tripo.

Схема получилась простой:

идея → 2D-изображение → 3D-модель → анимация → Godot.

Например, сначала создаём концепт растения.

Потом передаём изображение в генератор 3D-моделей.

Получаем .glb, который можно импортировать в игровой движок.

И здесь появляется первое важное ограничение нейросетей.

3D-модель — ещё не готовый игровой объект.

Модель может:

1. иметь неправильный масштаб;
2. неправильно стоять на земле;
3. содержать лишнюю геометрию;
4. иметь странные названия материалов;
5. получить неидеальный риг;
6. содержать проблемы в анимациях.

То есть раньше художник или 3D-моделер делал большую часть работы руками.

Теперь часть этой работы выполняет ИИ.

Но появляется другая:

проверить, исправить и интегрировать результат.

Шаг 4. Передаём разработку Claude

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

Здесь нейросеть оказалась особенно полезной.

Но я не использовал её как обычный генератор кода.

Главный принцип был таким:

Нейросеть получает не отдельную функцию, а целую задачу с контекстом проекта.

Например, вместо:

«Напиши магазин».

Я давал задачу примерно такого уровня:

«Создай систему магазина для Godot. В магазине должны продаваться растения и помощники. У каждого объекта есть цена, описание и лимит покупки. После покупки стоимость списывается только после успешного создания объекта. Система должна работать в одиночной игре и быть подготовлена для последующего подключения мультиплеера. Сначала проанализируй существующую структуру проекта и перечисли файлы, которые необходимо изменить. Код пока не пиши».

И только после согласования структуры давал команду на реализацию.

Это сильно снижает количество хаотичного кода.

Что я понял: ИИ лучше работает «блоками»

Когда проект становится больше одного файла, появляется проблема контекста.

Допустим, есть:

1. магазин;
2. HUD;
3. система ресурсов;
4. растения;
5. мультиплеер.

Если изменить только одну функцию покупки, можно легко сломать связь с другой системой.

Поэтому я просил нейросеть перед изменением:

1. найти все связанные файлы;
2. объяснить текущую логику;
3. определить, что именно изменится;
4. только после этого внести изменения.

Пример промпта:

«Перед изменением кода найди все места проекта, связанные с системой покупки. Покажи зависимости между магазином, ресурсами, HUD и созданием объекта. Не меняй код, пока не убедишься, что понимаешь полный цикл покупки от нажатия кнопки до появления объекта на карте».

Это гораздо надёжнее, чем бесконечно отправлять ИИ отдельные куски кода.

Шаг 5. Создаём карту

Саму карту я не моделировал вручную.

Большую часть окружения можно создавать процедурно.

В Godot для этого использовал генерацию рельефа, растительности и объектов через код.

Получается интересный эффект.

Нейросеть не обязана рисовать каждую травинку.

Она может написать алгоритм:

«Создай участок 340×340 метров, сформируй рельеф, добавь возвышенности, центральную площадку под базу и размести растительность с разной плотностью».

После запуска движок уже генерирует окружение.

Это особенно удобно для объектов, которые должны повторяться.

Например:

1. трава;
2. камни;
3. кусты;
4. мусор;
5. небольшие декоративные объекты.

Один объект создаётся нейросетью, а затем код размножает его сотни раз.

И вот здесь ИИ действительно начинает экономить время.

Потому что мне не нужно было вручную расставлять тысячи объектов.

Шаг 6. Добавляем врагов

Следующим этапом я попросил нейросеть реализовать несколько типов врагов.

Но здесь я специально разделял:

данные врага и логику поведения.

Например, обычный монстр идёт к ближайшему объекту.

Другой тип может атаковать издалека.

Третий — иметь большое количество HP.

А ещё я добавил врага, который вообще не атакует.

Он подходит к растению и пытается его украсть.

Такой противник интереснее обычного «ещё одного монстра», потому что заставляет игрока принимать решение.

Шаг 7. Самая важная часть — тестирование

И вот здесь эксперимент стал намного интереснее.

На этапе создания контента ИИ был невероятно быстрым.

Но когда дело дошло до проверки игры, всё изменилось.

Нейросеть может посмотреть:

1. появился ли объект;
2. изменился ли счётчик;
3. работает ли кнопка;
4. существует ли нужный узел;
5. вызывается ли функция;
6. передаются ли данные.

Но она гораздо хуже понимает:

интересно ли играть.

Например, система может быть полностью рабочей технически.

Но игроку может быть:

1. скучно;
2. слишком медленно;
3. непонятно;
4. неудобно;
5. слишком сложно;
6. слишком легко.

И это невозможно полностью определить по коду.

Поэтому я разделил работу.

Нейросеть проверяет:

«Работает ли система?»

Человек проверяет:

«Хорошо ли работает система для игрока?»

Это оказалось одним из главных выводов всего эксперимента.

Баг, который показал ограничение ИИ

Один из самых показательных случаев произошёл с персонажем.

После импорта 3D-модели он визуально немного «парил» над землёй.

Первое объяснение было очевидным:

проблема в анимации.

Нейросеть предложила несколько вариантов исправления.

Но ни один не дал нормального результата.

Тогда я поменял подход.

Вместо:

«Попробуй ещё один способ исправить положение персонажа».

дал команду:

«Не исправляй проблему. Сначала докажи, откуда она возникает. Выведи в лог все доступные animation tracks, их типы, длительность и наличие position tracks. Отдельно проверь трансформацию root bone и костей стоп. Никаких предположений — только фактические значения».

И вот здесь проблема быстро стала понятной.

Нейросеть до этого пыталась исправить симптом, не доказав причину.

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

Это стало моим главным правилом работы с ИИ:

Если нейросеть не может объяснить проблему фактами — заставьте её сначала собрать данные.

Не:

«Попробуй починить».

А:

«Покажи, что именно сейчас происходит».

Это правило применимо далеко не только к разработке.

Как я использовал ИИ для ревью кода

После каждого крупного этапа я запускал отдельную проверку.

Пример промпта:

«Проведи статическое ревью текущего проекта. Не исправляй код автоматически. Ищи только логические ошибки: недостижимые ветки, неправильные условия, возможные null reference, списание ресурсов до успешного действия, RPC с неправильными параметрами, обращения к несуществующим узлам и функции, которые никогда не вызываются. Для каждого найденного места укажи файл, функцию, причину и возможный сценарий воспроизведения».

И это дало неожиданный результат.

Некоторые ошибки невозможно было заметить обычной игрой.

Код мог выглядеть нормально.

Игра запускалась.

Но определённая ветка никогда не выполнялась.

Это тот случай, когда нейросеть полезна не как программист, а как второй разработчик на code review.

Мультиплеер: здесь магии уже меньше

Кооперативную часть я также строил с помощью ИИ.

Но именно здесь стало особенно хорошо видно, что нейросеть не избавляет от инженерной работы.

В одиночной игре всё может работать идеально.

Подключается второй игрок — и внезапно:

1. один игрок не видит предмет;
2. второй не получает изменение HP;
3. объект появляется только у хоста;
4. действие выполняется дважды;
5. данные обновляются у одного клиента, но не у другого.

Причём некоторые сетевые ошибки могут вообще не сопровождаться понятным сообщением.

Поэтому для каждой сетевой механики я использовал отдельный сценарий проверки.

Например:

1. игрок 1 создаёт объект;
2. игрок 2 подключается;
3. игрок 2 должен увидеть объект;
4. игрок 2 взаимодействует с ним;
5. игрок 1 должен увидеть результат;
6. оба игрока перезапускают действие;
7. проверяется, не произошло ли двойное списание ресурса.

Получается не просто:

«Проверь мультиплеер».

А конкретная последовательность действий.

И чем сложнее система, тем важнее такая детализация.

Звук я сначала тоже хотел отдать ИИ

С эффектами получилось интересно.

Для части звуков я использовал процедурную генерацию через Python.

Например:

1. выстрел;
2. удар;
3. шаги;
4. интерфейсные клики;
5. сигнал предупреждения;
6. подбор предмета.

Почему не генерировать всё через отдельную нейросеть?

Потому что простой эффект иногда быстрее создать математически.

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

Плюс такой звук можно полностью контролировать.

Но для музыки подход уже другой.

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

простые SFX → процедурная генерация;

музыка и атмосфера → специализированные AI-инструменты.

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

Где я использовал агрегатор нейросетей

В процессе такого проекта возникает ещё одна проблема: приходится постоянно переключаться между разными инструментами.

Одна модель лучше работает с изображением.

Другая — с кодом.

Третья — с видео или звуком.

Четвёртая удобнее для конкретной задачи.

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

Но здесь действует тот же принцип, что и с остальными инструментами:

не существует одной «лучшей нейросети».

Есть модель, которая лучше подходит под конкретную задачу.

Что в итоге действительно ускорилось

Если убрать маркетинговое «ИИ сделал игру за четыре дня», картина получается гораздо интереснее.

Нейросети действительно очень сильно сократили время на:

1. Создание визуального контента

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

2. Написание типового кода

Системы, интерфейсы, обработка данных и большое количество повторяющихся операций генерируются очень быстро.

3. Работа с большим количеством файлов

ИИ не устаёт искать одинаковые изменения в десятках файлов и может быстро находить связанные участки проекта.

4. Первичное ревью

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

5. Прототипирование

Самое главное — теперь можно очень быстро проверить:

«А вообще эта идея работает?»

Раньше ради такого эксперимента нужно было сначала потратить много времени на производство.

Сейчас можно собрать прототип и понять, стоит ли развивать его дальше.

Но что нейросеть не заменила

Вот здесь, на мой взгляд, находится главный вывод.

ИИ не сделал меня ненужным.

Он изменил мою роль.

Я меньше занимался непосредственным производством и больше:

1. формулировал задачи;
2. выбирал направление;
3. проверял результат;
4. искал ошибки;
5. тестировал механику;
6. принимал продуктовые решения.

Именно поэтому я бы не формулировал результат как:

«Нейросеть сделала игру за четыре дня».

Правильнее:

«За четыре дня я смог организовать производство прототипа, используя несколько нейросетей как команду специалистов».

Это принципиально разные вещи.

Мой рабочий пайплайн сейчас выглядел бы так

Если повторять такой проект сегодня, я бы использовал примерно следующую схему:

1. Идея

Человек формулирует концепцию и ограничения.

↓

2. Дизайн

ИИ раскладывает идею на игровые системы и этапы.

↓

3. Концепты

Генеративные модели создают визуальные референсы.

↓

4. 3D

2D-концепты превращаются в игровые модели.

↓

5. Код

Claude или другая сильная coding-модель реализует системы блоками.

↓

6. Code review

Вторая проверка ИИ ищет логические ошибки.

↓

7. Сборка

Godot объединяет код, модели, звук и окружение.

↓

8. Человеческое тестирование

Я сам прохожу игру и проверяю то, что ИИ оценить не способен.

↓

9. Итерация

Нейросеть получает конкретный список проблем и исправляет их.

Что я понял после четырёх дней

Самый важный вывод оказался довольно простым.

ИИ уже способен очень сильно сократить стоимость производства цифрового продукта.

Но он пока не превращает сложную разработку в кнопку.

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

А взамен требует от человека другой компетенции.

Раньше разработчику нужно было уметь самому писать большую часть кода.

Теперь гораздо важнее понимать:

что именно попросить сделать;

как проверить результат;

как понять, что нейросеть ошиблась;

как разбить большую задачу на маленькие;

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

И это, пожалуй, главный сдвиг.

За четыре дня я не стал профессиональным 3D-художником, программистом, звукорежиссёром и геймдизайнером одновременно.

Но получил возможность работать с задачами всех этих специалистов через разные AI-инструменты.

И если раньше основной вопрос звучал:

«Что умеет эта нейросеть?»

то сейчас гораздо полезнее спрашивать:

«Какой этап моего производства я могу передать ИИ — и как буду проверять результат?»

Именно от ответа на этот вопрос зависит, станет ли нейросеть реальным инструментом бизнеса или останется просто ещё одним сервисом, который интересно попробовать.