Unity Update FixedUpdate LateUpdate: The Complete Guide to Timing Your Game Logic

Here's the thing about Unity Update FixedUpdate LateUpdate—when I first started with Unity at CMU, I spent half a day debugging why my player controller felt "floaty" at different frame rates. Turned out, I was mixing up where to put my physics code versus my input handling. This one tripped me up because Unity's game loop isn't as straightforward as it seems at first glance. If you've ever had a character controller that works perfectly on your machine but behaves weirdly on your friend's laptop, or a camera that jitters when following your player, you're dealing with the exact same timing issues I struggled with. Let me show you how I cracked this—and how understanding these three methods will transform your game development workflow.

Why Your Game Needs Different "Heartbeats"

The core problem that Update, FixedUpdate, and LateUpdate solve is the need for timed and ordered execution of game logic within Unity's game loop. These methods provide distinct "heartbeats" for your game, allowing you to create responsive player controls, predictable physics simulations, and reliable camera movements that all work in harmony.

Think of it like a film director coordinating different departments: Update is like the director giving continuous instructions to the actors for their performance, FixedUpdate is the special effects team running their simulations at a consistent rate for realistic explosions, and LateUpdate is the camera crew making final adjustments to frame the shot perfectly after the actors have moved.

Mastering the use of these methods is fundamental to controlling the flow and behavior of every interactive element in your game.

The Five Foundation Terms You Actually Need to Know

Before we get into the code, let me break down the terminology you'll need. These aren't just textbook definitions—these are the concepts that clicked for me when I finally understood Unity execution order.

Game Loop: This is the central, continuous cycle that runs your game. Unity processes input, updates game logic, simulates physics, renders graphics, and repeats this cycle every frame. Think of it as the engine that keeps everything moving.

Frame Rate (FPS - Frames Per Second): This refers to the number of times per second your game renders a new image to the screen. A high frame rate results in smooth visuals, but it can fluctuate depending on the complexity of the scene and the hardware's performance. Your laptop might run at 60 FPS while your friend's runs at 144 FPS—and that's exactly why we need frame-rate independent code.

Time.deltaTime: This crucial value represents the time in seconds it took to complete the last frame. It is essential for making game logic frame-rate independent, ensuring that movement and other time-based actions behave consistently regardless of FPS fluctuations. This was my game-changer when I learned to use it properly.

Fixed Timestep: This is a consistent, configurable time interval at which Unity's physics engine updates. Unlike the frame rate, the fixed timestep is stable and predictable, making it ideal for physics calculations. By default, it's set to 0.02 seconds (50 times per second).

Execution Order: This is the predefined sequence in which Unity calls its various event functions like Awake, Start, FixedUpdate, Update, and LateUpdate. Understanding this order is critical for preventing bugs and ensuring your game logic runs as intended.

Breaking Down Update, FixedUpdate, and LateUpdate

Let me walk you through each method with the exact approach I use when teaching students at Outscal.

Update(): Your Every-Frame Workhorse

Update is the most common place for game logic. It is called once per frame, making it ideal for things that need to be checked or adjusted continuously, like player input or non-physics-based movement. Its frequency is tied directly to the frame rate, so it can be called many times per second.

Here's how I always check for player input:

// C#
using UnityEngine;

public class PlayerInput : MonoBehaviour
{
    void Update()
    {
        // Check for the jump button press every single frame
        if (Input.GetButtonDown("Jump"))
        {
            Debug.Log("Jump button was pressed!");
        }
    }
}

Verified: Unity Docs - MonoBehaviour.Update

FixedUpdate(): Where Physics Lives

FixedUpdate is called at a consistent, fixed interval, independent of the frame rate. This makes it the correct place for all physics-related calculations, such as applying forces to a Rigidbody, to ensure simulations are stable and predictable across different hardware.

In my projects, I always start by implementing physics movement in FixedUpdate. Here's my go-to setup for 3D movement:

// C# (3D Version)
using UnityEngine;

public class PlayerMovement3D : MonoBehaviour
{
    public Rigidbody rb;
    public float moveSpeed = 5f;

    void FixedUpdate()
    {
        // Apply a consistent force for physics-based movement
        rb.AddForce(Vector3.right * moveSpeed);
    }
}

And for 2D games, I use this variation:

// C# (2D Version)
using UnityEngine;

public class PlayerMovement2D : MonoBehaviour
{
    public Rigidbody2D rb2D;
    public float moveSpeed = 5f;

    void FixedUpdate()
    {
        // Apply a consistent force for 2D physics-based movement
        rb2D.AddForce(Vector2.right * moveSpeed);
    }
}

Verified: Unity Docs - MonoBehaviour.FixedUpdate

LateUpdate(): The Finishing Touch

LateUpdate is called once per frame, but only after all Update methods have been executed. This makes it perfect for logic that needs to happen after other game elements have completed their movement or state changes, such as a camera following a player.

After working on multiple Unity projects, I learned this is the only reliable way to prevent camera jitter:

// C#
using UnityEngine;

public class CameraFollow : MonoBehaviour
{
    public Transform playerTransform;
    private Vector3 offset;

    void Start()
    {
        offset = transform.position - playerTransform.position;
    }

    void LateUpdate()
    {
        // Update the camera's position after the player has moved in Update()
        transform.position = playerTransform.position + offset;
    }
}

Verified: Unity Docs - MonoBehaviour.LateUpdate

The Quick-Reference Table I Wish I Had as a Beginner

I've configured this dozens of times, and here's my tried-and-tested comparison that I always keep handy:

What Happens When You Get This Right

Let me tell you what changes when you nail Unity execution order:

• Predictable Physics: Using FixedUpdate for physics ensures your game's simulation is stable and deterministic, preventing issues where objects might behave differently at varying frame rates. From my time working with Unity Rigidbody physics, I've seen how critical this is for competitive games.
• Responsive Controls: Placing input checks in Update guarantees the game captures player actions with the lowest possible latency, as it checks every single frame. This is why I always tell my students to look at how responsive controls feel in polished games.
• Smooth Camera Motion: By placing camera logic in LateUpdate, you eliminate visual jitter that can occur if the camera moves before its target has finished its movement for the frame. Trust me, you'll thank me later for this tip—camera bugs are incredibly frustrating to debug.
• Clear Code Organization: Separating logic into the correct methods makes your code cleaner, more readable, and easier to debug, as you instinctively know where to find physics, input, or camera code. After analyzing dozens of Unity projects, this organizational clarity stands out as a mark of professional code.

The Pro Tips That Saved My Projects

Here are the lessons I learned the hard way so you don't have to:

Always Multiply by Time.deltaTime in Update

To ensure movement is smooth and consistent regardless of frame rate, always multiply your movement values by Time.deltaTime. This one had me stuck for a bit until a mentor at CMU showed me the difference:

// C#
void Update()
{
    // GOOD: Movement is scaled by the time of the frame
    transform.position += new Vector3(5, 0, 0) * Time.deltaTime;
}

Never Poll Input in FixedUpdate

Input events can be missed if they occur between FixedUpdate calls. Poll for input in Update and store it in a variable to be used in FixedUpdate. I ran into this issue early on, and here's how I solved it:

// C#
private bool jumpRequested = false;

void Update()
{
    if (Input.GetButtonDown("Jump"))
    {
        jumpRequested = true;
    }
}

void FixedUpdate()
{
    if (jumpRequested)
    {
        // Use the cached input for a physics action
        GetComponent<Rigidbody>().AddForce(Vector3.up * 10, ForceMode.Impulse);
        jumpRequested = false; // Reset the flag
    }
}

Keep Heavy Calculations Out of Update Methods

Heavy calculations in Update or FixedUpdate can slow down your game. Use Coroutines or other techniques to spread complex logic over multiple frames if necessary. What I find fascinating about this approach is how it maintains smooth frame rates even during intensive operations.

Verified: Unity Learn - Execution Order of Event Functions

How the Best Games Use These Methods

Let me share some examples that I always recommend my students study:

Super Mario Odyssey: The Perfect Jump

The Mechanic: Mario's precise and responsive jump.

The Implementation: I've seen this technique used brilliantly in platformers—the game likely checks for the jump button press in Update() to ensure the input is captured immediately. The actual application of the jump force to Mario's Rigidbody would then happen in FixedUpdate() for a consistent and predictable jump arc.

The Player Experience: The player feels that Mario jumps the instant they press the button, providing a tight and satisfying control feel.

Rocket League: Physics That Feels Fair

The Mechanic: The physics-based movement of the ball and cars.

The Implementation: One of my favorite implementations of physics timing—all forces applied to the cars (boosting, flipping) and the ball are certainly handled in FixedUpdate(). This ensures that the complex physics interactions are stable and behave the same for all players, which is critical for a competitive multiplayer game.

The Player Experience: The physics feels consistent and fair. Players can learn to predict how the ball will react, allowing for high-skill maneuvers and competitive play.

The Legend of Zelda: Breath of the Wild: Cinematic Camera Work

The Mechanic: The camera system that smoothly follows Link while avoiding being obscured by terrain.

The Implementation: After analyzing how smooth camera follow works in AAA games, I realized the camera's logic to follow Link and adjust its position based on his movement and the surrounding environment would be placed in LateUpdate(). This ensures the camera makes its final positioning adjustments only after Link has completed all his actions for that frame.

The Player Experience: The camera feels cinematic and intelligent, smoothly tracking the action without stuttering or getting stuck on walls, providing an uninterrupted view of the game world.

Let's Build: Frame-Rate Independent Player Movement

Let me show you how I approach building a Unity player controller tutorial that works across all frame rates.

What We're Creating

Create a simple character controller that moves smoothly and consistently, whether the game is running at 30 FPS or 120 FPS. This is foundational for any game project.

Setting Up Your Scene

Here's the exact method I use when starting a new movement system:

• Create a 3D Cube GameObject and name it "Player".
• Add a Rigidbody component to the "Player". Set its Drag to 2 and Angular Drag to 2 to prevent it from sliding indefinitely.
• Create a new C# Script named "PlayerController" and attach it to the "Player".

Step 1: Declare Your Variables

We need variables to hold a reference to our Rigidbody and to define our movement speed.

// C#
using UnityEngine;

public class PlayerController : MonoBehaviour
{
    public float moveSpeed = 10f;
    private Rigidbody rb;
    private Vector3 moveInput;
}

Step 2: Capture Input in Update

We will capture the player's horizontal and vertical input every frame in Update. This ensures maximum responsiveness. We store this in our moveInput vector.

// C#
void Update()
{
    // Gather input in Update to avoid missing presses
    float horizontalInput = Input.GetAxis("Horizontal");
    float verticalInput = Input.GetAxis("Vertical");
    moveInput = new Vector3(horizontalInput, 0, verticalInput);
}

Step 3: Apply Physics in FixedUpdate

Now, we apply the captured input as a physical force in FixedUpdate. This keeps the movement physically accurate and stable—these are the exact settings I use:

// C#
void Start()
{
    rb = GetComponent<Rigidbody>(); // Get the component reference
}

void FixedUpdate()
{
    // Apply the movement force in FixedUpdate for physics consistency
    rb.AddForce(moveInput * moveSpeed);
}

Verified: Unity Docs - Rigidbody.AddForce

Let's Build: A Unity Smooth Camera Follow Script

Here's how you can adapt this technique for your own game's camera system.

What We're Creating

Implement a camera that smoothly follows the player from behind and slightly above, without any jittering. I spent a good chunk of time perfecting this in my early projects.

Setting Up Your Camera

When I'm working on camera systems, my process is:

• Use the "Player" GameObject from the previous blueprint.
• Ensure the Main Camera is a separate GameObject, not a child of the Player.
• Create a new C# Script named "SmoothCameraFollow" and attach it to the Main Camera.

Step 1: Define Camera Parameters

We need to know which Transform to follow (the player), how far away the camera should be (offset), and how smoothly it should move (smoothSpeed).

// C#
using UnityEngine;

public class SmoothCameraFollow : MonoBehaviour
{
    public Transform target; // The player's transform
    public float smoothSpeed = 0.125f;
    public Vector3 offset; // The desired distance from the player
}

Step 2: Calculate Where the Camera Should Be

In LateUpdate, we determine where the camera should be by taking the target's current position and adding the offset.

// C#
void LateUpdate()
{
    if (target == null) return;

    // Calculate the desired position after the player has moved
    Vector3 desiredPosition = target.position + offset;
}

Step 3: Smooth the Movement

Instead of instantly teleporting the camera, we use Vector3.Lerp to smoothly move it from its current position to the desired position over time. This creates a fluid, cinematic follow effect.

// C#
void LateUpdate()
{
    if (target == null) return;

    Vector3 desiredPosition = target.position + offset;
    // Use Lerp to smoothly interpolate to the target position
    Vector3 smoothedPosition = Vector3.Lerp(transform.position, desiredPosition, smoothSpeed);
    transform.position = smoothedPosition;

    transform.LookAt(target); // Optional: make the camera always look at the player
}

Verified: Unity Docs - Vector3.Lerp

Let's Build: A Cooldown System That Works

Let's tackle this together—cooldown timers are essential for ability systems.

What We're Creating

Create a timer that prevents the player from spamming an action, like shooting or dashing, by enforcing a cooldown period. This pattern shows up in almost every game I've worked on.

Setting Up the Manager

• Create an empty GameObject named "AbilityManager".
• Create a new C# Script named "CooldownAbility" and attach it to the "AbilityManager".

Step 1: Set Up Your Timer Variables

We need a cooldownTime to define how long the cooldown lasts and a nextFireTime to track when the ability can be used again.

// C#
using UnityEngine;

public class CooldownAbility : MonoBehaviour
{
    public float cooldownTime = 2f; // 2-second cooldown
    private float nextFireTime = 0f;
}

Step 2: Check Input and Current Time

In Update, we check for two conditions: if the player is pressing the "Fire1" button AND if the current game time is greater than our nextFireTime.

// C#
void Update()
{
    // Check for input and if the current time has passed the cooldown time
    if (Input.GetButtonDown("Fire1") && Time.time >= nextFireTime)
    {
        // The ability can be used
        Debug.Log("Ability Used!");
    }
}

Step 3: Start the Cooldown

If both conditions are met, we "use" the ability and then update nextFireTime to be the current time plus our cooldown duration. This effectively starts the cooldown timer.

// C#
void Update()
{
    if (Input.GetButtonDown("Fire1") && Time.time >= nextFireTime)
    {
        // Set the next allowed fire time
        nextFireTime = Time.time + cooldownTime;
        Debug.Log("Ability Used! Cooldown started.");
    }
}

Verified: Unity Docs - Time.time

What This Unlocks for Your Game Projects

When you master Unity Update FixedUpdate LateUpdate, you're not just learning timing methods—you're gaining control over how your entire game feels. Frame-rate independent movement means your game runs smoothly whether someone's playing on a budget laptop or a high-end gaming rig. Proper Unity physics timing ensures your mechanics work exactly the same way for every player, which is crucial if you're building multiplayer games or competitive experiences.

The Unity game loop becomes your canvas instead of your constraint. You'll know exactly where to put your input handling for instant responsiveness, where to calculate your physics for stability, and where to position your camera for that polished, professional look. These aren't just best practices—they're the difference between a game that feels amateur and one that feels tight and professional.

Ready to Start Building Your First Game?

Now that you understand the fundamentals of Unity's timing system, it's time to apply this knowledge to real game development. The concepts we've covered—from Unity execution order to Unity camera follow scripts—are just the beginning of what you'll need to create professional-quality games.

At Outscal, we've designed a comprehensive path that takes you from these core Unity concepts all the way to building complete, portfolio-ready games. Our Unity Game Development Course builds on exactly these fundamentals, showing you how to implement advanced player controllers, sophisticated camera systems, and complex game mechanics using the proper timing methods.

You'll work with industry mentors who've shipped real games, get hands-on with multiple game projects, and learn the workflows used by professional Unity developers. If you're serious about turning your game ideas into reality, this is your next step.

Key Takeaways

• Use Update() for input and frame-dependent logic - It runs every frame, making it perfect for checking player input and handling non-physics movement with Time.deltaTime.
• Use FixedUpdate() for all physics calculations - Its consistent timing ensures stable Rigidbody physics and predictable simulations across different frame rates.
• Use LateUpdate() for camera and follow logic - It runs after all Updates, eliminating jitter when tracking moving objects.
• Always multiply movement by Time.deltaTime in Update - This makes your game frame-rate independent, ensuring consistent behavior across different hardware.
• Never read input in FixedUpdate - Capture input in Update() and cache it as a variable to use in FixedUpdate() to avoid missing button presses.
• Understand the Unity execution order - Knowing when each method runs prevents bugs and helps you organize your code logically.
• Keep expensive calculations out of Update loops - Use Coroutines or spread heavy logic across frames to maintain smooth performance.
• Unity's fixed timestep is independent of frame rate - This makes FixedUpdate ideal for physics while Update handles variable-rate rendering.