Балансування ігрових параметрів і характеристик предметів
Балансування — це не «зменшити урон мечника на 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 < 3 сек (ситуації миттєвої смерті)
- Весь діапазон рівнів покритий предметами з правильним budget-значенням
- Немає характеристики з нульовою або негативною «корисністю» (які гравці завжди ігнорують)
- Перевірені edge case: максимальний крит стек, максимальна швидкість атаки, нульовий урон від броні
- У кожного класу є хоча б одна домінуюча роль в енкаунтерах, щоб жоден не був «строго гірше»