Проектування економіки мобільної гри від 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 автоматично скасовує покупку та повертає гроші. Середня вартість такої помилки — втрата значної суми на користувача на місяць (за даними наших проектів).

Рекламна медіація: підвищення 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 може перевищувати певну суму. При 100 000 показів rewarded відео на день перехід з waterfall на In-App Bidding може приносити додатково значну суму щоденно.

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, receipt-валідація, 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 на старті — користувач видаляє. Занадто щедрий безкоштовний тир — немає стимулу платити.

Як проєктувати paywall для freemium?

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

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

Обсяг робіт з монетизації

• Аудит поточної моделі — аналіз воронки, paywall, цінових тирів.
• Інтеграція IAP — StoreKit 2 / Google Billing 6, receipt-валідація, 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.