Quick Flow

Unity는 render frame과 fixed physics step을 분리합니다. input은 frame마다 sample해 buffer에 넣고, Rigidbody·physics state는 FixedUpdate에서 적용하며, target을 따라가는 camera 같은 render view는 LateUpdate에서 갱신합니다. 고정 step은 cadence를 정할 뿐 replay·network determinism을 자동으로 보장하지 않습니다.

Vector2 pendingMove;

void Update()
{
    pendingMove = ReadMoveInput(); // 최신 input을 frame마다 수집
}

void FixedUpdate()
{
    body.AddForce(new Vector3(pendingMove.x, 0f, pendingMove.y) * acceleration);
}

void LateUpdate()
{
    cameraRig.Follow(body.position); // simulation 뒤 화면 갱신
}

variable frame과 fixed physics

Update는 render frame마다 한 번 호출되므로 frame-rate dependent movement에는 Time.deltaTime을 곱습니다. FixedUpdate는 Time.fixedDeltaTime에 따라 호출되고 느린 frame에서는 여러 번, 빠른 frame에서는 호출되지 않을 수 있습니다. Unity physics update는 fixed step 뒤 수행되므로 Rigidbody에 force·velocity를 적용하는 code는 physics API와 같은 time domain에 둡니다.

input을 FixedUpdate에서만 읽으면 short press를 놓치거나 frame timing에 따라 반응이 달라질 수 있습니다. input command 또는 latest sample을 Update에서 모으고 fixed step에서 소비하면 responsiveness와 physics time을 분리할 수 있습니다. 입력을 한 번만 소비해야 한다면 tick id·sequence를 함께 buffer에 저장합니다.

fixed step과 결정성은 다르다

fixed timestep은 simulation interval을 같게 하지만 float math, physics engine, platform, execution order, random seed, load timing이 달라지면 결과도 달라질 수 있습니다. deterministic replay나 rollback network에는 input command order, seeded RNG, serializable state snapshot/hash, simulation version과 platform/physics policy가 추가로 필요합니다.

lag spike에서 fixed update가 여러 번 따라오면 CPU 부담과 input handling이 달라질 수 있습니다. max catch-up·time scale·pause에서 어떤 tick을 생략·보존할지 정하고 profiler로 확인합니다. “FixedUpdate이므로 replay 가능”처럼 표현하지 않습니다.

실행 순서 의존성 줄이기

특정 script가 먼저 실행돼야만 하는 구조는 fragile합니다. data flow를 명시적으로 호출하거나 tick coordinator가 순서를 소유하고, Unity Script Execution Order 또는 [DefaultExecutionOrder]는 정말 필요한 bootstrap·camera 관계에만 씁니다. Editor setting이 code attribute보다 우선할 수 있다는 점도 프로젝트 규약에 기록합니다.