У казуальних іграх головний ворог — низький retention. Day 1 retention <40% вбиває економіку проєкту: користувачі не доходять до монетизації. Кожен втрачений користувач на 1-й день — це гроші, витрачені на залучення. Ми вирішуємо цю проблему через energy system, push-сповіщення та Dynamic Difficulty Adjustment (DDA). На відміну від гіперказуальних ігор, де сесія триває хвилини, казуальна гра має утримувати гравця тижнями. Казуальна гра — жанр, що вимагає складної прогресії. Наш досвід — 5+ років і 10+ проєктів у цьому жанрі, від match-3 до runner. Ми пропонуємо розробку під ключ з оцінкою проєкту та вибором оптимального стеку. Зв'яжіться з нами для обговорення вашого проєкту.
Розробка мобільної казуальної гри з retention вище 40%: як це зробити?
Утримання — головна метрика. Day 1 retention нижче 40% вказує на проблеми з tutorial або першими рівнями. Day 7 нижче 15% — не вистачає мотивації. Ми вирішуємо це:
- Energy system — класичні 5 життів з поповненням раз на 30 хвилин. Зберігання часу в PlayerPrefs (або Hive/MMKV).
- Push-сповіщення через Firebase Cloud Messaging (FCM) для Android та iOS. Request permission на iOS — не одразу при старті, а після першої поразки (конверсія вища на 30%).
- Локальні сповіщення для офлайн-подій через
UNUserNotificationCenter(Unity iOS). - A/B-тести складності рівнів, вартості бустерів, частоти реклами через Firebase Remote Config.
Match-3 краще runner-ігор на 30% по retention на 7-й день, що підтверджується нашими проєктами. DDA збільшує проходження складних рівнів у 2 рази порівняно з фіксованою складністю.
| Механіка | Ефект | Реалізація |
|---|---|---|
| Energy system | Day 1 retention +15% | Відновлення 5 життів за 30 хв |
| Push-сповіщення | Day 7 retention +10% | FCM + локальні, permission після поразки |
| DDA | Проходження 3+ fail → зниження складності | Поточна складність у PlayerPrefs |
Чому прогресія — центральна механіка?
Казуальні ігри утримують через прогресію, а не тільки через core gameplay. Ми реалізуємо рівні з наростаючою складністю, meta-гру (будівництво, колекціонування, Battle Pass) та DDA: якщо гравець програє 3+ рази поспіль — знижуємо параметри ворогів або додаємо підказку. Конфігурація рівнів через ScriptableObject з експортом з Google Sheets (JSON). Жодного хардкоду — це сповільнює ітерації дизайнерів.
Інструменти та технології — розробка мобільної казуальної
| Компонент | Стек | Призначення |
|---|---|---|
| Ігровий двигун | Unity LTS | Рендеринг, фізика, анімації |
| Аналітика | Firebase + GameAnalytics | Події: level_start, level_complete, iap_completed |
| Push-сповіщення | FCM + локальні | Retention |
| Backend | PlayFab / кастомний | Battle Pass, лідерборди |
| Монетизація | StoreKit 2 / Billing 6 | IAP, rewarded ads (AdMob) |
Монетизація: що працює в казуальних іграх?
Ми використовуємо перевірені моделі:
- In-app purchase через StoreKit 2 (iOS) та Billing 6 (Android) — бустери, життя, Battle Pass.
- Rewarded ads за продовження рівня, бустери, подвоєння нагород.
- Battle Pass / Season — серверна логіка через PlayFab або кастомний backend. Клієнтська валідація недостатня.
Всі параметри монетизації тестуються A/B: вартість бустерів, частота реклами, енергія.
Як ми тестуємо монетизацію?
Використовуємо Firebase Remote Config для A/B-тестів: змінюємо ціну бустерів, інтервал показу реклами, кількість життів. Аналізуємо воронку: install → tutorial complete → day 1 → day 7 retention. Ітеруємо на основі даних.
Що входить до розробки казуальної гри під ключ
- Game Design Document з детальним описом рівнів та прогресії
- Прототип з 5–10 рівнями та core loop
- Повна версія з монетизацією (StoreKit 2 / Billing 6), push-сповіщеннями, аналітикою (Firebase + GameAnalytics)
- Документація з конфігурування рівнів та балансу
- Допомога з публікацією в App Store та Google Play
- Навчання команди замовника роботі з конфігами
- Пост-релізна підтримка: виправлення багів, доопрацювання контенту
Аналітика та ітерації
Стандартний стек — Firebase Analytics + GameAnalytics. Ключові події: level_start, level_complete, level_fail, booster_used, ad_watched, iap_initiated, iap_completed. Воронка: install → tutorial complete → day 1 → day 7 retention. Аналізуємо, ітеруємо. Налаштування аналітики гри — ключовий етап, що дозволяє відстежувати поведінку користувачів.
Покроковий план розробки
- Аналітика вимог та підготовка GDD (2–4 тижні)
- Прототип з 5–10 рівнями та core loop (6–10 тижнів)
- Повна версія з прогресією, монетизацією, push-сповіщеннями (4–8 місяців)
- Інтеграція аналітики (Firebase + GameAnalytics)
- Документація з конфігурування рівнів та балансу
- Допомога з публікацією в App Store та Google Play
- Навчання команди замовника роботі з конфігами
- Пост-релізна підтримка: виправлення багів, доопрацювання контенту
Типові помилки при розробці казуальних ігор
- Хардкод параметрів рівнів
- Відсутність DDA
- Push-сповіщення без permission flow
- Немає серверної валідації Battle Pass
- Аналітика не налаштована з першого дня
- Ігнорування тестування на пристроях різної потужності
Строки та вартість
Прототип: 6–10 тижнів. Повна гра: 4–8 місяців командою з 3–5 осіб. Вартість розраховується індивідуально після аналізу GDD та вимог до backend-інфраструктури. Оцінимо ваш проєкт — зв'яжіться для розрахунку строків та вартості. Замовте прототип вже сьогодні — отримайте консультацію щодо вашого проєкту. Гарантуємо якість та відповідність App Store Review Guidelines Section 4.2 та 5.1. Завдяки нашому досвіду, ви економите до 30% часу на етапі прототипування.
