Я делаю игру с помощью ИИ. Но не прошу ИИ сделать мне игру

Сейчас вокруг AI‑разработки игр происходит странная вещь. С одной стороны, появились инструменты, с которыми один человек действительно может делать то, для чего раньше требовалась небольшая команда. Код, графика, анимация, исследования, прототипирование — всё это стало в разы доступнее.

С другой стороны, интернет постепенно заполняется проектами, которые выглядят примерно так: «Я написал два промпта — и нейросеть сделала мне игру». После этого появляется вполне предсказуемая реакция: кому вообще нужна игра, которую никто толком не придумал?

И с этой критикой мне сложно спорить. Потому что если попросить AI придумать игру, сделать графику, написать код, придумать баланс и решить, зачем игрок должен во всё это играть, результат действительно очень легко превращается в то, что сейчас любят называть AI slop.

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

Глава 1. Я вообще не разработчик игр

Я пришёл в этот проект не из gamedev. Моя профессиональная область — 3D и автоматизация производственных процессов. Поэтому в начале разработки я довольно быстро столкнулся с огромным количеством вещей, в которых раньше просто не разбирался.

Какой движок выбрать для 2D‑игры? PixiJS? Phaser? Что между ними принципиально отличается? Как организовать frontend? Какой нужен backend? Как потом превратить игру в мультиплеерную? Где должна находиться игровая логика? Что должен считать клиент, а что сервер?

Раньше, чтобы нормально разобраться хотя бы в одном таком вопросе, пришлось бы несколько дней читать документацию, статьи, Stack Overflow и чужие проекты. Теперь я могу провести это исследование вместе с AI.

Но здесь есть важный нюанс. Я не спрашиваю: «На чём мне сделать игру?» Я пытаюсь понять, какие существуют варианты, чем они отличаются, какие у каждого ограничения и что подходит именно моей архитектуре.

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

Глава 2. ИИ хорошо считает. Но сначала нужно придумать, что считать

Одна из базовых систем моей игры — экономика городов. На карте существует около двадцати городов. Условно каждый начинает примерно с одинакового экономического уровня, но находится на разных территориях. А территории отличаются ресурсами.

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

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

Саму идею этой механики мне AI не придумал. Это моя конструкция. Но дальше начинается намного более интересная проблема. Как понять, что будет с этой системой через несколько игровых лет?

У нас двадцать городов. Разная география. Разные наборы ресурсов. Разная скорость развития. Торговля. Изменение цен. Потребление. Рост населения. В какой‑то момент количество возможных комбинаций становится огромным.

Человек может придумать правила. Но проверить вручную несколько миллионов вариантов поведения системы практически невозможно. И вот здесь AI становится действительно мощным инструментом.

Я определяю:

• какие параметры существуют;

• какие зависимости между ними действуют;

• какие ограничения нельзя нарушать;

• что мы считаем нормальным развитием;

• какие результаты считаются проблемой.

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

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

Глава 3. Первая проблема генеративной графики: она ничего не помнит

С графикой произошло примерно то же самое. Игра у меня двухмерная, с видом сверху в изометрической перспективе. Допустим, мне нужно сто зданий. На первый взгляд кажется, что AI здесь вообще решает половину разработки. Генерируй здания — и всё.

На практике всё гораздо веселее. Я создаю первое здание. Хорошо. Создаю второе. Оно тоже хорошее. Третье — красивое. А потом ставлю их рядом.

И оказывается, что первое снято условно с высоты десяти метров. Второе — с двадцати. У третьего вообще другая перспектива. Один дом визуально повернут чуть сильнее. У другого свет идёт справа. У третьего слева. Двери разного масштаба. Этажи разной высоты.

Каждая отдельная картинка может выглядеть прекрасно. Но вместе они не являются одним миром. И в этот момент можно начать бесконечно улучшать промпт. Я выбрал другой путь.

Глава 4. Вместо лучшего промпта — Blender

Я решил, что AI вообще не должен самостоятельно определять перспективу. Для каждого здания сначала создаётся простой 3D‑каркас. Не красивый. Без текстур. Фактически просто объём. Он строится в Blender в сцене с заранее заданной камерой.

Если здание занимает две клетки — создаётся объём размером в две клетки. Если шесть — в шесть. Если оно выше — меняется высота. Но камера, перспектива и базовые пространственные правила остаются теми же.

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

Теперь AI не нужно объяснять: «Пожалуйста, сделай точно такую же перспективу, как на предыдущих сорока картинках». У него уже есть перспектива. Я её ему дал.

Потом этот процесс можно превратить в skill. И в следующий раз я уже не объясняю всю последовательность заново. Я просто говорю: «Создай здание 3×4 клетки такого типа». А внутри происходит заранее определённая цепочка действий.

• Создать каркас.

• Выставить размеры.

• Использовать нужную камеру.

• Применить правила конкретного города.

• Соблюсти направление света.

• Сгенерировать изображение.

• Проверить результат.

В итоге появляется возможность сделать не одно красивое AI‑здание, а сотню ассетов, которые действительно принадлежат одной игре. Более того, одно здание может существовать в нескольких стадиях:

• фундамент;

• стройка;

• почти завершённое состояние;

• готовое здание;

• улучшенная версия.

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

Но прежде чем запускать такой процесс для конкретного города, нужно понять, каким я вообще хочу его видеть. Для каждого города я собираю мудборд: архитектура, материалы, цветовая палитра, крыши, дворы, растительность. Смотрю, что мне нравится, а какие детали хочется изменить. Где‑то убрать лишний декор, где‑то добавить больше зелени, где‑то совсем иначе решить силуэт здания.

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

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

Глава 5. Новый город — это уже не новая работа с нуля

Самое интересное начинается после того, как такой pipeline существует. Допустим, первый город готов. У него определённая архитектура. Свои материалы. Форма крыш. Окна. Декоративные детали. Цветовая палитра.

Теперь мне нужен второй город. И мне не нужно заново придумывать процесс производства ста зданий. Я меняю художественные правила. Например:

• вот новый референс;

• здесь больше белого камня;

• другой тип крыши;

• больше синего;

• другая растительность;

• другая архитектурная школа.

Но сама производственная система остаётся. То есть AI позволяет мне масштабировать уже мой способ решения задачи. И для меня это гораздо интереснее самой генерации изображений.

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

Глава 6. С персонажами всё сломалось точно так же

Похожая история произошла с людьми. Мне нужны маленькие 2D‑персонажи, которые ходят по дорогам города. Казалось бы, ещё одна идеальная задача для генеративного AI. Создаём человека. Потом второго. Потом третьего. И снова получаем хаос.

У одного камера выше. У второго ниже. Один крупнее. Другой мельче. Они по‑разному стоят. AI прекрасно создаёт персонажей. Но мне не нужны просто персонажи. Мне нужны ассеты одной игровой системы.

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

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

В какой‑то момент появилась довольно забавная техническая деталь. На земле рядом с персонажем рисуется стрелка. Игрок её, конечно, никогда не увидит. Она существует только в производственном процессе. Стрелка говорит следующему этапу системы: вот направление движения этого персонажа.

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

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

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

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

То есть теперь команда: «Сделай нового жителя города» для системы означает уже не генерацию случайного человека. За этой фразой стоит последовательность технических операций, которую я сам придумал.

Глава 7. В какой‑то момент я почти перестал думать о промптах

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

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

Повторяющееся требование должно становиться правилом. Правило — частью pipeline. Pipeline — инструментом. А инструмент уже можно использовать снова.

Получается странный парадокс. Со стороны AI‑разработка часто выглядит как бесконечный разговор с чат‑ботом. На практике мой процесс постепенно всё больше начинает напоминать обычное производство.

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

Глава 8. Так кто же тогда автор?

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

Для себя я пока нашёл довольно простой ответ. Авторство находится не там, где выполнена операция. Авторство находится там, где принято решение.

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

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

Вместо заключения

Поэтому мне кажется немного странным делить игры только на две категории: «сделано человеком» и «сделано AI». В реальности появляется огромная область между ними.

Можно написать один промпт: «Сделай мне стратегическую игру про Древнюю Грецию». Получить что‑нибудь работающее и действительно практически не иметь отношения к результату. А можно месяцами проектировать механику, визуальный язык, экономику, pipelines, ограничения и правила — используя AI как инструмент реализации.

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

Наверное, поэтому меня сейчас гораздо меньше интересует вопрос: «Сколько процентов этой игры сделал AI?» Гораздо интереснее другой: «Кто решил, какой эта игра должна быть?»

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

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