Геймдизайн: проектування механік
Перш ніж почати цю розмову, варто зафіксувати розрізнення: геймдизайн — це не «придумати ідею гри». Придумати ідею може будь-хто. Геймдизайн — це спроектувати систему правил, яка при взаємодії з гравцем виробляє конкретний емоційний та поведінковий результат. Це інженерна дисципліна, тільки замість компілятора — людський мозок.
Механіки: що ми проектуємо
Рух та управління
Character controller — перше, що гравець торкається, та останнє, до чого привикає. Ощущення від руху задається не швидкістю персонажа, а acceleration та deceleration curves. В Unity це криві в AnimationCurve або параметри в CharacterController. Ми не ставимо лінійне прискорення: в більшості жанрів правильне ощущення досягається через ease-in на старті руху та різке гальмування при відпусканні кнопки.
Coyote time (150–200 мс після сходу з платформи, протягом яких стрибок все ще спрацьовує) та jump buffering (стрибок реєструється за 100–150 мс до дотику землі) — це не «фічі», це стандарт платформерів. Гравці не формулюють їхню відсутність словами, але відчувають як «управління дубове».
Інвентар
Система інвентаря з виду проста, на практиці — джерело безкінечних edge cases. Stackable/non-stackable предмети, обмеження по вазі vs. по слотам, drag-and-drop з валідацією, збереження стану між сесіями, серверна верифікація в мультиплеєрі.
Ми проектуємо інвентар через дані: кожен предмет — ScriptableObject з набором параметрів, слоти інвентаря — контейнери, які приймають або відхиляють предмет по набору правил (тип, клас персонажа, кількість). Це дозволяє додавати нові предмети без змін коду.
Бойова система: глибокий розбір
Бойова система — це та частина геймдизайну, де розрив між «виглядає просто» та «зроблено правильно» максимальний. Візьмімо melee combat як приклад.
Hit detection
Два основних підходи: hitbox-based та raycast/spherecast-based.
Hitbox — коллайдери на зброї та персонажах, перетин = попадання. Добре працює в уповільнених іграх. При швидких атаках з'являється tunneling: за один кадр зброя пролітає крізь, не зафіксувавши перетин. Вирішується через sweep test або включення Physics.CCD (Continuous Collision Detection) — дорого по продуктивності.
Raycast/spherecast — кожен кадр протягом активного вікна атаки кастуємо промені або сфери вздовж траєкторії зброї. Точніше, менше залежить від framerate, легше контролювати зону поранення. Ми віддаємо перевагу цьому підходу для більшості action-ігор.
Вікна атаки (Attack Windows)
Кожна атака розбита на фази:
- Startup — анімація замаху, персонаж уразливий, дія ще не почалась
- Active — активне вікно хіту, попадання засчитуються
- Recovery — анімація повернення, персонаж уразливий, скасувати дію не можна
Ці таймінги — не просто числа для аніматора. Вони визначають ощущення бою. Довгий startup створює «важкі» удари. Короткий recovery дозволяє агресивний стиль гри. В Souls-like довгий recovery — основне джерело покарання за помилку.
В Unity це реалізується через Animation Events: аніматор кидає подію в певний кадр, код активирує/деактивирує hitbox або вмикає/вимикає spherecast loop.
State Machine для персонажа
Бойовий персонаж — це скінченний автомат. В Unity ми використовуємо Animator Controller як основу state machine, але бізнес-логіку виносимо в код, не в Animator. Animator управляє переходами анімацій, C#-код управляє переходами станів персонажа.
Базові стани: Idle, Moving, Jumping, Falling, Attacking, Hurt, Dead, Blocking, Dodging. Кожен перехід — явна умова. Перехід з Attacking в Hurt відбувається тільки якщо атака переривна (деякі атаки мають iframes або super armor).
Ієрархічні state machines (через Override Animator Controller в Unity або Hierarchical State Machine в власній реалізації) дозволяють робити вкладені стани: наприклад, Moving містить підстани Walking, Running, Crouching, не дублюючи переходи.
Економіка: математична модель
Це та частина геймдизайну, яку найчастіше роблять «на око» — і отримують розвалений баланс через місяць після релізу.
Базова модель прогресії
Прогресія в більшості ігор будується на одній з трьох математичних моделей:
Лінійна — кожен наступний рівень потребує одинакову кількість опиту. Просто, передбачувано, нудно на високих рівнях.
Експоненціальна — XP(n) = base * multiplier^n. Стандарт для RPG. multiplier зазвичай від 1.5 до 2.0. При 1.5 — ранні рівні швидкі, пізні — довгі. При 2.0 — різкий ріст складності.
Поліноміальна — XP(n) = a * n^b. Більш м'який ріст, ніж експонента. b від 1.5 до 2.5 для більшості ігор.
Ми будуємо таблиці прогресії в Google Sheets, перш ніж імплементувати в рушій. Це дозволяє за хвилини перевірити, скільки годин гравець витратить на кожен рівень при різних параметрах.
Ігрова економіка: валюти та потоки
Базовий принцип: кожна валюта повинна мати явне джерело (tap) та явний сток (sink). Якщо золото можна тільки отримувати, але не витрачати на щось цінне — воно обесцінюється, інфляція вбиває економіку.
Приклад простої двовалютної системи (характерна для мобільних f2p):
| М'яка валюта (золото) | Тверда валюта (кристали) | |
|---|---|---|
| Джерело | Квести, враги, щоденні награди | Покупка за гроші, рідкі досягнення |
| Сток | Розходники, покращення снаряження, будівлі | Пропуск часу, рідкісні предмети, premium |
| Конвертація | → кристали: ні | → золото: так (але не навпаки) |
Однонапрямлена конвертація (тверда → м'яка, але не навпаки) захищає монетизацію.
Баланс через розрахунок DPS та TTK
В екшн-іграх баланс зброї будується на двох метриках:
DPS (Damage Per Second) — урон в одиницю часу з урахуванням повного циклу атаки (включаючи recovery).
TTK (Time To Kill) — час убивства противника з повним HP. TTK = HP_enemy / DPS.
Різні види зброї повинні мати зіставний TTK проти стандартного противника, але різні профілі застосування: пістолет швидко витягується, снайперська гвинтівка високий разовий урон, дробовик ефективний на близькій дистанції.
Дисбаланс легко виявити: якщо TTK якої-небудь зброї в два рази нижче решти — це meta-зброя, і всі будуть використовувати тільки її.
Наратив та level-дизайн
Наратив не повинен бути текстовим. Environmental storytelling — розташування об'єктів, сліди подій на рівні, звуковий дизайн — часто ефективніше діалогів.
Для діалогових систем ми використовуємо Ink (мова наративу від Inkle) в інтеграції з Unity. Ink дозволяє писати розгалужені діалоги з змінними та умовами в людиночитаємому форматі, який редагує наративний дизайнер без участі програміста.
Level-дизайн — окрема дисципліна. Базовий принцип: рівень повинен навчати через gameplay, а не через текстові підказки. Якщо гравець не розуміє, що потрібно зробити — це проблема дизайну, не гравця.
Інструменти геймдизайнера в нашому процесі
| Завдання | Інструмент |
|---|---|
| GDD та документація | Notion, Confluence |
| Таблиці балансу | Google Sheets |
| Прототипування механік | Unity (C#), Godot для швидких прототипів |
| Діаграми state machine | Miro, draw.io |
| Наративні дерева | Ink, Twine |
| Конфігурація в рушії | ScriptableObjects (Unity), DataTable (Unreal) |
| Аналітика та A/B тести | Firebase Analytics, GameAnalytics |
Ітерація та плейтестинг
Механіки не народжуються правильними з першого разу. Перший прототип завжди незручний, і це нормально. Ненормально — не змінювати його після плейтестингу.
Ми проводимо внутрішній плейтест кожні два тижні. Після плейтесту — конкретний список змін з пріоритетами. Думка «щось не так з боєм» — не завдання. Завдання — «startup-час атаки 400 мс, це занадто довго, скорочуємо до 250 мс та тестуємо знову».
Цифри змінюються. Ощущення фіксуються. Цикл повторюється.