Как создать игру с помощью нейросети по методу OpenAI и где взять подписку на ИИ

4 сентября OpenAI выложила разбор того, как её модель собрала браузерную игру Void Explorer: 2048 звёздных систем, больше десяти тысяч планет, посадка на планету размером с Землю. Вот рабочий порядок, который из этого разбора вытаскивается, и что в нём переносится на проект попроще.

Разбор написан про космический симулятор, но сам порядок к жанру не привязан. Он ведь одинаково лёг и на вторую игру из того же материала - лодку по процедурному океану, и на третью, двумерную ролевую про подземную реку.

1. Описать опыт, а не функции.

2. Закрепить картинку до первой строчки кода.

3. Дать модели способ самой посмотреть на игру.

4. Жаловаться конкретно, по одной вещи за раз.

5. Мерить, а не спорить.

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

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

Начальное описание Void Explorer уместилось в абзац (разбор в блоге OpenAI для разработчиков). Смысл его такой: всё, что видно, должно быть достижимо; расстояния оставляем настоящими, а перемещение решаем через масштаб и скорость; хочу лететь из космоса в атмосферу и до самой земли; планеты бывают размером с Землю, значит нужен процедурный ландшафт и порционный рендерер.

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

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

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

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

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

Смысл шага прикладной. Словами «сделай красиво» договориться ведь нельзя, а картинкой можно: она фиксирует палитру, уровень стилизации и настроение до того, как в проект попадёт первый шейдер.

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

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

Что это даёт. Модель ну никак не сможет дальше чинить вслепую по вашему пересказу. Она запускает сцену, смотрит на неё, читает счётчики, находит место и правит код. Автор прямо советует делать эти инструменты рано - раньше, чем начнёт казаться, что они нужны.

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

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

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

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

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

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

Замены модели корабля сравнили по числам: было 119 вызовов отрисовки и 48 809 треугольников, стало 77 вызовов и 61 092 треугольника. Треугольников-то больше, зато вызовов меньше, и в той тестовой среде кадр стал быстрее. Тут же оговорка от автора: мерили в headless-браузере с программным рендерингом, так что число говорит о сравнении двух вариантов, а не о частоте кадров на настоящей видеокарте.

Дальше три оптимизации, каждая из которых началась с замера.

Дальние планеты генерировали одинаковую геометрию независимо от того, сколько пикселей занимают на экране. После привязки детализации к экранному размеру заглушка похудела с 51 200 треугольников до 7 040 при той же функции-генераторе.

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

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

Отдельно решили проблему подвисаний: генерацию ландшафта разбили на возобновляемые шаги с бюджетом около 4 мс на кадр. Большой кусок работы больше не обязан доделываться одним неразрывным блоком.

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

По выбранному концепту - четыре отдельных крыла, симметричная форма, розовые огни на законцовках - модель собрана в Blender в стиле игры. В исходнике 193 редактируемых меша, в экспорте 14 968 треугольников, сгруппированных в восемь непрозрачных материальных пакетов. Смысл группировки как раз в предыдущем шаге: детализация растёт, а вызовы отрисовки держатся под контролем.

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

TypeScript и Vite, рендеринг на Three.js. Стартовали на WebGL2, позже перешли на архитектуру Three.js WebGPU с нодовыми материалами и языком затенения TSL. Генерация ландшафта вынесена в веб-воркеры. Юнит-тесты на Vitest, браузерные на Playwright. Трёхмерные ассеты в Blender, локальная физика ходьбы на Rapier.

Набор вот самый обычный, и это важнее, чем кажется. Метод не требует закрытого движка: браузерная игра, открытые библиотеки, обычные тесты.

Расплывчатый бриф. «Сделай интересно» не конвертируется в архитектуру. Ограничение конвертируется: настоящие расстояния, непрерывный спуск, одна волновая модель на картинку и на физику.

Отсутствие способа посмотреть. Пока модель не может запустить сцену и прочитать счётчики, она правит по вашему пересказу, а пересказ ведь теряет половину условий.

Жалоба пакетом. Пять претензий в одном сообщении разъезжаются на пять поверхностных правок. Одна претензия с условиями воспроизведения работает лучше.

Оценка на глаз. «Стало тормозить» не проверяется и не опровергается. Девяносто интервалов кадров проверяются.

Ландшафт в Void Explorer лежит на карте высот: одна высота в каждой точке поверхности. Для больших планет это разумно, но пещер, навесов и разрушаемых тоннелей такая схема не даёт в принципе. Ограничение тут архитектурное, промптом его не обойти же.

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

И последнее. Решение о том, правильно ли ощущается результат, в этом методе остаётся за человеком. Модель закрывает код, ассеты и тесты; что чинить дальше, определяет тот, кто в игру играет.

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

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

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