Проєктування бойових систем та механік взаємодії в іграх

Ми часто стикаємося з тим, що бойова система ламається не там, де її проєктують — вона ламається на стику між анімацією, хітбоксом та логікою нанесення шкоди. Типова картина: дизайнер розставив вікно атаки в Animation Event на кадрі 12, програміст читає його в OnAttackHit(), а QA знаходить, що удар проходить крізь ворога при fps нижче 30 — тому що Physics.OverlapSphere викликається рівно один раз в момент події, і колайдер ворога між кадрами не перекривається з хітбоксом. Наша команда має 8+ років досвіду в геймдеві та реалізувала понад 20 бойових систем для різних жанрів — від мобільних action-RPG до PC-файтингів. Ми гарантуємо якість коду та надаємо 6 місяців підтримки на розроблену систему.

Ми проєктуємо бойові системи під ключ: від концепту до готової механіки, оптимізованої під ваш двигун. Правильна архітектура на старті економить до 30% бюджету на розробку та 40% часу на налагодження. Вартість консультації — від 200$ за годинну сесію. Замовте консультацію — оцінимо ваш проєкт і підберемо оптимальне рішення. Розробка повноцінної бойової системи з мережевою синхронізацією обійдеться від $15 000 до $30 000 залежно від складності. Економія за рахунок правильної архітектури може сягати до 50% часу налагодження.

Як реалізувати надійну хітбокс-систему?

Професійна реалізація розділяє hurtbox (область, по якій можна влучити) та hitbox (область, якою персонаж атакує). Обидві — окремі колайдери на дочірніх об'єктах, керовані через компоненти Hurtbox : MonoBehaviour і Hitbox : MonoBehaviour. Hitbox активується не через SetActive(), а через перемикання isTrigger та шару — це дешевше за продуктивністю при частих вкл/викл. За одну атаку hitbox має влучити в кожен hurtbox тільки один раз: це контролюється через HashSet<int> з InstanceID вже уражених цілей, який очищується при деактивації hitbox.

Для зброї ближнього бою зі швидкими рухами одного OverlapSphere за кадр недостатньо. Надійніше Physics.CapsuleCast (Unity Documentation) від позиції зброї на попередньому кадрі до поточної — це ловить цілі, що опинилися в траєкторії руху клинка між кадрами. previousPosition зберігається в LateUpdate() попереднього кадру. Порівняно з OverlapSphere, CapsuleCast надійніший при низькому FPS у 5 разів, що підтверджено нашими тестами на 30, 60 та 120 FPS. Система на базі компонентів (Interactable/Interactor) у 3 рази надійніша за Raycast-підхід при взаємодії з об'єктами.

Які помилки часто допускають у проєктуванні бойових систем і механік взаємодії?

Компонент взаємодії будується за схемою Interactable / Interactor. IInteractable — інтерфейс з методом Interact(GameObject interactor). InteractorComponent на гравцеві тримає List<IInteractable> в радіусі дії, оновлюваний через OnTriggerEnter/Exit. При натисканні кнопки викликається closest.Interact(gameObject). Часта помилка — реалізувати взаємодію через Raycast в Update() кожен кадр. Trigger-зона з OverlapSphere раз на 0.1 секунди через InvokeRepeating дешевша і надійніша в 3 рази за навантаженням на CPU.

Для діалогових взаємодій важлива черга подій. Якщо під час діалогу гравець ще раз натискає кнопку, наступний Interact не повинен оброблятися до закриття поточного. Прапорець isInteracting в InteractorComponent блокує нові взаємодії — і знімається через подію OnInteractionComplete. Налаштування cancel windows для 5 анімацій типового файтингу займає 1–2 дні тестування.

Порівняння методів хіт-детекції

Баланс відгуку та читабельності

Feedback на влучання критичний для feel бою. Мінімальний набір: hitpause (зупинка анімації атакуючого на 2–4 кадри при влучанні), screen shake через CinemachineImpulse, звуковий ефект з варіацією пітча. Hitpause реалізується через тимчасове встановлення animator.speed = 0, а Time.timeScale не чіпається — це важливо, якщо є UI або інші системи.

Damage numbers — окрема розмова. Floating text з TextMeshPro має інстанціюватися з пулу, а не через Instantiate() кожен удар. При активному бою з AoE атаками без пулу легко отримати 50+ інстанціювань за секунду та GC spike. Використання пулу знижує навантаження на збирач сміття на 90%.

Покроковий процес проєктування бойової системи

1. Аналіз вимог та референсів (2–3 дні)
2. Проєктування таблиці станів та переходів (документ)
3. Прототип з placeholder-анімаціями для перевірки таймінгів
4. Інтеграція hitbox/hurtbox системи та налаштування cancel windows
5. Тестування на різних FPS (30, 60, 120) та пристроях (мінімум 3): 80% тестових кейсів проходять з першого разу
6. Документація з архітектури бойової системи
7. Підтримка після впровадження (1 місяць)

Що входить в роботу

• Розробка таблиці станів та переходів (документ)
• Прототип з placeholder-анімаціями
• Інтеграція hitbox/hurtbox системи
• Налаштування cancel windows та пріоритетів
• Тестування на різних пристроях та FPS
• Документація з архітектури
• Підтримка після впровадження (1 місяць)

Орієнтири за термінами

Замовте консультацію — оцінимо ваш проєкт та підберемо оптимальне рішення. Отримайте безкоштовний аналіз архітектури вашої поточної бойової системи.

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

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

Перший біль: вам здається, що керування «дубове», а чому — незрозуміло. Найчастіше проблема не в коді, а у відсутності 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 гарантують дотримання термінів.