Проектирование экономики мобильной игры от match-3 до стратегий

Мы проектируем сбалансированную экономику для мобильных игр: от match-3 до стратегий. Если источники ресурсов превышают стоки, наступает инфляция: игрок накапливает валюту быстрее, чем тратит, цены перестают быть значимыми, а IAP теряет привлекательность. Если стоки слишком агрессивны — игра воспринимается как pay-to-win и теряет аудиторию. Наш подход — числовой дизайн до запуска, а не по фидбеку после релиза. Опыт команды — 10+ проектов в мобильных играх, 5 лет на рынке геймдизайна.

Правильная экономика незаметна для игрока. Он не думает о балансе — он думает о том, что хочет купить следующим. Мы гарантируем точность расчётов и используем проверенные инструменты: Google Sheets с формулами прогрессии и Machinations для симуляции.

Валютная система как основа

Большинство мидкор-игр работают на dual-currency архитектуре, но часто её реализуют с ошибками. Типичная проблема: слишком щедрые источники мягкой валюты.

Игрок получает 500 золота за уровень, а апгрейд стоит 300. Через неделю у него 50 000 золота, и он понимает, что деньги в игре ничего не стоят. Когда ему предлагают купить 1000 золота за $1.99 — это выглядит абсурдно, у него и так полный кошелёк.

Исправить это после запуска крайне тяжело: нельзя просто «сделать золото дороже» — существующие игроки взбунтуются. Поэтому балансировку нужно делать до запуска, на бумаге.

Проектирование источников (sources)

Каждый источник ресурса классифицируем по:

• Предсказуемость: регулярный (ежедневный логин) vs случайный (дроп из моба)
• Зависимость от активности: активный (прохождение уровня) vs пассивный (ферма, таймер)
• Количество: фиксированное vs вариативное (с рандомом)

Для прогнозирования экономики строим таблицу норм: сколько игрок зарабатывает в день при casual-, mid- и hardcore-уровне активности.

Стоки: куда уходит валюта

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

Хорошие стоки для мягкой валюты:

• Апгрейды с растущей стоимостью (каждый уровень в 1.5–2 раза дороже предыдущего)
• Расходники с постоянным потреблением (зелья, патроны, энергия)
• Ежедневные ротируемые предложения в магазине

Хорошие стоки для твёрдой валюты:

• Ускорение таймеров
• Открытие слотов (инвентарь, очереди строительства)
• Покупка эксклюзивного контента (скины, юниты)
• Продолжение после поражения

Как предотвратить инфляцию в игровой экономике?

Hard caps. Ограничение на максимальное количество валюты, которое можно хранить без IAP. Например, максимум 10 000 золота без «кошелька». Игрок, достигший лимита, либо тратит, либо покупает расширение хранилища.

Срочные события. Ивенты с эксклюзивными наградами создают временный дефицит: игрок тратит накопленное на ивент-контент. Flash sales работают по той же логике.

Decay-механика. Валюта, полученная через passive sources (ферма), прекращает накапливаться после достижения capacity. Это вынуждает игрока заходить регулярно и тратить.

Числовой дизайн: пример расчёта

Допустим, у нас match-3 с уровнями. Параметры:

• Средняя длина уровня: 2–3 минуты
• Средняя сессия: 20–25 минут = 8–10 уровней
• Жизни: 5, восстановление 1 жизнь / 30 минут

Источники золота за сессию (casual-игрок):

• 8 уровней × 50 золота = 400 за прохождение
• Ежедневный бонус: 100 золота
• Итого: ~500 золота в день

Стоки: extra lives через IAP или gold (150 gold = 1 жизнь), booster (200 gold). Если игрок тратит в среднем 2 жизни/день = 300 gold. Остаток: 200 gold/day — нужен дополнительный сток или уменьшение источников.

После балансировки добавляем событие «удвоенный дроп по выходным» — это не ломает экономику, но создаёт причину играть активнее.

Почему важен правильный monetization cliff?

Monetization cliff — момент в игре, где бесплатный прогресс резко замедляется и игрок упирается в стену. Либо платит, либо гриндит часами, либо уходит.

Правильный подход — не стена, а наклонная поверхность: прогресс без платёжей возможен, но платёж делает его значительно комфортнее. Разница между «платишь или страдаешь» и «платишь или чуть медленнее» принципиальна для long-term retention.

Проектирование cliff требует знания кривой прогрессии: на каком уровне средняя сложность превышает среднее умение игрока? Этот момент — точка предложения, а не стена.

Ресурсная экономика в стратегиях

В стратегиях (builder, 4X) экономика сложнее: несколько типов ресурсов с разными скоростями добычи, зависимостями между ними и временными таймерами.

Ключевой инструмент — матрица ресурсов: таблица, где строки — типы ресурсов, столбцы — источники и стоки. Для каждой ячейки: количество, условие, периодичность. Это позволяет увидеть дисбалансы до имплементации.

Пример: если wood и stone добываются с одинаковой скоростью, но stone нужен в 3 раза больше для апгрейдов — stone становится bottleneck. Это не обязательно плохо, но должно быть сознательным решением, а не случайностью.

Инструменты для проектирования

Экономику проектируем в Google Sheets с формулами прогрессии, не в голове. Базовая модель: колонки — дни (1–30), строки — источники/стоки/баланс для каждого типа валюты. Три сценария: casual / average / hardcore.

Для сложных экономик используем Machinations — визуальный язык для моделирования игровых экономик, позволяет симулировать поведение системы без кода.

Что входит в проектирование экономики

В результат работы входит:

• Документация валютной системы: типы валют, конвертации, лимиты
• Таблица источников и стоков с 30-дневной симуляцией для трёх сценариев
• Прогрессионная кривая сложности с указанием точек монетизации
• Описание анти-инфляционных механик
• Техническое задание для разработчиков
• Консультация после внедрения (до 2 часов)

Наш опыт: 10+ проектов для мобильных игр, 5 лет работы на рынке геймдизайна. Мы гарантируем, что экономика будет сбалансирована до запуска и не потребует срочных правок после релиза.

Этапы работы

1. Анализ жанра и механик игры — что игрок делает, какие ресурсы нужны для прогресса
2. Проектирование валютной системы: количество валют, типы, конвертации
3. Карта источников и стоков с расчётом дневного баланса
4. Прогрессионная кривая сложности и монетизации
5. Анти-инфляционные механики
6. Числовые модели в таблице с симуляцией 30-дневного цикла
7. Техническое ТЗ для разработки системы

Срок проектирования базовой экономики — 3–5 дней. Комплексная многоресурсная экономика для стратегии или RPG — 1–2 недели. Стоимость рассчитывается по объёму и сложности системы. Свяжитесь с нами — оценим ваш проект за один рабочий день.

Монетизация мобильных приложений: IAP, подписки и рекламная медиация

Приложение с плохо реализованными покупками теряет деньги не потому что пользователи не хотят платить, а потому что StoreKit транзакция зависает, Receipt Validation падает с ошибкой или restore purchases не работает — и пользователь пишет в поддержку или оставляет 1 звезду. Наш опыт (более 7 лет в мобильной разработке) показывает, что грамотная монетизация увеличивает LTV на 30–60% уже в первые три месяца после внедрения. Получите консультацию по монетизации вашего приложения — проанализируем текущую модель и найдём точки роста.

Почему StoreKit 2 — лучший выбор для IAP?

StoreKit 2 (iOS 15+) — современный API с async/await и верифицированными транзакциями на стороне устройства без сервера. Transaction.currentEntitlements возвращает все активные покупки. Ключевое изменение по сравнению со StoreKit 1: верификация JWS-подписи на устройстве через VerificationResult<Transaction> — не нужно отправлять receipt на сервер для базовой проверки.

Но сервер-сайд валидация всё равно нужна для consumable покупок и против fraud. App Store Server API заменяет старый /verifyReceipt endpoint. Вебхуки через App Store Server Notifications v2 дают real-time события: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — без поллинга.

Типичная ошибка: не обрабатывают paymentQueue(_:updatedTransactions:) в фоне для незавершённых транзакций. Пользователь купил consumable, приложение упало до finishTransaction — покупка висит в очереди, при следующем запуске восстанавливается и требует повторной обработки на сервере. Без идемпотентности сервера — двойное начисление.

Как не потерять доход на подписках?

Подписочная модель требует отслеживания состояний: триал → активная → grace period → expired → refunded. RevenueCat — фактический стандарт для управления подписками в продакшне. Абстрагирует StoreKit и Google Play Billing, даёт unified API, webhooks, аналитику когорт и A/B тесты paywall.

Альтернатива RevenueCat — своя реализация с Adapty или Qonversion. Полностью кастомная — только если данные не должны покидать инфраструктуру или есть нестандартная логика. Мы гарантируем, что настройка webhooks и обработка событий жизни подписки выполняется без потерь — проверено на проектах с аудиторией более 500 тыс. DAU.

Google Play Billing Library 6+ требует обработки PurchasesUpdatedListener и явного вызова acknowledgePurchase() или consumePurchase() в течение 3 дней — иначе Google автоматически отменяет покупку и возвращает деньги. Средняя стоимость такой ошибки — потеря $0.3–0.8 на пользователя в месяц (по данным наших проектов).

Рекламная медиация: повышение CPM через bidding

Показывать рекламу через один источник — значит терять доход. Медиация (waterfall или bidding) запрашивает рекламу у нескольких сетей и показывает лучшую ставку. Google AdMob — основа для banner, interstitial, rewarded. Медиация через AdMob Mediation или MAX (AppLovin) — второй де-факто стандарт. MAX использует In-App Bidding — real-time аукцион без водопада. На практике MAX даёт CPM на 15-30% выше классического waterfall (зависит от гео и аудитории). В США для rewarded видео CPM может превышать $20. При 100 000 показов rewarded видео в день переход с waterfall на In-App Bidding может приносить дополнительно $50-100 ежедневно.

ironSource (Unity Ads) — сильная позиция в игровом сегменте, особенно rewarded video. Mintegral — хорошо закрывает азиатскую аудиторию.

Настройка медиации требует ATT (App Tracking Transparency) на iOS 14+. Без requestTrackingAuthorization рекламный CPM падает в 3-5 раз для не-согласившихся пользователей. SKAdNetwork и Privacy Manifest (iOS 17) — обязательные требования, без которых ревью падает.

Как мы внедряем монетизацию: пошаговый процесс

1. Аудит текущей модели — анализ воронки, paywall, ценовых тиров и выявление узких мест.
2. Проектирование модели — выбор типа (subscription, consumable, non-consumable) и оптимизация ценовых точек.
3. Интеграция IAP — настройка StoreKit 2 / Google Billing 6, receip-валидация, webhooks.
4. Рекламная медиация — подключение 3-6 сетей, настройка waterfall или In-App Bidding, тестирование fill rate.
5. Аналитика и когорты — интеграция RevenueCat, Amplitude или Firebase для отслеживания LTV.
6. A/B тестирование paywall — использование Remote Config для экспериментов без релиза.
7. Запуск и мониторинг — 2 недели бесплатной поддержки после запуска, фикс багов по SLA 24 часа.

Freemium: проектирование модели и paywall

Freemium работает когда граница между бесплатным и платным проведена правильно. Слишком жёсткий paywall на старте — пользователь удаляет. Слишком щедрый бесплатный тир — нет стимула платить.

Паттерн, который работает технически: feature flags с сервера (Remote Config в Firebase или LaunchDarkly) управляют доступом к фичам. Это позволяет A/B тестировать paywall без релиза, менять условия триала, проводить акции.

Реализация на уровне кода: EntitlementManager — единая точка проверки доступа к фичам, которая знает о статусе подписки, флагах и промо. Никаких проверок isPremium разбросанных по всему коду. Опыт показывает: такой подход снижает количество багов с paywall на 80% (подтверждено на 30+ проектах).

Объём работ по монетизации

• Аудит текущей модели — анализ воронки, paywall, ценовых тиров.
• Интеграция IAP — StoreKit 2 / Google Billing 6, receip-валидация, webhooks.
• Рекламная медиация — настройка MAX / AdMob, подключение 3-6 сетей, тестирование fill rate.
• Настройка аналитики — RevenueCat, Amplitude / Firebase, когортный анализ.
• Документация — описание энтитлментов, процедура восстановления, чек-лист ревью.
• Обучение команды — разбор типовых ошибок, рекомендации по поддержке.
• Гарантия — бесплатная поддержка 2 недели после запуска, фикс багов по SLA 24 часа.

Сроки ориентировочно

Стоимость рассчитывается индивидуально. Мы работаем в этой сфере более 8 лет и реализовали более 40 проектов с монетизацией — многие из них прошли App Store Review без единой блокировки. Свяжитесь с нами для аудита или закажите консультацию — расскажем, какие точки роста есть в вашем приложении.

Источники: Apple StoreKit 2 Documentation, RevenueCat Best Practices, Wikipedia: Freemium.