Что делает движок, когда вы делаете прыжок в игре? Часть 1

Кажется, всё просто: нажал пробел — подпрыгнул. На практике: за примерно 16 миллисекунд (при 60 FPS) движок успевает обработать ввод, пересчитать физику, обновить анимации, собрать сцену и отрендерить кадр.

Это первая часть статьи про геймдев и как устроены игры под капотом. Здесь мы разберём, что происходит внутри игрового движка в момент обычного действия. Возьмём прыжок как простой пример и по нему пройдём весь путь: от клавиатуры до готового кадра на экране.

Меня зовут Валерий Линьков. Я проектирую облачную инфраструктуру и системы безопасности. Также, я являюсь основателем Монтировки — независимой студии разработки игр. Мой архитектурный подход к работе помогает проектировать игры на движке Unity так, чтобы игра была максимально технологически целостна.

Вопрос, который развернём: как это вообще укладывается в миллисекунды — и почему иногда не укладывается

Как устроен игровой движок: что происходит внутри, пока вы играете

Игровой цикл — это базовая структура, которая непрерывно выполняется, пока запущена игра. Он определяет порядок обработки ввода, обновления состояния мира и отрисовки. Пока цикл работает — вы играете, но если цикл остановится, игра вылетит и вместо игры будет код ошибки.

Классическая схема:

Input → Update → Physics → Render → Repeat

Этапы цикла

Этот цикл повторяется каждую миллисекунду в игре. Движок отслеживает какие кнопки жмёт игрок, просчитывает движение персонажа по экрану, продумывает физику поведения всех окружающих объектов и показывает это игроку. Каждую миллисекунду… Это не просто! Но нужно понять про то как считать время. 

FPS и Tick Rate

Важно различать:

Они могут быть независимыми. Например:

Связывание логики с FPS может приводить к нестабильному поведению игры на разных системах. Связь между ними идёт через свойство в реальной жизни — через время, а не напрямую друг через друга.

Есть два параллельных процесса:

Tick (логика/физика) — обновляет состояние мира. Логика отвечает на вопрос “Что происходит в мире?”

Frame (кадр) — показывает это состояние игроку. Рендер отвечает на вопрос “Как это сейчас выглядит?”

Допустим:

Tick Rate = 60 Гц, значит обновление каждые 16.67 мс

FPS = 120, значит кадр каждые 8.33 мс

Что происходит:

Визуально:

Вертикальные линии — обновление логики, короткие — отрисовка. 

Если логика зависит от FPS:

Причина — шаг времени привязан к кадру. Если вы не ставите ограничения по кадрам, получится, что у каждого игрока в зависимости от мощности ПК будет разная скорость игры.

Правильный подход базируется на двух правилах:

Коротко, резюмируя о том что на что влияет:

Tick Rate влияет на:

FPS влияет на:

Пример проблем с взаимосвязью FPS и Tick Rate

Fixed timestep vs Variable timestep

Fixed timestep (фиксированный шаг):

Variable timestep (переменный шаг):

Интересный факт

В Dark Souls логика и физика были привязаны к 30 FPS. При увеличении частоты кадров поведение игры нарушалось, поскольку временные расчёты зависели от количества кадров.

Обработка ввода (Input Handling)

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

Базовый pipeline упрощённо:

Device → OS → Engine → Input Queue → Game Logic

Что происходит по шагам

Input buffering (буферизация ввода)

Это механизм, при котором ввод сохраняется на короткое время, даже если игра прямо сейчас не может его выполнить. Пример: “Игрок нажал “атака” во время проигрывающейся анимации. Игра не может прервать текущую анимацию, но запоминает ввод и выполняет его сразу после завершения“

Без буферизации:

С буферизацией:

Но есть побочный эффект — ощущение задержки.

Input lag — откуда берётся задержка

Задержка ввода складывается из нескольких этапов:

Даже при хороших условиях это может быть 30–100 мс.

Практический пример

В c используется input buffering. Если нажать кнопку чуть раньше нужного момента, действие всё равно выполнится, но с задержкой относительно нажатия. Это может восприниматься как “подвисание” управления, хотя на самом деле система старается помочь игроку.

Важный баланс

При проектировании ввода приходится балансировать между отзывчивостью (минимальная задержка) и  надёжностью (ввод не теряется). Если система слишком жёсткая, у игрока будет фрустрация, а если слишком мягкая — ощущение “вязкости”.

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

Мини-совет для инди-студий и малых разработчиков. Делегируйте весь ввод на движок. Не пишите свои собственные системы ввода: в Unity такие механики обычно собирают через встроенные инструменты движка и код на C#. Есть готовы ассеты, есть работа с уже установленными базовыми вещами в движке. Всё это нужно чтобы сделать процесс разработки дешевле, а не хуже.

Игровая логика

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

Базовый принцип

Любое действие в игре — это не просто реакция на кнопку, а результат проверок. Например, нужно понять можно ли игроку прыгать. Игрок нажал кнопку. Игра не спрашивает нажата ли кнопка, но она проверяет:

Только если все условия выполняются — действие разрешается.

FSM (Finite State Machine)

Чаще всего такие проверки реализуются через конечные автоматы состояний (FSM).

Простейший пример для персонажа. У него есть несколько состояний:

Idle → Run → Jump → Fall → Land

Эти состояния сообщают что делает персонаж:

Каждое состояние задаёт доступные действия и определяет, куда можно перейти дальше.

Пример с прыжком. Условие “прыжок”:

Если игрок нажимает кнопку в состоянии Fall — логика просто игнорирует ввод. То есть, у персонажа нет двойного прыжка (и тройного, и четверного…).

Таким образом, FSM даёт:

Но есть и минус:

Более того, в современных играх это уже не просто FSM, а комбинация:

Один персонаж может одновременно находиться в нескольких “слоях” состояний:

Игровой пример

В The Witcher 3: Wild Hunt значительная часть логики построена на состояниях. Иногда это проявляется так:

Например, Геральт выпил несколько элексиров и получил интоксикацию, а игрок пытается выпить ещё немного элексира. Геральт не будет это делать, чтобы не погибнуть. Причина не в баге, а в том, что:

С точки зрения системы всё работает корректно — просто ожидания игрока не совпали с логикой.

Игровая логика — это система правил и состояний, которая:

FSM — один из базовых инструментов, который позволяет держать это поведение под контролем, пока проект не вырастает до размеров, где без дополнительных абстракций уже не обойтись.

Физика (Physics)

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

Упрощённо процесс выглядит так:

Apply Forces → Integrate Motion → Collision Detection → Resolve Collisions

Этапы

Что происходит при прыжке

Дальше каждый тик:

Пока нет контакта с землей, объект находится в состоянии Jump/Fall. Когда контакт с землей произведён, объект переходит в состояние Land (например).

Почему физика почти всегда фиксированная

Физика чувствительна к шагу времени. Если timestep меняется:

Поэтому физику обычно считают с фиксированным шагом (например, 60 Гц), независимо от FPS.

Игровая физика — это компромисс:

Цель физики в играх — не академическая точность, а:

Практический эффект

В Half-Life 2 (движок Source) физика стала частью геймплея:

Это был переход от “декораций” к системному миру, где физика влияет на игровой процесс.

Анимация

Анимация отвечает за то, как именно выглядит движение, которое уже решила игровая логика и рассчитала физика. Если логика говорит “персонаж прыгает”, а физика — “он движется вверх”, то анимация делает это визуально убедительным.

Упрощённо, процесс состоит из этапов:

State → Animation Selection → Blending → Pose → Render

Этапы

Blend Trees (деревья смешивания)

Это механизм, который управляет тем, как именно смешиваются анимации. Пример:

В зависимости от них система выбирает и смешивает:

То есть не одна анимация, а континуум состояний между ними.

Без blending резкое переключение с бега на прыжок выглядит неестественно. А с blending движение плавно переходит в прыжок, сохраняется инерция, а тело “подхватывает” предыдущее состояние

Анимация — это процесс, где нужно:

Чем больше анимаций — тем сложнее система. И дороже.

Анимация — это слой, который:

И чем сложнее система анимации, тем сильнее она влияет не только на внешний вид, но и на ощущение управления.

Практический эффект

В Red Dead Redemption 2 используется огромное количество анимаций (около 300 000 анимаций) и сложные blend-системы:

Но есть побочный эффект:

Это осознанный компромисс между:

Рендеринг (визуализация)

Рендеринг — это этап, на котором состояние игрового мира превращается в изображение на экране.

Упрощённая схема:

CPU → Scene Setup → GPU Pipeline → Frame

Роли CPU и GPU

CPU (процессор) собирает сцену, решает, какие объекты нужно рисовать (culling) и отправляет команды GPU. GPU (видеокарта) обрабатывает геометрию, рассчитывает освещение, применяет текстуры, формирует итоговый кадр.

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

Упрощённая схема рендеринга

Vertices → Transform → Rasterization → Fragment Shader → Framebuffer

Этапы

После базовой отрисовки добавляются тени, отражения, глобальное освещение и постобработка:

Почему рендеринг дорогой

Основные затраты:

GPU обрабатывает миллионы пикселей каждый кадр — и делает это десятки раз в секунду. Отсюда и цена расчётов.

Практический эффект

В Cyberpunk 2077 значительная часть визуального качества достигается не за счёт сложной геометрии, а благодаря продвинутому освещению, отражениям и постобработке.

Это была одна из первых игр, где применялась трассировка лучей, но за счёт того что технология была новой — она была плохо адаптирована к консолям.

Даже относительно простые модели могут выглядеть реалистично при правильном освещении.

Звук и эффекты

Звук в игре — это система, которая синхронизируется с логикой, учитывает пространство и формирует восприятие происходящего.

Упрощённый pipeline

Event → Audio System → Processing → Output

Этапы

Что происходит при прыжке:

Почему важен 3D звук

Без пространственного звука всё звучит “плоско” и из одной точки. Становится сложно определить направление источника. С 3D звуком можно ориентироваться на слух, усиливается погружение (даже если игра 2D) и появляется геймплейная ценность (например, шаги за спиной).

Однако, есть свои сложности. Синхронизация с анимацией — один из сложнейших этапов. Звук шага должен совпасть с касанием земли, а шаг может быть недовыполнен или земля может быть не ровной.

На этапе звукорежиссуры важно управлять приоритетами. Важно ответить себе на вопрос “Что в игре ключевая механика?”. Это может быть стрельба, окружение, поведение главного героя, психологизм процесса или звуки ударов покрышек. Этот процесс может влиять на производительность из-за огромного числа источников звука одновременно. Ну и конечно влиять на псизику. Никто не любит шквал звуков.

Хорошо реализованный аудио-движок не только усиливает атмосферу, но и передаёт информацию, которую игрок может использовать.

Практический эффект

В Battlefield V звук учитывает окружение:

Это делает звук не просто эффектом, а частью игрового процесса.

Многопоточность

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

Упрощённая схема

Main Thread → Job System → Worker Threads

                ↘ Render Thread

Какие потоки обычно есть

Пример потоков на Unity:

Также, потоки можно разобрать на примере самописных движков. Например, когда я только начинал разбираться с игровыми движками, я уже знал Python и хотел понять как именно работает процесс написания ПО в виде игры. Результаты большой работы можно почитать в книге, в которой я описал весь процесс The Legend of PyZelda: Breath of the Snakes. Ссылка на доступ к книге.

Если же, многопоточность так удобна, то почему нельзя просто распараллелить всё? Главная проблема — зависимости данных. Как это работает. Физика обновляет позицию объекта, анимация читает позицию объекта, а рендер использует результат. Если выполнять это одновременно без контроля получаются гонки данных (race conditions), неконсистентное состояние и трудноуловимые баги.

Чтобы этого избежать, вводится синхронизация. В игру добавляют барьеры (synchronization points), двойную (или тройную) буферизация данных, а также очереди задач. Цена такого подхода — часть потоков иногда ждёт другие (собственно, концепция очереди).

Даже при 16 ядрах не все задачи можно распараллелить, есть последовательные участки (концепция транзитивности решений, где из А следует Б, из Б следует В, что значит что из А получится В). Также есть точки синхронизации. Это классическое ограничение (по сути — закон Амдала).

На практике, мы имеем следующую картину: один поток перегружен, а значит FPS упирается в него. Остальные ядра недогружены и из-за зависшего главного потока, они не догружаются. GPU может простаивать, ожидая CPU. Отсюда эффект загрузки CPU 30–40%, а FPS не растёт.

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

Примеры из игр

Конец первой части

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

Именно здесь становится понятно, почему игра не всегда реагирует мгновенно и почему высокий FPS сам по себе не гарантирует хорошее ощущение управления. Движок постоянно балансирует между точностью, стабильностью, отзывчивостью и производительностью. Во второй части разберём, где эта система начинает упираться в CPU, GPU и видеопамять — и какие настройки реально помогают, а какие почти ничего не меняют.

Советуем дополнительно почитать по теме:

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

Бэкенд с нуля в 2026: учим Flask, Docker, Redis и ещё 7 технологий — универсальный роадмап для разработчика: HTTP, базы данных, Docker, Redis, очереди, деплой и инженерные навыки, которые помогают понимать сложные системы, а не только писать отдельные функции.

17 инструментов разработчика: базовый набор для любого стека — GitHub, Docker, Postman, Codex и другие инструменты, которые помогают писать, проверять и поддерживать код без зоопарка случайных сервисов.

Востребованные языки программирования в 2026 году — какие языки реально нужны рынку: Python для данных и AI, Go и Rust для высоконагруженных систем, JavaScript / TypeScript для веба, Java / Kotlin для enterprise и Android.

9 лучших книг для программистов в 2026 году — подборка книг про код, архитектуру, инженерное мышление, карьерный рост и работу с большими проектами.

Бонус для читателей

Если вам интересно погрузиться в мир ИИ и при этом немного сэкономить, держите наш промокод на курсы Практикума. Он даст вам скидку при оплате, поможет с льготной ипотекой и даст безлимит на маркетплейсах. Ладно, окей, это просто скидка, без остального, но хорошая.