Разработка мобильной головоломки (Puzzle) с процедурной генерацией

Разработка мобильных игр: где ломается генерация уровней

Узкое место контента проявляется на второй-третьей неделе после релиза. Игрок проходит 20–40 уровней за первые сессии, а автор уровней вручную собирает 5–8 головоломок в неделю: чем глубже прогресс, тем дороже каждая следующая — нужно проверить решаемость, единственность решения и отсутствие тупиковых ветвей. Команда либо останавливает прогресс искусственными ограничениями, либо выпускает уровни ниже планки качества.

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

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

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

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

Процедурная генерация уровней в игре: что меняется

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

Wave Function Collapse применяем как один из режимов сборки раскладки, когда нужна вариативность поля при сохранении структуры. Основной контур остаётся детерминированным: инварианты проверяются на каждом шаге, и уровень отбраковывается до попадания в сборку.

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

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

Режимы генерации уровней и их ограничения

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

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

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

Этапы разработки головоломки с генерацией уровней

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

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

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

Артефакты проекта: правила генерации и документация

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

• Правила генерации уровней — формальное описание: какие параметры задают запас ходов, плотность препятствий и кривую сложности по главам, какие ограничения гарантируют решаемость. Рядом — сама конфигурация правил, которую правят без изменения логики.
• Таблицы баланса — награды, темп появления механик и сложность вынесены в файлы данных. Правка чисел не требует пересборки приложения, результат видно сразу на тестовом прогоне.
• Автопроверка уровней — прогон партии сгенерированных уровней: отсекает нерешаемые и тривиальные, отдаёт отчёт по распределению сложности. Защита от того, что после правки коэффициента игра стала слишком лёгкой.
• Сборки под две платформы — релизные сборки под обе целевые платформы, профили и ключи подписи, скрипты сборки. Выпуск версии — одна команда вместо ручной последовательности шагов.
• Регламент обновлений — порядок выпуска контента: ветки, проверки перед релизом, критерий и способ отката на предыдущую версию, окно доставки сезонных наборов уровней.
• Документация проекта — архитектура, схема хранения прогресса, инструкция «как добавить новую механику целиком» с разбором на уже существующей.
• Набор тестовых сценариев — фиксированные начальные значения генератора и сохранённые состояния прогресса, на которых жалоба игрока воспроизводится за один прогон, а не за день поисков.

Кейс: головоломка на двух платформах без переписывания

Головоломка выходила сразу на двух платформах: общая логика поля и правил, различия — только в слое ввода и покупок. Уровни при этом набирали руками: дизайнер собирал сетку, прогонял её на решаемость и заливал в общий формат описания. Пакет из 60 уровней занимал 4-6 недель, а сильные игроки проходили его за три вечера и уходили.

Что было узким местом

Удержание на 7-й день держалось около 18%, на 30-й падало до 6% — контент заканчивался быстрее, чем его успевали делать. Правки баланса требовали пересборки всего пакета, а часть уровней всё равно возвращалась с жалобами «нет решения». Одна и та же сетка на телефоне и планшете ощущалась по-разному, и разбор каждой такой ситуации съедал время команды.

Что изменили

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

Метрики после

Выпуск в Google Play и App Store стал одним циклом: генератор и правила общие, отличаются только слои платформы. Поток уровней перестал быть узким местом — ежедневный набор собирается под конкретного игрока, а баланс правится параметрами, а не пересборкой пакета. Удержание на 7-й день выросло с 18% до 31%, на 30-й — с 6% до 12%, доля сессий с жалобой «застрял» упала втрое.

Чем процедурная генерация уровней отличается от ручного дизайна

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

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

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

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

Технические вопросы по генерации и кроссплатформе

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

Не станут ли уровни предсказуемыми?

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

Что с различиями между платформами?

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

Обсудим задачу: что нужно для оценки вашей головоломки

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

• Правила уровня: размер поля, набор элементов, условия победы и проигрыша, лимит ходов или времени.
• Логика процедурной генерации: что должно быть случайным, а что задано жёстко; нужна ли проверка решаемости и единственности решения на каждом уровне.
• Режимы и прогрессия: бесконечный режим, последовательность уровней с ростом сложности, ежедневные задания, сравнение результатов игроков.
• Платформы и целевые устройства: где запускаем в первую очередь, ограничения по объёму установочного пакета и по работе без сети.
• Материалы по визуалу: макеты или примеры-ориентиры, описание стиля, требования к анимации и звуку.
• Ограничения проекта: желаемые сроки, кто на вашей стороне принимает решения по спорным местам, есть ли уже наработки или прототип.

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