Балансировка параметрів мобільної гри
Баланс — це не таблиця в Excel з числами, які правлять раз у квартал. Це жива система, в якій зміна одного параметра переміщує точку оптимального вибору по всьому дереву прогресії. Підвищили урон базового меча на 15% — гравці перестали купувати «Меч героя» в магазині, ARPU впав на 12% за тиждень. Таке відбувається регулярно.
Балансировка в мобільних іграх розв'язує одночасно кілька завдань: управління складністю (щоб не було ні надто легко, ні надто складно), управління економікою (хто, коли й за що платить), й управління retention (гравець повинен хотіти повернутися завтра).
Математичні моделі прогресії
Основа будь-якого балансу — крива прогресії. Для RPG, стратегій і більшості casual-ігор використовуються степеневі або експоненціальні залежності:
Вартість наступного рівня:
cost(n) = base_cost × growth_factor^n
Наприклад: base_cost = 100, growth_factor = 1.5. Тоді:
- Рівень 1: 100
- Рівень 5: ~759
- Рівень 10: ~5766
- Рівень 20: ~332 525
При growth_factor > 1.6 прогресія стає занадто крутою — гравець упирається в стіну й або платить, або йде. При < 1.3 — занадто пологою, нема відчуття досягнення.
Крива складності рівнів:
enemy_hp(level) = base_hp × (1 + level × difficulty_scale)
player_dps(level) = base_dps × (1 + level × power_scale)
Ключевий параметр — співвідношення difficulty_scale / power_scale. Якщо гравець отримує силу швидше ростання складності (power_scale > difficulty_scale) — гра стає тривіальною до середини. Якщо повільніше — з'являється pay-wall.
Інструментарій і процес
Балансировка не робиться вслепу — потрібні дані. Для цього використовуємо комбінацію:
GameAnalytics / PlayFab Analytics — дивимось retention по рівнях, відсоток прохождення, місце першого виходу:
// Логуємо смерть з контекстом
GameAnalytics.NewProgressionEvent(
GAProgressionStatus.Fail,
"world_1", "level_07",
score: remainingHP // здоровя при смерті як проксі складності
);
// Логуємо час прохождення
GameAnalytics.NewDesignEvent("Level:CompletionTime:world1_07",
(float)completionTime.TotalSeconds);
За подією score = remainingHP при Fail видно, наскільки близько гравець підходить до перемоги. remainingHP = 5% означає «майже пройшов» — трошки знизити складність. remainingHP = 80% — «навіть не почав» — значний розрив у балансі.
Google Sheets / Airtable як balance sheet. Параметри ворогів, предметів, здібностей — у таблиці з формулами. Зміна однієї комірки перераховує всі залежні значення. Потім JSON/CSV експортується в гру через Remote Config або Addressables:
// Unity: завантаження баланс-таблиці з Addressables
var balanceHandle = Addressables.LoadAssetAsync<BalanceConfig>("balance_config");
await balanceHandle.Task;
BalanceManager.Instance.ApplyConfig(balanceHandle.Result);
Remote Config для hot-patch балансу. Критичні параметри (drop rate, ціни магазину, множники урона) через Firebase Remote Config — змінюються без оновлення:
var remoteConfig = FirebaseRemoteConfig.DefaultInstance;
await remoteConfig.FetchAndActivateAsync();
float bossHealthMultiplier = (float)remoteConfig.GetValue("boss_health_multiplier").DoubleValue;
float goldDropRate = (float)remoteConfig.GetValue("gold_drop_rate").DoubleValue;
Економіка: три кити
Джерела валюти (Sources): квести, рівні, щоденні бонуси, досягнення, іноді реклама. Повинні бути передбачувальними — гравець планує накопичення.
Стоки (Sinks): апгрейди, витрачаємі предмети, розблокування контенту, косметика. Повинні споживати валюту активно, інакше вона знецінюється.
Обмінний курс: скільки реального часу потрібно для отримання одиниці ігрової цінності без платежу. Це й є головний важіль монетизації.
Баланс здоровий, якщо час до досягнення цілі без оплати залишається розумним (1–3 дні на наступну значиму ціль), а оплата прискорює, але не блокує прогрес. Виключення: cosmetic-only монетизація — там баланс інший.
Типичні сигнали проблем в аналітиці:
| Симптом | Ймовірна причина |
|---|---|
| Day-7 retention різко падає на конкретному рівні | Занадто висока складність, pay-wall |
| Конверсія в першу покупку < 1% | Нема відчуття «потреби» в валюті |
| ARPU високий, але DAU падає | Монетизація агресивна, гра відштовхує |
| Середній час сесії < 3 хвилин | Нема «ще один хід» механіки, петля занадто коротка |
PvP і мультиплеєр: matchmaking й рейтинг
У PvP-іграх баланс ускладнюється системою матчмейкингу. ELO-подібні системи (TrueSkill, Glicko-2) використовуються як основа, але з мобільними обмеженнями: не можна довго тримати гравця в очереді. Звичайний компроміс — tight skill range в перші 15 секунд очереди, wider range після:
float skillRange = Mathf.Lerp(50f, 300f,
Mathf.Clamp01(queueTime / maxQueueTime));
var opponent = MatchmakingService.FindOpponent(playerRating, skillRange);
Дані матчів потрібно логувати й аналізувати: якщо win rate топ-10% гравців > 75% — рейтингова система не працює.
Процес ітерації балансу
Ітерація повинна бути швидкою. Схема:
- Гіпотеза: «Level 12 занадто складний — pass rate 23%, норма 55-65%»
- Зміна: знижуємо HP ворогів рівня на 20% через Remote Config
- Вкатка: на 10% аудиторії (A/B тест через Firebase)
- Вимір: через 3 дні дивимось pass rate й retention в експериментальній групі
- Рішення: якщо pass rate 58% й retention не впав — вкатуємо на 100%
Без A/B тестування ітерації балансу — сліпі польоти. Зміна може покращити одну метрику й вбити іншу.
Що входить у роботу
- Аудит поточних аналітичних даних: retention по рівнях, drop points, економічні потоки
- Розробка або аудит математичної моделі прогресії
- Настройка аналітичних подій для балансовочних даних
- Вивід балансних параметрів у Remote Config / Addressables для hot-patch
- Проектування баланс-таблиці з залежностями
- Настройка A/B тестування для ітерацій
- Рекомендації по matchmaking для PvP (якщо застосовується)
Терміни
Аудит й рекомендації по балансу існуючої гри: 3–5 днів. Повне проектування системи балансу з нуля + аналітика: 2–4 тижні. Вартість розраховується індивідуально.