Проектування ігрових механік мобільної гри

Проектування ігрових механік мобільної гри

Ігрова механіка — це не «що трапляється в грі», а «чому гравець продовжує грати». Різниця принципіальна. Можна описати механіку match-3: сполучай три однакові елементи. Це не механіка — це правило. Механіка — петля зворотного зв'язку: гравець бачить майже-совпадіння, витрачає хід, отримує вибух, бачить каскад, відчуває задоволення, робить наступний хід. Саме цю петлю ми проектуємо.

Що таке ігрові механіки на технічному рівні

З точки зору розробки, механіка — це скінченний автомат зі входом подій, переходами між станами та вихідними ефектами. Для мобільної гри вхідні события — торкання, свайп, нахил пристрою (через CMMotionManager на iOS або SensorManager на Android). Переходи — ігрова логіка. Виходи — візуальний та звуковий зворотний зв'язок.

Unity реалізує механіки через MonoBehaviour з Update() / FixedUpdate() циклами. Фізичні взаємодії — через Rigidbody, Collider, PhysicsMaterial. Управління станами — Animator State Machine для простих випадків або користувацький FSM через enum + switch. Godot — Node з _process() / _physics_process(), StateMachine як окремий Node. Cocos Creator — Component з update().

Але це інструменти. Проектування — до коду.

Core loop та meta loop

Core loop — дія, яку гравець повторює кожні 30–120 секунд. У Tower Defense: розміщення башні → хвиля ворогів → результат → ресурси → наступна хвиля. У idle-грі: тап → монети → апгрейд → більше монет в секунду → тап рідше. Петля повинна бути зрозуміла без туторіалу та приносити задоволення сама по собі.

Meta loop — прогрес за кілька сесій. Відкриття нових башень, персонажів, рівнів. Meta loop утримує гравця між сесіями — дає причину повернутися завтра.

Помилка: проектувати meta loop до core loop. Якщо базовий геймплей скучен — ніяка прогресія не спасе retention.

Мобільні обмеження та жанрові механіки

Мобільний екран диктує механіки. Клік за 100мс на PC — тап за 200мс на сенсорі. Миш з точністю пікселя — палець шириною 10dp. Це не недоліки — це параметри проектування.

Добре працює на мобайле:

• Свайп-механіки (Tinder-style, match-3, slice)
• Тап з утриманням (зарядка, прицілювання)
• Тайм-менеджмент (Cooking Dash) — обмежений час рішення на малому екрані створює напруження
• Pinch для масштабу (стратегії, симулятори міст)
• Гіроскоп (лабіринти, гоночні ігри) — через Input.gyro в Unity

Погано працює:

• Точне прицілювання (шутери з мишею)
• Одночасне управління кількома об'єктами
• Швидкі реакції (<100мс) — фізіологічна межа touchscreen'у

Проектування механік з урахуванням монетизації

Монетизація не повинна ломати core loop. Енергетична система (життя у Candy Crush) — штучне гальмування core loop. Працює з точки зору IAP, але завдає шкоди user experience. Альтернатива: косметична монетизація (скини, ефекти) — не обмежує геймплей, зберігає player experience.

Якщо проект передбачає rewarded ad монетизацію (rewarded video через Unity Ads, AdMob, IronSource), механіки проектуються з «моментами рішення» — точками, де гравець сам хоче подивитися рекламу: продовжити рівень після програшу, подвійна нагорода. Примусова реклама руйнує flow.

З практики: hyper-casual гра на Unity, механіка «нарізання» (слайсер). Core loop: свайп по об'єктам → розрізання → комбо-множник → високий рахунок. Перші тести показали: гравці втрачали інтерес на 3-й хвилині — не хватало escalation (нарастання складності). Додали динамічне збільшення швидкості об'єктів + нові типи (неразрізаємі «бомби») через AnimationCurve в Unity — D1 retention виріс з 28% на 41%.

Документування механік

Кожна механіка документується в GDD (Game Design Document) з:

• Описанням дії гравця
• Очікуваним зворотним зв'язком (що бачить/чує)
• Параметрами (числа, таймери, множники) — у форматі, який можна балансувати через ScriptableObject в Unity або конфіг-файл
• Edge case'ами: що трапляється при 0 HP, при заповненому інвентарі, при втраті з'єднання

Параметри-константи в коді — ворог балансу. Всі числові параметри (швидкість, урон, таймери) виносимо в ScriptableObject або JSON-конфіг. Game designer міняє баланс без розробника.

Типічні механіки мобільних жанрів

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

• Аналіз жанру та цільової аудиторії
• Проектування core loop з урахуванням мобільного input
• Опис всіх механік з параметрами для балансування
• Схеми state machine для ключових систем
• Документування у форматі GDD (секції механік)
• Рекомендації з монетизації без разрушения gameplay
• Прототип-верифікація ключової механіки (за домовленістю)

Графік

3–5 робочих днів на проектування механік для hyper-casual або casual проекту. Для midcore RPG/стратегії з кількома взаємопов'язаними системами — 5–10 днів. Вартість розраховується індивідуально після аналізу концепції.