Продолжаем разбирать разные Update.
Сегодня - коротко про Time.fixedDeltaTime.

Time.fixedDeltaTime - это значение фиксированного шага физики (Fixed Timestep). По умолчанию - 0.02, то есть FixedUpdate вызывается 50 раз в секунду.
Логично подумать, что в FixedUpdate нужно использовать именно Time.fixedDeltaTime.
Но это не обязательно.

Time.deltaTime достаточно умный. Документация говорит:

When this is called from inside MonoBehaviour.FixedUpdate, it returns Time.fixedDeltaTime.

То есть внутри FixedUpdate: Time.deltaTime и Time.fixedDeltaTime вернут одно и то же значение. Разница - только в читаемости кода.

Тогда зачем вообще Time.fixedDeltaTime?

1️⃣ Чтобы изменить частоту FixedUpdate

Time.fixedDeltaTime = 0.01f;

Было 0.02 → 50 вызовов в секунду.
Стало 0.01 → 100 вызовов в секунду.

Меняем шаг физики - меняется частота FixedUpdate.

2️⃣ Если нужно получить фиксированный шаг вне FixedUpdate

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

Чаще всего Time.fixedDeltaTime вам пригодится:

• либо при тонкой настройке физики
• либо чтобы блеснуть знанием на собеседовании 🙂

В следующем посте разберём, что происходит с Update и FixedUpdate, когда игра подвисает.

🚀 Пост Guru Unity: @Minerope

Продолжаем углубление в методы Update - Рассмотрим поведение FixedUpdate при зависании

Давайте попробуем ответить на вопрос, который мне задавали на собесе:

Если игра зависла на 2 секунды, то какое будет поведение FixedUpdate в восстановившийся кадр?
Если мы знаем, что FixedUpdate работает зафиксированное время, то что делать, если время прошло, а операция не выполнилась?

Из того, что мы знаем о FixedUpdate, напрашивается очень неприятный вывод.
Если Fixed Timestep установлен в 0.02 секунды, это означает, что физика должна обновляться 50 раз в секунду. Прошло 2 секунды? Значит Unity должен вызвать FixedUpdate 100 раз, чтобы физика "догнала" реальное время.

Но это катастрофа! Если Unity в одном кадре начнёт вызывать FixedUpdate сто раз подряд, это займёт огромное количество времени и игра зависнет ещё сильнее. Следующий кадр тоже будет долгим, что потребует ещё больше вызовов FixedUpdate, и так далее. Это называется "спиралью смерти" производительности.

Но это не происходит, потому что я не сказал вам про ещё одну важную составляющую FixedUpdate. Это - Maximum Allowed Timestep, который располагается в настройках рядом с Fixed Timestamp и по умолчанию равняется 0.3333333.
Эта настройка ограничивает количество времени, которое Unity тратит на обработку физики и вызовов FixedUpdate в течение одного кадра в секундах.
Если обработка кадра занимает больше времени, чем Maximum Allowed Timestep, физический движок не пытается симулировать дополнительное время, превышающее Maximum Allowed Timestep, и вместо этого позволяет обработке кадра завершиться, после чего возобновляет работу так, как будто время не прошло.

Детальнее. У нас Fixed Timestep равен 0.02 секунды, Maximum Allowed Timestep равен 0.33 секунды. Игра зависла на 2 секунды.
Без ограничения Unity должен был бы вызвать FixedUpdate сто раз (две секунды разделить на 0.02 секунды). Но с ограничением в 0.33 секунды максимум он может вызвать примерно шестнадцать раз (0.33 разделить на 0.02).
Как это выражается в поведении физики на сцене? Предположим, мы симулируем полёт пули, скорость которой равняется 100 метров в секунду. За 2 секунды она должна была пролететь 200 метров, но из-за зависания, она пролетит только 33 метра.

0.33 сек : 0.02 сек = 16-17 вызовов, в зависимости от дробной части (Пока возьмём 16)
16 вызовов * 0.02 сек = примерно 0.33 сек
100 м * 2 сек = 200 м - сколько она должна пролететь
Но из - за ограничения выходит вот так:
100 м * 0.33 = 33 м

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

Следующий пост будет финальным, в котором мы рассмотрим поведение Update и LateUpdate при зависании.

🚀 Пост Guru Unity: @Minerope

Как работают Update и LateUpdate

Завершаем цикл постов про методы Update. Сегодня разберём, как ведут себя Update и LateUpdate, если игра подвисает.

Эти методы работают очень просто: кадр вызвался → методы вызвались.

Они не пытаются “догнать” пропущенные вызовы, как это делает FixedUpdate.
То есть один кадр = один вызов метода.

Теоретически при длительном зависмании нас может спасти Time.deltaTime, потому что он учитывает время между кадрами. Но тут есть важный нюанс.

У Time.deltaTime есть ограничение - Time.maximumDeltaTime (в инспекторе это Maximum Allowed Timestep).

Это означает, что значение Time.deltaTime никогда не будет больше ~0.333 секунды.

Подробнее можно почитать в документации:
https://docs.unity3d.com/ru/530/Manual/TimeFrameManagement.html
https://docs.unity3d.com/6000.3/Documentation/Manual/time-handling-variations.html

Как это выглядит на практике

Вспомним простой код движения:

private void Update()
{
    transform.position += Vector3.forward * 10f * Time.deltaTime; // 10 м/с
}

Если игра подвиснет на 2 секунды, то Time.deltaTime всё равно будет равен 0.33.

В итоге - ожидали пройти 20 метров, а фактически пройдём 3.3 метра. Потому что deltaTime ограничен.

Можно ли это исправить?

Технически - да.

Можно использовать:

• Time.unscaledDeltaTime - deltaTime без ограничений
• Time.realtimeSinceStartup - реальное время с момента запуска приложения

Но это почти всегда плохая идея для игровой логики.

Если игра подвиснет, объект может “телепортироваться” на большое расстояние.

Кроме этого:
• физика не будет успевать за объектом
• логика станет сложнее
• нагрузка на CPU может увеличиться

По сути, можно раскрутить “спираль смерти”-— когда из-за лагов система начинает лагать ещё сильнее.

Когда это всё-таки имеет смысл

Использовать unscaledDeltaTime имеет смысл там, где важно реальное время, а не игровое.

Например, для таймера UI:

private void Update()
{
    _uiTimer += Time.unscaledDeltaTime;
    UpdateUITimerText(_uiTimer);
}

А что насчёт LateUpdate?

LateUpdate работает по тем же принципам, что и Update.
Единственная разница - порядок вызова. Сначала Update, потом LateUpdate.

То есть всё, что мы разобрали про Update (ограничение deltaTime, поведение при фризах и т.д.), полностью применимо и к LateUpdate.
Если понимать эти механизмы под капотом, можно без труда отвечать на каверзные вопросы на собеседованиях и, что важнее, писать более предсказуемую игровую логику.

🚀 Пост Guru Unity: @Minerope