In this lesson, you will learn why moving your physics-based movement logic into FixedUpdate is essential for creating predictable, consistent gameplay that doesn't break when your frame rate fluctuates.
Why Update() isn't enough for Physics
You are likely familiar with Update(), which runs once per rendered frame. Because your computer might render 60 frames per second one moment and 120 the next, Update() has a variable time step. If you apply a force to an object inside Update(), it will behave differently depending on how fast the game is running—causing objects to pass through walls or jump higher on faster machines.
The Power of FixedUpdate
Unity provides FixedUpdate() specifically for physics. Unlike Update(), FixedUpdate() runs on a fixed timer (by default, every 0.02 seconds). Because the time interval is constant, your physics calculations remain perfectly stable regardless of your frame rate.
When you want to move a character using Rigidbody forces, you should always handle that logic here:
void FixedUpdate()
{
// Apply a force to the Rigidbody at a consistent interval
rb.AddForce(movementVector * speed);
}
Keeping Logic Clean
Think of Update() as the place for "human-responsive" tasks, like checking for button presses or updating UI elements. Think of FixedUpdate() as the engine room where the physical rules of your game world are enforced. If you mix the two—for example, by performing input detection inside FixedUpdate—you might miss a player's button press because the input happened between the fixed time steps.
To keep your code optimized, capture your input in Update() by setting a variable, and then simply apply that variable to your physics movement inside FixedUpdate(). This ensures your game feels responsive to the player while remaining mathematically consistent for the physics engine.
Key Takeaway: Always calculate physics forces inside FixedUpdate to ensure consistent behavior regardless of the user's frame rate.