FixedUpdate vs Update in Unity - Trade-offs & Expert Analysis

Overview - FixedUpdate vs Update

What is it?

In Unity, FixedUpdate and Update are two special functions that run repeatedly during the game. Update runs once every frame and is used for general game logic like input and animations. FixedUpdate runs at a fixed time interval and is mainly used for physics calculations to keep them stable and consistent. Both help control when and how often certain code runs in your game.

Why it matters

Without FixedUpdate and Update, game actions would be unpredictable and messy. Physics might behave strangely if updated irregularly, and input or animations could feel laggy or uneven. These functions solve the problem of timing in games, making sure physics stays smooth and gameplay feels responsive no matter the frame rate.

Where it fits

Before learning FixedUpdate and Update, you should understand basic Unity scripting and the game loop concept. After mastering these, you can learn about advanced timing techniques like Coroutines and how to optimize performance by controlling update rates.

Mental Model

Core Idea

Update runs every frame for general tasks, while FixedUpdate runs at steady intervals for physics to keep things smooth and predictable.

Think of it like...

Think of Update as checking your phone every time you hear a notification (irregular timing), and FixedUpdate as checking the mailbox every hour on the hour (regular timing). Both are important but serve different purposes.

┌───────────────┐       ┌───────────────┐
│   Frame 1     │       │ Fixed Time 1  │
│ Update runs   │       │ FixedUpdate   │
│ (variable)    │       │ runs (fixed)  │
└──────┬────────┘       └──────┬────────┘
       │                       │
┌──────▼────────┐       ┌──────▼────────┐
│   Frame 2     │       │ Fixed Time 2  │
│ Update runs   │       │ FixedUpdate   │
│ (variable)    │       │ runs (fixed)  │
└───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Unity's Game Loop

Concept: Learn how Unity runs your game code repeatedly in cycles called frames.

Unity runs your game by repeating a cycle many times per second. Each cycle is called a frame. During each frame, Unity updates game logic, processes input, and renders graphics. This cycle is the heartbeat of your game.

Result

You understand that game code runs repeatedly and timing matters for smooth gameplay.

Knowing the game loop helps you see why timing functions like Update and FixedUpdate exist to organize code execution.

2

Foundation

What is Update Method?

Concept: Update runs once every frame and is used for general game logic.

The Update method is called once per frame. It is where you put code that needs to check input, move objects, or play animations. Because frame rates can change, Update runs at variable intervals.

Result

Your code inside Update runs frequently but not at fixed time steps.

Understanding Update's variable timing is key to knowing when it is suitable and when it is not.

3

Intermediate

What is FixedUpdate Method?

Concept: FixedUpdate runs at fixed time intervals, ideal for physics updates.

FixedUpdate is called on a fixed timer, independent of frame rate. It is used for physics calculations like applying forces or moving rigid bodies. This fixed timing keeps physics stable and predictable.

Result

Physics code inside FixedUpdate runs consistently, avoiding glitches caused by variable frame rates.

Knowing FixedUpdate's fixed timing explains why physics code should go here, not in Update.

4

Intermediate

Difference Between Update and FixedUpdate

🤔Before reading on: Do you think Update or FixedUpdate runs more often during high frame rates? Commit to your answer.

Concept: Update runs every frame and can run more or less often depending on frame rate; FixedUpdate runs at a steady rate regardless of frame rate.

Update frequency depends on how fast frames render, so it can speed up or slow down. FixedUpdate runs at a set interval (default 0.02 seconds). When frame rate is high, Update runs more often than FixedUpdate; when low, fewer times.

Result

You see that Update timing is variable and FixedUpdate timing is constant.

Understanding this difference helps prevent bugs like physics behaving inconsistently or input feeling laggy.

5

Intermediate

When to Use Update vs FixedUpdate

🤔Before reading on: Should you handle player input in Update or FixedUpdate? Commit to your answer.

Concept: Use Update for input and animations; use FixedUpdate for physics and movement involving Rigidbody.

Input should be checked in Update because it matches frame rendering and feels responsive. Physics changes like applying forces or moving Rigidbody objects should be done in FixedUpdate to keep physics stable.

Result

Your game feels smooth and physics behaves correctly by using each method properly.

Knowing the right place for code prevents common gameplay bugs and improves player experience.

6

Advanced

Handling Variable Frame Rates and Physics

🤔Before reading on: Do you think physics calculations in Update will always be stable? Commit to your answer.

Concept: Physics calculations in Update can cause instability because frame rates vary; FixedUpdate ensures consistent physics steps.

If physics code runs in Update, varying frame rates cause inconsistent physics steps, leading to jitter or tunneling. FixedUpdate runs at fixed intervals, so physics calculations are stable and predictable regardless of frame rate changes.

Result

Physics behaves smoothly and reliably even if frame rate fluctuates.

Understanding how timing affects physics prevents subtle bugs that ruin gameplay feel.

7

Expert

Advanced Timing: Syncing Update and FixedUpdate

🤔Before reading on: Can FixedUpdate run multiple times between two Update calls? Commit to your answer.

Concept: FixedUpdate can run zero, one, or multiple times between Update calls depending on frame rate; syncing them is important for smooth gameplay.

When frame rate is low, FixedUpdate may run multiple times before Update runs again. When frame rate is high, Update may run multiple times without FixedUpdate. This mismatch can cause issues like input lag or physics jitter. Techniques like interpolation and buffering help sync physics and rendering smoothly.

Result

Your game maintains smooth visuals and responsive controls even with varying frame rates.

Knowing this timing relationship helps you write advanced code that bridges physics and rendering seamlessly.

Under the Hood

Unity's engine runs a main loop where it processes input, updates game logic, runs physics simulations, and renders frames. Update is called once per frame during the game logic phase. FixedUpdate is called during the physics simulation phase at fixed time intervals, independent of frame rendering. The physics engine steps forward in fixed increments to maintain stable simulations. Unity may call FixedUpdate multiple times or skip it between frames to keep physics in sync with real time.

Why designed this way?

This design separates variable frame-rate tasks from fixed-rate physics to avoid physics glitches caused by inconsistent timing. Early game engines ran everything per frame, causing unstable physics on slow or fast machines. Unity introduced FixedUpdate to guarantee consistent physics steps, improving reliability and player experience.

┌─────────────────────────────┐
│        Unity Main Loop       │
├─────────────┬───────────────┤
│             │               │
│   Input     │               │
│ Processing  │               │
│             │               │
├─────────────┼───────────────┤
│ Update()    │               │
│ (per frame) │               │
├─────────────┼───────────────┤
│             │ FixedUpdate() │
│             │ (fixed steps) │
├─────────────┼───────────────┤
│             │ Physics Step  │
│             │ Simulation    │
├─────────────┴───────────────┤
│        Rendering Frame       │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does FixedUpdate run exactly once every frame? Commit to yes or no.

Common Belief: FixedUpdate runs once every frame just like Update.

Reality: FixedUpdate runs at fixed time intervals independent of frame rate, so it may run multiple times or not at all between frames.

Why it matters: Assuming FixedUpdate runs once per frame can cause timing bugs, like physics running too fast or too slow relative to rendering.

Quick: Should you read player input inside FixedUpdate? Commit to yes or no.

Common Belief: Player input should be read inside FixedUpdate for consistency.

Reality: Input should be read in Update because it matches frame rendering and is more responsive.

Why it matters: Reading input in FixedUpdate can cause delayed or missed input, making controls feel unresponsive.

Quick: Does putting physics code in Update always work fine? Commit to yes or no.

Common Belief: You can put physics code in Update without problems.

Reality: Physics code in Update can cause unstable simulations due to variable frame timing.

Why it matters: This leads to jittery or unrealistic physics behavior, harming gameplay quality.

Quick: Is FixedUpdate timing affected by frame rate? Commit to yes or no.

Common Belief: FixedUpdate timing changes if frame rate changes.

Reality: FixedUpdate timing is constant and independent of frame rate.

Why it matters: Misunderstanding this causes confusion about why physics behaves differently on different machines.

Expert Zone

1

FixedUpdate can be called multiple times per frame or skipped depending on frame rate and physics timestep settings, which affects how you sync animations and physics.

2

Changing the fixed timestep value affects physics accuracy and performance; smaller values increase precision but cost more CPU.

3

Using interpolation between FixedUpdate and Update can smooth out visual jitter caused by timing differences.

When NOT to use

Avoid using FixedUpdate for non-physics logic like UI updates or input handling; use Update instead. For very precise timing or asynchronous tasks, consider Coroutines or async methods. When physics is not involved, FixedUpdate adds unnecessary overhead.

Production Patterns

In real games, physics forces and Rigidbody movements are applied in FixedUpdate, while input and animations run in Update. Developers often use interpolation to smooth visuals between physics steps. Some optimize by adjusting fixed timestep dynamically or decoupling physics from rendering for better performance.

Connections

Game Loop

FixedUpdate and Update are specific phases within the broader game loop pattern.

Understanding the game loop helps grasp why Unity separates physics and rendering updates for smooth gameplay.

Real-Time Systems

FixedUpdate resembles fixed-interval task scheduling in real-time systems to guarantee timing predictability.

Knowing real-time scheduling principles clarifies why fixed timing is crucial for stable physics simulations.

Signal Processing

The difference between variable Update and fixed FixedUpdate is like sampling signals at irregular vs regular intervals.

This connection helps understand how irregular sampling (Update) can cause jitter, while regular sampling (FixedUpdate) ensures stable data processing.

Common Pitfalls

#1 Reading player input inside FixedUpdate causing delayed response.

Wrong approach:

void FixedUpdate() {
if (Input.GetKeyDown(KeyCode.Space)) {
Jump();
}
}

Correct approach:

void Update() {
if (Input.GetKeyDown(KeyCode.Space)) {
Jump();
}
}

Root cause:

Misunderstanding that input should be checked every frame for responsiveness, not at fixed physics intervals.

#2 Applying physics forces inside Update causing unstable physics.

Wrong approach:

void Update() {
rb.AddForce(Vector3.forward * force);
}

Correct approach:

void FixedUpdate() {
rb.AddForce(Vector3.forward * force);
}

Root cause:

Not realizing physics calculations need fixed time steps to remain stable.

#3 Assuming FixedUpdate runs once per frame leading to timing bugs.

Wrong approach:

// Treating FixedUpdate as frame-based update
void FixedUpdate() {
frameCount++;
if (frameCount % 2 == 0) {
DoSomething();
}
}

Correct approach:

// Use Update for frame-based logic
void Update() {
frameCount++;
if (frameCount % 2 == 0) {
DoSomething();
}
}

Root cause:

Confusing FixedUpdate's fixed interval calls with frame-based Update calls.

Key Takeaways

Update runs once every frame and is best for input and animations because it matches rendering timing.

FixedUpdate runs at fixed intervals independent of frame rate, making it ideal for physics calculations.

Mixing physics code in Update causes unstable behavior due to variable frame timing.

Input should always be read in Update to keep controls responsive.

Understanding the timing difference between Update and FixedUpdate is essential for smooth, predictable gameplay.

Practice

1. What is the main difference between Update and FixedUpdate in Unity?

easy

A. Both run at the same time but handle different components.

B. Update runs every frame; FixedUpdate runs at fixed time intervals.

C. FixedUpdate runs every frame; Update runs at fixed time intervals.

D. Update is only for physics; FixedUpdate is for animations.

Solution

1. Step 1: Understand the timing of Update

   Update is called once per frame, so its timing depends on the frame rate.

2. Step 2: Understand the timing of FixedUpdate

   FixedUpdate is called at fixed intervals, independent of frame rate, ideal for physics calculations.

3. Final Answer:

   Update runs every frame; FixedUpdate runs at fixed time intervals. -> Option B

4. Quick Check:

   Update = frame-based, FixedUpdate = fixed interval [OK]

Hint: Remember: Update = frame, FixedUpdate = fixed time [OK]

Common Mistakes:

• Confusing which method runs at fixed intervals
• Thinking FixedUpdate depends on frame rate
• Assuming Update is for physics only

2. Which of the following is the correct syntax to declare the FixedUpdate method in a Unity C# script?

easy

A. void FixedUpdate() { /* code here */ }

B. void fixedUpdate() { /* code here */ }

C. void Fixedupdate() { /* code here */ }

D. void Fixed_Update() { /* code here */ }

Solution

1. Step 1: Check method name capitalization

   Unity requires exact method names with correct capitalization; FixedUpdate starts with capital F and U.

2. Step 2: Verify method signature

   The method must be declared as void FixedUpdate() with no parameters.

3. Final Answer:

   void FixedUpdate() { /* code here */ } -> Option A

4. Quick Check:

   Correct capitalization and signature = void FixedUpdate() { /* code here */ } [OK]

Hint: Method names are case-sensitive; use exact spelling [OK]

Common Mistakes:

• Using wrong capitalization like fixedUpdate
• Adding underscores in method names
• Adding parameters to FixedUpdate

3. Consider this Unity C# script snippet:

void Update() {
    Debug.Log("Update called");
}

void FixedUpdate() {
    Debug.Log("FixedUpdate called");
}

If the game runs at 60 frames per second and the fixed timestep is 0.02 seconds, which output will appear more frequently in the console?

medium

A. Both will appear the same number of times.

B. "FixedUpdate called" will appear more frequently.

C. "Update called" will appear more frequently.

D. Neither will appear because Debug.Log is disabled.

Solution

1. Step 1: Calculate Update calls per second

   At 60 FPS, Update runs 60 times per second.

2. Step 2: Calculate FixedUpdate calls per second

   Fixed timestep is 0.02 seconds, so FixedUpdate runs 1/0.02 = 50 times per second.

3. Final Answer:

   "Update called" will appear more frequently. -> Option C

4. Quick Check:

   60 (Update) > 50 (FixedUpdate) calls per second [OK]

Hint: Update frequency = FPS; FixedUpdate frequency = 1/fixedDeltaTime [OK]

Common Mistakes:

• Assuming FixedUpdate runs more often than Update
• Ignoring fixed timestep value
• Confusing frame rate with fixed update rate

4. You wrote this code to move a Rigidbody smoothly:

void Update() {
    rb.AddForce(Vector3.forward * forceAmount);
}

But the movement is jittery. What is the best fix?

medium

A. Move the AddForce call into FixedUpdate.

B. Increase forceAmount in Update.

C. Call rb.MovePosition inside Update instead.

D. Disable physics in Rigidbody.

Solution

1. Step 1: Identify physics update timing

   Physics updates happen in fixed time steps, so applying forces in Update causes inconsistent timing and jitter.

2. Step 2: Move physics code to FixedUpdate

   Calling AddForce inside FixedUpdate matches physics timing and smooths movement.

3. Final Answer:

   Move the AddForce call into FixedUpdate. -> Option A

4. Quick Check:

   Physics code belongs in FixedUpdate [OK]

Hint: Put physics code in FixedUpdate to avoid jitter [OK]

Common Mistakes:

• Applying physics forces in Update
• Trying to fix jitter by increasing force
• Disabling physics instead of fixing timing

5. You want to create a smooth player movement that responds to input and uses physics. Which is the best way to organize your code?

hard

A. Apply forces in Update, ignore input.

B. Read input and apply forces both in Update.

C. Read input and apply forces both in FixedUpdate.

D. Read input in Update, apply movement forces in FixedUpdate.

Solution

1. Step 1: Understand input timing

   Input should be read every frame in Update to avoid missing user actions.

2. Step 2: Understand physics timing

   Physics forces should be applied in FixedUpdate for consistent physics simulation.

3. Step 3: Combine input and physics correctly

   Store input values in Update, then use them in FixedUpdate to apply forces smoothly.

4. Final Answer:

   Read input in Update, apply movement forces in FixedUpdate. -> Option D

5. Quick Check:

   Input in Update + physics in FixedUpdate = smooth movement [OK]

Hint: Input in Update, physics in FixedUpdate for smooth control [OK]

Common Mistakes:

• Reading input in FixedUpdate causing missed inputs
• Applying physics in Update causing jitter
• Ignoring input or physics timing differences