Build, наш новый инструмент для создания игр, ориентированный на мобильные устройства, позволяет пользователям Roblox создавать игры с помощью текстовых запросов и публиковать их для игроков по всему миру. Создание полноценной игры требует комплексной агентной системы: такой, которая координирует код, визуальные ресурсы, игровые системы, пользовательский интерфейс и элементы управления в единый сложный артефакт. Эта система должна надежно обрабатывать различные сценарии, возникающие при взаимодействии с игроками и в многопользовательских сессиях. С момента альфа-запуска в Новой Зеландии более 100 000 игроков использовали Build для создания игр, и было опубликовано около 9 000 игр. Из тысяч тех, кто использовал Build для создания игры, 71% никогда раньше не пользовались Roblox Studio, что показывает, что они пробуют нечто новое с помощью Build.

Но авторы будут использовать этот новый инструмент только в том случае, если он прост в обращении, а качество создаваемых им игр достаточно высоко, чтобы их можно было развивать дальше. Чтобы понять качество игр, созданных с помощью Build, мы оцениваем весь путь создания и используем эти оценки, а также отзывы авторов для улучшения продукта. Наша система оценки (eval) помогла нам расставить приоритеты и улучшить понимание намерений, 3D-играбельность и качество проработки. С момента альфа-запуска Build в Новой Зеландии удовлетворенность авторов выросла на 10%, количество непреднамеренных результатов снизилось с 18% до 3%, а публикуется около 14% сессий по запросам и 19% игровых тестов. Это описательные показатели прогресса, а не причинно-следственные оценки влияния исключительно системы оценивания.

Почему оценка создания игр отличается

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

Что отличает игры, так это то, что артефакт является исполняемой системой реального времени, управляемой игроками. Такие свойства, как отзывчивость, агентность, прогрессия и «ощущение игры» (game feel), возникают в процессе взаимодействия и не могут быть полностью оценены только путем проверки кода или ресурсов. Поэтому игра должна соответствовать уникально высокой планке низкоуровневой корректности (отсутствие дефектов и играбельность), а также высокоуровневого игрового опыта (игра, которая ощущается завершенной, а не прототипом).

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

Четыре сигнала, одна система

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

1. Качество спецификации игры (оценка 0–100): Build — это агент создания полного цикла: он переводит запрос автора в спецификацию, а затем использует ее для генерации игры. Оценщик проверяет, четко ли спецификация определяет важные решения, сохраняет ли замысел автора, учитывает ли осуществимость в среде выполнения Roblox и избегает ли выдумывания требований, которые не были выражены.

2. Статическое качество игры (оценка 0–100): Оценщик статического места проверяет сгенерированную игру в режиме редактирования Roblox Studio. Это включает структуру игры, скрипты, ресурсы, свойства, соединения и границы клиент/сервер. На этом этапе мы стремимся ответить на два вопроса. Первый — правильно ли построена игра: реализация необходимых систем, выбор API движка и сетевых решений, наличие ожидаемых элементов управления и интерфейса, надежность и согласованность архитектуры игры.

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

Разделение этих двух подходов и измерение по лучшим практикам дает нам более детальное представление о том, где игра не справляется.

3. Игровой тест (процент прохождения 0–100%): Оценщик игрового теста запускает игру и выполняет план тестирования с вводом, имитирующим действия реального игрока, включая нажатия, клики, клавиши и навигацию, вместо запуска событий из кода. План тестирования для каждого случая проверяет, запускается ли игра, реагирует ли она, прогрессирует ли, восстанавливается ли после сбоев и остается ли свободной от ошибок времени выполнения. Каждый пункт — это бинарный результат (пройдено/не пройдено), который сообщается как взвешенный по уровням процент прохождения вместе с вердиктом «играбельно/неиграбельно». Мы повторяем запуски для измерения стабильности.

4. Визуальное и эмпирическое качество (оценка 0–100): Некоторые из наиболее важных аспектов внешнего вида и ощущений от игры нельзя прочитать из кода, поэтому визуальный оценщик оценивает презентацию отдельно, используя захваченный игровой процесс на видовых экранах, представляющих разные устройства. Эта рубрика оценивает только то, как игра выглядит и звучит, основываясь на качестве ресурсов, проработке интерфейса, движении, освещении и звуке. Основной вопрос: выглядит ли игра как готовый к выпуску продукт или как прототип? Разделение визуальных эффектов и механики означает, что «код работает» и «игра выглядит завершенной» не усредняются в одну вводящую в заблуждение оценку.

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

Сигналы соотносятся с ошибками, которые они выявляют:

Сигнал

Типичная ошибка

Спецификация игры

Размытый цикл; отсутствие обработки сбоев/повторов или предположений об управлении на мобильных устройствах

Статическое место:

Инженерия и дизайн

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

Дизайн: Архитектурно чисто, но поверхностно; нет прогрессии, разнообразия или «крючка»

Игровой тест

Игра не запускается, не реагирует, не засчитывает очки, не восстанавливается или содержит ошибки времени выполнения

Визуальный

Работает правильно, но выглядит незавершенной, загроможденной или нечитаемой на телефоне

Прохождение курса 3D-обби по запросу

Сигналы легче всего увидеть на реальном запросе. Например: «Настоящая 3D-игра обби со стартовой платформой, движущимися препятствиями, контрольными точками и финишной чертой». Обби — популярный тип платформеров в Roblox. Замысел автора ясен, даже если он не предписывает каждую деталь реализации. Build должен заполнить детали разумными предположениями.

План и спецификация

Build подготовил документ спецификации для новой игры под названием Skyforge Ascent, подробно описывающий курс из пяти секций с контрольными точками и тремя типами препятствий. Он определил основной цикл, кривую сложности, художественное направление, экраны, наложения и элементы управления. Оценка спецификации составила 91/100, что принесло полные баллы за полноту, соответствие запросу, осуществимость и внутреннюю согласованность. Снижение оценки произошло по двум конкретным параметрам: детализация реализации и охват критериев приемки.

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

Статические проверки: качество кода и качество контента

Виртуальный судья проверил файл места Skyforge Ascent, не запуская его, и две оценочные линзы пришли к разным выводам.

Инженерная линза, прочитав тот же файл места, оценила его на 98/100. Она обнаружила образцовую сборку с пятью секциями и тремя движущимися опасностями, полностью соответствующую замыслу создателя благодаря использованию серверных последовательных контрольных точек, систем сброса при падении и пользовательского интерфейса, построенного на фреймворке StyleSheet. Все, что было указано в спецификации, было выполнено. Единственной проблемой были два неиспользуемых экспорта вспомогательных функций.

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

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

Плейтест

Агент для плейтеста прошел запущенную игру, используя ввод, имитирующий действия реального игрока, и выполнил все девять пунктов плана тестирования: появление персонажа на стартовой платформе, навигация по 3D-геометрии через провалы, получение урона от опасностей, активация контрольных точек и автоматическое восстановление после падения, завершение забега и перезапуск — и все это с нулевым количеством ошибок во время выполнения. В этом конкретном прогоне Skyforge Ascent набрала 100/100 на плейтесте.

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

Визуальное качество

Наконец, система оценки оценила записанную сессию на видовом экране размером с телефон для визуальной презентации. Skyforge Ascent набрала 86/100: чисто, целостно и вполне соответствует визуальному стилю типичного обби; читаемая геометрия платформ; разборчивые опасности; современный, ненавязчивый HUD. Незначительные визуальные ограничения не дают ей стать идеальной, но нет ничего сломанного и ничего такого, что заставило бы игрока прекратить прокрутку.

Метрики трассировки

Тот же прогон также записал метрики процесса. На сборку игры ушло около восьми минут, ошибок инструментов не было, а Build использовал навыки 3D, UI, редактирования скриптов, вставки ассетов и игрового аудио. Эти метрики не влияют на оценку напрямую, но они показывают нам, как была создана игра, и позволили бы отметить будущую сборку, которая стала медленнее или дороже без какой-либо выгоды.

На пяти этапах Skyforge Ascent получила разные оценки по спецификации игры, качеству кода, качеству контента, плейтесту и визуальному качеству. Четыре из этих измерений говорят о том, что Build может превратить один промпт в полноценный, корректный, играбельный и презентабельный опыт Roblox. Одно измерение говорит о том, что это не та игра, в которую кто-то захотел бы сыграть дважды. Измерение этого разрыва, а не его усреднение, — это и есть главная цель оценки Build.

Как ранняя оценка улучшила Build

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

Быстрое решение проблем создателей альфа-версии: В нашем альфа-запуске в Новой Зеландии пользователи дали нам обратную связь, что Build иногда создавал 2D-игру, когда они хотели 3D-игру. Фреймворк оценки помог нашей команде быстро улучшить 3D-возможности Build. В течение двух недель мы улучшили способность Build понимать намерение пользователя создать 3D-игру — даже если они не заявляли об этом явно. Мы также усовершенствовали 3D-играбельность и полировку, исправив распространенные проблемы с позиционированием объектов, освещением и т.д. С тех пор жалобы «не то, что я хочу» снизились с 18% до 3% среди всех жалоб; общая неудовлетворенная реакция после плейтеста снизилась на 10 процентных пунктов. Мы также накопили знания при итерации самого фреймворка.
Сравнительный бенчмаркинг моделей и архитектур: Мы используем наш фреймворк оценки для тщательного бенчмаркинга конфигураций системы Build по стандартизированным наборам промптов. Перед отправкой изменений в продакшн, автономные отчеты A/B оценки сравнивают релизы-кандидаты с нашими продакшн-базовыми линиями по всем четырем измерениям:

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

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

Prod vs. Candidate

Плейтест

Визуальное

Контент

Модель 1 vs Модель 2

+7.6

+9.0

+5.2

Один агент vs два агента

-11.2

-13.2

0.1

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

Набор

Плейтест

Визуальное

Контент

Ранний набор 2D-игр

75.9

67.1

19.2

Текущий набор 3D-игр

51.5

66.3

33.9

Выявление узких мест, специфичных для жанров: Данные оценки также подчеркивают значительные различия в производительности между жанрами. Жанры с упором на игровой процесс (например, RPG, шутеры, гоночные игры) склонны сталкиваться с большим количеством проблем с играбельностью. Жанры с относительно простой логикой (например, симуляторы выживания и тайкуны) часто показывают лучшие результаты в ходе плейтестов, что делает визуальную полировку и дизайн пользовательского интерфейса следующей задачей на пути к решению. Понимание различий между жанрами побуждает нас расширять наш набор оценок за счет более сбалансированной выборки игр на платформе Build.
Уроки, извлеченные при разработке инструментария оценки: Итеративная доработка самого фреймворка преподала нам важные уроки о надежности средств тестирования:
Системные метрики против метрик компонентов: Четкая структура кода или использование API не гарантируют играбельность игры. Мы разделяем корректность, дизайн и презентацию, чтобы избежать скрытия устранимых багов.
Слабые места инструментария и калибровка по человеку: Статические проверки могут упускать критические баги во время выполнения, приводящие к сбоям в игре, в то время как автоматизированные плейтесты испытывают трудности со сложной физикой. Виртуальные судьи постоянно калибруются на основе оценок профессиональных разработчиков игр и опытных рецензентов из сообщества.
Расширение до многошаговых сценариев и реального трафика: Поскольку реальные создатели постоянно дорабатывают свои проекты (добавляют системы, настраивают сложность, исправляют баги), мы расширяем наш комплекс оценки для анализа многошаговых правок и реальных распределений промптов.

Что дальше

В настоящее время мы сосредоточены на расширении нашей системы оценки создания Build в пяти направлениях:

Более широкое покрытие жанров, 2D/2.5D/3D-опыта, многопользовательских сценариев и уровней сложности
Усиленная поддержка многошаговых правок
Более надежные свидетельства из плейтестов, скриншоты, видео- и аудиоматериалы
Масштабируемая калибровка по оценкам людей и эталонные кейсы от создателей
Лучшая интеграция между офлайн-оценкой, онлайн-сигналами продукта и регрессионным тестированием

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

Связанный материал об оценке агентных систем для Roblox Assistant см. в статье Using OpenGameEval to Benchmark Agentic AI Assistants for Roblox Studio.

На основе данных по состоянию на 1 сентября 2026 г.

По состоянию на 29 августа 2026 г.