Чому гіперказуальна гра не виходить у топ за встановленнями
Прототип гіперказуальної гри зібрано: ядро механіки працює, рівні генеруються, збірка проходить модерацію та з’являється в Google Play.
Встановлення йдуть, але на другий-третій день воронка обвалюється: повернення падає нижче 20%, середня сесія вкладається в хвилину, і далі цифри не рухаються.
Причина зазвичай не в рекламі. Алгоритми закупівлі трафіку оцінюють поведінку перших сесій: якщо гравець не повертається наступного дня, система відносить аудиторію до слабкої, і вартість встановлення зростає швидше, ніж база гравців.
Виходить замкнене коло — обсяг закупівлі збільшують, а низьке утримання й зростаюча ціна тягнуть проєкт униз.
Провал прототипу майже ніколи не в графіці. Ламається зв’язка «перша дія — перший успіх — наступний запуск»: гравець не розуміє мету за 5-10 секунд, крива складності на третьому-п’ятому рівні б’є по новачку, і він іде раніше, ніж механіка встигає розкритися. Тест механіки потрібен саме тут — на поведінці, а не на суб’єктивному «грається цікаво».
Далі розбираємо, як із цього стану вийти: які метрики знімати на прототипі, як розділити проблему утримання й проблему трафіку, і в який момент масштабувати закупівлю.
Що дає гіперказуальна гра з налагодженим циклом правок
Налагоджений цикл правок — це не «багато ітерацій», а фіксований маршрут гіпотези: механіка описується словами й цільовими числами, збирається ігровий прототип на одному рівні, і лише потім вирішується, розвивати її чи закрити.
Одна ітерація розробки не чіпає прогресію, магазин і аналітику — змінюється лише перевірюваний вузол, тому збірка й замір займають дні, а не тижні.
Головний замір циклу — утримання перших сесій. Дивимося не середню цифру, а криву: частка гравців, які дійшли до другої сесії, довжина першої сесії, точки відвалу на перших рівнях і на першому ускладненні.
Якщо відвал стоїть на конкретному екрані, причина зазвичай у балансі або в поясненні правила, а не в джерелі трафіку — і це виправляється наступною збіркою.
Гіпотези механік перевіряються по одній і в порядку впливу: спочатку керування й мета, потім темп нагороди, далі прогресія та рекламні вставки. Слабкі відсіюються до масштабної збірки, коли правка коштує одного прототипу, а не перероблення рівнів, інтерфейсу й системи нагород. Правило просте: механіка без приросту на замірі у виробництво не йде.
Швидкість перевірки стає керованою величиною. До кінця циклу в команди є журнал гіпотез із результатами, панель метрик з утримання перших сесій і зрозумілий критерій відсіву.
Замовник бачить не звіт «зробили», а динаміку: які механіки залишені, які закриті й на якому замірі це підтвердилося.
Формати робіт: готове ядро, прототип під ключ, гібрид
Формат обирають за одним критерієм: скільки ітерацій відділяє команду від першого запуску на рекламному трафіку й наскільки механіка розходиться з перевіреними референсами.
Готове ядро механік знімає ризики щодо фізики, керування та відгуку на введення, але одразу накладає обмеження шаблону; прототип під ключ знімає обмеження, зате додає обсяг робіт до першої збірки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готове ядро механік | Гіпотеза перевіряється на знайомому жанрі: ранер, стекер, розбір головоломки | Стеля за глибиною: унікальні умови рівнів і прогресії вимагають переписати шари логіки |
| Прототип під ключ | Механіка й є гіпотеза — потрібні власна фізика й нестандартний відгук на жест | Довше до першої збірки, вищий шанс не зійтися за утриманням |
| Гібридна розробка | Ядро унікальне, а аналітика, рекламні вставки, навчання — типові | Більше стиків: версії модулів потрібно тримати сумісними з ядром |
| Повний цикл | Запуск уже дав робочу вартість встановлення і є сенс нарощувати контент | Виправданий лише після підтвердженої гіпотези, інакше масштабуються помилки |
Як формати стикуються між собою
Ми збираємо всі варіанти на одному контракті подій: аналітика й внутрішня логіка рівнів підключаються до ядра через спільний шар, тому перехід від прототипу до релізної гілки не потребує переписування.
Гілку рушія тримаємо на актуальній LTS-гілці Unity, щоб готові модулі та ядро не розходилися під час оновлень, а метрики першого запуску можна було порівнювати з релізними безпосередньо.
Як відбувається робота: від гіпотези до передачі вихідників
Робота відбувається етапами, і після кожного є точка рішення: підтверджуємо гіпотезу даними або закриваємо її, поки в неї не пішли тижні.
Порядок однаковий і для одиничної механіки, і для серії прототипів — спочатку аудит референсів, потім схема й збірка, і лише потім перевірка на живому потоці встановлень.
-
Аудит референсів. Розбираємо 8–12 ігор жанру: цикл однієї сесії, криву складності, момент першої нагороди, місця рекламних вставок. На виході — таблиця механік із позначкою «беремо / адаптуємо / відкидаємо».
-
Схема механік і математика. Фіксуємо час до першого успіху, крок ускладнення й точки винагороди. Баланс рахуємо в таблицях: скільки рівнів проходить середній гравець і де відвалюється.
-
Етапи розробки прототипу. Збираємо грабельний білд на сірих заглушках: одна механіка, десяток рівнів, мінімум візуалу. Так перевіряється сама механіка, а не якість відмальовування.
-
Інструментовка аналітики. Події старту сесії, завершення рівня, прогресу й показів реклами. Без них потік встановлень дає цифри без причин, і незрозуміло, що саме докручувати.
-
Перевірка на потоці встановлень. Обмежений запуск на реальному трафіку: утримання першого дня, довжина сесії, глибина прогресу, частка тих, хто дійшов до ключового екрана.
-
Рішення за метрикою успіху. Якщо цифри тримають планку, задану до запуску, — масштабуємо й нарощуємо контент. Якщо ні — фіксуємо, яка гіпотеза не спрацювала, і змінюємо механіку, а не графіку.
-
Передача. Вихідники, збірки під цільові платформи, таблиці балансу, карта подій аналітики та інструкція зі збірки — команда замовника продовжує роботу без нас.
Що залишається у вас: збірки, аналітика, регламенти
Передача проєкту — це не архів із кодом і посилання на збірку. Для гіперказуальної гри ми віддаємо комплект, за яким ваша команда або новий підрядник збере реліз, побачить поведінку гравців і випустить оновлення без нас. Нижче — перелік того, що фіксується в акті приймання.
- Передача вихідників — репозиторій із повною історією змін, гілками релізів і коментарями до ключових модулів ігрового циклу.
- Права на збірку — підписаний реліз, опублікований у магазинах застосунків під вашим обліковим записом розробника.
- Доступи й володіння — акаунти публікації, ключі підпису та налаштування переоформлюються на вашу організацію, а не залишаються в нас.
- Налаштована аналітика — події, воронка від показу до першої сесії, звіти з утримання за днями та витратами на залучення.
- Документація проєкту — архітектура, схема зберігання прогресу, опис балансу рівнів та інструкція зі збірки релізу.
- Регламент оновлень — порядок випуску правок під нові версії систем, строки перевірки та правило відкату на попередній реліз.
- Чек-лист приймання — набір перевірок, що підтверджують, що збірка, аналітика й доступи працюють уже на вашій стороні.
Кожен пункт закривається тестом, а не підписом: ви збираєте реліз із вихідників і звіряєте, що події доходять до звітів.
Розбір проєкту: динаміка метрик до і після правок
До нас прийшов грабельний прототип гіперказуальної гри: базовий цикл «запустив — пройшов — програв — повторив» працював, але на перших тестових закупівлях когорта йшла майже одразу.
Заміри через Adjust показали ту саму картину на всіх заходах: значна частина гравців не доживала до першої перемоги. Навчання займало більше хвилини, а перший програш припадав на рівень, де правила ще не були зрозумілі.
Що переробили в механіці
Навчальний екран прибрали й перевели знайомство з правилами в дію — перша перемога тепер вкладається в 15 секунд. Криву складності перезібрали: провал настає після двох поспіль успіхів, а не на першому рівні.
На екрані програшу з’явився рестарт в один тап, додалася смуга прогресу до наступної нагороди й бонус за повернення на другий день.
| Метрика | До правок | Після |
|---|---|---|
| Утримання першого дня | 24% | 37% |
| Утримання сьомого дня | 4% | 9% |
| Середня довжина сесії | 2,1 хв | 4,3 хв |
| Повернення протягом двох днів | 18% | 34% |
Переробка торкнулася лише шару мотивації та подачі: ядро й система рівнів залишилися тими самими, тому повторний цикл закупівель запустили без перезбирання проєкту.
Динаміка метрик у такому кейсі майже завжди впирається в перші 60 секунд і в момент першого програшу — обсяг контенту на старті впливає куди слабше.
Чим тестовий прототип відрізняється від повної збірки?
Прототип і повна збірка — різні інструменти, і плутати їх дорого. Прототип перевіряє, чи чіпляє сам ігровий цикл, і відповідає на це питання за лічені тижні. Повна збірка перевіряє інше: чи витримає механіка потік платного трафіку і чи окупить його.
Строки в прототипу короткі — два-чотири тижні, бо візуал умовний, а частину систем замінено заглушками. Повна збірка займає в рази більше: додаються мета-прогресія, рекламні вставки, вбудовані покупки й розмітка подій.
Відмінності в точності висновків принципові. Прототип показує, чи цікавий цикл, але не підтверджує окупність: без реального арту й рекламних мереж тест на вартість встановлення (CPI) дає зміщену картину.
Тому в повну збірку переходить не все — каркас механіки, баланс перших рівнів і розмітка подій, тоді як візуал та економіка збираються заново.
Часті питання щодо механіки, аналітики та передачі
Рішення щодо механік ухвалюються не «на смак», а за цифрами: у прототипу є набір подій — перша сесія, її довжина, проходження рівнів, повернення наступного дня. Гілка не йде в релізну збірку, поки не дає стійкого зростання ключового показника на короткому відрізку трафіку.
Передача прав фіксується до старту, а не після: вихідники лежать у вашому репозиторії, публікація в магазинах, панель аналітики й рекламні кабінети оформлені на вас. Ми працюємо як виконавець, а не як утримувач акаунтів — це знімає половину питань під час зміни підрядника.
У нас уже зібрано прототип — його можна доопрацювати?
Дивимося збірку, структуру екранів і те, які події вона вже віддає. Якщо основа дозволяє нарощувати механіки й підключати аналітику — розвиваємо її. Якщо ні, переносимо логіку в чисту базу: зазвичай це швидше, ніж лагодити чужу архітектуру, і ми окремо проговорюємо обсяг.
Кому належать вихідники й накопичені дані?
Вам. Вихідний код, конфігурації рівнів і накопичені події залишаються на вашій стороні, доступи ми передаємо по завершенні етапу. Дані одного проєкту не перевикористовуються в інших — це прописано в договорі та технічних умовах.
Як змінюються механіки після тесту?
Гіпотези перевіряємо по одній: правимо конкретний параметр, тримаємо інші незмінними й дивимося, як реагує показник. Так видно, що саме дало ефект, а що просто збіглося зі зростанням трафіку.
Обговоримо задачу: що надіслати для оцінки та плану
Концепту у вигляді опису, референсів і пари екранів достатньо, щоб повернутися з оцінкою обсягу робіт і планом першого циклу. Нижче — ввідні, які найсильніше розсувають вилку в оцінці: чим повніше вони закриті, тим менше уточнювальних ітерацій.
- Ядро геймплею: ключові механіки, тривалість раунду, умова програшу й те, що тягне гравця в наступний захід.
- Референси: 2–3 гри-орієнтири й що в них важливо — темп, крива складності, подача.
- Арт і контент: 2D чи 3D, кількість рівнів і асетів, чи є вихідники або збираємо з нуля.
- Платформи й регіони: магазини застосунків, мінімальні версії систем, орієнтація екрана, географія запуску.
- Монетизація й аналітика: рекламні формати між раундами, покупки всередині гри, список подій для воронки та утримання.
- Доступи й критерії тесту: акаунти магазинів і рекламних кабінетів, а також показник, який вважаємо успіхом і за якого масштабуємо.
Далі — обговорення задачі: короткий дзвінок, після якого надсилаємо план робіт за етапами, строки й склад команди під перший цикл. Опишіть задачу у вільній формі — відсутнє уточнимо самі.
