FixedUpdate vs Update in Unity - Visual Side-by-Side Comparison

Concept Flow - FixedUpdate vs Update

Game Loop Start

↓

Update Called Every Frame

↓

Process Input, Animations

↓

FixedUpdate Called at Fixed Intervals

↓

Physics Calculations

↓

Render Frame

↓

Loop Back to Start

The game loop calls Update every frame for general tasks, and FixedUpdate at fixed time steps for physics updates.

Execution Sample

Unity

void Update() {
    MovePlayer();
}

void FixedUpdate() {
    ApplyPhysics();
}

Update moves the player every frame; FixedUpdate applies physics at fixed intervals.

Execution Table

Step	Time (seconds)	Method Called	Action	Notes
1	0.00	Update	MovePlayer called	First frame update
2	0.02	FixedUpdate	ApplyPhysics called	Physics step 1
3	0.03	Update	MovePlayer called	Second frame update
4	0.04	FixedUpdate	ApplyPhysics called	Physics step 2
5	0.06	FixedUpdate	ApplyPhysics called	Physics step 3 (FixedUpdate called twice due to frame delay)
6	0.06	FixedUpdate	ApplyPhysics called	Physics step 4 (FixedUpdate called twice due to frame delay)
7	0.06	Update	MovePlayer called	Third frame update
8	0.08	FixedUpdate	ApplyPhysics called	Physics step 5
9	0.09	Update	MovePlayer called	Fourth frame update
10	0.10	FixedUpdate	ApplyPhysics called	Physics step 6
11	0.12	Update	MovePlayer called	Fifth frame update
12	0.12	FixedUpdate	ApplyPhysics called	Physics step 7
Exit	End	Stop	Game loop continues	Execution trace ends here

💡 Game loop continues indefinitely; FixedUpdate runs at fixed intervals, Update runs every frame.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	After Step 8	After Step 9	After Step 10	After Step 11	Final
frameCount	0	1	1	2	2	2	2	3	3	4	4	5	5
fixedUpdateCount	0	0	1	1	2	3	4	4	5	5	6	7	7

Key Moments - 3 Insights

Why does FixedUpdate sometimes run multiple times between two Update calls?

Because FixedUpdate runs at fixed time intervals independent of frame rate, if frames are slow, FixedUpdate can run multiple times to catch up, as shown in step 5 and 6 where FixedUpdate runs twice before the next Update.

Can physics calculations be done inside Update instead of FixedUpdate?

No, physics should be done in FixedUpdate because it runs at consistent intervals, ensuring stable and predictable physics behavior, unlike Update which varies with frame rate.

Why is Update called more frequently than FixedUpdate in some cases?

Update is called every frame, which can vary in time, while FixedUpdate is called at fixed intervals, so if frame rate is high, Update runs more often than FixedUpdate.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of fixedUpdateCount after step 5?

A 3

B 4

C 2

D 5

💡 Hint

Check the fixedUpdateCount value in the variable_tracker after step 5.

At which step does FixedUpdate run twice before the next Update?

A Step 4

B Step 5

C Step 6

D Step 7

💡 Hint

Look at the execution_table rows where FixedUpdate is called twice with the same time.

If the frame rate drops, how does FixedUpdate behave compared to Update?

A FixedUpdate runs less often than Update

B Both run at the same frequency

C FixedUpdate runs more often than Update to catch up

D FixedUpdate stops running

💡 Hint

Refer to the explanation in key_moments about FixedUpdate running multiple times when frames are slow.

Concept Snapshot

Update runs every frame and handles input and animations.
FixedUpdate runs at fixed time intervals for physics.
FixedUpdate can run multiple times per frame if frame rate is low.
Use Update for frame-dependent tasks.
Use FixedUpdate for physics and consistent timing.

Full Transcript

In Unity, the game loop calls Update every frame to handle tasks like input and animations. FixedUpdate runs at fixed time intervals to handle physics calculations. This means FixedUpdate can run multiple times between two Update calls if the frame rate is slow, ensuring physics stays stable. Update frequency depends on frame rate and can vary. Physics should always be done in FixedUpdate for consistent behavior. The execution table shows Update and FixedUpdate calls over time, with variable tracking for frameCount and fixedUpdateCount. Key moments clarify why FixedUpdate runs multiple times sometimes and why physics belongs there. The visual quiz tests understanding of these timings and counts.

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