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