Retention падає, коли на другому тижні гравці бачать, що прогрес застопорився. Причина — неправильна крива прогресії: числа йдуть у нескінченність, генератори стають непотрібними. Виправляємо це математикою ще на етапі проектування. Ми створюємо idle/clicker-ігри з нуля — від прототипу до публікації в магазинах. У нашій idle грі з пресет системою та push сповіщеннями ми досягаємо високого retention. Досвід понад 5 років і 8 проектів показує: правильно налаштована прогресія та офлайн-механіка дають retention вище 40% на 30-й день. Грамотна монетизація збільшує LTV на 25% — у цьому допомагає баланс між рекламою та IAP. Середній ARPU для idle-ігор — $0.8–$1.5, а ROI від реклами може досягати 400%. Вартість розробки базової idle-гри стартує від $10 000.
Проблеми, які вирішуємо
Основні технічні складності idle-ігор: нескінченні числа, офлайн-прогрес, утримання користувачів. Розглянемо кожну.
Як працюють великі числа в idle-іграх
Idle-ігри використовують числа, які не поміщаються в double. Через 10 годин гри у гравця може бути 1.23e+150 монет. double дає точність 15–17 значущих цифр, після чого додавання маленьких сум ігнорується — гравець перестає бачити приріст від слабких генераторів. Рішення: кастомний BigDecimal або готова бібліотека BreakInfinity.cs (спеціально створена для idle-ігор, працює в Unity, в 10 разів швидша за стандартний BigInteger). Форматування чисел: 1.23e+12 → «1.23T» або «1.23 трлн» — пишемо кастомний formatter зі словником суфіксів.
| Підхід | Точність | Швидкість | Застосовність |
|---|---|---|---|
double |
15–17 знаків | Висока | Не підходить для idle |
BigInteger |
Будь-яка | Низька (10x повільніше) | Тільки якщо числа цілі |
| BreakInfinity | ~300 знаків | Висока | Ідеально для idle |
Для зберігання на сервері використовуємо рядки — уникаємо втрати точності при серіалізації.
Докладніше про зберігання чисел
У деяких проектах ми використовуємо BigNumber з бібліотеки Newtonsoft.Json для серіалізації. Важливо: не серіалізуйте безпосередньо в double — після рестарту сервера значення можуть змінитися. Завжди перевіряйте цілісність даних через CRC32.Реалізація офлайн-прогресу
Стандартний підхід: рахувати офлайн-приріст при наступному відкритті. Важливий нюанс: обмежуй офлайн-період (наприклад, 8 годин максимум), інакше гравець може «накопичити» 30 днів і миттєво пройти весь контент. Преміум-пропозиція «збільшити офлайн-межу до 16 годин» — популярна IAP у жанрі.
Збереження: поточні ресурси + timestamp останнього закриття + версія балансу. При завантаженні: offlineSeconds = min(now - lastClose, maxOfflineSeconds), потім earned = productionPerSecond * offlineSeconds. Production per second кешується і перераховується тільки при покупці апгрейда, не кожен тік.
Кроки реалізації:
- Записуємо timestamp і ресурси при закритті.
- При завантаженні обчислюємо час відсутності.
- Обмежуємо максимум (наприклад, 8 годин).
- Нараховуємо ресурси та додаємо бонус за повернення.
Для прототипу використовуємо PlayerPrefs, для продакшену — JSON з перевіркою цілісності (CRC32).
Чому push-сповіщення підвищують retention?
FCM scheduled notifications: «Твої генератори заповнені, забери ресурси!». На Android — AlarmManager через Unity plugin для точних таймерів. На iOS — UNNotificationRequest. Не відправляй сповіщення раніше ніж через 2 години після закриття — інакше дратує.
Ми налаштовуємо персоналізовані сценарії: якщо гравець не заходив 6 годин, відправляємо нагадування з бонусом. Якщо 24 години — пропонуємо повернутися з подарунком. Це підвищує DAU на 15–20%.
Як вибрати між рекламою та IAP?
Баланс залежить від аудиторії. Для казуальних ігор ефективна rewarded video — гравець дивиться рекламу за бонуси. Для хардкорних — IAP на прискорення прогресу. Ми тестуємо обидва варіанти і вибираємо оптимальний за конверсією.
Що входить в нашу роботу
- Документація API та схеми даних
- Вихідний код з коментарями
- Доступ до сервісів (Firebase, App Store Connect)
- Навчання команди замовника (2 години)
- Підтримка 30 днів після релізу
- Код-рев'ю та юніт-тести
Економія бюджету: на етапі прототипу виявляються проблемні місця, що знижує витрати на виправлення. Скорочення часу на доробки — до 30% порівняно з ad-hoc підходом.
Етапи розробки idle/clicker гри
- Архітектура: проектування балансу, розрахунок кривої прогресії, вибір стеку (Unity, Firebase/Supabase).
- Прототип: MVP з 3–5 апгрейдами, базовим офлайн-розрахунком та тестовою рекламою.
- Фінальний білд: повний функціонал (дерево розвитку, пресет, досягнення), інтеграція IAP (StoreKit 2, Google Play Billing 6), аналітики (Firebase, Amplitude).
- Публікація: підготовка метаданих, скріншотів, проходження рев'ю App Store та Google Play.
- Підтримка: 30 днів після релізу — виправлення багів, моніторинг серверів.
Як ми забезпечуємо якість?
Кожен етап супроводжується код-рев'ю та юніт-тестами. Використовуємо Continuous Integration (GitHub Actions) для автоматичної збірки та перевірки на регресії. Перед публікацією проводимо навантажувальне тестування серверної частини (до 10k одночасних користувачів). Наш досвід 5 років та сертифікація Unity гарантують якість. Наші ігри проходять модерацію магазинів з першого разу. Ми гарантуємо проходження рев'ю та підтримку 30 днів. Якщо гра вже запущена, ми проводимо аудит кривої прогресії та ціноутворення IAP.
| Метод | Retention (D30) | DAU |
|---|---|---|
| Базова офлайн-механіка | 30% | 5k |
| + Push-сповіщення | 40% | 7.5k |
| + Пресет | 45% | 9k |
Пресет-система підвищує retention в 1.5 рази порівняно з базовою офлайн-механікою. Терміни: базовий idle/clicker — 6–10 тижнів. З розширеним контентом — 3–4 місяці. Вартість розраховується індивідуально. Замовте розробку idle/clicker-гри під ключ — отримайте консультацію та демонстрацію прототипу. Зв'яжіться з нами для обговорення вашого проекту.