Просадки FPS при простой сцене почти всегда начинаются с одного и того же места — главного цикла игры, который каждый кадр выполняет лишнюю работу: пересчитывает физику чаще, чем нужно, вызывает отрисовку объектов вне камеры или блокируется на ожидании вертикальной синхронизации. Если игра «тормозит» на сильном железе, первым делом стоит замерить, сколько миллисекунд занимает каждая фаза игрового цикла — обновление логики, физика, рендеринг.
Гейм луп (game loop) — это бесконечный цикл, который обрабатывает ввод, обновляет состояние мира и выводит картинку на экран. От того, как он построен, зависят плавность геймплея, стабильность физики и отзывчивость управления. Ниже разберём, как устроен цикл, где он чаще всего теряет производительность и какие приёмы оптимизации дают эффект без переписывания всего проекта.
Как устроен игровой цикл и где он теряет время
Классическая структура цикла выглядит так: чтение ввода → обновление логики (update) → физика → рендеринг → ожидание следующего кадра. Проблемы возникают, когда одна из стадий занимает нестабильное время: например, физический движок пересчитывает столкновения для всех объектов сцены, хотя активна только их малая часть.
Типичные «пожиратели» времени кадра:
- 🔁 Пересчёт логики для объектов, которые сейчас не видны и не активны;
- 🧮 Физика с переменным шагом, из-за которой движок делает лишние итерации;
- 🎨 Лишние draw calls — отрисовка каждого объекта отдельным вызовом;
- 📦 Выделение памяти внутри цикла, провоцирующее сборку мусора;
- ⏳ Блокирующие операции ввода-вывода прямо в главном потоке.
Прежде чем что-то менять, измерьте. Без профилирования оптимизация превращается в гадание: можно день потратить на ускорение кода, который занимает 2% времени кадра.
Профилирование: найдите узкое место кадра
Начните с встроенных инструментов вашего движка. В Unity это Profiler, в Unreal Engine — Unreal Insights и статистические команды, в Godot — встроенный монитор производительности. Они показывают, сколько миллисекунд уходит на скрипты, физику, рендеринг и ожидание GPU.
Добавьте и собственные замеры. Оберните ключевые фазы цикла таймерами и выведите среднее и максимальное время:
// псевдокод замера фаз кадра
startTimer();
updateInput();
updateLogic(dt);
tLogic = stopTimer();
startTimer();
physics.step(fixedDt);
tPhysics = stopTimer();
startTimer();
render();
tRender = stopTimer();
Смотрите не только на среднее, но и на пики. Средний кадр в 8 мс с регулярными всплесками до 40 мс ощущается как заикание — именно такие всплески обычно вызывают сборка мусора, подгрузка ресурсов или физические «взрывы» при массовых столкновениях.
⚠️ Внимание: замеряйте производительность в сборке релизного типа, а не в редакторе и не в debug-конфигурации. Отладочные проверки, логирование и отсутствие оптимизаций компилятора могут искажать картину в разы.
Фиксированный шаг против переменного delta time
Один из ключевых архитектурных вопросов — как считать время между кадрами. При переменном delta time логика обновляется ровно один раз за кадр с фактическим прошедшим временем. Это просто, но делает физику нестабильной: на слабом устройстве с редкими кадрами объекты могут «проскакивать» сквозь стены.
Альтернатива — фиксированный таймстеп: физика и логика обновляются с постоянным шагом (например, 60 раз в секунду), а рендеринг идёт с любой частотой. Накопленное время разбивается на целые шаги:
accumulator += frameTime;
while (accumulator >= FIXED_DT) {
update(FIXED_DT);
accumulator -= FIXED_DT;
}
render(interpolationAlpha);
Чтобы картинка не дрожала при несовпадении частоты обновления и рендера, используют интерполяцию между предыдущим и текущим состоянием объектов — позиция на экране вычисляется как смесь двух последних физических состояний.
| Подход | Плюсы | Минусы | Когда применять |
|---|---|---|---|
| Переменный dt | Простота, нет лишних итераций | Нестабильная физика, зависимость от FPS | Простые игры без точной физики |
| Фиксированный шаг | Детерминизм, стабильная физика | Сложнее код, нужна интерполяция | Физические игры, сетевые симуляции |
| Гибридный | Физика фиксирована, лёгкая логика — по dt | Требует разделения систем | Большинство средних и крупных проектов |
| Полуфиксированный (с лимитом шагов) | Защита от «спирали смерти» | Возможны замедления на слабом ПК | Игры с тяжёлой физикой |
Что такое «спираль смерти» в гейм лупе
Если обновление логики занимает больше времени, чем сам фиксированный шаг, аккумулятор растёт быстрее, чем успевает обрабатываться. Цикл пытается «догнать» время, выполняя всё больше итераций за кадр, и игра замирает. Лечение — ограничить максимальное число шагов за кадр и при переполнении просто сбрасывать остаток аккумулятора (игра чуть замедлится, но не зависнет).
Снижение нагрузки на CPU внутри цикла
Когда профилировщик показывает, что время уходит на обновление логики, работайте с объёмом обрабатываемых данных, а не с микрооптимизациями отдельных строк.
- 🧊 «Усыпляйте» неактивные объекты: врагов за пределами радиуса вокруг игрока можно обновлять реже или не обновлять вовсе;
- 🗂️ Группируйте данные по типу (подход data-oriented), чтобы снизить промахи кэша процессора;
- 🚫 Уберите выделение памяти из горячего пути: переиспользуйте пулы объектов вместо создания новых экземпляров каждый кадр;
- 🧵 Выносите независимые системы (поиск пути, ИИ, подготовка данных) в фоновые потоки, если движок это позволяет;
- 📉 Ограничьте частоту тяжёлых проверок: не каждую систему нужно обновлять 60 раз в секунду.
Отдельного внимания заслуживает сборка мусора в языках со сборщиком (C#, GDScript). Каждое new внутри цикла — потенциальный будущий фриз. Переведите часто создаваемые объекты (пули, эффекты, снаряды) на пулинг: объекты не удаляются, а возвращаются в пул и используются повторно.
Оптимизация рендеринга в рамках цикла
Если профилировщик показывает, что узкое место — отрисовка, проверьте количество draw calls и работу с прозрачностью. Каждый отдельный вызов отрисовки несёт накладные расходы на драйвер, поэтому сотни мелких объектов дороже одного большого.
Основные приёмы: объединение статичной геометрии (static batching), атласы спрайтов для 2D, отсечение невидимых объектов (frustum culling и occlusion culling), уровни детализации (LOD) для далёких моделей. Большинство движков включают часть этих механизмов автоматически, но статические объекты часто нужно пометить вручную.
⚠️ Внимание: отключение вертикальной синхронизации (VSync) ради «честного» замера FPS допустимо только на этапе профилирования. В релизе бесконтрольный цикл без ограничения кадров гоняет GPU на полную мощность, повышая нагрев и энергопотребление, — на ноутбуках это особенно заметно.
Пошаговый порядок оптимизации
Действуйте от измерения к изменению, а не наоборот. Произвольная перестройка архитектуры без замеров часто ухудшает читаемость кода, не давая прироста.
☑️ Чек-лист оптимизации гейм лупа
После каждого изменения фиксируйте результат: среднее время кадра, 1% худших кадров (это показатель плавности важнее среднего FPS) и пиковые значения. Только так можно понять, сработала ли оптимизация, или она лишь усложнила код.
Типичные ошибки при оптимизации цикла
Первая ошибка — преждевременная микрооптимизация: замена умножения на битовые сдвиги там, где профилировщик показывает доли процента времени. Вторая — оптимизация под средний FPS вместо борьбы с просадками. Третья — смешение логики и рендеринга: когда расчёт состояния мира зависит от кода отрисовки, любой перенос на другую частоту кадров ломает игру.
Ещё одна частая проблема — обработка ввода внутри физического шага. Ввод нужно считывать каждый кадр и применять к ближайшему шагу симуляции, иначе на высокой частоте кадров управление будет ощущаться «ватным» или, наоборот, рывками.
Частые вопросы
Какой фиксированный шаг выбрать для физики?
Распространённый ориентир — 60 шагов в секунду, но конкретное значение зависит от жанра и требований к точности. Гоночные и файтинги иногда используют более частый шаг, стратегии — более редкий. Подбирайте значение экспериментально, проверяя стабильность симуляции на самом слабом целевом устройстве.
Нужно ли ограничивать FPS в игре?
Ограничение кадров снижает нагрев и энергопотребление и делает время кадра стабильнее. На ПК разумно давать игроку выбор в настройках, на мобильных устройствах ограничение часто является обязательной практикой из-за троттлинга.
Почему игра фризит, хотя средний FPS высокий?
Фризы — это всплески времени отдельных кадров. Типичные источники: сборка мусора, синхронная загрузка ресурсов, компиляция шейдеров «на лету», массовое создание объектов. Ищите причину по графику времени кадра в профилировщике, а не по среднему FPS.
Стоит ли выносить игровую логику в отдельные потоки?
Многопоточность даёт выигрыш, когда системы независимы (ИИ, поиск пути, подготовка данных рендера). Но синхронизация потоков сама по себе сложна и может съесть прирост. Начинайте с однопоточной оптимизации и переходите к потокам только при доказанной необходимости.
Чем интерполяция отличается от экстраполяции в рендере?
Интерполяция строит картинку между двумя известными состояниями — она точна, но добавляет задержку в один шаг симуляции. Экстраполяция предсказывает будущее состояние — отклик мгновенный, но при резких изменениях движения возможны видимые рывки и откаты. Для большинства игр интерполяция предпочтительнее.