GameObjects & Components

Almost every confusing thing about Unity becomes obvious once this one idea clicks: a GameObject does nothing by itself. It is an empty container. Everything you can see, hear, or interact with comes from the components attached to it.

A GameObject is an empty box

Create an empty GameObject in a scene and you get almost nothing: a name, a position, and a place in the hierarchy. It does not render. It does not collide. It has no behaviour. It is a label with coordinates.

What makes a GameObject into a player, an enemy, a door, or a camera is the set of components bolted onto it. Change the components and you change what the object is.

Your scripts are components too

When you write a class that extends MonoBehaviour, you are writing a component. Unity can attach it to a GameObject, show its public fields in the Inspector, and call its lifecycle methods.

using UnityEngine;

// This class becomes a component the moment it extends MonoBehaviour
public class Health : MonoBehaviour
{
    [SerializeField] private int maxHealth = 100;

    private int current;

    private void Awake()
    {
        current = maxHealth;
    }

    public void TakeDamage(int amount)
    {
        current = Mathf.Max(0, current - amount);

        if (current == 0)
            Destroy(gameObject);   // destroys the whole GameObject
    }
}

Talking to other components

Components on the same GameObject find each other with GetComponent<T>(). It is a search, not a free lookup, so cache the result instead of calling it every frame.

public class Enemy : MonoBehaviour
{
    private Rigidbody rb;
    private Health health;

    private void Awake()
    {
        // Look them up once, reuse forever
        rb = GetComponent<Rigidbody>();
        health = GetComponent<Health>();
    }

    private void FixedUpdate()
    {
        rb.AddForce(Vector3.forward);
    }
}

public class Enemy : MonoBehaviour
{
    private void FixedUpdate()
    {
        // Searching the component list every single physics step.
        // Works, but it is wasted time in your hottest loop.
        GetComponent<Rigidbody>().AddForce(Vector3.forward);
    }
}

There are directional variants when the component lives elsewhere in the hierarchy:

• GetComponent<T>() — this GameObject only
• GetComponentInChildren<T>() — this object and everything beneath it
• GetComponentInParent<T>() — this object and everything above it
• GetComponents<T>() — all matches, not just the first

Require what you depend on

If your script cannot work without another component, say so. [RequireComponent] makes Unity add it automatically and stops anyone removing it while your script is attached.

using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
public class Movement : MonoBehaviour
{
    private Rigidbody2D rb;

    private void Awake()
    {
        // Guaranteed to exist, so no null check needed
        rb = GetComponent<Rigidbody2D>();
    }
}

Composition over inheritance

Coming from other engines or from classic OOP, the instinct is to build a class tree: Entity → Character → Enemy → FlyingEnemy. Unity pushes the opposite way. Instead of one deep class, you write several small components and mix them.

A flying enemy that explodes is not a new class. It is a GameObject with Health, FlightMovement, and ExplodeOnDeath attached. Want a ground enemy that explodes? Swap one component. No new subclass, no refactor.

Active, enabled, and the difference

These two are not the same, and mixing them up causes bugs that look like the engine misbehaving.

What to take away

• A GameObject is a container; components give it behaviour.
• Your MonoBehaviour scripts are components, no different from built-in ones.
• Cache GetComponent results in Awake rather than calling them per frame.
• Declare hard dependencies with [RequireComponent].
• Prefer several small components over one deep class hierarchy.
• SetActive affects the object; enabled affects one component.