What if your game's physics felt glitchy just because your computer runs faster or slower?
FixedUpdate vs Update in Unity - When to Use Which
Imagine you are making a game where a ball moves and bounces. You try to update the ball's position and check for collisions manually every frame without thinking about timing.
Doing everything in one place every frame can cause the ball to jump or behave oddly because the frame rate changes. Sometimes the ball moves too fast or too slow, making the game feel unfair or glitchy.
Unity gives you two special methods: Update runs every frame for smooth animations, and FixedUpdate runs at fixed time steps for physics. Using them correctly keeps movement smooth and physics stable.
void Update() {
MoveBall();
CheckPhysics();
}void Update() {
MoveBallSmoothly();
}
void FixedUpdate() {
ApplyPhysics();
}You can create games where animations look smooth and physics behave realistically, no matter how fast or slow the computer runs your game.
In a racing game, the car's steering feels responsive and smooth (Update), while the car's speed and collisions stay accurate and fair (FixedUpdate), making the game fun and playable.
Update runs every frame for smooth visuals.
FixedUpdate runs at fixed intervals for stable physics.
Using both properly avoids glitches and improves game feel.
Practice
Update and FixedUpdate in Unity?Solution
Step 1: Understand the timing of
UpdateUpdateis called once per frame, so its timing depends on the frame rate.Step 2: Understand the timing of
FixedUpdateFixedUpdateis called at fixed intervals, independent of frame rate, ideal for physics calculations.Final Answer:
Updateruns every frame;FixedUpdateruns at fixed time intervals. -> Option BQuick Check:
Update = frame-based, FixedUpdate = fixed interval [OK]
- Confusing which method runs at fixed intervals
- Thinking FixedUpdate depends on frame rate
- Assuming Update is for physics only
FixedUpdate method in a Unity C# script?Solution
Step 1: Check method name capitalization
Unity requires exact method names with correct capitalization;FixedUpdatestarts with capital F and U.Step 2: Verify method signature
The method must be declared asvoid FixedUpdate()with no parameters.Final Answer:
void FixedUpdate() { /* code here */ } -> Option AQuick Check:
Correct capitalization and signature = void FixedUpdate() { /* code here */ } [OK]
- Using wrong capitalization like fixedUpdate
- Adding underscores in method names
- Adding parameters to FixedUpdate
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?Solution
Step 1: Calculate Update calls per second
At 60 FPS,Updateruns 60 times per second.Step 2: Calculate FixedUpdate calls per second
Fixed timestep is 0.02 seconds, soFixedUpdateruns 1/0.02 = 50 times per second.Final Answer:
"Update called" will appear more frequently. -> Option CQuick Check:
60 (Update) > 50 (FixedUpdate) calls per second [OK]
- Assuming FixedUpdate runs more often than Update
- Ignoring fixed timestep value
- Confusing frame rate with fixed update rate
void Update() {
rb.AddForce(Vector3.forward * forceAmount);
}
But the movement is jittery. What is the best fix?Solution
Step 1: Identify physics update timing
Physics updates happen in fixed time steps, so applying forces inUpdatecauses inconsistent timing and jitter.Step 2: Move physics code to
CallingFixedUpdateAddForceinsideFixedUpdatematches physics timing and smooths movement.Final Answer:
Move theAddForcecall intoFixedUpdate. -> Option AQuick Check:
Physics code belongs in FixedUpdate [OK]
- Applying physics forces in Update
- Trying to fix jitter by increasing force
- Disabling physics instead of fixing timing
Solution
Step 1: Understand input timing
Input should be read every frame inUpdateto avoid missing user actions.Step 2: Understand physics timing
Physics forces should be applied inFixedUpdatefor consistent physics simulation.Step 3: Combine input and physics correctly
Store input values inUpdate, then use them inFixedUpdateto apply forces smoothly.Final Answer:
Read input inUpdate, apply movement forces inFixedUpdate. -> Option DQuick Check:
Input in Update + physics in FixedUpdate = smooth movement [OK]
- Reading input in FixedUpdate causing missed inputs
- Applying physics in Update causing jitter
- Ignoring input or physics timing differences
Ready to prove it?
Pass the test and this pattern moves unknown
