Unity player loop: separating input, physics and camera updates

The boundary that matters

A jump button, a rigidbody and a following camera operate on different schedules. Treat their interaction as a transfer of intent into simulation and then into presentation. The useful design question is which system owns each state transition, rather than which callback can access every object. This article uses the Unity 6.0 documentation and Input System 1.14.

Know the three phases

Update runs with rendered frames; FixedUpdate can run zero, once or several times during one frame. Use the latter for forces on a Rigidbody. LateUpdate follows Update, making it a useful camera phase. These callbacks are parts of a larger player loop, not the complete schedule. [1][2]

Transfer input deliberately

The Input System can process events during dynamic updates, fixed updates or manual updates. Choose that setting explicitly. [3] In a design using dynamic input, record movement intent and queue a jump request when its action fires. The physics owner reads that stored intent; it should not assume every physics step receives a fresh button edge. Give queued commands a consumption rule and, if needed, an expiry time.

Example: a delivery robot

Consider a robot that moves crates and hops over cables. Store the most recent steering vector and one pending hop. At the next physics tick, check whether hopping is allowed, apply the chosen impulse once and consume the request. Keep steering available for later ticks until input changes. In LateUpdate, position the camera using the robot’s resulting presentation pose. If a slow frame causes three physics ticks, this design applies three movement updates but only one hop. If no physics tick occurs, the pending request remains available. This is an illustrative design, not a measured implementation.

Limits and verification

Specify what happens to pending input during pause, respawn and focus loss; otherwise a stale hop may fire when play resumes. A boolean queue intentionally merges repeated presses, so use a bounded command queue if every press matters. Do not infer ordering between arbitrary instances from their hierarchy. [1] Test short taps and held movement at several frame rates, then inspect the profiler timeline for duplicate command consumption. Camera smoothing and rigidbody interpolation require their own tuning; moving code into LateUpdate does not by itself guarantee smooth motion.

Sources

1. Event function execution order — Unity Technologies.
2. MonoBehaviour.FixedUpdate — Unity Technologies.
3. Input System 1.14: Input settings — Unity Technologies.