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

Мы разрабатываем системы внутриигровой монетизации с учётом баланса и пользовательского опыта. Более 8 лет мы интегрируем IAP, рекламу и подписки для игр разных жанров — от гипер-казуальных до мидкор RPG. Наша команда реализовала монетизацию в 40+ проектах, используя проверенные стеки: Unity IAP, PlayFab, AppLovin MAX. Когда монетизацию добавляют в конце разработки, она либо нарушает игровой баланс, либо воспринимается игроком как инородное тело — это снижает ARPU и рейтинг. Свяжитесь с нами для аудита или проектирования монетизационной модели.

Как работают IAP в Unity и Unreal?

Основной инструмент для мобильных игр — 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 минут. Apple App Store Server API docs рекомендуют именно такой подход.

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

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

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

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

• Бэкенд как источник истины. Баланс валют хранится на сервере, клиент — только отображает. Локальный кэш для отзывчивости 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 с первого дня. Это определяет: кривую прогрессии, структуру валют, точки конверсии, ценность каждого ресурса.

Что входит в работу

• Аудит монетизационной модели — анализ текущей экономики, точек конверсии, конкурентов.
• Проектирование экономики — sink/source баланс, двойная валюта, ценность предметов.
• Интеграция IAP — Unity IAP, серверная валидация, обработка edge cases.
• Настройка рекламы — UnityAds, IronSource/MAX, rewarded video, interstitial.
• Battle Pass и LiveOps — конфигурация событий, трекер прогресса, награды.
• Аналитика монетизации — воронки конверсии, настройка Firebase/Amplitude.
• Документация и обучение — передача инструментов, описание процессов.
• Поддержка после запуска — мониторинг, A/B-тесты, доработки.

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

1. Аналитика и проектирование (3-5 дней). Анализ жанра и конкурентов, выбор монетизационной модели, проектирование экономики (sink/source баланс ресурсов).
2. Бэкенд-инфраструктура (1-2 недели). Настройка PlayFab или собственного бэкенда: валюты, каталог предметов, CloudScript для транзакций, серверная валидация чеков.
3. Клиентская интеграция (1-2 недели). Unity IAP, UI магазина, интеграция с геймплеем, обработка edge cases (нет сети, failed purchase, restore).
4. Аналитика (3-5 дней). Настройка воронок конверсии в Firebase/Amplitude: просмотр магазина → инициация покупки → успешная покупка. Отслеживание retention в разрезе монетизационных сегментов.
5. QA и сэнда́кс. Sandbox-тестирование IAP на тестовых аккаунтах Google и Apple. Проверка всех edge cases: отмена покупки, failed payment, восстановление покупок.

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

Проектирование механик: с чего начинается отзывчивое управление

Прежде чем говорить о геймдизайне, зафиксируем разграничение: геймдизайн — это не «придумать идею». Придумать может любой. Задача — спроектировать систему правил, которая производит конкретный эмоциональный и поведенческий результат. Это инженерная дисциплина, только вместо компилятора — человеческий мозг.

Первая боль: вам кажется, что управление «дубовое», а почему — непонятно. Чаще всего проблема не в коде, а в отсутствии coyote time и jump buffering. Или в линейном ускорении, которое не даёт ощущения веса. Мы это чиним на этапе прототипа.

Какие услуги геймдизайна мы предлагаем

Полный цикл: от концепта до выверенного билда. Под ключ — вы получаете геймдизайн-документ (GDD), таблицы баланса, прототип ключевых механик на Unity/Unreal, и сопровождение вплоть до релиза.

Что входит в работу:

• Документация: GDD, спецификации механик, нарративные деревья, API для разработчиков
• Таблицы баланса: прогрессия, экономика, DPS-калькуляторы
• Прототипы: интерактивные сцены с core loop (движение, бой, инвентарь)
• Конфигурация в движке: ScriptableObject, DataTable, анимационные событий
• Проведение плейтестов и итераций по метрикам (удержание, монетизация, retention)

Оцените ваш проект — свяжитесь для расчёта сроков. Подход основан на методологии MDA и опыте 50+ реализованных проектов с 2012 года.

Как проектировать боевую систему: глубокий разбор

Боевая система — самая дорогая ошибка: на первый взгляд простая, на деле — ад из edge cases. Разберём melee combat.

1. Выбор метода hit detection

Hitbox — коллайдеры на оружии. Просто, но при быстрых атаках возникает tunneling: оружие пролетает сквозь противника за кадр. Решение — Physics.CCD (Continuous Collision Detection), но это дорого. Raycast/spherecast — кастуем лучи вдоль траектории оружия. Точнее, меньше зависит от fps. Мы предпочитаем spherecast для action-игр. Подробнее о методах — в Wikipedia.

2. Настройка окон атаки

Каждая атака — три фазы: Startup, Active, Recovery. Длинный startup создаёт «тяжёлые» удары. Короткий recovery даёт агрессивный стиль. В Unity аниматор кидает событие через AnimationEvent, код включает/выключает hitbox. Типичные тайминги для рукопашного боя: startup 200–400 мс, active 100–150 мс, recovery 300–500 мс.

3. Построение state machine

Персонаж — конечный автомат. Базовые состояния: Idle, Moving, Jumping, Attacking, Hurt, Dead. Бизнес-логику выносим в C#-код, аниматор отвечает только за переходы анимаций. Иерархические state machine (через Override Animator Controller) позволяют вложенные подсостояния, не дублируя переходы.

Почему математическая модель экономики критична?

Экономику «на глаз» не делают — получается развал через месяц после релиза. Базовая прогрессия: линейная (скучно), экспоненциальная (XP(n) = base * multiplier^n, multiplier 1.5–2.0), полиномиальная (a * n^b, b 1.5–2.5). Мы строим таблицы в Google Sheets за 2–3 дня, проверяя, сколько часов игрок потратит на каждый уровень.

Потоки валют

Принцип: каждая валюта — явный источник (tap) и сток (sink). Пример двухвалютной системы:

Однонаправленная конвертация защищает монетизацию. Дисбаланс легко обнаружить по DPS и TTK: если TTK оружия вдвое ниже остальных — оно становится meta. Мы выявляем это на этапе прототипа, сокращая последующие правки на 40%.

Нарратив и левел-дизайн: как обучать без текста

Environmental storytelling — расположение объектов, звуков, следов — часто эффективнее диалогов. Для диалогов используем Ink (интеграция с Unity). Ink-скрипты читает нарративный дизайнер без программиста. Каждый уровень проверяем по принципу: игрок должен понять механику действием, а не по подсказке.

Инструменты в процессе

Итерация и плейтестинг: 2-недельный цикл

Первый прототип всегда неудобен — это норма. Наш цикл: плейтест каждые 2 недели. После — список изменений с числами: «startup 400 мс → 250 мс». Мнения без цифр не принимаются. Фиксируем ощущения, меняем цифры, повторяем.

Свяжитесь для консультации — мы оценим сроки и бюджет вашего проекта. Наши заказчики экономят от 2 до 3 недель на итерациях за счёт чёткого процесса.