Quick Comparison

두 값은 Project Settings > Time의 전역 설정이며 Time.fixedDeltaTime, Time.maximumDeltaTime으로 런타임에서도 읽고 바꿀 수 있습니다. 특정 기기에 맞는 만능 숫자는 없습니다. 목표 기기와 실제 충돌 장면에서 정확도와 frame pacing을 함께 측정해 결정합니다.

private void FixedUpdate()
{
    // fixedDeltaTime은 물리 step 하나의 game-time 간격입니다.
    _body.AddForce(thrust * Time.fixedDeltaTime, ForceMode.Force);
}

값이 바꾸는 결과

Fixed Timestep

Fixed Timestep이 작으면 같은 game time 동안 FixedUpdate와 physics simulation이 더 많이 실행됩니다. 빠른 투사체나 단단한 joint가 있다는 이유만으로 이 값을 먼저 낮추지 마세요. Collision Detection, Collider 두께, Rigidbody 속도, solver iteration, 물리 단위 scale도 충돌 결과에 관여합니다.

값을 키우면 CPU는 절약할 수 있지만 입력 반영, 힘 적용, trigger/collision callback의 시간 해상도도 함께 낮아집니다. 카메라가 따라가는 Rigidbody는 step 간격이 커질수록 시각적 흔들림이 보일 수 있어 interpolation도 함께 봐야 합니다.

timeScale과의 관계도 분리합니다. fixedDeltaTime은 game time 간격입니다. timeScale만 낮추면 실제 시간 기준 physics step은 더 드물어집니다. slow motion 중에도 실제 시간 기준 step 빈도를 유지해야 할 때만 원래 fixed timestep에 scale을 곱해 조정하고, 종료 시 저장한 원래 값으로 복구합니다.

Maximum Allowed Timestep

느린 프레임에서 Unity는 물리 시간을 따라잡기 위해 여러 fixed step을 실행할 수 있습니다. 이 catch-up 자체가 다음 프레임을 더 늦춰 악순환이 될 수 있습니다. Maximum Allowed Timestep은 한 렌더 프레임 사이에 시뮬레이션할 물리 시간의 상한입니다.

프레임 처리가 이 상한보다 오래 걸리면 Unity는 추가 시간을 물리로 시뮬레이션하지 않고 frame processing이 따라잡게 합니다. 그래서 해당 구간의 물리 객체는 완벽한 real-time으로 움직이지 않고 잠시 느려질 수 있습니다. 값을 낮춰 stutter를 숨겼는데 네트워크 판정, 리플레이, 정밀 타이머가 어긋나는지 확인해야 하는 이유입니다.

측정으로 결정하기

1. release에 가까운 build에서 warm-up 뒤 같은 입력과 같은 장면을 재현합니다.
2. 변경 전후에 CPU physics 비용, median뿐 아니라 worst frame과 collision 결과를 기록합니다.
3. 문제가 난 기기에서 Fixed Timestep만 바꾸지 말고 collider scale, detection mode, solver, allocation spike를 함께 비교합니다.
4. Maximum Allowed Timestep을 낮췄다면 긴 프레임 뒤 물리 시간이 느려지는 것이 게임 규칙상 허용되는지 확인합니다.