What a GameObject actually is (a named container with a Transform), why every capability - drawing, falling, colliding, running your code - is a component you attach, and the difference between switching an object off and destroying it.
Subject: Unity Game Engine · 61 slides · code lesson
Open the interactive version of this deck · Homework for this lesson
Title
Unity - Lesson 1
A cube is not a kind of object. It is an empty container with four things bolted on.
Objectives
This lesson exists because of one diagnostic result: you got the GameObject questions right, and marked yourself unsure on all of them. That is a sign of a model that is nearly there.
SetActive(false), enabled = false and Destroy()Warm-up
Answer from memory. Being wrong here costs nothing and makes the next twenty minutes stick.
Discussion prompt
You drag a Cube into an empty scene. List everything you think that cube can now do, and next to each one write what makes it able to do that.
Hint: There are exactly four things attached to a fresh cube. Two of them are about being seen.
Answer:
A fresh cube can: be positioned (Transform), hold a shape (Mesh Filter), be drawn (Mesh Renderer), and be touched by contact tests (Box Collider).
It cannot fall, cannot be clicked, cannot run any code, and does not know it is a cube. Everything on that second list is a component you have not added yet.
Section
Part 1
Concept
Figure (svg): A GameObject drawn as a board labelled Cube, with four component cards attached: Transform, Mesh Filter, Mesh Renderer, Box Collider
A GameObject has exactly two properties of its own: a name and a list of components. That is the whole definition.
GameObject — A named container that holds components. It has no behaviour of its own - every capability it appears to have comes from something attached to it.
Unity Manual - GameObjects GameObjects
Intuition
A pegboard on a wall does nothing. Hang a hook on it and it holds a coat; hang a shelf and it holds a plant. The board never changed - the things on it did.
Unity has one kind of GameObject. A Camera, a Light, a Player and a Cube are the same type of container with different components hanging off them.
This is why there is no Cube class to inherit from, and why 'what type of GameObject is it?' is not a question Unity can answer. It only knows what is attached.
Prediction
GameObject > Create Empty makes an object with nothing on it.
Predict first
How many components does a brand-new empty GameObject have?
Correct: One - the Transform.
Try it: create an empty object and look for the minus button on the Transform. There isn't one.
Why: Every GameObject has a Transform, always, and Unity will not let you remove it. An object with no position, rotation or scale would have no place in the scene, so 'empty' means 'empty apart from the one component that cannot be optional'.
Concept
Position, rotation and scale live on the Transform component. Every GameObject has exactly one, and it is the only component you cannot remove.
The Transform is also what makes parenting work - a child's position is measured from its parent. Lesson 6 is entirely about that.
| question | the component that answers it |
|---|---|
| Where is it? | Transform |
| What shape is it? | Mesh Filter |
| Should it be drawn? | Mesh Renderer |
| Can it be touched? | Collider |
| Does it fall? | Rigidbody |
| Does it run my code? | your MonoBehaviour script |
Concept
Add a Rigidbody and the object falls. Remove the Mesh Renderer and it vanishes but still collides. Each capability is independent, and each is a row in the Inspector.
Unity Manual - Introduction to components Introduction to components
Matching
Each of these is a real thing a beginner says. Match it to what is actually missing.
Match the pairs
Drag each complaint onto the component that would fix it.
Why: Every one of these is a missing component, not a broken setting. That is the diagnostic habit worth building: when something does not happen in Unity, the first question is 'what is attached?', not 'what did I type wrong?'.
Worked example
GetComponents<Component>() returns the honest answer to 'what is this made of?'. Here it is on a plain cube.
using UnityEngine;
public class ComponentReport : MonoBehaviour
{
void Start()
{
Component[] parts = GetComponents<Component>();
Debug.Log($"{name} has {parts.Length} components");
foreach (Component part in parts)
Debug.Log(" " + part.GetType().Name);
}
}Attach it to a plain cube and press Play
Why: Nothing runs until the script is a component on an object - that is the whole point of the next section.
| printed line | what it is | could you remove it? |
|---|---|---|
| Transform | position, rotation, scale | no - never |
| MeshFilter | which mesh: the cube shape | yes, it goes invisible |
| MeshRenderer | draws the mesh with a material | yes, it goes invisible |
| BoxCollider | the shape used for contact tests | yes, things pass through it |
| ComponentReport | your script - itself a component | yes, that is the checkbox |
Five lines, not four: your script is in the list. It is not 'the object' - it is one more part bolted on beside the others.
Explain it to yourself
Discussion prompt
The report printed five components on a cube that visibly has four things in the Inspector. Explain, in your own words, why ComponentReport appears in its own report.
Hint: What does the word MonoBehaviour inherit from?
Answer:
Because MonoBehaviour is a component. Your class inherits from MonoBehaviour, which inherits from Behaviour, which inherits from Component.
So a script is not something a GameObject has in a special way - it is attached in exactly the same way a Collider is, appears in the same list, and has the same enabled checkbox.
Sorting
Unity has objects in a scene, components on those objects, and assets in the Project window. They are not interchangeable.
Sort into buckets
Sort each one.
Trap
The mental model: GameObject is a base class, Cube extends it, and my Coin script extends Cube.
// The way it feels like it should work
public class Coin : Cube // <- there is no Cube class
{
void Start() { ... }
}| belief | consequence |
|---|---|
| Cube is a type | you look for a Cube class to inherit from |
| My script IS the object | you expect this to be the whole cube |
| Objects differ by type | you cannot explain how a Camera and a Cube are related |
There is one GameObject type. 'Cube' is a name plus a Mesh Filter that happens to hold the cube mesh.
// The way it really works
public class Coin : MonoBehaviour // a COMPONENT you attach
{
void Start()
{
// 'this' -> the Coin component
// 'gameObject' -> the container it is attached to
}
}| fact | consequence |
|---|---|
| One GameObject type | you compose with components instead of inheriting |
| Your script rides on the object | this and gameObject are two different things |
| Objects differ by what is attached | a Camera is a GameObject with a Camera component |
Error analysis
Every line here is legal C#. One of them is a category error.
Annotate
this is the Coin COMPONENT. Destroying it removes the script and leaves the coin sitting there, visible and solid, forever. You meant Destroy(gameObject).this versus gameObject is the single most useful distinction in this lesson. One is the part; the other is the whole.
Concept
A MonoBehaviour has the same two switches every component has: the object it is on can be inactive, and the component itself can be disabled.
// three different ways of "turning it off"
GetComponent<Coin>().enabled = false; // this script stops; the object is fine
gameObject.SetActive(false); // the whole object stops
Destroy(gameObject); // the whole object is removed| call | what stops | what survives |
|---|---|---|
enabled = false | that one script's Update | everything else on the object |
SetActive(false) | the whole object | the object itself, in the scene |
Destroy(gameObject) | everything | nothing |
Two truths and a lie
One statement below is false. Rule it out and say what rules it out.
Eliminate the wrong options
Which claim about components is false?
Survives elimination: B
Why: B is the false one, and it is the useful falsehood: a component is defined by the object it is attached to, which is why new Rigidbody() is refused and AddComponent<Rigidbody>() is the way in. A and C are both true - duplicates are allowed unless the script says [DisallowMultipleComponent], and the checkbox is per component.
Section
Part 2
Concept
Unity does not apply gravity to objects. It applies gravity to Rigidbodies. An object without one is not 'held up' by anything - it was never being simulated in the first place.
Rigidbody — The component that hands an object's position over to the physics solver. Without it, an object's position is whatever your code or the Inspector last set.
Unity Manual - Introduction to components components
Prediction
Two cubes, same size, same position, same material. One has a Rigidbody; the other does not. You press Play.
Predict first
What happens to the cube WITHOUT the Rigidbody?
Correct: It does not move at all - not slowly, not eventually. Nothing is simulating it.
Why: This is the difference between 'gravity is switched off for this object' and 'this object is not part of the physics simulation'. The second is the true one. It has a Collider, so other things can be stopped by it, but nothing will ever move it.
Worked example
AddComponent<T>() is the Add Component button, in code. Watch the moment a cube gains physics.
public class AddComponentAtRuntime : MonoBehaviour
{
public GameObject target;
public float addAfterSeconds = 3f;
bool added;
void Update()
{
if (added || Time.timeSinceLevelLoad < addAfterSeconds) return;
added = true;
Rigidbody body = target.AddComponent<Rigidbody>();
body.mass = 1f;
}
}Nothing about the cube changed except its component list
Why: It has the same mesh, the same material, the same position. One row appeared in the Inspector and it started falling.
| time | components on the cube | is it moving? |
|---|---|---|
| 0.0s | Transform, MeshFilter, MeshRenderer, BoxCollider | no |
| 2.9s | same four | no |
| 3.0s | the four, plus Rigidbody | yes - it starts to fall |
| 3.5s | the five | yes, accelerating at 9.81 m/s squared |
Discrimination
For each goal, pick the component you would add. Do not think about settings yet.
Sort into buckets
Sort each goal under the component that provides it.
Trap
The cube has a Box Collider. Physics is clearly involved. So it should fall.
// "why isn't my cube falling? it has a collider!"
void Start()
{
GetComponent<Rigidbody>().mass = 2f; // NullReferenceException
}GetComponent<Rigidbody>() returned null, because there is no Rigidbody. The next . throws.
A Collider is a shape. A Rigidbody is being simulated. They are independent, and most objects in a game want the shape without the simulation.
void Start()
{
if (TryGetComponent(out Rigidbody body))
body.mass = 2f;
else
Debug.Log("no Rigidbody here - this object is not simulated");
}| what it has | what it can do |
|---|---|
| Collider only | stop things, be a trigger; never moves on its own |
| Rigidbody only | fall and be pushed; passes through everything |
| Both | falls AND is stopped - a crate |
Comparison
Three components, three questions. Fill the blanks from what you have seen so far.
Comparison matrix
| Is it drawn? | Can it be hit? | Does it move on its own? | |
|---|---|---|---|
| Mesh Renderer only | yes | no | no |
| Collider only | no | yes | no |
| Rigidbody + Collider | only with a Renderer | yes | yes |
The middle row is the one worth staring at: a Collider with no Renderer is a perfectly normal object. Every trigger zone in every game you have played is exactly that.
Concept
GetComponent<T>() searches what is already attached and returns null if there is no T. Asking for a Rigidbody does not conjure one.
Rigidbody body = GetComponent<Rigidbody>(); // null if there isn't one
if (body == null)
body = gameObject.AddComponent<Rigidbody>(); // this is the call that creates| call | searches? | creates? | returns |
|---|---|---|---|
GetComponent<T>() | yes | no | the component or null |
AddComponent<T>() | no | yes | the new component |
new T() | no | refused for components | an error in the Console |
Unity Scripting API - GameObject.GetComponent GetComponent
Fill the middle
Fill the blanks so this reads a Rigidbody's mass without ever throwing.
Fill in the blanks
void Start()
GetComponent}<Rigidbody>();
if (body != null)
Debug.Log(body.mass);
else
Debug.Log("not simulated");
}
Why: GetComponent searches and may return null, so the null check is not defensive noise - it is the actual API contract. Unity overloads == for components so a destroyed or missing component compares equal to null, which is what makes this readable.
Section
Part 3
Concept
Figure (svg): Three switches diagram: object active, component enabled, and destroyed, showing what survives each
These are not three ways of saying the same thing. They differ in what stops, what survives, and whether you can undo it.
Unity Scripting API - GameObject.SetActive GameObject.SetActive
Intuition
Switching a room's light off leaves the room, the furniture and the address exactly where they were. You can switch it back on.
Demolishing the building leaves nothing. The address is not 'off' - it is invalid, and so is every piece of paper pointing at it.
SetActive(false) is the switch. Destroy() is the demolition. The reason to care is that after a Destroy, every reference anyone kept to that object is now dead - and using one is the most common runtime error in Unity.
Prediction
A cube with a script whose Update prints once a second. At t = 2s something calls SetActive(false) on it.
Predict first
What happens to the printing, and to the reference you were holding?
Correct: Printing stops, and the reference stays valid.
Why: An inactive GameObject runs no Update, draws nothing and collides with nothing - but it is still in the scene with all its components and values intact, so any reference to it still points at something real. OnDisable runs; OnDestroy does not, because nothing was destroyed.
Worked example
This is the lab script for lesson 1. Two identical cubes: one is switched off, one is destroyed, and both are polled every second afterwards.
void Update()
{
if (!acted && Time.timeSinceLevelLoad >= 2f)
{
acted = true;
toDeactivate.SetActive(false);
Destroy(toDestroy);
}
if (acted && Time.timeSinceLevelLoad >= nextReport)
{
nextReport += 1f;
Debug.Log($"deactivated alive: {toDeactivate != null}");
Debug.Log($"destroyed alive: {toDestroy != null}");
}
}Poll both references once a second
Why: The question obj != null is how you ask 'does this still exist?'. Unity overloads == for objects precisely so this reads naturally.
| time | deactivated: reference alive? | deactivated: running? | destroyed: reference alive? |
|---|---|---|---|
| 1s (before) | true | true | true |
| 2s (the calls) | true | false | true - until end of frame |
| 3s | true | false | false |
| 4s | true | false | false |
| 5s | true | false | false |
The deactivated cube never leaves the table. It is off, not gone - and SetActive(true) brings it back mid-run.
Invariant
Step through the four states and watch which row never changes.
Step through it
One column here is constant across all four frames. Which, and why?
'Reference still valid' stays true for the first three frames. Only destruction invalidates it - which is exactly why mixing up the third and fourth states produces a bug that appears one frame later.
Trap
The coin has been collected, so switch it off. Same thing as deleting it, and easy to undo.
void Collect()
{
gameObject.SetActive(false);
score += 1;
}GameObject.Find skips them, so debugging gets confusingDecide by intent. Coming back? switch it off. Never coming back? destroy it.
void Collect()
{
score += 1;
Destroy(gameObject); // gone at the end of this frame
}
void Respawn() // the case where SetActive really is right
{
checkpointFlag.SetActive(true);
}| intent | the call | undo? |
|---|---|---|
| collected for good | Destroy(gameObject) | no - Instantiate a new one |
| hidden until later | SetActive(false) | yes - SetActive(true) |
| pooled for reuse | SetActive(false), deliberately | yes - that is the point |
There is a third option once you know it: object pooling - deactivate instead of destroy specifically because you will reuse the object. That is a deliberate choice, not a synonym.
Unity Scripting API - Object.Destroy Object.Destroy
Elimination
A pickup should disappear when collected, and reappear at the start of the next round.
Eliminate the wrong options
Which is the right call when the player collects it?
Survives elimination: A
Why: Reuse is the deciding fact. Because the pickup comes back next round, deactivating is right and cheap - the object keeps its position and its wiring, and SetActive(true) restores it. Choice D is worth noticing: hiding something is not the same as switching it off, and a hidden-but-active collider is a real bug you will meet.
Ranking
You call SetActive(false) on an object at t = 2s, then stop Play mode at t = 5s. Put the callbacks in the order Unity fires them.
Put in order
Earliest first.
Why: OnDisable runs when the object is deactivated, and again on the way to destruction - so OnDestroy is never the first goodbye. That ordering is why subscribe-in-OnEnable and unsubscribe-in-OnDisable is the standard pairing: it survives an object being switched off and on again, which OnDestroy would not.
Concept
An object can be switched on and still not running, because a parent above it is switched off. Unity gives you both answers.
// parent is inactive; child was never touched
child.activeSelf // true - the child's own switch is on
child.activeInHierarchy // false - but nothing above it is running, so neither is it| property | asks | typical use |
|---|---|---|
activeSelf | is MY switch on? | restoring an object to how you found it |
activeInHierarchy | am I actually running? | the one you almost always want |
Counterexample
Discussion prompt
A classmate says: 'If activeSelf is true, the object is running.' Give a concrete two-object scene where that is false.
Hint: You only need a parent and a child.
Answer:
Parent Hud with child ScoreLabel. Call Hud.SetActive(false).
ScoreLabel.activeSelf is still true - nobody touched its switch. ScoreLabel.activeInHierarchy is false, and its Update does not run.
This is the bug behind 'my script stopped working and I never disabled it'. Something above it in the Hierarchy did.
Section
Part 4
Concept
A scene that prints its own component model to the Console. Five cubes, three scripts, and every claim in this deck checked out loud.
Files: unity-labs/Assets/NaruhodoLabs/Lesson01_GameObjects/. Full instructions in that folder's SETUP.md.
Step zero
Discussion prompt
Before touching the editor: what is the smallest scene that proves 'SetActive(false) is not Destroy'? Name the objects and what each one is for.
Hint: You need two things that are identical apart from what happens to them, and something to do the doing.
Answer:
That is the shape of every experiment in this course: two things, one difference, one observer.
Worked example
Unity Hub, new project, 3D. Then build the object and read it before adding anything.
PlainCube, Position (-3, 0.5, 0)ComponentReport| Inspector row | what it does | in the printed list? |
|---|---|---|
| Transform | position, rotation, scale | yes |
| Mesh Filter | holds the cube mesh | yes |
| Mesh Renderer | draws it | yes |
| Box Collider | shape for contact tests | yes |
| Component Report | your script | yes - it counts itself |
Worked example
Type this into ComponentReport.cs. It is the lab file, trimmed to what the lesson needs.
using UnityEngine;
public class ComponentReport : MonoBehaviour
{
void Start()
{
Component[] parts = GetComponents<Component>();
Debug.Log($"{name}: {parts.Length} components");
if (GetComponent<Rigidbody>() == null)
Debug.Log("no Rigidbody - physics is opt-in");
Debug.Log($"this = {GetType().Name}, gameObject = {gameObject.name}");
}
}Line 7 asks the object what it is made of
Why: GetComponents (plural) returns every component; GetComponent (singular) returns the first of one type, or null.
Line 10 is the physics claim, checked
Why: A null result is not an error here - it is the answer.
| line | prints on a plain cube | prints on a cube with a Rigidbody |
|---|---|---|
| 7 | PlainCube: 5 components | PhysicalCube: 6 components |
| 10 | no Rigidbody - physics is opt-in | (nothing - the branch is skipped) |
| 13 | this = ComponentReport, gameObject = PlainCube | this = ComponentReport, gameObject = PhysicalCube |
Faded example
Here is the second lab script with two holes in it. Same shape as the one you just typed.
Fill in the blanks
public class ActiveVsDestroy : MonoBehaviour
SetActive}(false);
Destroy(toDestroy);
}
}
}
Why: SetActive is a method ON a GameObject, so it is called through the reference: toDeactivate.SetActive(false). Destroy is inherited from Object, so it is called as a plain method with the victim as the argument: Destroy(toDestroy). That asymmetry is worth noticing - it is why the two calls look so different for such similar-sounding jobs.
Worked example
Two more cubes and an empty object to drive them.
WillBeDeactivated and WillBeDestroyedLab DriverActiveVsDestroy to the driver| at t = 2s, in the Hierarchy | what you see |
|---|---|
| WillBeDeactivated | still listed, name goes grey |
| WillBeDestroyed | disappears from the list |
| Lab Driver | unchanged - it did the doing |
| Console | two PASS lines confirming both |
The Hierarchy is the honest view. The Game view cannot tell you the difference between 'switched off' and 'gone', because both are invisible.
Real world
Discussion prompt
You are building a level with 40 enemies, 200 coins, a pause menu and a boss that appears at the end. For each of the four, would you deactivate it, destroy it, or never do either? Say why.
Answer:
That last one is the practical reason SetActive exists: an object that is not needed yet, but whose references have to be in place before it is.
Concept
The lab prints through one helper so the output reads as a report. Learn the three prefixes now - every later lesson uses them.
[L01] ====== component report for 'PlainCube' ======
[L01] ---- 5 component(s): Transform, MeshFilter, MeshRenderer, BoxCollider, ComponentReport
[L01] PASS every GameObject has a Transform
[L01] PASS no Rigidbody on this object - physics is something you ADD
[L01] FAIL expected 3 components, found 4| prefix | means | what to do |
|---|---|---|
---- | an observation | read it |
PASS | a claim about Unity that held | nothing |
FAIL | the scene is not set up as the lesson assumes | read the message - it names what it expected |
Pattern
You add a second ComponentReport to the same cube and press Play.
Predict first
What does the Console show?
Correct: Two reports, each saying 6 components.
Why: Callbacks are per component, not per object, so both instances run Start. And each one counts the other, so the total is six. Unless a script is marked [DisallowMultipleComponent], duplicates are allowed - which is a real source of 'why did this happen twice?' bugs.
Explain it
Discussion prompt
A friend asks: 'I made a Coin.cs script but nothing happens when I press Play.' Answer them in three sentences, without using the word 'component' more than once.
Answer:
A model answer: 'A script file on its own is just a description - Unity has not been told to use it anywhere. Drag it onto an object in the Hierarchy, or use Add Component on that object. Now there is an actual copy of your script running on that object, and Start will fire.'
The idea to land: a class is a definition; attaching it creates an instance. Unity only ever runs instances.
Concept
Each of these takes twenty seconds and kills one wrong belief for good.
| do this | what you expect | what happens |
|---|---|---|
| Delete the Rigidbody from the falling cube | it still falls | it hangs in the air |
| Untick the checkbox beside your script only | the object switches off | only that script stops |
| Untick the checkbox at the top of the Inspector | the script stops | the whole object stops |
| Write a script and attach it to nothing | it runs | nothing happens at all |
Hypothesis
You untick the checkbox beside ComponentReport in the Inspector - the component's own checkbox - and press Play.
Predict first
Does Start run?
Correct: No. Start does not run on a disabled component.
Why: Start and Update are skipped for a disabled component. Awake is the exception: it runs even on a disabled component, because Awake is about the object being created rather than about it running. That single exception is why lesson 4 tells you to cache in Awake and reach out in Start.
Pattern
Nine times out of ten in Unity, nothing is wrong with your code. Something is not attached, not enabled, or not assigned.
GetComponent<T>() returns null when there is no T.Debug.Log in Start. If it never appears, the problem is one of the five above, not your logic.Work down that list before you read your own code again. It is faster, and it is what an experienced developer does automatically.
Check
Answer before you click.
Check your understanding
Which statement is the most accurate description of a GameObject in Unity?
Answer: B
Why: There is exactly one GameObject type. A Camera is a GameObject with a Camera component; a Cube is a GameObject with a Mesh Filter, Mesh Renderer and Box Collider. Composition, not inheritance - which is why you attach your script rather than subclassing anything.
Check
A cube in a scene, Play pressed, nothing moves.
Check your understanding
A cube sits in mid-air with a Transform, Mesh Filter, Mesh Renderer and Box Collider. You press Play and it does not move. What is the fix?
Answer: B
Why: Gravity in Unity is applied to Rigidbodies, not to GameObjects. Without one the cube is not part of the simulation at all, so there is nothing for gravity to act on. Adding a Rigidbody is what hands its position to the physics solver.
Socratic
Discussion prompt
Unity chose composition (attach components) over inheritance (subclass a base type). Name one thing that becomes easy under composition which would be awkward under inheritance.
Hint: Think about an object that needs to be two things at once.
Answer:
A door that is also a light source that is also a save point. Under inheritance you would need a LightEmittingSaveDoor class, and the next combination needs another one.
Under composition you attach three components to one GameObject and you are done. The combinatorial explosion never happens - which is why nearly every game engine written since 2005 works this way.
Check
The last one. Take your time.
Check your understanding
You call enemy.SetActive(false) at t = 2s. At t = 3s, which of these is true?
enemy == null is true, and OnDestroy has runenemy == null is false, the enemy is still in the scene, and OnDisable has run (correct)enemy == null is false, and the enemy's Update is still runningAnswer: B
Why: SetActive(false) stops the object running - no Update, no rendering, no collisions - and fires OnDisable. It does not remove anything: the object stays in the scene with its components and values intact, so the reference is still valid and SetActive(true) restores it.
Estimation
A level has one player, 40 enemies, 200 coins, 60 pieces of scenery, 12 lights and a UI canvas with 30 elements.
Predict first
Roughly how many of those GameObjects need a Rigidbody?
Correct: Around 40, and possibly fewer.
Why: Enemies that are pushed around by the simulation need one. Coins usually need only a trigger collider. Scenery, lights and UI need nothing. Rigidbodies cost simulation time every fixed step, so the habit of adding one to everything is both a performance problem and the source of the tunnelling bugs in lesson 3.
Concept
Everything after this is a component. Prefabs are saved component trees; physics is one component; your gameplay code is a component. The container never gets more complicated than it is right now.
| next lesson | the question it answers |
|---|---|
| 2 - Prefabs | how do I make fifty of these and change them all at once? |
| 3 - Rigidbody | what does 'has physics' actually mean? |
| 4 - Lifecycle | when does Unity call my code? |
| 5 - GetComponent | how do I reach one component from another? |
Analogy
If you have written any object-oriented code before, this maps onto something familiar.
Match the pairs
Match the Unity idea to its closest cousin outside Unity.
Why: The pattern has a name outside Unity: entity-component composition. The GameObject is the entity - an identity with no behaviour. Components supply behaviour and state. Recognising it as a known pattern rather than a Unity quirk makes the rest of the engine much easier to predict.
Connect it up
Draw it
Draw a GameObject as a box with its name in it, then hang every component from part 1 off it as a labelled card. Beside each card, write the one thing that stops working if you remove it.
Exit ticket
Predict first
Which of these four are you least sure of right now?
Correct: Whichever you picked - that is the one to bring to the session and the one to re-run in the lab scene.
Why: The diagnostic marked this topic Fragile, and fragile means the answers were right while the confidence was low. Naming the shakiest piece out loud is what turns a lucky guess into knowledge, so bring the one you picked to the next session and we will build the scene for it from scratch.
Recap
You can describe a GameObject without hand-waving, and you can predict what a cube will do from its Inspector alone.
enabled = false stops one script, SetActive(false) stops the object, Destroy() removes it - and only the last one is permanentLab: unity-labs/Assets/NaruhodoLabs/Lesson01_GameObjects/SETUP.md. Build the scene, run the 'now break it' table, then go to lesson 2.
Want this taught 1-on-1? Alexander tutors Unity Game Engine — $55/session, free consultation.