Чи повинен цикл гри базуватися на фіксованих або змінних часових кроках? Чи завжди хтось вищий, чи правильний вибір залежить від гри?

Змінений крок часу

Оновлення фізики передаються аргументом "час, що минув з моменту останнього оновлення", і, отже, залежать від частоти кадрів. Це може означати проведення розрахунків як 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, який використовують більшість людей) та використовуючи промені для виявлення зіткнень а не прості перевірки відстані Піфагора. Я задав питання про це на стеці Overflow деякий час назад і отримав кілька чудових відповідей:

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

Варіант 3

Використовуйте підхід «Виправити свій крок часу» Гаффера. Оновіть гру фіксованими кроками, як у варіанті 1, але зробіть це кілька разів за кожний кадр, відведений - залежно від часу, який минув, - щоб логіка гри йшла в ногу з реальним часом, залишаючись у дискретних кроках. Таким чином, прості в реалізації ігрові логіки, такі як інтегратори Ейлера, і просте виявлення зіткнень, як і раніше, працюють. У вас також є можливість інтерполяції графічних анімацій на основі дельта-часу, але це лише для візуальних ефектів, і нічого, що впливає на вашу основну логіку гри. Ви можете потенційно потрапити в проблеми, якщо ваші оновлення дуже інтенсивні - якщо оновлення відстають, вам знадобиться все більше й більше, щоб не відставати, що може зробити вашу гру ще менш чуткою.

Особисто мені подобається Варіант 1, коли я можу піти з ним, і Варіант 3, коли мені потрібно синхронізуватися в режимі реального часу. Я поважаю, що варіант 2 може бути хорошим варіантом, коли ви знаєте, що ви робите, але я знаю свої обмеження досить добре, щоб триматися далеко від нього.

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

У 2.0 поведінка малюнка змінилося:

• Оновіть дзвінки стільки разів, скільки потрібно, щоб дотягнути до поточного часу
• Телефонуйте Малюнок один раз
• Зачекайте, поки настане час для наступного оновлення

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

Примітка: xna також підтримує змінний часовий крок, це лише налаштування.

Є ще один варіант - роз'єднати оновлення гри та оновлення фізики. Спроба пристосувати двигун фізики до часового кроку гри призводить до проблеми, якщо ви виправите свій часовий крок (проблема відкручування поза контролем, оскільки для інтеграції потрібно більше часових кроків, які потребують більше часу, для чого потрібно більше часових кроків), або зробіть її змінною і отримаєте невмілу фізику.

Я дуже бачу рішення, щоб фізика працювала за фіксованим часовим кроком, в іншому потоці (на іншому ядрі). Гра інтерполює або екстраполює з урахуванням двох останніх дійсних кадрів, які вона може захопити. Інтерполяція додає певного відставання, екстраполяція додає певної невизначеності, але ваша фізика буде стабільною і не відкрутить ваш крок часу з-під контролю.

Це не банально для реалізації, але може виявити майбутнє доказ.

Особисто я використовую варіацію змінного часового кроку (який я думаю, що це гібрид фіксованої та змінної). Я підкреслював цю систему хронометражу декількома способами, і я можу використовувати її для багатьох проектів. Я рекомендую його для всього? Напевно, ні.

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

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

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

У своїй грі я дозволяю "плавному" (своєрідному) уповільненню обмежувати кількість логічного накопичення, яке повинно бути можливим між двома нічиями. Я роблю це затисканням: F = min (F, MAX_FRAME_DELTA), яке зазвичай має MAX_FRAME_DELTA = 2/100 * s або 3/100 * s. Тож замість того, щоб пропускати кадри, коли занадто далеко за логікою гри, відмовтеся від будь-яких масштабних втрат кадру (що сповільнює роботу), відновіть кілька кадрів, намалюйте та спробуйте ще раз.

Роблячи це, я також переконуюсь, що елементи плеєра підтримують тіснішу синхронізацію з реальним зображенням на екрані.

Псевдокод кінцевого продукту приблизно такий (дельта згадується раніше):

// 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-кратного прискорення буде недостатньо. Вам знадобиться понад 1000 000x прискорення для корисної сим-версії, що складно зробити в моделі з часовим відрізком. За допомогою моделі на основі подій ми отримуємо довільні темпи часу, від 1 s = 7 мс до 1 s = 1 yr.

Зміна темпу часу не змінює поведінку симу, що є критичною особливістю. Якщо недостатньо потужності процесора для запуску тренажера з потрібною швидкістю, події будуть складатись, і ми можемо обмежити оновлення інтерфейсу користувача до тих пір, поки не буде очищена черга подій. Аналогічно, ми можемо перемотати сім настільки, наскільки нам хочеться, і бути впевненими, що ми не витрачаємо процесор і не жертвуємо точністю.

Отже, підводячи підсумки: ми можемо моделювати один транспортний засіб на довгій неквапливій орбіті (використовуючи інтеграцію Runge-Kutta), а інший транспортний засіб одночасно підстрибуючи по землі - обидва транспортні засоби будуть моделюватися з відповідною точністю, оскільки у нас немає глобального часового кроку.

Мінуси: Складність та відсутність будь-яких позаштатних фізичних двигунів, які підтримують цю модель :)

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

Це простий фрагмент коду, тому було б корисно спробувати його і перевірити, чи працює він для вашої гри.

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 кадрів в секунду.

Зважаючи на це, можливо використовувати декілька фіксованих часових кроків. 60 кадрів в секунду можна використовувати для оновлення тривіальних об'єктів (таких як інтерфейс користувача або анімовані спрайти) та 30 кадрів в секунду для оновлення нетривіальних систем (таких як фізика і) і навіть більш повільних таймерів, які можна робити за кадром, наприклад, видалення невикористаних об'єктів, ресурсів тощо.

Крім того, що ви вже заявляли, це може призвести до того, що ви хочете мати вашу гру. Якщо ви не зможете гарантувати, що у вас завжди буде постійний кадр, тоді ви, швидше за все, десь сповільниться, і фіксовані та змінні кроки часу будуть виглядати зовсім інакше. Виправлений призведе до того, що ваша гра відбуватиметься в повільному режимі на деякий час, що іноді може бути наміченим ефектом (подивіться на старого шкільного шутера, як Ікаруга, де масивні вибухи викликають уповільнення після побиття боса). Змінні часові кроки дозволять тримати рух з правильною швидкістю за часом, але ви можете побачити раптові зміни позиції тощо, що може ускладнити гравцеві точне виконання дій.

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

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

Використовуйте підхід «Виправити свій крок часу» Гаффера. Оновіть гру фіксованими кроками, як у варіанті 1, але зробіть це кілька разів за кожний кадр, відведений - залежно від часу, який минув, - щоб логіка гри йшла в ногу з реальним часом, залишаючись у дискретних кроках. Таким чином, прості в реалізації ігрові логіки, такі як інтегратори Ейлера, і просте виявлення зіткнень, як і раніше, працюють. У вас також є можливість інтерполяції графічних анімацій на основі дельта-часу, але це лише для візуальних ефектів, і нічого, що впливає на вашу основну логіку гри. Ви можете потенційно потрапити в проблеми, якщо ваші оновлення дуже інтенсивні - якщо оновлення відстають, вам знадобиться все більше й більше, щоб не відставати, що може зробити вашу гру ще менш чуткою.

Особисто мені подобається Варіант 1, коли я можу піти з ним, і Варіант 3, коли мені потрібно синхронізуватися в режимі реального часу. Я поважаю, що варіант 2 може бути хорошим варіантом, коли ви знаєте, що ви робите, але я знаю свої обмеження досить добре, щоб триматися далеко від нього

Я виявив, що фіксований часовий крок, синхронізований до 60 кадрів в секунду, дає дзеркальну плавну анімацію. Це особливо важливо для VR-додатків. Все інше - це нудота фізично.

Змінні часові кроки не підходять для VR. Погляньте на кілька прикладів Unity VR, які використовують змінні часові кроки. Це неприємно.

Правило, якщо ваша 3D-гра гладка в режимі VR, вона буде відмінною в режимі, що не стосується VR.

Порівняйте ці два (програми VR для картону)

(Змінні часові кроки)

(Фіксовані часові кроки)

Ваша гра повинна бути багатопоточною, щоб досягти послідовного кроку / частоти кадрів. Фізику, інтерфейс користувача та візуалізацію необхідно розділити на виділені нитки. Синхронізувати їх огидно PITA, але результати - це дзеркальне плавне відображення, яке потрібно (особливо для VR).

Мобільні ігри - це esp. складно, тому що вбудовані процесори та графічні процесори мають обмежену продуктивність. Використовуйте GLSL (сленг), щоб зменшити якомога більше роботи з процесора. Будьте в курсі, ніж передавання параметрів GPU споживає ресурси шини.

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

Рамка, яку ви використовуєте, повинна мати можливість повідомляти вас про запит на синхронізацію або використовувати таймер. Не вставляйте затримку сну / очікування, щоб досягти цього - навіть незначні зміни помітні.

Змінні етапи часу призначені для процедур, які слід виконувати якомога частіше: цикли візуалізації, обробка подій, мережеві матеріали тощо.

Фіксовані часові кроки - це коли потрібно щось передбачуване та стабільне. Це включає, але не обмежується фізикою та виявленням зіткнень.

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

Все інше може працювати на змінному кроці часу (хоча професійно кажучи, часто це гарна ідея, щоб дозволити блокування відображення на фіксований крок часу). Для того, щоб ігровий механізм був чуйним, такі речі, як мережеві повідомлення та введення користувачів, слід обробляти якомога швидше, а це означає, що інтервал між опитуваннями в ідеалі повинен бути якомога коротшим. Це загалом означає змінну.

З усім іншим можна обробляти асинхронно, роблячи момент часу суперечкою.