📝 Lesson 1.3: Accessing GameObjects and Components

The Wiring Problem

In Lesson 1.1 we built a Health component and a Shooter, and said "the Shooter finds the target's Health and calls TakeDamage." That word — finds — is the whole subject of this lesson. Composition only pays off if components can locate each other.

From Lesson 1.1 you already have two references handed to you for free by the base classes:

Everything else you reach by one of three strategies, in rough order of preference:

GetComponent on the Same Object

GetComponent<T>() asks the GameObject, "do you also have a component of type T?" and returns it — or null if there isn't one. It's the workhorse for components that live together on one object.

using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class Jumper : MonoBehaviour
{
    private Rigidbody body;   // cache the reference

    void Awake()
    {
        // Grab the Rigidbody attached to THIS same GameObject.
        body = GetComponent<Rigidbody>();
    }

    void Jump()
    {
        body.AddForce(Vector3.up * 5f, ForceMode.Impulse);
    }
}

The safer variant: TryGetComponent

When a component might not be there, TryGetComponent<T>(out T) avoids both a null check and (in editor) a harmless-but-noisy allocation when nothing is found. It returns a bool and follows the classic C# Try... pattern you know from int.TryParse:

// Only heal if this object actually has a Health component.
if (TryGetComponent<Health>(out Health health))
{
    health.Heal(10);
}

Reaching Children & Parents

Complex objects are usually a hierarchy: a Player GameObject with child objects for the model, a weapon, and a health bar. Two variants search that hierarchy instead of just the one object.

public class PlayerController : MonoBehaviour
{
    private Animator animator;

    void Awake()
    {
        // The Animator lives on the child 'Model', not on the Player root.
        animator = GetComponentInChildren<Animator>();
    }
}

// A child weapon script finding the Player it belongs to:
public class Weapon : MonoBehaviour
{
    private PlayerController owner;

    void Awake()
    {
        owner = GetComponentInParent<PlayerController>();
    }
}

💡 Note: the InChildren/InParent versions include the object they're called on, not just its relatives. And they return the first match found in the hierarchy — use the plural GetComponentsInChildren when you want them all.

[SerializeField] & Inspector Wiring

Searching in code is great for relatives, but for a reference to a specific object elsewhere in the scene — "this door's key", "the camera to follow" — the cleanest approach is to expose a slot in the Inspector and drag the object in. No lookup code at all.

In Lesson 1.1 we made fields public so they'd show in the Inspector. That works, but it breaks encapsulation — now any other script can modify the field too. The idiomatic Unity solution is the [SerializeField] attribute: it shows a private field in the Inspector without making it public.

using UnityEngine;

public class CameraFollow : MonoBehaviour
{
    // Shows in the Inspector as a slot, but stays private to other code.
    [SerializeField] private Transform target;

    [SerializeField] private float height = 5f;   // also tunable in Inspector

    void LateUpdate()
    {
        if (target != null)
            transform.position = target.position + new Vector3(0f, height, -10f);
    }
}

⚠️ Important: A serialized reference wired in the Inspector is set before Awake runs — Unity deserializes it as the object loads. So you can safely use [SerializeField] references starting in Awake. (The counterpart [HideInInspector] public does the opposite: public to code, hidden from the Inspector.)

Finding Objects Across the Scene

Sometimes you need an object you can't wire in the Inspector — perhaps it's spawned at runtime. Unity offers scene-wide search methods, but they come with a health warning.

// By name (searches the whole active scene — slow, brittle to renames):
GameObject player = GameObject.Find("Player");

// By tag (faster than Find, still a search):
GameObject respawn = GameObject.FindWithTag("Respawn");

// Find a component of a type anywhere in the scene (Unity 2023+ API name):
Camera cam = Object.FindFirstObjectByType<Camera>();

Caching & Avoiding Null

Two habits prevent the vast majority of "it compiled but crashed at runtime" bugs in Unity scripting.

1. Cache once, reuse forever

Look up a component once in Awake/Start, store it in a field, and use the field everywhere else. This is faster and makes your dependencies obvious at the top of the class.

2. Assume lookups can fail

Any lookup that isn't guaranteed (no [RequireComponent], no wired Inspector slot) can return null. Reading a member off null throws a NullReferenceException — the most common runtime error in Unity. Guard it:

public class DamageOnContact : MonoBehaviour
{
    [SerializeField] private int damage = 10;

    private void ApplyTo(GameObject other)
    {
        // TryGetComponent gives us a clean guarded call — no separate null check.
        if (other.TryGetComponent<Health>(out Health health))
        {
            health.TakeDamage(damage);
        }
        // If there's no Health, we simply do nothing — no crash.
    }
}

💡 Unity's special null: Unity overloads == so that a destroyed object compares equal to null even though the C# reference technically still exists. That's why if (target != null) is the right guard even after something was Destroy-ed. It also means you should avoid the C# null-conditional ?. on Unity objects in edge cases — a plain != null check is the safe idiom.

Exercise & Quiz

using UnityEngine;

public class Trap : MonoBehaviour
{
    [SerializeField] private Health target;   // drag Enemy's Health here

    void Start()
    {
        // TODO: if target is assigned, deal 5 damage to it.
    }
}

using UnityEngine;

// 1) Same object
public class Suicidal : MonoBehaviour
{
    private Health health;
    void Awake()  => health = GetComponent<Health>();
    void Start()  => health.TakeDamage(5);
}

// 2) Inspector-wired reference
public class Trap : MonoBehaviour
{
    [SerializeField] private Health target;

    void Start()
    {
        if (target != null)
            target.TakeDamage(5);
        else
            Debug.LogError("Trap: target not assigned", this);
    }
}

// 3) Guarded runtime lookup
public class DamageZone : MonoBehaviour
{
    [SerializeField] private int damage = 10;

    public void ApplyTo(GameObject other)
    {
        if (other.TryGetComponent<Health>(out Health health))
            health.TakeDamage(damage);
    }
}

Summary

📚 Additional Resources

• Scripting Reference — GetComponent
• Scripting Reference — TryGetComponent
• Scripting Reference — SerializeField
• Scripting Reference — RequireComponent

🚀 What's Next?

That completes Module 1 — Unity's C# Model: you understand components, the lifecycle, and how to wire objects together. In Module 2 we put it to work — starting with Lesson 2.1, Input and Movement, where you'll read the player's input and move a Transform every frame.