Одним запросом создать 3D-игру: как проверять ИИ-кодера и оценивать результат

Тест на создание 3D-игры одним запросом проверяет не только умение модели писать код.

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

Сообщение о GPT-6 Astra, которая подготовила полноценную 3D-игру примерно за 45 минут почти за один проход, относится к пользовательскому эксперименту. Пользователь также сообщил о расходе лишь нескольких процентов доступной квоты. Такие наблюдения интересны для воспроизведения, однако сами по себе не заменяют независимый бенчмарк: без одинаковых условий, заранее заданных метрик и повторных запусков нельзя отделить возможности модели от особенностей конкретной среды.

Почему 3D-игра сложнее обычной генерации кода

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

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

В пользовательских демонстрациях Astra описывалась как модель, способная создавать трёхмерные миры, воксельные сцены, окружение, объекты и интерактивные сайты по одному запросу. Эти сведения характеризуют отдельные эксперименты автора и пользователей, а не универсальную гарантию результата для любого проекта, движка или браузера.

Как составить единый запрос

Хороший запрос задаёт не только тему игры, но и проверяемое поведение. Формулировка «сделай 3D-игру» оставляет модели слишком много свободы, поэтому разные запуски дадут несопоставимые результаты.

1. Среда запуска. Укажите браузер, один HTML-файл или структуру проекта, допустимые библиотеки и способ запуска без ручной настройки.
2. Сцена. Опишите размер игрового пространства, тип камеры, освещение, фон, рельеф, основные зоны и объекты, которые игрок должен увидеть.
3. Управление. Перечислите клавиши, мышь или сенсорные действия, а также поведение при нажатии, отпускании и повторном вводе.
4. Игровая цель. Задайте условие победы, поражения, ограничения по времени, сбор предметов, здоровье или другой измеримый результат.
5. Интерфейс. Укажите элементы HUD, стартовый экран, счётчик, сообщения об ошибках и состояние после завершения раунда.
6. Ограничения. Попросите сохранить работоспособность после перезагрузки, не использовать внешние файлы без необходимости и сообщить о невыполненных требованиях.

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

Что проверить после первого запуска

Код и запуск

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

Сцену и пространственную структуру

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

Управление и игровую логику

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

Интерфейс

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

Как считать время, итерации и ручную работу

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

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

Расход токенов или квоты записывают по данным интерфейса либо API. Сообщение о нескольких процентах доступной квоты нельзя переводить в универсальную стоимость без информации о тарифе, длине контекста, режиме модели, кэшировании и повторных запросах. В доступном описании GPT-6 Astra указаны поддержка генерации кода, инструментов и большого контекстного окна, однако эти характеристики не доказывают экономичность конкретного игрового эксперимента.

Единая шкала для сравнения моделей

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

Почему красивый прототип не равен готовой игре

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

Для production-разработки нужны дополнительные проверки: производительность на целевых устройствах, управление памятью, доступность интерфейса, сохранение состояния, безопасность загрузки ресурсов, лицензии ассетов и поведение при сетевом взаимодействии. Однофайловый браузерный прототип не следует сравнивать с полноценным проектом на Unreal Engine или Unity по одинаковым критериям, поскольку у таких продуктов различаются среда, архитектура и требования к проверке.

Показателен контраст с GameEngineBench, исследовательским бенчмарком для задач внутри работающих проектов Unreal Engine. В описанной методике проверяются не только изменения исходного кода, но и сборка, запуск в режиме Play in Editor, серверная авторитетность, репликация, жизненный цикл объектов и интеграция с существующими системами. В наборе 110 задач лучший результат достиг 55,5 процента pass@1, а 31 задача не была решена ни одной из проверенных конфигураций. Этот результат относится к другому классу задач, однако хорошо показывает, почему компилируемый код и эффектная сцена ещё не равны корректной игровой системе.

Как воспроизвести эксперимент без завышенных выводов

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

Вывод формулируют узко: «в этом сценарии модель создала запускаемый прототип с таким набором функций». Формулировка «модель умеет создавать полноценные 3D-игры одним запросом» требует значительно более широкой серии повторяемых испытаний, независимой проверки и описания неудачных запусков.

Частые вопросы

Можно ли считать пользовательскую демонстрацию бенчмарком?

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

Что важнее: скорость или отсутствие правок?

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

Почему сравнение по одному запросу полезно?

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