tell me godot's load order in detail (like parent node-> first child -> second child-> parent node's ready func? or sth idk)

[Siltag]

Good question. This is not optional knowledge if you’re doing composition. I’ll be exact and mechanical.

---

GODOT NODE LOAD / READY ORDER (FACTUAL)

I’ll describe what actually happens, not vibes.

Assume this scene tree:

Player (CharacterBody2D)
├── MovementComp
├── HealthComp
└── Sprite

---

1️⃣ Scene is instantiated (NO callbacks yet)

• Memory for all nodes is created
• Scripts are attached
• NO _ready()
• NO @onready
• NO scene tree

At this point:

• You cannot access children
• You cannot use $Node
• You cannot rely on exported values being wired

---

2️⃣ Nodes enter the scene tree (TOP → DOWN)

Godot inserts nodes from root to leaves.

Order:

Player enters tree
MovementComp enters tree
HealthComp enters tree
Sprite enters tree

Still:

• No _ready()
• No @onready
• Just structural insertion

---

3️⃣ _enter_tree() is called (TOP → DOWN)

Now callbacks begin.

Order:

Player._enter_tree()
MovementComp._enter_tree()
HealthComp._enter_tree()
Sprite._enter_tree()

Important facts:

• Parent runs BEFORE children
• Scene tree exists
• Children exist
• $Child works
• @onready has NOT run yet

Use _enter_tree() if:

• You need early registration
• You need to add to groups
• You must exist before children logic

---

4️⃣ @onready variables are assigned (BOTTOM → UP)

This is the part most people do NOT know.

Order:

MovementComp @onready vars
HealthComp @onready vars
Sprite @onready vars
Player @onready vars

Why?

• Godot guarantees children exist before parents cache them

So this is safe:

@onready var health := $HealthComp

Because HealthComp already exists.

---

5️⃣ _ready() is called (BOTTOM → UP)

This is the critical one.

Order:

MovementComp._ready()
HealthComp._ready()
Sprite._ready()
Player._ready()

Children FIRST, parent LAST.

This is why your bug happened.

---

6️⃣ First _process / _physics_process

Only after ALL _ready() calls finish:

• _process() starts
• _physics_process() starts
• Signals can fire safely
• Game logic begins

---

VISUAL SUMMARY (MEMORIZE THIS)

1. Instantiate nodes
2. enter_tree (parent → children)
3. _enter_tree (parent → children)
4. @onready (children → parent)
5. _ready (children → parent)
6. process / physics loop

---

WHY YOUR HEALTH BUG HAPPENED (CONNECTED TO THIS)

You assumed:

Player sets health.base_health BEFORE HealthComp initializes itself

Reality:

• HealthComp _ready() ran FIRST
• @onready max_health computed with base_health = 0
• Setter clamped to 0
• Death triggered
• Scene reloaded
• Loop

This was 100% predictable given the order.

---

LAYER 1 — SIMPLE RULES (USE THESE NOW)

If you remember nothing else, remember this:

1. Children _ready() runs before parent _ready()
2. Never compute gameplay state in @onready
3. Never rely on parent data inside child _ready()
4. If a child needs parent data → parent must call init()
5. @onready is for node references, not gameplay logic

These five rules will prevent 90% of Godot bugs.

---

LAYER 2 — ADVANCED / SCALABLE RULES

When to use _enter_tree()

• Register in autoloads
• Add to groups
• Setup global references
• Do NOT read parent data

When to use _ready()

• Connect signals
• Receive explicit init() calls
• Final wiring
• No assumptions about parents having run logic

When to use explicit init()

• Component needs external data
• Component must be deterministic
• Component must be reusable
• You care about scalability

---

COMMON WRONG ASSUMPTIONS (KILL THESE)

❌ Parent _ready() runs first
❌ @onready is a constructor
❌ Setters are safe during initialization
❌ Components should self-initialize
❌ Scene reload is harmless in setters

All false.

---

FINAL VERDICT

• Godot’s load order is child-first for _ready()
• This is why composition requires explicit init
• Your confusion was justified
• Your fix (explicit init) is mandatory, not stylistic
• If you internalize this order, Godot stops feeling random

If you want next:

• exact rules for _exit_tree()
• what happens on scene reload
• how signals behave during load
• how to enforce init contracts safely

Pick one.