Разработка внутриигровой монетизации

Разработка внутриигровой монетизации

Монетизация — это часть игровой механики, а не надстройка над ней. Когда систему покупок добавляют в конце разработки, она либо нарушает игровой баланс, либо воспринимается игроком как инородное тело. Оба варианта приводят к плохим отзывам и низкому ARPU.

Типы монетизации и их техническая реализация

IAP (In-App Purchases)

Основной инструмент для мобильных игр. На Unity реализуется через Unity IAP пакет — единый API для Google Play Billing и Apple StoreKit. Базовая интеграция несложная, но есть нюансы:

Receipt validation. Проверка чека на клиенте бесполезна — любой рутованный Android позволяет сгенерировать фейковый чек. Серверная валидация обязательна: клиент отправляет receipt на бэкенд, бэкенд проверяет через Google Play Developer API или Apple App Store Server API, затем начисляет валюту. Без этого любой читер получает бесплатную валюту за 5 минут.

Consumable vs. Non-consumable vs. Subscription. Consumables (кристаллы, монеты) требуют подтверждения транзакции после начисления: controller.ConfirmPendingPurchase(product). Если не вызвать — Google/Apple вернёт покупку при следующем запуске. Non-consumables (разблокировка контента) должны восстанавливаться через RestorePurchases() — это требование App Store.

Оффлайн-устойчивость. Покупка может начаться при хорошем соединении и завершиться при плохом. Храним состояние транзакции локально (PlayerPrefs или SQLite), обрабатываем pending purchases при следующем запуске.

Игровая валюта и экономика

Двойная валюта (мягкая + твёрдая) — стандарт для мидкор игр. Техническая реализация:

• Бэкенд как источник истины. Баланс валют хранится на сервере, клиент — только отображает. Локальный кэш для отзывчивости UI, но всегда синхронизируется с сервером. PlayFab Virtual Currency — готовое решение с транзакционностью и историей операций.
• Защита от race condition. Параллельные запросы на списание (одновременное нажатие кнопки покупки) должны обрабатываться атомарно. PlayFab CloudScript выполняется в одном потоке на пользователя — это решает проблему. Собственный бэкенд требует транзакций в БД.
• Аудит транзакций. Каждое изменение баланса — запись в лог с причиной, суммой, timestamp. Без этого невозможно расследовать жалобы игроков и детектировать аномалии.

Реклама (Ad Monetization)

Для гипер-казуальных и казуальных игр — основной источник дохода. Стек:

• UnityAds — наиболее простая интеграция для Unity-проектов.
• IronSource / AppLovin MAX — mediation платформы, позволяют конкурировать нескольким ad-сетям за показ. Ставки выше на 20-40% по сравнению с одной сетью.
• Rewarded Video требует корректной интеграции с геймплеем: показываем рекламу только в органических точках (Game Over, перед бонусным уровнем), не принудительно.

Interstitial между уровнями — ставим через счётчик, не после каждого уровня. Частота определяется A/B тестированием через Firebase Remote Config или PlayFab Experiments.

LiveOps и события

Временные события, battle pass, сезонный контент — это отдельная инфраструктура. Конфигурация событий живёт на сервере, клиент скачивает при запуске. PlayFab Title Data или собственное CMS. Важно: клиент не должен хардкодить даты событий — это гарантированный баг при изменении расписания.

Battle Pass технически: track прогресса в PlayFab Statistics, milestone rewards через PlayFab CloudScript, отображение прогресса через Addressable-бандлы с иконками наград (чтобы не раздувать base build).

Почему монетизацию нельзя добавлять в конце

Реальный кейс: мобильный match-3, баланс прогрессии спроектирован под fun, без учёта монетизации. На этапе интеграции IAP выяснилось, что игрок проходит весь контент за 4 часа без единой покупки. Пришлось переделывать кривую сложности и добавлять energy system — что потребовало переработки 60% геймплейных систем.

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

Процесс работы

Аудит или проектирование (3-5 дней). Анализ жанра и конкурентов, выбор монетизационной модели, проектирование экономики (sink/source баланс ресурсов).

Бэкенд-инфраструктура (1-2 недели). Настройка PlayFab или собственного бэкенда: валюты, каталог предметов, CloudScript для транзакций, серверная валидация чеков.

Клиентская интеграция (1-2 недели). Unity IAP, UI магазина, интеграция с геймплеем, обработка edge cases (нет сети, failed purchase, restore).

Аналитика (3-5 дней). Настройка воронок конверсии в Firebase/Amplitude: просмотр магазина → инициация покупки → успешная покупка. Отслеживание retention в разрезе монетизационных сегментов.

QA. Sandbox-тестирование IAP на тестовых аккаунтах Google и Apple. Проверка всех edge cases: отмена покупки, failed payment, восстановление покупок.

Стоимость рассчитывается после анализа требований и выбранного стека.