Start and Update methods in Unity - Deep Dive

Overview - Start and Update methods

What is it?

In Unity, Start and Update are special methods used in scripts attached to game objects. Start runs once when the game begins or when the object is created. Update runs repeatedly every frame, allowing the game to respond to changes over time. These methods help control how objects behave and change during the game.

Why it matters

Without Start and Update, games would be static and unresponsive. Start sets up initial conditions, like placing a character or setting health. Update lets the game react continuously, like moving a player or checking for input. Without them, games would lack life and interaction.

Where it fits

Before learning Start and Update, you should understand basic C# scripting and Unity’s component system. After mastering these methods, you can learn about other event methods like FixedUpdate for physics or coroutines for timed actions.

Mental Model

Core Idea

Start sets up your game object once at the beginning, and Update keeps it alive and changing every frame.

Think of it like...

Think of Start as turning on a machine and setting it up, and Update as the machine running continuously, doing its job step by step.

┌─────────────┐
│   Game Run  │
└──────┬──────┘
       │
       ▼
┌─────────────┐       ┌─────────────┐
│    Start    │──────▶│   Update    │
│ (runs once) │       │(runs every  │
│             │       │   frame)    │
└─────────────┘       └─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Start Method Basics

Concept: Start is a method that runs once when the game object becomes active.

In Unity, when you attach a script to a game object, the Start method runs automatically once before the first frame. Use it to set initial values or prepare the object. For example, setting a player's health or position. Example: void Start() { health = 100; transform.position = new Vector3(0, 0, 0); }

Result

The game object is ready with initial settings before the game begins updating frames.

Knowing Start runs once helps you separate setup code from ongoing behavior, avoiding repeated initialization.

2

Foundation

Understanding Update Method Basics

Concept: Update runs every frame to handle ongoing changes and interactions.

Update is called once per frame, which means it runs many times per second depending on the frame rate. Use it to check for input, move objects, or update animations. Example: void Update() { transform.Translate(Vector3.forward * speed * Time.deltaTime); }

Result

The game object moves forward smoothly every frame, creating animation or interaction.

Recognizing Update runs continuously helps you write code that responds to time and player actions fluidly.

3

Intermediate

Timing Differences Between Start and Update

🤔Before reading on: Do you think Start runs before or after the first Update call? Commit to your answer.

Concept: Start runs once before the first Update call, ensuring setup happens before ongoing updates.

Unity calls Start once before the first Update. This means any initialization in Start is guaranteed to happen before Update tries to use those values. Example: void Start() { speed = 5; } void Update() { transform.Translate(Vector3.forward * speed * Time.deltaTime); }

Result

The object moves forward using the speed set in Start, avoiding errors from uninitialized variables.

Understanding this order prevents bugs where Update tries to use data that isn’t ready yet.

4

Intermediate

Using Time.deltaTime in Update

🤔Before reading on: Should you multiply movement by Time.deltaTime in Update? Yes or no? Commit to your answer.

Concept: Time.deltaTime represents the time between frames, making movement smooth and frame-rate independent.

Without Time.deltaTime, movement speed depends on frame rate, causing inconsistent behavior on different devices. Example: void Update() { transform.Translate(Vector3.forward * speed * Time.deltaTime); } This ensures the object moves the same distance per second regardless of frame rate.

Result

Movement appears smooth and consistent on all devices, avoiding jerky or too fast/slow motion.

Knowing to use Time.deltaTime in Update is key to writing reliable, smooth animations and movements.

5

Intermediate

When Start Does Not Run

🤔Before reading on: Do you think Start runs if the script or object is disabled at game start? Commit to your answer.

Concept: Start only runs when the script and game object are enabled and active for the first time.

If a game object or script is disabled at the start, Start will not run until it becomes enabled. This can cause unexpected behavior if you assume Start always runs at game launch. Example: // Disabled object // Start will run only when enabled later void OnEnable() { // Can be used to initialize when enabled }

Result

Start delays running until activation, so initialization timing depends on object state.

Understanding this helps avoid bugs where initialization code is skipped or delayed unexpectedly.

6

Advanced

Performance Considerations in Update

🤔Before reading on: Is it okay to put heavy calculations inside Update? Yes or no? Commit to your answer.

Concept: Update runs every frame, so heavy or unnecessary work inside it can slow down the game.

Because Update runs many times per second, expensive operations here can cause frame drops. Use Update only for essential per-frame tasks. Move heavy calculations to Start, coroutines, or events. Example: // Bad void Update() { for(int i=0; i<10000; i++) { /* heavy work */ } } // Better void Start() { // heavy setup } void Update() { // light per-frame work }

Result

Game runs smoothly without lag caused by unnecessary work in Update.

Knowing Update’s cost helps you write efficient code that keeps games responsive.

7

Expert

Hidden Order and Execution Nuances

🤔Before reading on: Do you think multiple scripts’ Start and Update methods run in a fixed order? Commit to your answer.

Concept: Unity does not guarantee the order of Start or Update calls across different scripts, which can cause subtle bugs.

Start and Update run per script, but Unity does not define which script runs first. This means if one script depends on another’s Start or Update, you must manage execution order explicitly using Script Execution Order settings or design patterns. Example: // Script A and Script B both have Start // Their Start order is not guaranteed // Use Script Execution Order in Project Settings to fix

Result

Avoids bugs where one script tries to use data from another before it’s ready.

Understanding this subtlety prevents hard-to-find bugs in complex projects with many scripts.

Under the Hood

Unity’s engine calls Start once when the game object becomes active and enabled. Internally, it queues all Start calls before the first frame update. Update is called every frame by the engine’s main loop, iterating over all active scripts. The engine manages these calls efficiently to keep the game running smoothly.

Why designed this way?

This design separates initialization from ongoing behavior, making scripts easier to organize and reason about. It also aligns with game loop architecture, where setup happens once and updates happen continuously. Alternatives like running initialization inside Update would cause repeated setup and inefficiency.

┌───────────────┐
│ Game Engine   │
│ Main Loop     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Call all Start│
│ (once per obj)│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Each Frame:   │
│ Call all      │
│ Update methods│
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Start run every time the game object is enabled? Commit to yes or no.

Common Belief: Start runs every time the game object is enabled.

Reality: Start runs only once in the lifetime of the script instance, even if the object is disabled and enabled multiple times.

Why it matters: Assuming Start runs multiple times can cause repeated initialization bugs or unexpected behavior.

Quick: Is Update called at a fixed time interval? Commit to yes or no.

Common Belief: Update runs at a fixed time interval, like every 0.02 seconds.

Reality: Update runs once per frame, but frame duration varies, so Update timing is not fixed.

Why it matters: Not accounting for variable frame time causes inconsistent movement or animations if Time.deltaTime is ignored.

Quick: Does disabling a script stop its Start method from running? Commit to yes or no.

Common Belief: Start runs regardless of whether the script is enabled or disabled at game start.

Reality: Start only runs if the script is enabled and the game object is active when the scene starts or when enabled later.

Why it matters: Misunderstanding this leads to missing initialization and bugs when scripts are disabled initially.

Quick: Do all scripts’ Start methods run in the order they appear in the project? Commit to yes or no.

Common Belief: Start methods run in a predictable order based on script file order.

Reality: Unity does not guarantee Start execution order across scripts unless explicitly set in project settings.

Why it matters: Assuming order can cause bugs where one script depends on another’s initialization.

Expert Zone

1

Start and Awake both run only once per script instance, even if you disable and re-enable the script or GameObject.

2

Update frequency depends on frame rate, so heavy Update code can cause frame drops; using FixedUpdate or coroutines can help manage timing.

3

Script Execution Order settings allow controlling Start and Update call order, critical in complex projects with interdependent scripts.

When NOT to use

Do not use Update for physics calculations; use FixedUpdate instead for consistent physics timing. Avoid heavy computations in Update; use coroutines or event-driven methods for better performance.

Production Patterns

In production, Start is used for setup like loading data or initializing variables. Update handles input, animations, and real-time changes. Developers often combine Update with coroutines for timed events and use Script Execution Order to manage dependencies.

Connections

Game Loop Architecture

Start and Update are specific implementations of the game loop pattern.

Understanding the game loop helps grasp why Start runs once and Update runs every frame, reflecting initialization and continuous update phases.

Event-Driven Programming

Start and Update act like events triggered by the engine at specific times.

Seeing these methods as events clarifies how Unity manages script behavior reactively rather than sequentially.

Factory Assembly Line

Start is like setting up a machine once, Update is the machine working continuously on products.

This connection to manufacturing processes highlights the importance of separating setup from ongoing work for efficiency and clarity.

Common Pitfalls

#1 Putting heavy calculations inside Update causing frame rate drops.

Wrong approach:

void Update() {
for(int i=0; i<100000; i++) {
// heavy work
}
}

Correct approach:

void Start() {
for(int i=0; i<100000; i++) {
// heavy work
}
}
void Update() {
// light per-frame work
}

Root cause:

Misunderstanding that Update runs every frame and should be kept lightweight.

#2 Assuming Start runs every time the object is enabled.

Wrong approach:

void Start() {
Debug.Log("Setup");
}
// Object disabled and enabled multiple times expecting multiple logs

Correct approach:

void OnEnable() {
Debug.Log("Setup on enable");
}
void Start() {
Debug.Log("Setup once");
}

Root cause:

Confusing Start with OnEnable lifecycle methods.

#3 Not using Time.deltaTime in Update causing inconsistent movement.

Wrong approach:

void Update() {
transform.Translate(Vector3.forward * speed);
}

Correct approach:

void Update() {
transform.Translate(Vector3.forward * speed * Time.deltaTime);
}

Root cause:

Ignoring variable frame duration and assuming fixed frame rate.

Key Takeaways

Start runs once when a game object becomes active, perfect for setup tasks.

Update runs every frame, ideal for continuous changes like movement or input handling.

Always use Time.deltaTime in Update to keep behavior smooth and consistent across devices.

Start and Update execution order across scripts is not guaranteed; manage dependencies carefully.

Keep Update lightweight to maintain good game performance and avoid frame drops.