📝 Lesson 1.1: MonoBehaviour and the Component Model

From Plain Classes to Components

In the "Introduction to C#" course you built classes that you controlled from top to bottom: you called new, you invoked methods, you decided exactly when everything ran. A console app has one entry point — Main — and you drive it.

Unity flips that around. There is no Main that you write. Instead, the Unity engine runs the loop, and your code is invited in as the engine ticks along. The way you plug your C# into that engine loop is by writing a component and attaching it to an object in the scene.

This is the single most important mental shift for a C# programmer arriving in Unity: you rarely build one big class that "is" the player. Instead you assemble a Player GameObject out of many small components — one for movement, one for health, one for the camera — and Unity runs them all. Let's take that apart.

GameObjects, Components & MonoBehaviour

Three words get used constantly in Unity, and beginners blur them together. Keep them distinct:

Every GameObject always has at least one component: a Transform, which stores its position, rotation, and scale. You can never remove it. Everything else — renderers, colliders, and your scripts — you add on top.

The green boxes are the scripts you write. They sit right alongside Unity's built-in components — from the engine's point of view, your Health script and its own Rigidbody are the same kind of thing: both are components attached to the GameObject.

⚠️ Important: A script asset sitting in your Assets folder does nothing on its own. It only runs when an instance of it is attached to a GameObject that exists in a loaded scene. "Attaching" a script is creating a component instance.

Where MonoBehaviour Comes From

When you write class Health : MonoBehaviour, you are inheriting a whole chain of Unity base classes. Each link in that chain hands your script another capability. Here is the real hierarchy:

You don't need to memorize the chain, but a few facts from it explain things you'll use every day:

• From Object: your component can be dragged into an Inspector slot as a reference, and Destroy(...) can delete it.
• From Component: you get gameObject, transform, GetComponent<T>(), and CompareTag(...) for free — no fields to declare (we cover these in Lesson 1.3).
• From Behaviour: the enabled flag. Set enabled = false and Unity stops calling this component's Update.
• From MonoBehaviour: the ability to define event functions like Awake, Start, and Update that the engine calls automatically, plus coroutine support. That is the whole point of inheriting it — it's your hook into the game loop, which is the subject of Lesson 1.2.

Your First MonoBehaviour

When you create a script in Unity (right-click in the Project window → Create → C# Script), you get a template like this. Two rules matter: it inherits MonoBehaviour, and the class name must exactly match the file name (a Health.cs file must contain class Health), or Unity won't let you attach it.

using UnityEngine;

public class Health : MonoBehaviour
{
    // A field marked public shows up in the Inspector so a designer can tune it.
    public int maxHealth = 100;

    // A private backing value — not shown in the Inspector by default.
    private int currentHealth;

    // Called once by Unity before the first frame. (More on this in Lesson 1.2.)
    void Start()
    {
        currentHealth = maxHealth;
        Debug.Log($"{gameObject.name} spawned with {currentHealth} HP");
    }

    // A normal public method — other components can call this.
    public void TakeDamage(int amount)
    {
        currentHealth -= amount;
        if (currentHealth <= 0)
        {
            Debug.Log($"{gameObject.name} died");
            Destroy(gameObject);   // remove the whole GameObject from the scene
        }
    }
}

Look at what your class got for free without declaring any of it: gameObject (the object this component is attached to), Debug.Log, and Destroy. Those all came down the inheritance chain from MonoBehaviour and its bases. Your job was only to add the game-specific parts: a health value and a way to take damage.

Why You Never new a Component

Here is the biggest surprise for a C# programmer. In plain C#, you create an object like this:

Health h = new Health();   // ❌ WRONG for a MonoBehaviour

In Unity that line is a mistake. A MonoBehaviour is meaningless without a GameObject to live on — new Health() would create a bare C# object with no gameObject, no transform, and Unity would never call its Start or Update. (Unity even logs a warning if you try.) You also should not write a constructor for a MonoBehaviour; the engine instantiates it, and your setup code belongs in Awake/Start instead.

So how do components get created? Two ways:

• In the Editor: you drag the script onto a GameObject, or click Add Component. Unity creates the instance for you.
• In code: you ask an existing GameObject to add one with AddComponent.

// Create a GameObject, then add components to it — the Unity way.
GameObject enemy = new GameObject("Enemy");   // a GameObject CAN be new'd
Health health = enemy.AddComponent<Health>(); // let Unity build the component
health.maxHealth = 50;                          // now it's safe to configure

💡 Rule of thumb: You may new a GameObject and you may new a plain C# class. You may never new a MonoBehaviour — ask a GameObject to AddComponent it, or attach it in the Editor.

Composition Over Inheritance

In the OOP part of the intro course, "reuse" mostly meant inheritance: an Enemy extends Character extends Entity. That works for a while, but game objects vary along too many independent axes — "flying?", "shoots?", "has health?", "can be picked up?" — to fit one tidy tree. You quickly hit the classic problem: where does a flying, shooting, healable object go, versus a walking, shooting, healable one?

Unity's answer is composition: instead of one deep class that is everything, you attach several small components that each add one capability. Need it to shoot? Add a Shooter. Need health? Add a Health. Mix and match per object.

To make the enemy fly, you swap its Movement component for a FlyingMovement and change nothing else — Health and Shooter don't care. To make a friendly turret, reuse Health and Shooter but drop Movement. This is why Unity ships Rigidbody, Collider, and AudioSource as separate components rather than one giant "PhysicalObject" base class.

💡 Components talk to each other, they don't inherit from each other. When your Shooter needs to reduce the target's health, it finds the target's Health component and calls TakeDamage — it does not try to be a Health. How one component finds another is Lesson 1.3.

Exercise & Quiz

using UnityEngine;

public class Rotator : MonoBehaviour
{
    public float degreesPerSecond = 90f;

    void Update()
    {
        // TODO: rotate this object around its Y axis every frame.
        // Hint: transform.Rotate(...) and Time.deltaTime (covered fully in Module 2).
    }
}

using UnityEngine;

public class SelfDestruct : MonoBehaviour
{
    public float lifetimeSeconds = 3f;

    void Start()
    {
        // TODO: schedule this GameObject to be destroyed after 'lifetimeSeconds'.
    }
}

using UnityEngine;

public class Rotator : MonoBehaviour
{
    public float degreesPerSecond = 90f;

    void Update()
    {
        // Frame-rate independent spin around the Y axis.
        transform.Rotate(0f, degreesPerSecond * Time.deltaTime, 0f);
    }
}

using UnityEngine;

public class SelfDestruct : MonoBehaviour
{
    public float lifetimeSeconds = 3f;

    void Start()
    {
        // Ask Unity to destroy the whole GameObject after the delay.
        Destroy(gameObject, lifetimeSeconds);
    }
}

Summary

📚 Additional Resources

• Unity Manual — MonoBehaviour
• Scripting Reference — MonoBehaviour
• Unity Manual — GameObjects and the component model

🚀 What's Next?

You now know what a MonoBehaviour is and how it attaches to a GameObject. Next we'll look at when Unity calls into it — the event function lifecycle: Awake, OnEnable, Start, Update, FixedUpdate, and OnDestroy, and the exact order they fire.