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