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

Ожидание наконец-то закончилось! Shadow Blade Zero вышел!

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

Через три недели закончится ещё одно долгое ожидание: релиз GTA 6 запланирован на 19 ноября.

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

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

Когда вышла игра Claude Opus 5.5, Anthropic специально продемонстрировала результаты работы различных моделей, создающих игры на основе одной и той же задачи, заявив, что Opus 5.5 получила наивысшие оценки по графике и полноте. OpenAI представила вычислительные возможности GPT-6 Astra, также подчеркнув важность разработки игр в своих демонстрациях; один из разработчиков использовал его для создания играбельной версии исторического Лондона.

После выхода Kimi K3.1 Pro сообщество сравнило время создания, цену и конечные результаты с результатами Claude , GPT и DeepSeek, создавших шутеры от первого лица, игры про фермерство, гонки и лабиринты. Недавно выпущенная Genie 4 официально описывается как «интерактивный мир», «симуляция в реальном времени» и «исследуемый прототип», но при ближайшем рассмотрении она по-прежнему очень похожа на игру.

Традиционный подход после выпуска модели заключается в её бенчмаркинге; сейчас всё больше людей предпочитают, чтобы она использовалась для создания игр. Конечно, это не *Shadow Blade Zero* или *GTA 6*. Но интересно то, почему компании, занимающиеся разработкой ИИ, всё чаще предпочитают сначала использовать модель для создания игры, когда им нужно доказать её возможности?

Как получилось, что странная птица стала моделью для эксперимента?

28 октября независимый разработчик Саймон Уиллисон сделал прогноз относительно этих изменений: в ноябре 2025 года Code Agent преодолеет порог «становления повседневным инструментом для программистов», а в октябре 2026 года эта модель преодолеет еще один порог — переход к разработке игр.

Этот метод презентации имеет более простой предшественник.

В 2024 году Саймон Уиллисон начал тестировать различные модели, используя одну и ту же задачу: «Сгенерируйте SVG-изображение пеликана, едущего на велосипеде», и модели должны были напрямую писать SVG-код, составляющий изображение, а не просто предоставлять картинку.

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

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

«Тест Пеликана» не является строгим эталоном; он выполняется только один раз, не имеет стандартизированного контроля над скоростью вывода, стоимостью и инструментами и не может доказать, какая модель демонстрирует наилучшую общую производительность . Его популярность обусловлена ​​тем, что он не требует объяснений. Разумность пространственных отношений и правильность преобразования кода в изображение становятся очевидны сразу.

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

Сколько способностей скрыто в игре?

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

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

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

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

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

Почему именно браузерные игры?

Большинство игр в новых демоверсиях не являются полноценными клиентами, требующими установки, а представляют собой браузерные разработки, созданные с использованием HTML, JavaScript, Three.js или Phaser.

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

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

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

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

От "как игра" до "действительно весело"

Последние изменения касаются не только улучшения возможностей моделей в плане программирования. Саймон Уиллисон считает, что Claude Opus 5.5 начинает демонстрировать некоторые возможности в области игрового дизайна, которых не хватало в предыдущих моделях.

Используя стандартный интерфейс чата Claude и всего одну подсказку, он создал «Ценителя деревьев». На экране отображаются два немного отличающихся друг от друга 3D-дерева, расположенные рядом, и игроки могут вращать и увеличивать изображение, чтобы обнаружить едва заметные различия, такие как птицы, белки или листья; после завершения дерево добавляется в виртуальную коллекцию образцов.

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

Другой проект, *Battle Drones*, ещё нагляднее иллюстрирует разницу. Ранние версии, созданные Claude Фэйблом 5, уже включали сбор ресурсов и сражения, похожие на *Command & Conquer*, но Уиллисон счёл их неинтересными. Он просто попросил Opus 5.5 «сделать игру намного интереснее», а позже перенёс её на Three.js. Теперь игра может похвастаться сражениями для двух-четырёх игроков, семью картами, медалями, возможностью повторов, случайной сменой карт и модификатором, который может изменять правила.

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

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

Трехмерная городская игра "Neon Palms", созданная Claude Опусом 5.5, изначально появилась на основе игрового бенчмарка. В видеоролике игроки могут управлять автомобилем и исследовать неоновый город; все кадры взяты из работающей программы, а не сгенерированы.

Однако результат не был получен «в один клик». Весь проект длился с 26 по 28 сентября, агент работал в одиннадцать раундов, всего было выполнено 69 запусков, при этом одновременно работало максимум шесть агентов. Согласно общедоступным данным, модель обработала приблизительно 4,07 миллиарда токенов, подавляющее большинство из которых представляли собой кэшированные контексты, выдав около 3,2 миллиона токенов. Исходя из цены API, стоимость разработки оценивалась примерно в 1512 долларов. В демонстрационном видео также использовалась более поздняя версия с незначительными визуальными исправлениями и специальным режимом отображения; сам бенчмарк по-прежнему фиксирует многочисленные ошибки.

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

Более систематический тест GameCraft-Bench дал аналогичные выводы. Он требовал от агента, управляющего кодом, выполнения 140 игровых заданий в Godot на основе естественного языка. Оценка не только проверяла код, но и фактически запускала программу, воспроизводила действия и наблюдала за производительностью игры. На момент публикации статьи общий процент выполнения заданий самым сильным агентом составлял всего 41,46%. Модель отлично справлялась с быстрым созданием впечатляющих прототипов, но еще не могла последовательно выполнять все правила, обратную связь и визуальные требования.

Лучший способ для моделей "продемонстрировать свои мышцы".

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

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

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

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