XVIII Международная студенческая научная конференция Студенческий научный форум - 2026

Введение

Современная индустрия компьютерных игр все чаще обращается к сложным механикам, связанным с манипуляцией четвертым измерением — временем. Игры, такие как Braid, Superhot и Katana Zero, демонстрируют высокий потенциал геймплея, построенного на нелинейном течении времени. При разработке дипломного проекта «Игра-платформер с механиками остановки времени» ключевой технической задачей стала реализация системы, позволяющей «замораживать» или замедлять объекты окружения и врагов, оставляя при этом управление главным героем в реальном времени.

Среда разработки Godot Engine предоставляет мощные инструменты для работы с физикой, однако стандартные подходы к изменению скорости времени часто затрагивают глобальное состояние системы. Цель данной работы — проанализировать особенности физического движка Godot (версии 4.x) и выявить наиболее эффективный алгоритм реализации селективной остановки времени.

Постановка проблем

Разработка платформеров с элементами головоломки требует от современных игровых движков высокой гибкости в управлении физическими процессами. Одной из наиболее технически сложных механик является реализация нелинейного течения времени, в частности — селективной остановки времени (Time Stop), при которой главный герой сохраняет возможность перемещения и взаимодействия с застывшим окружением.

Фундаментальная проблема заключается в архитектуре большинства физических движков, включая PhysicsServer в Godot, которые проектируются исходя из предположения о едином глобальном времени для всей сцены. Стандартные методы синхронизации игровой логики и физики (physics_process) опираются на единый параметр дельты времени (delta). Попытка разорвать эту связь для отдельных объектов приводит к ряду коллизий: потере инерции при возобновлении времени, некорректной работе детекторов столкновений (туннелирование объектов) и конфликтам с системой интерполяции кадров. Таким образом, возникает необходимость в разработке архитектурного решения, позволяющего обойти ограничения глобального планировщика физики без потери производительности и точности симуляции.

Анализ последних исследований и публикаций

Вопросы реализации игровых механик, связанных со временем, рассматриваются как в теоретических трудах по геймдизайну, так и в прикладной документации.

Большинство существующих туториалов и исследований предлагают решения, основанные на глобальном замедлении (Engine.time_scale), что эффективно для механик типа «slow-mo» (как в Max Payne), но неприменимо для задач, где агент игрока должен функционировать в нормальном режиме времени на фоне статичного мира. Исследования, касающиеся прямой манипуляции состоянием физических серверов для сохранения импульса твердых тел (RigidBody) при выборочной остановке времени, в открытых источниках представлены фрагментарно. Отсутствует единый алгоритм, систематизирующий работу с кинематическими и динамическими телами в среде Godot 4.x в контексте данной механики.

Формулировка целей статьи

Целью данной работы является исследование возможностей физического движка Godot Engine (версии 4.x) для реализации механики селективной остановки времени. Для достижения поставленной цели необходимо решить следующие задачи:

1. Провести сравнительный анализ штатных средств управления временем в Godot (TimeScale, ProcessMode, ручная модификация delta).

2. Выявить ограничения физического движка при работе с инерцией и коллизиями в условиях остановленного времени.

3. Разработать и обосновать гибридный программный алгоритм, обеспечивающий корректное сохранение импульсов физических объектов и стабильность симуляции при переключении временных состояний.

4. Предложить практическую реализацию взаимодействия игрока с «замороженными» объектами через PhysicsServer2D.

Основная часть

Начнем с анализа стандартных средств управления временем в Godot. В основе игрового цикла Godot лежит концепция дискретного времени, выраженная через параметр delta — время, прошедшее с предыдущего кадра. Физический цикл обрабатывается в методе _physics_process(delta), который по умолчанию вызывается 60 раз в секунду.

Наиболее очевидным инструментом является свойство Engine.time_scale. Изменение этого параметра влияет на скорость течения времени во всем приложении:

Достоинства метода:

• Простота реализации (одна строка кода).

• Автоматическая корректная работа всех таймеров (Timer), анимаций и физических симуляций.

• Недостатки:

• Глобальность воздействия. При Engine.time_scale = 0.0 останавливается всё, включая игрока, что противоречит поставленной задаче (игрок должен двигаться, пока мир замер).

• Проблемы с вводом. Обработка input-событий также может зависеть от фреймрейта, что при замедлении времени вызывает ощущение «лага».

Следовательно, для реализации механики, где игрок движется быстрее окружения (или окружение стоит), глобальный Engine.time_scale неприменим в чистом виде.

Поэтому далее были рассмотрены архитектурные подходы к селективной остановке времени. Для решения задачи разделения временных потоков игрока и окружения были рассмотрены три основных подхода.

Первый из них — использование режима паузы (Process Mode). Godot обладает встроенной системой паузы. Узлы (Nodes) имеют свойство process_mode.

• Если перевести корневой узел уровня в состояние паузы, а узлу игрока выставить PROCESS_MODE_ALWAYS, игрок продолжит обновляться.

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

Второй подход подразумевает манипуляцию скаляром времени на уровне объектов (Custom Time Scale). Данный подход предполагает введение глобального синглтона (например, TimeManager), который хранит переменную environment_time_scale (от 0.0 до 1.0). Все объекты, подверженные влиянию времени, в своем методе _physics_process(delta) умножают входящую delta на этот коэффициент.

Код для врага (CharacterBody2D):

func _physics_process(delta):
var adjusted_delta = delta * TimeManager.environment_time_scale
# Применениегравитациисучетомзамедления
if not is_on_floor():
velocity.y += gravity * adjusted_delta
# Перемещение. Важно: move_and_slide() сам использует внутреннюю физику,
# поэтому нужно масштабировать саму скорость перед вызовом.
var original_velocity = velocity
velocity = velocity * TimeManager.environment_time_scale
move_and_slide()

Особенности работы с физикой Godot при этом подходе: Функция move_and_slide() в Godot 4 автоматически учитывает delta при расчете перемещения, однако она опирается на текущее значение вектора velocity. Если мы просто уменьшим velocity, физический движок воспримет это как потерю импульса, а не как замедление времени. Это приводит к тому, что при замедлении времени дальность прыжка врагов уменьшается (они падают быстрее, чем летят вперед), так как гравитация — это ускорение ( ), а скорость — это .

Для корректной симуляции необходимо масштабировать все силы: гравитацию, трение и прикладываемые импульсы. При полной остановке (scale = 0) необходимо принудительно пропускать вызов move_and_slide(), чтобы избежать деления на ноль или артефактов коллизии.

В итоге был выработан гибридный метод: работа с PhysicsServer2D.Для наиболее корректной реализации, особенно касающейся твердых тел (RigidBody2D), простых манипуляций с velocity недостаточно, так как движок управляет ими на низком уровне.

В ходе исследования было выявлено, что наиболее надежным способом «заморозки» физических объектов является изменение их режима работы (freeze_mode) или прямое вмешательство через PhysicsServer2D.

Переходя непосредственно к реализации механики в проекте, стоит отметить, что была выбранагибридная архитектура, разделяющая объекты на две категории: Кинематические (враги, платформы) и Физические (ящики, дебрис).

При управлении кинематическими телами, напримерCharacterBody2D (враги), используется паттерн «Наблюдатель». При активации способности игрока TimeStop отправляется сигнал. Враги переходят в состояние STOPPED.

В этом состоянии:

1. Сохраняется текущий вектор velocity.

2. Отключается анимация (AnimationPlayer.pause()).

3. В _physics_process полностью блокируется исполнение кода перемещения.

Это позволяет избежать багов физики, связанных с туннелированием (прохождением сквозь стены), так как объект фактически перестает запрашивать перемещение.

Что касается управления RigidBody2D, то здесь ситуация сложнее.Простое обнуление скоростей приведет к тому, что после возобновления времени объекты начнут падать вертикально вниз, потеряв инерцию горизонтального полета.

Для решения этой проблемы использован следующий алгоритм при остановке времени:

1. Получить текущую линейную и угловую скорости (linear_velocity, angular_velocity).

2. Сохранить их в переменные экземпляра.

3. ПереключитьрежимтелавFreeze (Static):freeze = true
freeze_mode = RigidBody2D.FREEZE_MODE_STATIC.В режиме Static объект становится неподвижным препятствием. Игрок может запрыгнуть на застывший в воздухе ящик.

При возобновлении времени:

1. freeze = false.

2. Принудительно восстановить скорости через PhysicsServer2D, так как прямое присваивание свойств может не сработать мгновенно в том же кадре физики.

Отдельного внимания заслуживают проблемы интерполяции и частоты кадров. Одной из выявленных проблем при реализации стала рассинхронизация физики и графики. Godot использует интерполяцию физики (Physics Interpolation) для плавности картинки на мониторах с высокой частотой обновления. При резкой остановке времени (изменении параметров скоростей на 0) интерполятор может попытаться сгладить переход, создавая визуальный эффект «дрожания» объекта перед остановкой.

Для устранения этого эффекта необходимо использовать метод force_update_transform() или сбрасывать буфер интерполяции при переключении режимов времени.

Наконец, необходимо рассмотреть взаимодействие игрока с остановленным миром. Здесь критический аспект — коллизии. В Godot система слоев коллизий (Collision Layers/Masks) позволяет гибко настраивать взаимодействие. Когда время остановлено, враги по сути становятся статичными препятствиями. Однако, если игрок атакует врага в остановленном времени, враг должен получить урон, но отлететь от удара только после возобновления времени.

Реализация:

• При ударе по застывшему врагу импульс отбрасывания (knockback) не применяется к velocity немедленно.

• Вместо этого он аккумулируется в переменной pending_impulse.

• В момент запуска времени (TimeManager.resume()) накопленный импульс применяется к врагу.

Это создает эффектный геймплейный момент: игрок наносит серию ударов в тишине, а при щелчке таймера враги разлетаются одновременно.

Выводы

Работа с нелинейным временем в Godot требует отхода от использования глобального Engine.time_scale в пользу кастомных менеджеров, управляющих состоянием объектов. Анализ показал, что для 2D-платформера оптимальным решением является:

1. Оставление игрока в стандартном физическом цикле.

2. Перевод RigidBody2D в режим Freeze с сохранением векторов инерции.

3. Блокировка вызовов move_and_slide у кинематических тел.

Использование низкоуровневого PhysicsServer2D для восстановления состояний обеспечивает стабильность симуляции и предотвращает потерю инерции, что критично для сохранения динамики игрового процесса (game feel). Реализованная система позволяет создавать сложные головоломки и боевые ситуации, являясь ключевым элементом научной новизны дипломного проекта.

Списоклитературы

1. Bradfield, C. Godot 4 Game Development Projects : Build five cross-platform 2D and 3D games with Godot 4.0 / C. Bradfield. — Birmingham : Packt Publishing, 2023. — 336 p. — ISBN 978-1-80323-921-3.

2. Felicia, P. Godot from Zero to Proficiency. Series of five books / P. Felicia. — 2022.

3. Vanhove, S. Learning GDScript by Developing a Game with Godot 4 : A fun introduction to programming in GDScript 2.0 and game development using the Godot Engine / S. Vanhove. — 2024.

4. Wang, W., Walcott, T. Programming for Game Design : A Hands-On Guide with Godot / W. Wang, T. Walcott.

Код для цитирования: Скопировать