Персонаж відривається від землі на півкадру раніше, ніж натиснута кнопка стрибка — і гравець відчуває це як «пластилінове» керування. Саме тут починається наша робота: ми не підбираємо Rigidbody.mass навмання, а формалізуємо відчуття через конкретні числа та архітектурні рішення. За 10+ років у геймдеві ми впровадили системи пересування в більш ніж 50 проєктах — від мобільних платформерів до консольних шутерів. Зв'яжіться з нами — ми налаштуємо чуйне керування за 2–5 днів.
Чому CharacterController підводить у платформерах?
Unity пропонує два шляхи: фізичний Rigidbody + колайдер та кінематичний CharacterController. У платформерах Rigidbody частіше виявляється кращим вибором: він забезпечує точну фізику на рухомих платформах, тоді як CharacterController потребує ручного оброблення. З Rigidbody ви отримуєте в 2 рази менше багів при рухомих об'єктах.
CharacterController.Move() не взаємодіє з фізичним двигуном напряму — персонаж проходить крізь рухомі платформи, якщо не реалізувати кастомний механізм riding. Стандартний isGrounded флаг повертає false на одному кадрі при спуску по схилу — і персонаж починає нескінченно «підстрибувати» через накопичену гравітацію в буфері вертикальної швидкості.
Rigidbody-персонаж стійкіший до фізичних взаємодій, але потребує ручного контролю тертя: без PhysicMaterial з нульовим dynamicFriction на капсулі персонаж застрягає на кутах геометрії. При цьому Rigidbody.AddForce() у режимі ForceMode.VelocityChange веде себе передбачувано лише при fixedDeltaTime 0.02. Якщо ви зміните крок фізики, всі налаштовані відчуття «пливуть». У нас є готовий набір конфігурацій під різні жанри, який гарантує стабільну поведінку при будь-якому фіксованому кроці.
Як ми будуємо архітектуру системи пересування
Добре спроєктована система пересування розділяє три зони відповідальності: введення, стан та фізика/переміщення. Введення читається в Update() і записується в структуру MovementInput. Стани (Idle, Running, Jumping, Falling, Crouching, WallRunning) керуються кінцевим автоматом — зазвичай це кастомний клас поверх MonoBehaviour, а не Animator State Machine, тому що логіка переходів часто нелінійна і зав'язана на ігрові умови. Сам зсув позиції відбувається в FixedUpdate() через Rigidbody.MovePosition() або напряму через velocity.
Для платформерів з повітряним контролем важлива крива airControlCurve: горизонтальне прискорення в повітрі має бути меншим за наземне, але не нульовим. Реалізується через AnimationCurve в ScriptableObject налаштувань персонажа — дизайнер змінює криву в інспекторі, не торкаючись коду. Ми гарантуємо, що ваші дизайнери зможуть налаштовувати параметри без нашої участі.
Як реалізувати повітряний контроль?
Coyote time та jump buffering — обов'язкові компоненти для чуйного керування. Coyote time дозволяє стрибнути через coyoteTimeDuration (зазвичай 0.1–0.15 с) після сходу з платформи. Jump buffering зберігає натискання стрибка на jumpBufferDuration (0.1–0.2 с) і виконує його при першій можливості. Без цих двох механік гравець постійно «промахується» повз стрибок на краю платформи. Змінна висота стрибка — ще одна point: якщо відпустити кнопку стрибка в середині підйому, вертикальна швидкість зрізається до minJumpVelocity. Це реалізується простою перевіркою в Update().
| Параметр | Рекомендоване значення | Опис |
|---|---|---|
| Coyote time | 0.1–0.15 с | Буфер стрибка після сходу з платформи |
| Jump buffer | 0.1–0.2 с | Буфер натискання стрибка до його виконання |
| Air control ratio | 0.3–0.5 | Відношення горизонтального прискорення в повітрі до наземного |
| Min jump velocity | 2–4 units/s | Вертикальна швидкість при відпусканні кнопки стрибка |
Що входить в роботу над системою пересування
- Аналіз GDD та референсів — виписуємо конкретні числа (швидкість бігу в units/s, висота стрибка, час дешу).
- Проєктування MovementSettings ScriptableObject — всі параметри в одному місці, доступні дизайнеру.
- Розробка прототипу на примітивах — лише колайдери та логіка для швидкого налаштування feel (1–2 дні).
- Інтеграція Animator Controller — підключення Blend Tree для локомоції та фінальних колайдерів.
- Тестування граничних кейсів — стрибок в 1-юнітовий отвір, рухомі платформи з обертанням, перехід між NavMesh Surface різних сцен.
- Документація та навчання — передаємо проєкт з коментарями та налаштуваннями, проводимо демо для команди.
Таблиця орієнтовних термінів
| Масштаб задачі | Опис | Термін |
|---|---|---|
| Базовий | 2D/3D персонаж, земля, стрибок, coyote time | 2–5 днів |
| Середній | + double jump, dash, wall jump, crouch | 1–2 тижні |
| Розширений | + swimming, climbing, ragdoll transition, moving platforms | 2–4 тижні |
| Повна система | + procedural footstep IK, lean, network replication | 4–8 тижнів |
Процес роботи над проєктом
Починаємо з аналізу вашого GDD та референсних ігор — виписуємо конкретні числа з механік. Потім проєктуємо MovementSettings ScriptableObject з усіма параметрами та PlayerMovement MonoBehaviour з задокументованими зонами відповідальності.
Прототип збирається на примітивах без анімацій — лише колайдери та логіка. Це дозволяє намацати feel керування за день-два, не витрачаючи час на інтеграцію з Animator. Після затвердження feel підключаємо Animator Controller з Blend Tree для локомоції та фінальні колайдери по меш-геометрії.
Тестування включає граничні кейси: стрибок в 1-юнітовий отвір, рухомі платформи з обертанням, перехід між NavMesh Surface різних сцен при адитивному завантаженні. Ці ситуації найчастіше виявляють проблеми з детектуванням землі та накопиченням velocity.
Чек-лист типових помилок при проєктуванні пересування
- Пропущений coyote time — гравець не може стрибнути одразу після сходу з платформи.
- Відсутність jump buffering — натискання «з'їдаються», якщо персонаж не на землі.
- Використання isGrounded без SphereCast — false на схилах, нескінченне підстрибування.
- Ручне обертання разом з NavMeshAgent.updateRotation — тремтіння повороту.
- Фіксований fixedDeltaTime для всіх платформ — на Android з 30 fps фізика «пливе».
- Не накладений LayerMask на детектор землі — SphereCast потрапляє в колайдер персонажа.
Наше рішення дозволяє заощадити до 40% часу на налагодження, скорочуючи бюджет проєкту. Замовте розробку системи пересування — ми підберемо архітектуру під ваш проєкт і бюджет. Оцінимо терміни по вашому GDD за 1 робочий день.