Настройка 2D-физики: 8 частых ошибок, которые ломают игру

Большинство проблем с 2D-физикой — это не баги движка, а ошибки настройки. Восемь ошибок ниже стоят за почти каждым случаем дрожания, проскоков сквозь стены, «невесомого» управления и ненадёжных столкновений, которые начинающие разработчики списывают на движок. Ни одна из них не требует менять движок — требуется лишь настроить его так, как он задуман.

Если ваша игра использует движок 2D-физики — а так делает большинство, потому что Unity, Godot и GameMaker считают 2D-физику на Box2D или его близком родственнике, — то значения по умолчанию разумны. Но они предполагают, что вы соблюли несколько правил, которые легко нарушить с первого раза. Эта статья — те самые правила, оформленные в чеклист.

1. Физика считает в пикселях, а не в метрах#

Самая частая ошибка, и она порождает целое семейство симптомов: объекты падают слишком медленно или слишком быстро, стопки рушатся, трение ощущается не так, вся симуляция выглядит «не той».

Box2D настроен на метры, килограммы и секунды (МКС). В его документации прямо сказано: движущиеся объекты должны быть размером от 0,1 до 10 метров, причём около 1 метра — оптимально. Эрин Катто, автор Box2D, посвятил отдельную заметку тому, почему не стоит использовать пиксели как единицы. Гравитация, решатель и пороги усыпления в движке откалиброваны именно под этот масштаб.

Когда вы скармливаете движку игрока высотой 64 пикселя и стену толщиной 128 пикселей, он считает, что игрок примерно размером с здание. Для такого масштаба гравитация, соотношения масс и поведение контактов просто не рассчитаны.

Решение: выберите масштаб (обычно 32 или 100 пикселей в метре), заведите под него одну константу и переводите значения на границе. Физический мир работает в метрах, а отрисовка — в пикселях. Не смешивайте их.

2. Шаг физики привязан к частоте кадров#

Если шаг симуляции равен времени кадра, физика движется с разной скоростью в каждом кадре. При проседании до 30 fps шаг становится огромным, на 240-герцовом мониторе — крошечным. Большие шаги ведут к проскокам сквозь препятствия и взрывающимся стопкам; маленькие меняют то, как разрешаются трение и упругость. В итоге физика ведёт себя по-разному на разных машинах и даже в разные моменты времени.

Решение: фиксированный шаг с аккумулятором. Двигайте симуляцию вперёд одинаковыми порциями (обычно 1/60 c), накапливайте остаток реального времени и ограничивайте аккумулятор сверху, чтобы проседание не привело к «спирали смерти». При желании интерполируйте позицию при отрисовке между шагами физики для плавности. Каноническое описание этого приёма — «Fix Your Timestep!» Гленна Фидлера, и большинство движков реализуют его внутри себя, но вы должны следить, чтобы ваш собственный код движения опирался на фиксированный шаг, а не на время кадра.

3. Неверно выбран тип тела#

В движках физики есть три типа тел, и ошибка с типом сразу ломает поведение:

Тип	Реагирует на силы и гравитацию	Сдвигается при столкновении	Для чего подходит
Статическое	Нет	Нет	Стены, пол, неподвижная геометрия уровня
Кинематическое	Нет	Нет (но может двигаться само)	Движущиеся платформы, двери, триггеры
Динамическое	Да	Да	Ящики, враги, всё, что должно падать и подвергаться толчкам

Частая ошибка — случайно сделать пол динамическим, и тогда весь уровень падает. Другая — сделать игрока кинематическим, а потом недоумевать, почему ящики не реагируют на столкновение с ним: кинематические тела толкают динамические, но лишь если движок настроен обнаруживать такие контакты. Сначала подберите тип под роль тела, и только потом — всё остальное.

4. Непрерывное обнаружение столкновений выключено для быстрых объектов#

Дискретное обнаружение проверяет: «не перекрывается ли этот объект прямо сейчас», один раз за шаг. Если за шаг пуля пролетает дальше, чем стена толще, то проверка в начале шага и проверка в конце шага обе не фиксируют столкновения, и пуля оказывается за стеной раньше, чем движок узнал о сближении. Это и есть туннелирование.

Решение: включить непрерывное обнаружение столкновений (CCD) — в терминах Box2D это режим bullet — для быстрых динамических тел. CCD «прокатывает» фигуру от старой позиции к новой и проверяет весь заметаемый объём на пересечение. Это стоит дополнительных ресурсов процессора, поэтому включают его не глобально, а для отдельных тел. Сочетайте это с разумной частотой симуляции, а для очень быстрых тонких объектов выполняйте явный рейкаст.

5. Персонажем управляют как физическим телом#

Динамическое тело — это симуляция: силы накапливаются, инерция несёт, упругость даёт отскок. Для ящика это прекрасно. Для платформенного персонажа, где нужно точное, чёткое управление — пробежал сюда, остановился здесь, прыгнул ровно на эту высоту, — это мучительно.

Если двигать персонажа, задавая ему скорость или прикладывая силу к физическому телу, получается классическая картина: «невесомый» прыжок, управление в воздухе словно на льду и проезд дальше точки, в которой вы хотели остановиться. Движок делает ровно то, о чём его просили.

Решение: используйте контроллер персонажа. Установившийся приём — кинематическое тело (или вообще без физического тела), которым двигает ваш код, плюс лучевая проверка или проверка формой, направленные вниз, чтобы определять, стоит ли персонаж на земле. Пусть движок физики считает ящики, которые бросает игрок, а самого игрока ему считать не нужно.

6. Слишком мало итераций решателя#

Когда тела накладываются друг на друга, решатель движка расталкивает их за несколько итераций. Итераций мало — разрешение получается грубым: стопка коробок дрожит и медленно утопает, шарниры кажутся резиновыми, соединения шатаются. В Box2D по умолчанию 8 итераций по скорости и 3 по положению, что подходит для большинства сцен. Плотные стопки и сложные системы шарниров требуют большего.

Решение: поднимите число итераций (сначала по скорости, затем по положению) и следите, как стопка успокаивается. Это стоит ресурсов процессора, поэтому поднимайте только то, что нужно, и только там, где сцена этого требует. Заодно проверьте, что упругость равна нулю для объектов, которые должны покоиться, — ненулевая упругость на покоящихся контактах служит главной причиной непрекращающейся мелкой дрожи.

7. Позицию физического тела меняют напрямую#

Если тело динамическое, а вы каждый кадр выставляете ему позицию напрямую (чтобы вести по маршруту, прилипнуть к сетке или исправить ошибку), вы вступаете в борьбу с решателем. Движок уже учёл инерцию тела и рассчитал разрешение контактов для его естественной позиции; вы телепортируете тело в другое место, и на следующем шаге движок дёргает его обратно или обрушивает на соседей огромные корректирующие импульсы. Симптом — резкая тряска или объекты, улетевшие через всю комнату.

Решение: для тела, которым управляет физика, никогда не задавайте позицию напрямую. Двигайте его через API движка — задавайте скорость, прикладывайте силу или импульс, либо сделайте тело кинематическим на то время, пока хотите управлять им вручную. Если телепортировать всё же необходимо, делайте это предусмотренным движком способом и сбрасывайте скорость.

8. Игнорируются спящие тела и широкая фаза#

Две ошибки производительности, которые всплывают по мере роста игры. Во-первых, движок может усыплять покоящиеся тела и полностью пропускать их — но лишь если вы ему позволяете. Крошечный скрипт, который каждый кадр «шевелит» скорость всех тел, не даёт им заснуть. Во-вторых, обнаружение столкновений ускоряется широкой фазой (деревом AABB), которая дёшево отсекает далёкие пары перед дорогой узкой фазой; если ваши коллайдеры огромны или у вас тысячи мелких пересекающихся коллайдеров, широкая фаза не может отсечь ничего, и кадр захлёбывается.

Решение: позвольте телам засыпать; не опрашивайте их, когда они в покое. Держите коллайдеры близко к видимой форме (никаких гигантских невидимых коробок «на всякий случай») и предпочитайте несколько составных коллайдеров десяткам мелких для сложных форм.

Симптом → ошибка настройки → решение#

Симптом	Вероятная ошибка	Решение
Объекты падают с неверной скоростью, стопки рушатся	Пиксели как единицы физики	Переведите в метры (диапазон 0,1–10 м)
Физика отличается от машины к машине, дрожит при лагах	Переменный шаг	Фиксированный шаг с аккумулятором
Быстрый снаряд проходит сквозь стену	CCD выключен для быстрого тела	Включите bullet/CCD, поднимите частоту, рейкаст
Персонаж ощущается «невесомым», проскакивает точку остановки	Персонаж — динамическое тело	Контроллер персонажа на рейкастах/кинематике
Стопки коробок дрожат и проваливаются	Мало итераций, ненулевая упругость	Поднимите итерации, нулевая упругость в покое
Объекты резко трясутся или улетают	Позиция меняется напрямую	Двигайте через API физики, без телепортов
Кадры проседают по мере роста сцены	Нет усыпления, раздутые коллайдеры	Усыпляйте тела, держите коллайдеры впритык

Как вписывается Egmatic#

Каждая ошибка из списка — это ошибка настройки, а значит, разница между хорошей и плохой 2D-физикой сводится к скорости цикла настройки: поменяли параметр — увидели результат — приняли решение. Egmatic построен вокруг живого предпросмотра: сцена продолжает работать, пока вы настраиваете свойства и логику, поэтому подкрутка гравитации, итераций решателя или типа тела — это то, за чем вы наблюдаете в реальном времени, а не то, что нужно пересобирать для проверки. Физика работает поверх кроссплатформенного движка, а физические события — столкновения, контакты, триггеры — представлены узлами, которые можно связать с геймплеем, не выходя из визуального редактора. Подробный разбор того, как устроен 2D-движок физики внутри, читайте в статье Движок 2D-физики: всё, что нужно знать; о настройке параметров на лету — в материале Редактор физики в реальном времени: меняйте параметры на лету.

Итог#

Движок 2D-физики — это симулятор, и симулятор ведёт себя хорошо лишь тогда, когда вы соблюдаете условия его работы: скармливаете ему те единицы, под которые он настроен, шагаете с фиксированной частотой, даёте каждому телу верный тип, включаете непрерывное обнаружение для быстрых объектов, держите игрока вне симуляции, даёте решателю достаточно итераций, не боретесь с ним прямым изменением позиции и позволяете покоящимся телам засыпать. Если настройка верна, большинство «багов физики» просто не возникает, а те немногие, что остаются, превращаются в узкие локальные задачи, которые легко диагностировать и которые решаются за минуты, — об этом статья Как починить баги физики в игре: метод диагностики.