Может ли ИИ построить головоломку целиком? ScriptDoctor и его цикл «генерируй — тестируй — чини»

Введение

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

Статья — ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search, выложенная на arXiv 6 июня 2025 года. Она написана в соавторстве семью исследователями — во главе с Сэмом Эрлом из Нью-Йоркского университета, с коллегами из Университета Мальты, Университета Витватерсранда и Microsoft — и была подана как краткая статья на конференцию IEEE Conference on Games (CoG). Один из авторов, Джулиан Тогелиус, — среди известнейших фигур в исследованиях процедурной генерации контента.

Почему именно эта статья первой? Потому что её предмет — PuzzleScript. Выпущенный Стивеном Лавеллом (increpare) в 2013 году, этот крошечный предметно-ориентированный язык описывает целую игру в духе сокобана — правила, спрайты и уровни — в несколько десятков строк текста, и инди-разработчики по всему миру, включая Hempuli из Baba Is You, использовали его для прототипирования. Мир, знакомый читателям этого сайта, здесь становится лабораторией.

Проблема: как проверить, что «ИИ сделал игру»?

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

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

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

Метод: цикл генерации, осмотра и починки

ScriptDoctor — это, одной фразой, цикл «генерируй — осматривай — чини». LLM (в экспериментах GPT-4o, o1 и o3-mini) пишет полную программу на PuzzleScript — определения объектов, правила, условия победы, уровни. Её промпт подбит документацией PuzzleScript, примерами, взятыми из базы 610 написанных людьми игр, и дизайнерскими идеями, выработанными отдельным агентом «мозгового штурма».

Осмотр происходит в две стадии. Сначала компиляция: сгенерированный код проходит через движок PuzzleScript, и любые ошибки или предупреждения отскакивают прямо обратно к LLM. Парсер, построенный из контекстно-свободной грамматики PuzzleScript (написанный с помощью библиотеки Python Lark), помечает также синтаксические ошибки.

Если код компилируется — стадия вторая: машина действительно играет. Поиск в ширину (BFS) — методичный, почти исчерпывающий поиск, проверяющий сначала неглубокие ходы, — исследует каждый уровень вплоть до миллиона уникальных состояний и сообщает три числа: решаем ли он, насколько длинно решение и сколько состояний было осмотрено, чтобы его найти. Эти числа подаются обратно в LLM через сервер.

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

Находки: примеры помогают, рассуждающие модели выигрывают и «сломано, но интересно»

Сначала самый ясный результат. Без сделанных людьми примеров (zero-shot) лишь 30% игр GPT-4o компилировались, и у 0% был уровень, который поисковый агент мог решить. Вставь примеры в промпт (few-shot) — и компиляция подскакивает до 70–80%, причём более чем у половины игр появляются решаемые уровни. PuzzleScript — не крупный язык вроде Python, так что отработанные примеры имеют решающее значение — авторы отмечают, что это не удивило даже их.

Сравнение моделей не менее интересно. При одинаковых условиях few-shot и 10 тыс. токенов, по десять игр каждая: GPT-4o компилировался в 67% случаев, рассуждающая модель o1 — в 87%, o3-mini — в 93%. По «все уровни решаемы» лучшим был результат o3-mini в 20%. Модели, что думают, прежде чем писать, лучше собирают связные правила и уровни. Между тем набивание промпта новыми примерами упёрлось в убывающую отдачу около 30 000 токенов.

Витрина статьи — «Unconventional PushPull», сгенерированная o1. Поверх привычных толкания и тяги она добавляет изюминку — когда путь игрока перекрыт, ящик скользит на одну лишнюю клетку — плюс переключатель и врата. Кратчайшее решение — 34 хода, и даже методичному BFS пришлось осмотреть 1006 состояний, чтобы его найти. Вердикт авторов: хитро, но осмысленно для человека-игрока.

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

Где применить: выводы для разработчиков и игроков

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

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

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

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

Ограничения: что эта статья не измеряет

Сначала формальности. Это пятистраничная краткая статья, и на момент выкладки на arXiv она была на стадии «подана в CoG». Каждое экспериментальное условие охватывает лишь 10–20 сгенерированных игр, так что таблицы лучше читать как тенденции, а не как строгие сравнения.

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

Технические слабости тоже изложены прямо. LLM с трудом справляются с пространственным рассуждением, которого требует дизайн уровней, и предоставленные сами себе склонны выдавать уровни со слишком короткими решениями. Когда их просят добавить вызова, они часто просто растягивают уровень на пару рядов или раскидывают препятствий. Система не может и самостоятельно диагностировать, что механика сломана относительно замысла; как будущую работу авторы предлагают показывать запись геймплея зрительно-языковой модели, чтобы выявлять такие изъяны.

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

Источники

・ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search (Sam Earle, Ahmed Khalifa, Muhammad Umair Nasir, Zehua Jiang, Graham Todd, Andrzej Banburski-Fahey, Julian Togelius; arXiv:2506.06524, выложена 6 июня 2025 года; CC BY 4.0)

・PuzzleScript (скриптовый язык Стивена Лавелла для головоломок, выпущен в 2013 году; исходники на GitHub)

・База данных игр PuzzleScript (источник 610 написанных людьми игр, которые статья использует как few-shot-примеры)

・Смежная работа: GAVEL: Generating Games via Evolution and Language Models (Todd и др., 2024 — более ранняя система, сочетающая эволюционный поиск и LLM в рамках Ludii)

В заключение

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

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