Система прогрессии мобильной игры: где ломается баланс
Система прогрессии мобильной игры — это не таблица уровней, а связи между шагом опыта, открываемыми механиками, силой противников и наградой за усилие. Кривая развития игрока задаёт темп, но проверяется она на боевых данных: по длине сессий, переходам на следующий шаг и доле прошедших главу до конца. Расхождения, которые в таблице не видны, проявляются именно там.
Первый разрыв — обрыв прохождения в середине. Чаще всего он в точке, где требования к ресурсам растут быстрее их выдачи: игроку нужно три-четыре повтора одного боя ради прокачки, он закрывает сессию «на потом» и не возвращается. В боевых данных это резкое сужение воронки на конкретном шаге, а не общее затухание по всей игре.
Второй — мёртвая зона сложности: участок, где барьер уже пройден, а новая механика ещё не открыта. Противники не дают сопротивления, награда не меняется, сессия растягивается без прогресса. В статистике уровней такая зона не видна — она видна в распределении времени между соседними шагами.
Третий — скачок на стыке глав: к расчётному шагу сложности добавляется новая механика и смена состава противников, и вместо плавного роста получается стена. Отсюда и главное расхождение с боевыми данными — правки в таблицах перестают совпадать с тем, что игрок реально проходит. Дальше разбираем, как это закрывается: снимаем метрики по шагам, сопоставляем с расчётной кривой и правим по точкам разрыва, а не на глаз.
Что даёт выверенная прогрессия: эффект в сроках и метриках
Прогрессию измеряют не по объёму контента, а по поведению игрока на первых сессиях. Мы снимаем показатели с GameAnalytics и сверяем с собственной телеметрией: открытие уровней, выдача наград, точки выхода и возврата. Пять метрик показывают, где именно ломается прогрессия, — и каждая меняется предсказуемо, если править кривую осознанно, а не наугад.
- Доля бросивших на первых сессиях. Первый шаг новичка самый дорогой: если после обучающего уровня уходит больше четверти, причина в темпе выдачи первых наград, а не в привлечении.
- Длительность сессии. Растёт, когда следующий шаг прогнозируем: игрок видит цель на один уровень вперёд и понимает, сколько усилий она требует.
- Глубина прохождения. Доля дошедших до середины контента показывает участки, где сложность обгоняет доступные игроку инструменты.
- Кривая удержания. Сглаживается на втором и седьмом днях: перестроенные интервалы наград возвращают тех, кто застрял на одной развилке.
- Нагрузка на поддержку. Однозначные правила прогрессии и честные подсказки срезают поток обращений в духе «застрял и не понимаю, что делать».
Эффекты идут связкой: правка одного участка кривой тянет за собой остальные метрики, поэтому мы смотрим на них вместе, а не по отдельности.
Модели прогрессии: линейная, пороговая, ветвящаяся
Прогрессия — это не одна кривая, а набор связанных решений: сколько опыта до следующего шага, где поставить пороги доступа и сколько путей развития открыть одновременно. Ниже — три рабочие схемы, которые мы закладываем в параметры игры, и то, во что обходится каждая при сопровождении.
| Схема | Когда подходит | Ограничения |
|---|---|---|
| Линейная шкала | Раннее ядро: интервалы и награды растут предсказуемо, легко посчитать ожидаемое время до следующего шага | Однообразие — на длинной дистанции игрок видит ту же кривую и перестаёт ждать следующий уровень |
| Пороговая схема | Нужны вехи и разблокировки: доступ к режимам, ступени сезона, награды за достижение | Порог легко превращается в стену: часть игроков останавливается перед ним и уходит |
| Ветвящаяся схема | Есть несколько стилей игры, и выбор должен влиять на дальнейшие возможности персонажа | Цена сложности выше: ветки настраиваются и проверяются вместе, ошибка в одной тянет за собой остальные |
Выбор модели определяется тем, сколько решений игрок принимает и насколько дорого ошибиться в каждом. Рабочий каркас обычно такой: линейная шкала задаёт ритм, пороговая схема расставляет вехи, ветвление добавляется только там, где выбор действительно меняет игру, — иначе оно растит объём настройки быстрее, чем интерес.
Саму схему мы держим в данных, а не в коде: уровни, коэффициенты и награды лежат в конфигурации, поэтому новая кривая выкатывается без выпуска обновления приложения. Время до уровня, доля дошедших до порога и распределение по веткам снимаем телеметрией и сверяем на двух группах игроков — так видно, где схема держит темп, а где начинает вредить.
Как строится внедрение: этапы инженерной работы
Прогрессия — не одна кривая сложности, а связка решений: где игрок застревает, когда получает следующую награду, что открывается после каждого шага. Поэтому начинаем не с дизайн-документа, а с данных работающей воронки, и только потом фиксируем модель. Внедрение идёт семью этапами.
-
Разбор боевых данных. Снимаем логи по шагам прохождения: где обрываются сессии, сколько времени проходит между наградами, как игроки распределены по уровням. Смотрим медиану и хвост, а не средние — узкое место видно именно в хвосте.
-
Схема кривой. Считаем модель: сколько ресурса нужно на каждом шаге, как растёт стоимость улучшения, опережает ли сложность рост силы игрока. Проверяем таблицей — на каком шаге возникает стена и сколько попыток требуется, чтобы её пройти.
-
Настройка наград. Привязываем источники ресурса к точкам кривой: за прохождение, за возврат, за социальные действия. Следим, чтобы ни одна награда не обесценивала предыдущую и на каждом участке был ощутимый прирост.
-
Балансировка экономики. Считаем приход и расход ресурса, темп траты и обесценивание на длинной дистанции. Прогоняем модель на несколько недель игры и проверяем, не остаётся ли игрок без следующих целей.
-
Проверка на тестовой группе. Выкатываем новую прогрессию на ограниченный сегмент и сравниваем с контрольной группой по глубине прохождения, частоте возвратов и числу брошенных сессий. Старая схема остаётся рабочей — откат делается переключением конфигурации.
-
Инструменты настройки. Значения выносим в конфигурационные таблицы, чтобы правка числа не требовала выпуска новой сборки. На входе — валидация: битые сочетания не доходят до игроков.
-
Передача команде. Отдаём модель с формулами, таблицы, регламент правок и панель с ключевыми метриками прогрессии. Дальше команда меняет параметры сама, а мы остаёмся на поддержке спорных участков.
Что остаётся у команды после передачи проекта
Проект передаётся не архивами и не записями созвонов, а рабочими артефактами: по ним геймдизайнер, аналитик и разработчик дальше двигают прогрессию сами. Что именно остаётся в репозитории и внутренней базе знаний — и по каким признакам заказчик понимает, что пакет полный.
- Документация по кривой: формулы порогов уровней, коэффициенты масштабирования наград, разбивка по этапам — обучение, середина, поздний контур. К каждой развилке приложено обоснование: почему выбран такой наклон и что поедет при его сдвиге.
- Таблицы наград: уровни, задания, ежедневный цикл, сезонные ветки — в редактируемых таблицах вне кода. Награду можно переставить и прогнать на симуляции за минуты, без пересборки приложения.
- Регламент правок: кто инициирует изменение, какие проверки обязательны, в каком случае правка откатывается к предыдущему состоянию кривой.
- Точки контроля: набор метрик — прохождение, отток на ранних уровнях, распределение выдачи — и пороги, за которыми команда вмешивается, а не действует на глаз.
- Карта зависимостей: какие системы завязаны на прогрессию — экономика, боевые характеристики, витрина — и что именно поедет при изменении порогов.
- Передача знаний: парные сессии с записью, разбор спорных мест баланса, канал для вопросов с оговорённым сроком ответа.
Проверяется такой пакет просто: очередная правка баланса проходит без нас, а на вопрос «почему здесь именно столько» находится письменный ответ, а не догадка.
Кейс: как убрали обрыв на середине прохождения
Что было до правок
Игрок доходил до середины сюжетной главы и упирался в стену: сложность росла быстрее, чем приходили усиления. По воронке в GameAnalytics это читалось как обрыв на середине — до следующего шага дотягивала примерно треть когорты, а дальше доля падала втрое за два уровня. Награды выдавались линейно, разницы между «прокачался» и «не прокачался» игрок не чувствовал.
Что изменили в кривой
Ключевые усиления сдвинули к точкам естественного спада, добавили награды за завершение главы и пересчитали требования к уровню под фактический темп набора опыта. Ежедневным задачам задали адаптивную сложность — она считается от текущего прогресса, а не от фиксированного порога. Часть механик открывается раньше, ровно там, где старый темп проседал.
Что показал замер до и после
Доля доходящих до конца главы выросла с 34 до 58%, отвал на середине сократился вдвое, средняя сессия стала длиннее примерно на треть, возврат на второй день — плюс 9 пунктов. Сдвиг показателей считали на разделённых группах три недели после выхода новой кривой. Конфигурацию баланса вынесли в отдельный файл: правки кривой и наград не требуют выпуска новой версии приложения и откатываются одной строкой.
Что делать, если баланс разошёлся с боевыми данными
Расхождение баланса с боевыми данными — не авария, а нормальное состояние выпущенной игры: живая аудитория всегда ведёт себя иначе, чем тестовые группы на закрытом этапе. Первый шаг — отделить ошибку кривой от ошибки данных. События прогрессии могут теряться при обрыве связи, дублироваться при повторной отправке, склеиваться по устройству, а не по игроку. Пока в телеметрии есть такие дыры, любая правка — это угадывание, и вторая итерация только укрепит неверную гипотезу.
Когда данные сошлись, расхождение локализуют по воронке уровней: где доля дошедших падает резче проектной, где образуется плато, где провал сразу после выдачи награды. Смотреть при этом нужно не на общий агрегат, а на когорты по времени входа и на группы по вовлечённости — усреднение прячет ровно тот участок, который и сломан.
Правки, не ломающие доверие игроков, всегда адресные. Меняются коэффициенты стоимости и награды выше точки расхождения, а всё, что игрок уже прошёл, остаётся неизменным: обесценить пройденный путь — значит потерять тех, кто дошёл до конца кривой и формирует ядро. Изменения вступают в силу только для новых шагов по прогрессии.
Пересборку кривой делают через параметры — базу, множитель роста, шаг награды, — а не через ручную правку каждого уровня. Тогда корректировка это одно число, откат — возврат предыдущего набора параметров, а версия конфигурации привязывается к сборке игры и периоду, в котором её выдали. Без этого невозможно понять, что именно повлияло на поведение после выката.
План действий выстраивается до первой правки: проверенная телеметрия, карта расхождений по уровням, контрольная и тестовая группы, окно наблюдения в несколько игровых циклов, заранее зафиксированные показатель успеха и условие отката. Так баланс возвращается к задуманному без потери доверия аудитории.
Частые технические сомнения по проектированию баланса
Перед стартом заказчик задаёт пять вопросов: не сломает ли баланс платное ускорение, за сколько игрок проходит контент, можно ли править кривые после выпуска, как прогрессия связана с наградами и что делать с вернувшимися. Ниже — ответы на уровне модели, а не обещаний.
Платное ускорение не сломает баланс?
Ускорение задаём множителем поверх базовой кривой, а не сдвигом уровней. Платящий проходит тот же контент и получает те же награды, но раньше выходит на следующую ступень — разрыв держим в днях, а не в разы.
Как контролируется скорость прохождения?
Воронку прогрессии собираем в GameAnalytics и смотрим распределение, а не средний темп: медиану и медленный хвост. Ранние уровни проходятся за первые сессии, дальше кривая выходит на плато, где темп задают события, а не объём требуемого опыта.
Можно ли править баланс после выпуска?
Кривые живут в конфигурации, а не в коде, поэтому правка коэффициентов не требует обновления приложения. Уже выданные награды и достигнутый прогресс при этом не откатываются.
Как прогрессия связана с наградами?
Награды привязаны к шагам кривой, а не к отдельным уровням: выдача считается от текущего места игрока. Новая награда не обесценивает пройденное и не ломает собранные ветки.
Что с игроками, которые вернулись?
Для вернувшихся держим отдельные кривые: сглаженный вход в первые сессии, ускоренный добор отставания и своя ветка наград. Иначе игрок либо упирается в стену, либо догоняет остальных слишком быстро и теряет интерес.
Обсудим задачу: с чего начинается проектирование
Прежде чем оценивать объём, нам нужно понять, какой прогрессией управляем и чем она ограничена. Проектирование системы прогрессии мобильной игры начинается не с балансных таблиц, а с ваших данных: без выгрузки реальных сессий любая кривая сложности останется догадкой. Поэтому первый шаг — собрать от команды материалы и доступы.
Что нужно, чтобы вернуться с планом работ и сроками:
- Постановка задачи: какой этап жизненного цикла затрагиваем, какую гипотезу проверяем и по какой метрике считаем результат — удержание первого дня, доля дошедших до ключевого уровня, число сессий на игрока.
- Доступ к данным: сырые выгрузки событий прогресса за наблюдаемый период, схема событий и словарь параметров, доступ к дашбордам или к хранилищу для запросов.
- Текущая экономика: таблицы наград, стоимости апгрейдов, источники и стоки ресурсов, формулы пересчёта опыта — в том виде, в каком они работают сейчас, а не в архивных документах.
- Конфигурация: где зашиты параметры баланса — в серверных конфигах или в клиентской сборке, можно ли править их без выпуска новой версии.
- Ограничения: платформы и минимальные устройства, требования магазинов, офлайн-режим, наличие серверной части и скорость её правок.
- Тестовый контур: сборка, на которой воспроизводится поведение, доступ к репозиторию, учётные записи с разным уровнем прогресса.
- Ответственный на вашей стороне: кто принимает решения по балансу и подтверждает приёмку этапов.
С этим набором мы возвращаемся с планом работ: разбивкой на этапы, сроками по каждому и точками, где вы видите промежуточный результат. Оценка сроков появляется после просмотра данных — до этого любая цифра будет угадыванием.
