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

Разработка раннера: где ломается удержание игроков

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

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

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

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

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

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

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

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

Эффект измерим. Длина игровой сессии выросла с 60–90 секунд до трёх с лишним минут, доля повторных забегов — примерно вдвое, брошенные попытки на первых 30 секундах сократились с 40% до 18%. Правка правил занимает пару часов вместо недель ручной сборки.

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

Режимы построения трасс: сравнение подходов

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

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

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

Этапы разработки раннера: от прототипа до релиза

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

1. Разбор механики. Фиксируем длину забега, набор препятствий, ось управления и условия проигрыша. Разное понимание этих вещей всплывает здесь, а не на релизе.
2. Прототип раннера. Серые блоки, честная физика прыжка и скольжения. Меряем время до первой смерти и с какого раза игрок проходит участок — по этим числам правим отзывчивость управления.
3. Схема генератора. Определяем, из каких блоков собирается трасса, их веса, правила усложнения и коридоры гарантированной проходимости.
4. Настройка генератора. Прогоняем тысячи автоматических забегов, смотрим долю непроходимых связок и разброс сложности. Правим веса и правила, а не отдельные уровни вручную.
5. Проверка баланса. Кривая сложности по дистанции, длительность сессии, доля выходов на первой минуте. Сюда же догоняем награды и рекламные включения, чтобы они не ломали темп.
6. Подготовка к публикации. Сборки под магазины, политика конфиденциальности, обучающий первый запуск, тестовые треки и работа с отзывами.
7. Передача проекта. Репозиторий, документация по параметрам генератора и экономики, обучение команды заказчика — дальнейшие правки баланса делаются уже без нас.

Что остаётся в проекте после передачи

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

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

Такой комплект снимает главный риск разработки раннера: через полгода никто не помнит, почему сложность растёт именно так и какой параметр отвечает за частоту бонусов.

Кейс: удержание и длина сессии до и после

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

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

Что изменили в генерации

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

Результат внедрения по когортам в Google Play: забегов за сессию стало 4–5, средняя длина сессии выросла до семи минут, доля повторных запусков приложения на следующий день выше в 1,8 раза. Доля игроков, дошедших до третьего отрезка трассы, выросла с 41% до 68%.

Чем процедурная генерация отличается от ручных трасс?

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

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

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

Технические сомнения по генерации и балансу

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

Как балансируется кривая сложности?

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

Потянет ли генерация слабое устройство?

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

Можно ли править контент и баланс без пересборки?

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

Обсудим задачу и вернёмся с планом работ

Чтобы разговор был предметным, а не о «приложении-раннере в общем», нам полезно увидеть вашу картину до созвона. Достаточно того, что уже есть: набросок механики, референсы, заметки по монетизации, данные по прошлым попыткам, если они были.

• Механика ядра: как задаётся скорость, из чего складывается счёт, есть ли ускорение со временем и чем заканчивается забег — от этого зависит структура процедурной генерации.
• Референсы и антиреференсы: 2-3 игры, которые нравятся, и 1-2, которые точно не подходят, с пояснением почему. Это снимает половину правок на этапе прототипа.
• Целевые платформы и устройства: на чём запускаем в первую очередь и какой уровень устройств считаем нижней границей — влияет на бюджет производительности и на то, где генерируем уровни: на клиенте или на сервере.
• Модель монетизации: реклама между забегами, награда за просмотр, внутриигровые покупки или их сочетание. От этого зависит, как встраиваются точки показа и что мы выносим в аналитику.
• Ограничения: жёсткие даты, обязательная интеграция с вашей аналитикой или платежами, требования по приватности и хранению данных игроков.
• Кто принимает решения: один человек или несколько, и как часто сможете смотреть сборки — от этого зависит ритм итераций.

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