Разработка игр стала новым бенчмарком для ИИ-агентов

Мы привыкли мерить прогресс AI-агентов по задачам вроде исправления багов в GitHub-репозиториях, написания Python-скриптов или фронтенда по макету. Но реальная разработка — особенно игровая — устроена куда грязнее и интереснее. Здесь мало просто сгенерировать функцию: нужно понимать сцены, иерархии объектов, спрайты, шейдеры, анимации, интерфейсы и то, как все это выглядит и движется на экране.

Когда AI умеет писать код, но не умеет «собирать игру»

Именно в эту болезненную, но крайне показательную зону бьет новая работа GameDevBench: Evaluating Agentic Capabilities Through Game Development. Исследователи из Carnegie Mellon, Princeton и других лабораторий предлагают первый бенчмарк, который оценивает, способен ли агент не просто «кодить», а решать полноценные задачи игровой разработки в современном движке.

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

Почему это вообще важно

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

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

Это делает GameDevBench чем-то средним между SWE-bench, задачами computer use и мультимодальным софтверным тестированием. Только ставка выше: если агент научится уверенно работать в игровом движке, это будет означать прогресс не только в кодогенерации, но и в более общем понимании цифровых сред.

Что такое GameDevBench

Бенчмарк построен на базе 132 задач для движка Godot 4. Источником стали веб- и видеоуроки по типичным игровым сценариям: от анимации персонажей и коллизий до UI, 2D/3D-графики, шейдеров и эффектов.

Авторы выбрали Godot по прагматичным причинам. Он open source, достаточно популярен, похож по рабочей логике на Unity и при этом проекты в нем удобно представимы в виде файлов и кода. Это важно: исследователям не пришлось изобретать экзотический API для действий в редакторе — многие задачи можно решать через правку файлов сцены и скриптов, а затем проверять автоматически.

Сами задачи заметно сложнее, чем типичные бенчмарки по software engineering. В среднем эталонное решение требует около 5 измененных файлов и 106 строк правок. Это больше чем втрое тяжелее по объему изменений, чем задачи из SWE-Bench, на который любят ориентироваться в индустрии.

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

Как они это построили

Методология у работы аккуратная и довольно практичная. Авторы не вручную сочинили сотню задач с нуля, а собрали их из реального обучающего материала сообщества Godot.

Сначала они отобрали уроки: YouTube-видео и веб-туториалы, обязательно с открытыми GitHub-репозиториями и совместимыми лицензиями. Затем транскрипты и код репозиториев использовались как сырье для автоматической генерации задач. Агенту поручали превратить tutorial в набор независимых, проверяемых подзадач: например, отдельно вынести анимацию, отдельно коллизии, отдельно UI.

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

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

Чем задачи в геймдеве отличаются от обычного кодинга

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

— понять, какой спрайт или набор кадров нужен для анимации;

— добавить узлы в правильное место дерева сцены;

— настроить физику, коллизии и сигналы;

— поправить код;

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

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

Авторы также делят задачи по навыкам: gameplay logic, 2D graphics and animation, 3D graphics and animation, user interface. А еще — по типу редактора в Godot: scene editor, script editor и контекстные редакторы вроде animation, shader или tilemap. Это важно для анализа: так видно не просто «какая модель лучше», а на чем именно она ломается.

Главные результаты: даже лидеры пока буксуют

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

Лидером оказался Gemini 3 Pro в своей нативной агентной среде с мультимодальной поддержкой. Следом — Gemini 3 Flash, Claude Opus 4.5 и Claude Sonnet 4.5. Но даже у них нет ощущения устойчивой зрелости: почти половина задач все еще остается нерешенной.

Особенно интересно распределение по типам задач. Лучше всего агенты справляются с gameplay-oriented сценариями — там средний success rate около 46,9%. Хуже всего — с 2D-графикой и анимацией, где успех падает до 31,6%. И это логично: когда нужно выбрать правильные спрайты, разобрать spritesheet, понять, какой кадр за что отвечает, текстового интеллекта уже мало.

Еще один важный вывод: падение качества по мере удаления от frontier-моделей очень резкое. Qwen3-VL-235B, который на некоторых визуальных бенчмарках чувствует себя достойно, здесь почти беспомощен. Это хороший сигнал рынку: успех на задачах типа “сверстай UI по картинке” плохо переносится на насыщенные мультимодальные инженерные среды.

Простая визуальная обратная связь неожиданно сильно помогает

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

Авторы протестировали два механизма:

— скриншот редактора через MCP-сервер, который дает модели картинку текущего состояния Godot;

— видео или запись игрового прогона, чтобы агент видел временную динамику и финальный camera view.

И это не декоративная опция. Например, Claude Sonnet 4.5 без дополнительной визуальной помощи решал 33,3% задач, а с видео — уже 47,7%. Это огромный скачок для одной, по сути, добавленной петли обратной связи. У Gemini 3 Flash лучший режим давал рост с 47,0% до 52,3%.

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

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

Где именно модели ошибаются

Авторы провели и качественный анализ ошибок, и он, пожалуй, не менее интересен, чем таблица метрик.

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

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

Именно здесь появляются характерные ошибки вроде той, что авторы показывают в кейс-стади: модель ставит корректное свойство sub_emitter не в тот объект. Формально она «знает нужные слова», но не понимает структуру движка на уровне инженерной практики. Это важный урок для всех, кто верит, что достаточно натренировать LLM на коде из GitHub — и она автоматически станет полноценным разработчиком игр.

Цена вопроса: качество против стоимости

Работа отдельно анализирует trade-off между ценой и качеством. Общая картина ожидаемая: мультимодальная обратная связь повышает стоимость задачи, но обычно повышает и шанс успеха. При этом самым выгодным по соотношению цена/результат оказался Gemini 3 Flash.

Интересно, что стоимость не всегда предсказуема по «цене токена» или размеру модели. Фреймворк агента тоже сильно влияет на итог. Одна и та же модель может показать заметно лучший или худший результат в зависимости от того, работает ли она в своем нативном CLI или через OpenHands. Это еще одно напоминание: в agentic AI важна не только сама модель, но и обвязка — инструменты, цикл наблюдения и способ редактирования среды.

Что из этого следует

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

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

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

Вывод

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

Для исследователей это важный сигнал: если мы хотим строить по-настоящему полезных автономных разработчиков, одних кодовых бенчмарков уже недостаточно. Для индустрии — тоже: «AI пишет код» еще не означает «AI умеет делать продукт». А для всех, кто следит за развитием агентов, GameDevBench дает, пожалуй, один из самых честных снимков состояния поля на сегодня.

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