Retention падает, когда на второй неделе игроки видят, что прогресс застопорился. Причина — неверная кривая прогрессии: числа уходят в бесконечность, генераторы становятся бесполезны. Исправляем это математикой ещё на этапе проектирования. Мы создаём idle/clicker-игры с нуля — от прототипа до публикации в магазинах. Опыт более 5 лет и 8 проектов показывает: правильно настроенная прогрессия и офлайн-механика дают retention выше 40% на 30-й день. Грамотная монетизация увеличивает LTV на 25% — в этом помогает баланс между рекламой и IAP. Средний ARPU для idle-игр — $0.8–$1.5, а ROI от рекламы может достигать 400%.
Проблемы, которые решаем
Основные технические сложности 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 одновременных пользователей). Наши игры проходят модерацию магазинов с первого раза.
| Метод | Retention (D30) | DAU |
|---|---|---|
| Базовая офлайн-механика | 30% | 5k |
| + Push-уведомления | 40% | 7.5k |
| + Пресест | 45% | 9k |
Сроки: базовый idle/clicker — 6–10 недель. С расширенным контентом — 3–4 месяца. Стоимость рассчитывается индивидуально. Закажите разработку idle/clicker-игры под ключ — получите консультацию и демонстрацию прототипа. Свяжитесь с нами для обсуждения вашего проекта.