Балансировка параметров мобильной игры

Балансировка параметров мобильной игры

Баланс — это не таблица в 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 монетизация — там баланс другой.

Типичные сигналы проблем в аналитике:

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% — рейтинговая система не работает.

Процесс итерации баланса

Итерация должна быть быстрой. Схема:

1. Гипотеза: «Level 12 слишком сложный — pass rate 23%, норма 55-65%»
2. Изменение: снижаем HP врагов уровня на 20% через Remote Config
3. Выкатка: на 10% аудитории (A/B тест через Firebase)
4. Измерение: через 3 дня смотрим pass rate и retention в экспериментальной группе
5. Решение: если pass rate 58% и retention не упал — выкатываем на 100%

Без A/B тестирования итерации баланса — слепые полёты. Изменение может улучшить одну метрику и убить другую.

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

• Аудит текущих аналитических данных: retention по уровням, drop points, экономические потоки
• Разработка или аудит математической модели прогрессии
• Настройка аналитических событий для балансировочных данных
• Вынос балансных параметров в Remote Config / Addressables для hot-patch
• Проектирование баланс-таблицы с зависимостями
• Настройка A/B тестирования для итераций
• Рекомендации по matchmaking для PvP (если применимо)

Сроки

Аудит и рекомендации по балансу существующей игры: 3–5 дней. Полное проектирование системы баланса с нуля + аналитика: 2–4 недели. Стоимость рассчитывается индивидуально.