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

Переменный шаг по времени

Физическим обновлениям передается аргумент «истекшее время с момента последнего обновления» и, следовательно, они зависят от частоты кадров. Это может означать выполнение расчетов как position += distancePerSecond * timeElapsed.

Плюсы : гладкие, легче
кодируемые Минусы : недетерминированные, непредсказуемые на очень маленьких или больших шагах

Пример deWiTTERS :

while( game_is_running ) {
    prev_frame_tick = curr_frame_tick;
    curr_frame_tick = GetTickCount();
    update( curr_frame_tick - prev_frame_tick );
    render();
}

Фиксированный шаг по времени

Обновления могут даже не принимать «истекшее время», так как они предполагают, что каждое обновление имеет фиксированный период времени. Расчеты могут быть сделаны как position += distancePerUpdate. Пример включает в себя интерполяцию во время рендеринга.

Плюсы : предсказуемый, детерминированный (проще для синхронизации по сети?), Более четкий код расчета.
Минусы : не синхронизируется для мониторинга v-синхронизации (вызывает дрожание графики, если вы не интерполируете), ограниченная максимальная частота кадров (если вы не интерполируете), трудно работать в рамках, которые предположить переменные временные шаги (например, Pyglet или Flixel )

Пример deWiTTERS :

while( game_is_running ) {
    while( GetTickCount() > next_game_tick ) {
        update();
        next_game_tick += SKIP_TICKS;
    }
    interpolation = float( GetTickCount() + SKIP_TICKS - next_game_tick )
                    / float( SKIP_TICKS );
    render( interpolation );
}

Некоторые ресурсы

• Торгуйте по играм: исправьте время!
• статья цикла игры deWitter
• FPS в Quake 3 влияет на физику прыжков - по какой причине Doom 3 блокируется до 60 кадров в секунду?
• Flixel требует переменного временного шага (я думаю, это определяется Flash), тогда как Flashpunk допускает оба типа.
• Руководство Box2D § Моделирование мира Box2D предполагает, что он использует постоянные временные шаги.

Есть два вопроса, связанных с этим вопросом.

• Должна ли физическая скорость шага быть привязана к частоте кадров?
• Должна ли физика идти с постоянными дельтами?

В «Исправлении вашего временного шага» Глен Филдер говорит «Освободи физику». Это означает, что ваша частота обновления физики не должна быть привязана к вашей частоте кадров.

Например, если частота кадров дисплея составляет 50 кадров в секунду, а симуляция рассчитана на работу со скоростью 100 кадров в секунду, то нам необходимо выполнять два шага по физике при каждом обновлении дисплея, чтобы синхронизировать физику.

В рекомендациях Эрин Катто для Box2D он также выступает за это.

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

Должна ли скорость физического шага быть привязана к вашей частоте кадров? Нет .

Мысли Эрин о фиксированном шаге и переменном шаге:

Box2D использует вычислительный алгоритм, называемый интегратором. Интеграторы моделируют физические уравнения в дискретные моменты времени. ... Нам также не нравится, когда временной шаг сильно меняется. Переменный шаг по времени приводит к переменным результатам, что затрудняет отладку.

Мысли Глена о фиксированном и переменном степпинге:

Исправьте свой временной шаг или взорвитесь

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

Должна ли физика идти с постоянными дельтами? Да.

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

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

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

Я думаю, что есть действительно 3 варианта, но вы перечисляете их как только 2:

Опция 1

Ничего не делать. Попытка обновления и рендеринга с определенным интервалом, например, 60 раз в секунду. Если он отстает, пусть это и не волнуйтесь. Игры замедлятся до резких замедлений, если процессор не поспевает за вашей игрой. Эта опция не будет работать вообще для многопользовательских игр в реальном времени, но подходит для однопользовательских игр и успешно используется во многих играх.

Вариант 2

Используйте дельта-время между каждым обновлением, чтобы варьировать движение объектов. Прекрасно в теории, особенно если в вашей игре ничего не ускоряется и не замедляется, а просто движется с постоянной скоростью. На практике многие разработчики плохо это реализуют, и это может привести к непоследовательному обнаружению столкновений и физике. Кажется, некоторые разработчики считают, что этот метод проще, чем есть. Если вы хотите использовать эту опцию, вам нужно значительно улучшить свою игру и вывести некоторые математические и алгоритмы с большим оружием, например, используя физический интегратор Verlet (а не стандартный Euler, который используют большинство людей) и используя лучи для обнаружения столкновений. а не простые проверки расстояния Пифагора. Я задал вопрос об этом в Stack Overflow некоторое время назад и получил несколько отличных ответов:

https://stackoverflow.com/questions/153507/calculate-the-position-of-an-accelerating-body-after-a-certain-time

Вариант 3

Используйте подход Гаффера "исправь свой временной шаг". Обновляйте игру фиксированными шагами, как в варианте 1, но делайте это несколько раз за каждый отрисованный кадр - исходя из того, сколько времени прошло - чтобы логика игры соответствовала реальному времени, оставаясь в дискретных шагах. Таким образом, простая в реализации логика игры, такая как интеграторы Эйлера, и простое обнаружение столкновений все еще работают. У вас также есть возможность интерполировать графические анимации, основанные на дельта-времени, но это только для визуальных эффектов, и ничего, что влияет на вашу основную игровую логику. Вы можете столкнуться с проблемами, если ваши обновления будут очень интенсивными - если обновления отстают, вам понадобится все больше и больше, чтобы поддерживать их, что может сделать вашу игру еще менее отзывчивой.

Лично мне нравится вариант 1, когда я могу обойтись без него, и вариант 3, когда мне нужно синхронизировать данные в реальном времени. Я уважаю, что вариант 2 может быть хорошим вариантом, когда вы знаете, что делаете, но я знаю свои ограничения достаточно хорошо, чтобы держаться подальше от него.

Мне действительно нравится, как XNA Framework реализует фиксированный временной шаг. Если заданный вызов отрисовки занимает слишком много времени, он будет вызывать update несколько раз, пока не «догонит». Шон Харгривз описывает это здесь:
http://blogs.msdn.com/b/shawnhar/archive/2007/11/23/game-timing-in-xna-game-studio-2-0.aspx

В 2.0 поведение Draw изменилось:

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

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

примечание: xna также поддерживает переменный временной шаг, это просто настройка.

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

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

Это не тривиально для реализации, но может оказаться доказательством будущего.

Лично я использую вариацию переменного временного шага (я думаю, что это своего рода гибрид фиксированного и переменного). Я стресс-тестировал эту систему синхронизации несколькими способами, и я обнаружил, что использую ее для многих проектов. Я рекомендую это для всего? Возможно нет.

Мои игровые циклы рассчитывают количество кадров для обновления (назовем это F), а затем выполняем F дискретных обновлений логики. Каждое обновление логики предполагает постоянную единицу времени (которая в моих играх часто составляет 1/100 секунды). Каждое обновление выполняется последовательно, пока не будут выполнены все обновления F дискретной логики.

Почему дискретные обновления в логических шагах? Что ж, если вы попытаетесь использовать непрерывные шаги, и вдруг у вас будут физические глюки, потому что рассчитанные скорости и расстояния для перемещения умножаются на огромное значение F.

Плохая реализация этого просто сделает F = текущее время - последние обновления времени кадра. Но если расчеты слишком сильно отстают (иногда из-за не зависящих от вас обстоятельств, например, из-за того, что другой процесс крадет процессорное время), вы быстро увидите ужасный пропуск. Быстро, тот стабильный FPS, который вы пытались поддерживать, становится SPF.

В моей игре я допускаю «плавное» (своего рода) замедление, чтобы ограничить количество логического захвата, которое должно быть возможно между двумя розыгрышами. Я делаю это, зажимая: F = min (F, MAX_FRAME_DELTA), который обычно имеет MAX_FRAME_DELTA = 2/100 * с или 3/100 * с. Таким образом, вместо того, чтобы пропускать кадры, когда они слишком далеко отстают от игровой логики, отбросьте любую значительную потерю кадров (что замедляет ход событий), восстановите несколько кадров, сделайте рисование и попробуйте снова.

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

Конечный псевдокод продукта выглядит примерно так (дельта F упоминается ранее):

// Assume timers have 1/100 s resolution
const MAX_FRAME_DELTA = 2
// Calculate frame gap.
var delta = current time - last frame time
// Clamp.
delta = min(delta, MAX_FRAME_RATE)
// Update in discrete steps
for(i = 0; i < delta; i++)
{
    update single step()
}
// Caught up again, draw.
render()

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

Это решение не применимо ко всему, но есть другой уровень переменного временного шага - переменный временной шаг для каждого объекта в мире.

Это кажется сложным, и это может быть, но думайте об этом как о моделировании вашей игры как о моделировании отдельных событий. Каждое движение игрока может быть представлено как событие, которое начинается, когда движение начинается, и заканчивается, когда движение заканчивается. Если есть какое-либо взаимодействие, требующее разделения события (например, коллизия), событие отменяется, и другое событие помещается в очередь событий (которая, вероятно, является приоритетной очередью, отсортированной по времени окончания события).

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

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

while (game_is_running)
{
   world.draw_to_screen(); 
   world.get_player_input(); 
   world.consume_events_until(current_time + time_step); 
   current_time += time_step; 
}

Основной причиной использования одного в космическом симуляторе является необходимость обеспечения произвольного ускорения времени без потери точности. Некоторые миссии в EXOFLIGHT могут занимать годы игры, и даже 32-кратного ускорения будет недостаточно. Вам понадобится более 1 000 000 раз ускорения для пригодного для использования сима, что трудно сделать в модели с временным интервалом. С помощью модели, основанной на событиях, мы получаем произвольные значения времени от 1 с = 7 мс до 1 с = 1 год.

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

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

Минусы: сложность и отсутствие каких-либо готовых физических движков, которые поддерживают эту модель :)

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

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

now = currentTime
frameTime = now - lastTimeStamp // time since last render()
while (frameTime > updateTime)
    update(timestep)
    frameTime -= updateTime     // update enough times to catch up
                                // possibly leaving a small remainder
                                // of time for the next frame

lastTimeStamp = now - frameTime // set last timestamp to now but
                                // subtract the remaining frame time
                                // to make sure the game will still
                                // catch up on those remaining few millseconds
render()

Основная проблема с использованием фиксированного временного шага заключается в том, что игроки с быстрым компьютером не смогут использовать скорость. Рендеринг со скоростью 100 кадров в секунду, когда игра обновляется только со скоростью 30 кадров в секунду, аналогичен рендерингу со скоростью 30 кадров в секунду.

При этом может быть возможно использовать более одного фиксированного временного шага. 60fps можно использовать для обновления тривиальных объектов (таких как пользовательский интерфейс или анимированные спрайты), а 30fps для обновления нетривиальных систем (таких как физика и т. Д.) И даже более медленных таймеров для управления за кулисами, таких как удаление неиспользуемых объектов, ресурсов и т. Д.

Помимо того, что вы уже заявили, это может привести к тому, что вы захотите, чтобы ваша игра была. Если вы не можете гарантировать, что у вас всегда будет постоянная частота кадров, то вы, вероятно, будете где-то замедляться, а фиксированные и переменные временные шаги будут выглядеть совсем иначе. Исправлено будет иметь эффект, что ваша игра некоторое время замедляется, что иногда может быть ожидаемым эффектом (посмотрите на шутер в старом школьном стиле, такой как Икаруга, где массивные взрывы вызывают замедление после избиения босса). Переменные временные шаги позволят вещам двигаться с правильной скоростью с точки зрения времени, но вы можете увидеть внезапные изменения в положении и т. Д., Из-за которых игрок может затруднить точное выполнение действий.

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

Я всегда склонялся к переменному подходу лично, но у этих статей есть некоторые интересные вещи для размышления. Тем не менее, я по-прежнему считаю фиксированные шаги довольно распространенными, особенно на консолях, где люди думают, что частота кадров составляет 60 кадров в секунду по сравнению с очень высокими скоростями, достижимыми на ПК.

Используйте подход Гаффера "исправь свой временной шаг". Обновляйте игру фиксированными шагами, как в варианте 1, но делайте это несколько раз за каждый отрисованный кадр - исходя из того, сколько времени прошло - чтобы логика игры соответствовала реальному времени, оставаясь в дискретных шагах. Таким образом, простая в реализации логика игры, такая как интеграторы Эйлера, и простое обнаружение столкновений все еще работают. У вас также есть возможность интерполировать графические анимации, основанные на дельта-времени, но это только для визуальных эффектов, и ничего, что влияет на вашу основную игровую логику. Вы можете столкнуться с проблемами, если ваши обновления будут очень интенсивными - если обновления отстают, вам понадобится все больше и больше, чтобы поддерживать их, что может сделать вашу игру еще менее отзывчивой.

Лично мне нравится вариант 1, когда я могу обойтись без него, и вариант 3, когда мне нужно синхронизировать данные в реальном времени. Я уважаю, что вариант 2 может быть хорошим вариантом, когда вы знаете, что делаете, но я знаю свои ограничения достаточно хорошо, чтобы держаться подальше от него

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

Переменные временные шаги не подходят для VR. Посмотрите на некоторые примеры Unity VR, которые используют переменные временные шаги. Это неприятно.

Правило гласит: если ваша 3D-игра плавная в режиме VR, она будет отличной в режиме без VR.

Сравните эти два (приложения Cardboard VR)

(Переменные временные шаги)

(Фиксированные временные шаги)

Ваша игра должна быть многопоточной, чтобы достигать согласованного временного шага / частоты кадров. Физика, интерфейс и рендеринг должны быть разделены на отдельные потоки. Это ужасная PITA, чтобы синхронизировать их, но в результате вы получите тот зеркально-плавный рендеринг, который вам нужен (особенно для VR).

Мобильные игры особенно. сложный, потому что встроенные процессоры и графические процессоры имеют ограниченную производительность. Используйте GLSL (сленг) экономно, чтобы максимально разгрузить процессор. Имейте в виду, что передача параметров в графический процессор потребляет ресурсы шины.

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

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

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

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

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

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

Все остальное можно обрабатывать асинхронно, что делает спорным моментом времени.