Балансування ігрових параметрів та характеристик предметів

Балансування ігрових параметрів та характеристик предметів

Часто після релізу гравці обирають лише одного персонажа, а решта класів простоюють. Ми стикалися з цим десятки разів під час балансування проєктів на Unity та Unreal. Кожного разу ми будуємо матрицю DPS за класами, рахуємо Time to kill (TTK) для кожної пари, знаходимо викиди та пояснюємо їх причину. Спираючись на 10+ років досвіду та понад 50 завершених проєктів, ми гарантуємо математично коректний баланс, який утримує користувачів та зберігає інтерес до гри.

Які метрики ми рахуємо перед правкою цифр?

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 для PvP — 8-15 секунд, згідно з гайдлайнами ігрового дизайну. Якщо TTK для всіх комбінацій класів лежить у цьому діапазоні, бої цікаві. TTK < 3 секунди означає, що один клас просто знищує іншого до першої відповідної дії. Матриця TTK виявляє дисбаланс у 5 разів швидше, ніж ручне тестування.

Ці три метрики будуються в таблиці для всіх класів, рівнів та ключових сетів екіпіровки — і оновлюються при кожній зміні базових параметрів.

Як працює бюджет предметів?

Кожен предмет в Unity описується ItemDefinition ScriptableObject з полями характеристик. Ми не правимо цифри прямо в редакторі — дані експортуються в CSV, відкриваються в Excel/Google Sheets, там будуються зведені таблиці та діаграми.

Budget system — стандартний підхід до балансування предметів. Кожен предмет має «бюджет» очок характеристик, пропорційний рідкості та рівню. Наприклад:

Характеристики всередині предмета витрачають цей бюджет за таблицею «вартість одиниці характеристики»: 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 для групи стає довшим. Це проектується в таблиці до розстановки ворогів на рівні.

Інструменти та процес роботи

Балансувальна робота завжди ітеративна. Стандартний цикл:

1. Правка таблиці в Excel/Google Sheets.
2. Експорт в CSV.
3. Автоматичний імпорт в ScriptableObject через Editor-скрипт.
4. Плейтест з автоматизованим збором метрик.
5. Аналіз даних і повторна правка таблиці.

Ручне перенесення цифр виключається з першого дня. Для онлайн-ігор критична можливість гарячого оновлення балансу без передеплою білда. Дані балансу в цьому випадку зберігаються на сервері в JSON/CSV і завантажуються при старті сесії. Unity-клієнт читає їх через Remote Config (Unity Gaming Services) або власний endpoint.

Що входить в нашу роботу

• Повна матриця DPS/EHP/TTK по всіх класах та рівнях
• CSV-експорт з автоматичним імпортом в ScriptableObject
• Налаштування Budget System та Affix Pool
• Документація з поточного балансу та рекомендації щодо змін
• Тестовий прогін на білді з фіксацією метрик
• Підтримка на етапі патчінгу та гарячого оновлення

Додатково ми надаємо звіт по кожному класу та рекомендації щодо ітерацій. Наша методика скорочує час балансування на 30% — це економія бюджету проєкту.

Орієнтовні терміни

П'ять речей, які потрібно перевірити до фінального балансу

• Чи немає в матриці TTK пар з TTK < 3 сек (instant kill ситуації)
• Чи покритий весь діапазон рівнів предметами з правильним budget-значенням
• Чи немає характеристики з нульовою або від'ємною «корисністю» (яку гравці завжди ігнорують)
• Чи перевірені edge case: максимальний крит стек, максимальна швидкість атаки, нульовий урон від броні
• Чи є у кожного класу хоча б одна домінуюча роль в енкаунтерах, щоб жоден не був «строго гіршим» за іншого

Отримайте консультацію з балансування вашого проєкту — ми оцінимо обсяг та запропонуємо план робіт. Зв'яжіться з нами, щоб замовити повне балансування з інструментарієм імпорту та аналітикою.

Проектування механік: з чого починається чуйне керування

Перш ніж говорити про геймдизайн, зафіксуємо розмежування: геймдизайн — це не «придумати ідею». Придумати може будь-хто. Завдання — спроектувати систему правил, яка виробляє конкретний емоційний та поведінковий результат. Це інженерна дисципліна, тільки замість компілятора — людський мозок.

Перший біль: вам здається, що керування «дубове», а чому — незрозуміло. Найчастіше проблема не в коді, а у відсутності coyote time та jump buffering. Наприклад, у платформерах без coyote time гравець програє 20% спроб через відчуття «нечесної» смерті. Або в лінійному прискоренні, яке не дає відчуття ваги — замінюємо на криву початкового ривка з подальшим загасанням. Ми це виправляємо на етапі прототипу, скорочуючи подальші правки на 40%.

Окрема категорія — економіка. Без попередньої математичної моделі розвал настає через місяць після релізу. Тому ми починаємо з прогресії: лінійна, експоненціальна або поліноміальна. Наприклад, для RPG використовуємо поліном a * n^b з b=2.0, перевіряючи, скільки годин гравець витратить на кожен рівень. Це дає прогнозований час гри і дозволяє уникнути дисбалансу монетизації.

Які послуги з геймдизайну ми пропонуємо?

Повний цикл: від концепту до вивіреного білду. Під ключ — ви отримуєте геймдизайн-документ (GDD), таблиці балансу, прототип ключових механік на Unity/Unreal, і супровід аж до релізу. Гарантія якості — покрокове узгодження на етапі прототипу, щоб уникнути переробок.

Що входить в роботу (deliverables):

• Документація: GDD, специфікації механік, наративні дерева, API для розробників
• Таблиці балансу: прогресія, економіка, DPS-калькулятори
• Прототипи: інтерактивні сцени з core loop (рух, бій, інвентар)
• Конфігурація в рушії: ScriptableObject, DataTable, анімаційні події
• Проведення плейтестів та ітерацій за метриками (утримання, монетизація, retention)

Оцініть ваш проект — зв'яжіться для розрахунку термінів. Підхід заснований на методології MDA та досвіді 50+ реалізованих проектів, більше 10 років на ринку. Наші замовники економлять від 2 до 3 тижнів на ітераціях завдяки чіткому процесу.

Як спроектувати бойову систему без помилок?

Бойова система — найдорожча помилка: на перший погляд проста, на ділі — пекло з edge cases. Розберемо melee combat.

Вибір методу hit detection

Hitbox — колайдери на зброї. Просто, але при швидких атаках виникає tunneling: зброя пролітає крізь противника за кадр. Рішення — Physics.CCD (Continuous Collision Detection), але це дорого. Raycast/spherecast — кастуємо промені вздовж траєкторії зброї. Точніше, менше залежить від fps. Ми віддаємо перевагу spherecast для action-ігор. Докладніше про методи — у статті про виявлення зіткнень.

Налаштування вікон атаки

Кожна атака — три фази: Startup, Active, Recovery. Довгий startup створює «важкі» удари. Короткий recovery дає агресивний стиль. В Unity аніматор кидає подію через AnimationEvent, код вмикає/вимикає hitbox. Типові таймінги для рукопашного бою: startup 200–400 мс, active 100–150 мс, recovery 300–500 мс. Зміна startup з 400 на 250 мс змінює відчуття з «важкий» на «середній» — це фіксується в метриках.

Побудова state machine

Персонаж — скінченний автомат. Базові стани: Idle, Moving, Jumping, Attacking, Hurt, Dead. Бізнес-логіку виносимо в C#-код, аніматор відповідає лише за переходи анімацій. Ієрархічні state machine (через Override Animator Controller) дозволяють вкладені підстани, не дублюючи переходи.

Чому математична модель економіки критична?

Економіку «на око» не роблять — виходить розвал через місяць після релізу. Базова прогресія: лінійна (нудно), експоненціальна (XP(n) = base * multiplier^n, multiplier 1.5–2.0), поліноміальна (a * n^b, b 1.5–2.5). Ми будуємо таблиці в Google Sheets за 2–3 дні, перевіряючи, скільки годин гравець витратить на кожен рівень.

Потоки валют

Принцип: кожна валюта — явне джерело (tap) і стік (sink). Приклад двовалютної системи:

Однонаправлена конвертація захищає монетизацію. Дисбаланс легко виявити за DPS і TTK: якщо TTK зброї вдвічі нижче за інші — воно стає meta. Ми виявляємо це на етапі прототипу, скорочуючи наступні правки на 40%.

Наратив та левел-дизайн: як навчати без тексту?

Environmental storytelling — розташування об'єктів, звуків, слідів — часто ефективніше за діалоги. Для діалогів використовуємо Ink (інтеграція з Unity). Ink-скрипти читає наративний дизайнер без програміста. Кожен рівень перевіряємо за принципом: гравець повинен зрозуміти механіку дією, а не за підказкою.

Інструменти в процесі

Ітерація та плейтестинг: 2-тижневий цикл

Перший прототип завжди незручний — це норма. Наш цикл: плейтест кожні 2 тижні. Після — список змін з числами: «startup 400 мс → 250 мс». Думки без чисел не приймаються. Фіксуємо відчуття, змінюємо числа, повторюємо. Завдяки цьому середня економія бюджету на етапі ітерацій становить 15–20%.

Зв'яжіться для консультації — ми оцінимо терміни та бюджет вашого проекту. Отримайте прототип core loop за 3 тижні. Сертифіковані фахівці Unity/Unreal гарантують дотримання термінів.