Впровадження гейміфікації: рівні та XP у мобільному застосунку

Чому система рівнів у мобільному застосунку не утримує

Система рівнів у мобільному застосунку майже завжди з'являється першою: смуга досвіду, номер рівня, спливаюче повідомлення про підвищення.

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

Типова поломка — лінійна крива досвіду. Кожен наступний рівень коштує на однакову надбавку дорожче, і до десятого кроку вартість проходження зростає у рази: гравець ще не отримав нічого відчутного, а темп уже впав.

Другий перекіс — нагорода не змінює гру: надбавка до характеристики, яка ні на що не впливає, знецінює весь пройдений шлях.

Ранній відтік гравців майже завжди припадає на другий-третій день. У подіях видно одну й ту саму картину: гравець доходить до третього-четвертого рівня, нагороду забирає, а наступного дня застосунок не відкриває.

Частка тих, хто дійшов до першої значущої нагороди, виявляється у рази нижчою за частку тих, хто дійшов до третього рівня — отже, криву рахували від бажаної кількості рівнів, а не від реального темпу проходження.

Лікується це перезбиранням кривої досвіду: контрольні нагороди ставляться на ті кроки, які гравець проходить у перші заходи, а далі вартість рівня зростає разом із можливостями, що відкриваються. Утримання у застосунку тримається на ритмі нагород, а не на їхній кількості. Нижче розбираємо, як рахувати таку криву і де вона ламається.

Вимірюваний ефект: утримання, повернення, темп проходження

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

Ці показники рухаються разом: прискорюється темп проходження — зростає частка тих, хто дійшов до середини сюжету, а разом із нею й повернення.

За галузевими вимірами GameAnalytics утримання першого дня в медіані тримається близько третини встановлень, а верхній квартиль відрізняється у рази. Основна втрата припадає на треті–п'яті рівні — тобто на перші хвилини, а не на пізній контент.

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

У нашій практиці переробка прогресії прискорювала темп проходження перших десяти рівнів і підвищувала частку повернень після трьох і більше днів паузи: прогрес збережено, найближча ціль видна, наступний крок не потребує перенавчання. Метрики утримання рахуємо за когортами встановлення — інакше зростання залучення маскує відтік.

Підсумок — за того самого обсягу залучення активна база ширша, а кожне встановлення дає більше сесій. Це і є вимірюваний результат: не рівні заради рівнів, а керована крива утримання.

Моделі прогресу: лінійна, сезонна, гібридна

Модель прогресії — це не про гарну шкалу, а про те, як довго продукт утримує мотивацію без постійного притоку нового контенту. Якщо рівні зростають нескінченно, аудиторія впирається в стелю і шкала перестає щось означати; якщо обнуляти її надто часто, знецінюються минулі зусилля.

Тому спочатку дивимося довжину контентного циклу, частку новачків і частоту оновлень, а вже потім обираємо режим.

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

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

Етапи впровадження: від аудиту механік до передачі

Впровадження рівнів — це не «увімкнути смугу досвіду». Робота йде етапами, і кожен закінчується артефактом: карта подій, конфігурація кривої, правила нарахування, звіт за контрольною групою.

1. Аудит ігрових механік і даних. Розбираємо, які дії вже логуються, де рахується прогрес і як зберігається історія сесій. На виході — карта подій, придатних для нарахування досвіду, і список місць, де потрібна додаткова точка збору.
2. Проєктування прогресії. Рахуємо криву: скільки дій до наступного рівня, як зростає крок, де з'являється «стіна». Перші рівні проходяться швидко, далі зростання плавне, інакше відвалюється середина воронки.
3. Налаштування нагород. Визначаємо, що дає рівень — доступи, косметика, місце в рейтингу. Нарахування живе на сервері й працює ідемпотентно: повторне надсилання події не подвоює досвід і не видає нагороду двічі.
4. Схема даних і синхронізація. Модель профілю, зберігання досвіду, поведінка при офлайні та вході з іншого пристрою. Схему версіонуємо, щоб нові поля не ламали раніше випущені збірки.
5. Перевірка змін на трафіку. Віддаємо механіку частині користувачів і порівнюємо з контрольною групою: утримання, повернення, глибина сесій, швидкість відгуку профілю. Механіка залишається, лише якщо виграш відтворюється.
6. Спостережуваність. Панель із розподілом рівнів і часткою застряглих на одному кроці, алерти на розбіжність між подіями та балансом досвіду.
7. Передача. Документація за правилами, доступи до конфігурації та інструкція, як змінювати криву й нагороди без випуску нової версії застосунку.

Передавані артефакти: конфігурації, схеми, регламенти

Після здачі блок рівнів і досвіду не повинен залишатися чорною скринькою, яку вміємо правити лише ми. Параметри прогресії виносимо в конфігурації й передаємо разом із документацією — баланс змінюється без перезбирання застосунку. Ось що залишається у вас на руках.

• Схема прогресії — дерево рівнів, пороги досвіду та формула кривої зростання. Видно, на якому кроці гравець застрягає; поріг правиться одним рядком у файлі налаштувань.
• Правила нарахування досвіду — таблиця джерел: скільки досвіду дає дія, добові ліміти, множники за серію, захист від повторного нарахування.
• Таблиці нагород — прив'язка нагороди до рівня або події, ваги випадання, правила повторної видачі. Звіряються з правилами нарахування на тестах, а не на живих гравцях.
• Регламент сезонних подій — вікно запуску, що відбувається з накопиченим досвідом при завершенні сезону, як переносяться незабрані нагороди, хто вмикає сезон достроково.
• Схема даних і журналювання — де зберігається поточний баланс, як синхронізується прогрес між пристроями, що писати в лог, щоб розібрати спірне нарахування.
• Матриця перевірок та інструкція з правок — сценарії приймання (стрибок рівня, межа ліміту, відкат сезону, два пристрої) і перелік параметрів, які змінюються налаштуванням без оновлення застосунку.

Конфігурації версіонуються разом із кодом, тому будь-яку правку балансу можна відкотити до попереднього стану. Передаємо у вихідних форматах, із коментарями та заповненим прикладом.

Кейс: як зросло тижневе утримання після перезапуску

Ігровий застосунок із казуальними головоломками: встановлення йшли хвилями, але до кінця першого тижня залишалося менше п'ятої частини гравців.

Розбір воронки показав, що причина не в трафіку й не в кількості рівнів, а в самій прогресії: нагорода надходила рідко, досвід нараховувався одним блоком у кінці рівня. Гравець не бачив, чи наближається він до наступного рівня, і не знаходив приводу відкрити застосунок завтра.

Поріг наступного рівня зростав швидше, ніж гравець устигав набирати досвід — на третьому-четвертому рівні потрібно було вдвічі більше, ніж давав середній пройдений рівень.

Смуга завмирала на 60–70%, а серія обнулялася за пропущений день без можливості відновлення: після такого обриву повертатися не хотілося.

Що змінювали під час перезапуску механік

Досвід розбили на короткі нарахування за дії всередині рівня, смуга рухалася кожні 20–30 секунд замість кількох хвилин.

Пороги вирівняли так, щоб новий рівень приходив кожні 2–3 сесії, а не раз на тиждень; серію дозволили відновлювати один раз, а нагороди на рівнях прив'язали до косметики й відкриття нових режимів.

Після оновлення в App Store прогрес синхронізувався між пристроями, тому зміна телефона більше не скидала досягнення.

Метрики до та після

Утримання першого дня зросло з 41% до 52%, першого тижня — з 18% до 29%. Частка гравців, які доходять до п'ятого рівня, піднялася з 22% до 47%, середня кількість сесій за перший тиждень — з 3 до 5.

Час до першого рівня скоротився з дев'яти хвилин до двох із половиною, тому новачок отримував першу нагороду у ту саму сесію.

Крива трималася й через місяць після перезапуску: змінилася механіка, а не разова акція. Далі прогресію налаштовуємо за сегментами — новачкам короткі кроки до нагороди, тим, хто повернувся після паузи, прискорене повернення у ритм.

Чим відрізняється сезонний прогрес від постійного?

Це не альтернативи, а два режими однієї шкали. Постійний прогрес живе весь термін життя застосунку: рівні, досвід і відкриті можливості накопичуються й не обнуляються.

Сезонний прогрес іде циклами — після завершення сезону шкала стискається, нагороди замінюються, а місце гравця в рейтингу перераховується заново.

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

Пропустили випуск — гравці відкривають порожній сезон, і мотивація повертатися обнуляється разом із ним.

На повернення підходи впливають по-різному. Сезон дає передбачувані сплески активності на старті, але утримання між циклами просідає, якщо новому сезону нема чого запропонувати. Постійна шкала дає рівний графік візитів: людина заходить добрати рівень або закрити колекцію.

Оновлення контенту в обох випадках проходить рев'ю App Store, тому дату старту сезону закладають із запасом, а не за календарем.

На практиці їх комбінують: постійна шкала відповідає за довгу мотивацію, сезонна — за регулярні приводи повернутися. Ми розкладаємо обидві механіки за етапами, щоб підтримка планувалася заздалегідь, а не перетворювалася на аврал перед кожним стартом.

Технічні сумніви: питання щодо впровадження та підтримки

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

Що робити, якщо нова механіка конфліктує з наявною економікою?

Конфлікт механік ловимо на проєктуванні: складаємо карту всіх джерел досвіду й дивимося перетини — наприклад, нагорода за щоденний вхід знецінює завдання на прогрес. Спірні механіки виносимо за окремий прапорець і вмикаємо поетапно, відстежуючи розподіл гравців за рівнями.

Чи можна змінювати рівні й нагороди без випуску нової версії?

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

Обговоримо задачу та повернемося з оцінкою й планом

Щоб повернутися з оцінкою та планом, нам потрібен не бриф «додайте рівні», а вхідні дані для аудиту. Прогресія зачіпає нарахування досвіду, зберігання балансу, аналітику та захист від накрутки — без цих деталей оцінка перетворюється на вилку «від і до».

• Події застосунку та поточна аналітика: які дії вже логуються, де рахуються сесії та утримання.
• Правила прогресії: скільки рівнів, крок досвіду, що видається на рівні, чи є спадна або прискорювальна крива.
• Схема даних: де зберігається баланс досвіду, хто джерело істини — клієнт чи сервер, що відбувається офлайн і при повторному вході.
• Вимоги до захисту від накрутки: серверна валідація подій, обмеження на повторне нарахування, ліміти за добу.
• Обмеження за платформами та частка користувачів на старих збірках — від неї залежить, чи потрібен примусовий апдейт.
• Тестові акаунти й доступи до середовищ розробки та перевірки: нарахування, скидання рівня, відкат зміни.
• Відповідальний на боці замовника, хто затверджує правила прогресії та порядок видачі нагороди.

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

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