Розробка внутрішньоігрової монетизації та ігрової економіки

Ми розробляємо системи внутрішньоігрової монетизації з урахуванням балансу та користувацького досвіду. Понад 8 років ми інтегруємо IAP, рекламу в іграх та підписки для ігор різних жанрів — від гіпер-казуальних до мідкор RPG. Наша команда реалізувала монетизацію в 40+ проектах, використовуючи перевірені стеки: Unity IAP, PlayFab, AppLovin MAX. Коли монетизацію додають наприкінці розробки, вона або порушує ігровий баланс, або сприймається гравцем як чужорідне тіло — це знижує ARPU та рейтинг. Зв'яжіться з нами для аудиту або проектування монетизаційної моделі. Вартість базової інтеграції IAP (1-3 продукти) — від $1,000, а економія від правильної монетизації може досягати $10,000 щомісяця для середнього проекту.

Як працюють 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 рекомендує саме такий підхід. Серверна валідація надійніша за клієнтську в 100 разів.

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

Офлайн-стійкість. Покупка може початися при хорошому з'єднанні та завершитися при поганому. Зберігаємо стан транзакції локально (PlayerPrefs або SQLite), обробляємо pending purchases при наступному запуску. Це в 10 разів знижує кількість втрачених транзакцій порівняно з ігноруванням документації PlayFab.

Як реалізувати подвійну валюту?

Подвійна валюта (м'яка + тверда) — стандарт для мідкор ігор. Основою ігрової економіки є подвійна валюта. Технічна реалізація:

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

Як інтегрувати рекламу без шкоди геймплею?

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

• UnityAds — найпростіша інтеграція для Unity-проектів.
• IronSource / AppLovin MAX — mediation платформи, дозволяють конкурувати декільком ad-мережам за показ. Mediation платформи (AppLovin MAX) працюють краще за одиночні ad-мережі в 1.2-1.4 раза, ставки вищі на 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. Наприклад, у платформерах без coyote time гравець програє 20% спроб через відчуття «нечесної» смерті. Або в лінійному прискоренні, яке не дає відчуття ваги — замінюємо на криву початкового ривка з подальшим загасанням. Ми це виправляємо на етапі прототипу, скорочуючи подальші правки на 40%.

Окрема категорія — економіка. Без попередньої математичної моделі розвал настає через місяць після релізу. Тому ми починаємо з прогресії: лінійна, експоненціальна або поліноміальна. Наприклад, для RPG використовуємо поліном a * n^b з b=2.0, перевіряючи, скільки годин гравець витратить на кожен рівень. Це дає прогнозований час гри і дозволяє уникнути дисбалансу монетизації.

Які послуги з геймдизайну ми пропонуємо?

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

Що входить в роботу (deliverables):

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

Оцініть ваш проект — зв'яжіться для розрахунку термінів. Підхід заснований на методології MDA та досвіді 50+ реалізованих проектів, більше 10 років на ринку. Наші замовники економлять від 2 до 3 тижнів на ітераціях завдяки чіткому процесу.

Як спроектувати бойову систему без помилок?

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

Вибір методу hit detection

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

Налаштування вікон атаки

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

Побудова 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 мс». Думки без чисел не приймаються. Фіксуємо відчуття, змінюємо числа, повторюємо. Завдяки цьому середня економія бюджету на етапі ітерацій становить 15–20%.

Зв'яжіться для консультації — ми оцінимо терміни та бюджет вашого проекту. Отримайте прототип core loop за 3 тижні. Сертифіковані фахівці Unity/Unreal гарантують дотримання термінів.