Балансировка игровых параметров и характеристик предметов
Балансировка — это не «уменьшить урон мечника на 10%, потому что он кажется слишком сильным». Это системная работа с данными: построить матрицу DPS по классам, посчитать TTK (time to kill) для каждой пары атакующий/защитник, найти выбросы и объяснить их причину.
Метрики, которые нужно считать перед правкой цифр
DPS (damage per second) — базовая метрика атаки. Считается с учётом скорости атаки, критического шанса и критического множителя: DPS = baseDamage * attacksPerSecond * (1 + critChance * (critMultiplier - 1)). Если у мага DPS = 450, а у воина DPS = 280, но воин при этом имеет 3x HP — их EHP/DPS соотношение нужно смотреть в паре.
EHP (effective hit points) — HP с учётом брони и уклонения: EHP = HP / (1 - damageReduction). При damageReduction = 0.4 и HP = 1000 получаем EHP = 1667. Это честное сравнение живучести классов разных архетипов.
TTK — для PvP и encounter design. TTK = EHP_target / DPS_attacker. Если TTK для всех комбинаций классов лежит в диапазоне 8–15 секунд, бои интересны. TTK < 3 секунды означает, что один класс просто уничтожает другого до первого ответного действия.
Эти три метрики строятся в таблице для всех классов, уровней и ключевых сетов экипировки — и обновляются при каждом изменении базовых параметров.
Балансировка предметов: от ScriptableObject к матрице
Каждый предмет в Unity описывается ItemDefinition ScriptableObject с полями характеристик. Балансировочная работа происходит не в редакторе Unity — там слишком неудобно сравнивать 200 предметов. Данные экспортируются в CSV, открываются в Excel/Google Sheets, там строятся сводные таблицы и диаграммы.
Budget system — стандартный подход к балансировке предметов. Каждый предмет имеет «бюджет» очков характеристик, пропорциональный редкости и уровню. Common-предмет уровня 20 имеет бюджет 100, Rare — 150, Legendary — 220. Характеристики внутри предмета тратят этот бюджет по таблице «стоимость единицы характеристики»: 1 единица урона = 2 бюджета, 1 единица HP = 1 бюджет, 1% критического шанса = 3 бюджета.
Это позволяет быстро проверить предмет: если Legendary меч уровня 20 по характеристикам выходит за 220 бюджета — он сломан. Если сильно ниже — он бесполезен. После настройки коэффициентов новые предметы добавляются без индивидуальной проверки — они автоматически укладываются в баланс.
Генерируемые предметы и диапазоны
В играх с процедурной генерацией предметов баланс задаётся не фиксированными значениями, а диапазонами: damage: [min, max] для каждого уровня. Разброс не должен быть слишком широким — предмет с damage: 10–90 при среднем 50 даёт игроку слишком много «лотерейных» ощущений и размывает прогрессию. Разброс ±20–30% от среднего — рабочий диапазон для большинства RPG.
Аффиксы на случайных предметах тоже берутся из пула с весами. AffixPool ScriptableObject хранит List<AffixDefinition> с weight у каждого — чем реже аффикс, тем меньше вес. WeightedRandom выборка при генерации. Важно: сумма весов не обязана равняться 100 — алгоритм считает вероятность как weight / totalWeight.
Баланс PvE-энкаунтеров
Encounter design — это тоже математика. Для каждого энкаунтера считается encounter budget: сумма «стоимостей» врагов, размещённых дизайнером. Стоимость врага = его HP * (1 + damageModifier) по упрощённой формуле, скалированной к DPS группы игроков для данного уровня.
Если DPS группы из 4 игроков уровня 15 составляет суммарно ~800/сек, а энкаунтер из трёх врагов имеет суммарный EHP 12000 — это 15 секунд боя при нулевых потерях. Добавить механику с прерыванием каста или атакой по площади — и TTK для группы становится длиннее. Это проектируется в таблице до расстановки врагов на уровне.
Инструменты и процесс
Балансировочная работа всегда итеративная. Стандартный цикл: правка таблицы → экспорт CSV → автоматический импорт в ScriptableObject через Editor-скрипт → плейтест → сбор данных → правка таблицы. Ручной перенос цифр исключается с первого дня.
Для онлайн-игр критична возможность горячего обновления баланса без передеплоя билда. Данные баланса в этом случае хранятся на сервере в JSON/CSV и загружаются при старте сессии. Unity-клиент читает их через Remote Config (Unity Gaming Services) или собственный endpoint.
Ориентировочные сроки
| Задача | Срок |
|---|---|
| Балансировка одного класса/типа предметов | 2–4 дня |
| Полный баланс 3–5 классов + предметные наборы | 2–3 недели |
| Балансировка + инструментарий импорта + аналитика | 4–6 недель |
Пять вещей, которые нужно проверить до финального баланса
- Нет ли в матрице TTK пар с TTK < 3 сек (instant kill ситуации)
- Покрыт ли весь диапазон уровней предметами с правильным budget-значением
- Нет ли характеристики с нулевой или отрицательной «полезностью» (которую игроки всегда игнорируют)
- Проверены ли edge case: максимальный крит стек, максимальная скорость атаки, нулевой урон от брони
- Есть ли у каждого класса хотя бы одна доминирующая роль в энкаунтерах, чтобы ни один не был «строго хуже» другого