logo

Node creation and the ready function

In this module, we saw the _ready() function for the first time. The _ready() function is a function that Godot recognizes and calls in your scripts when a node and all its children are ready to access in code.
We mentioned that Godot calls this function for every node in the scene tree, but we didn't go into much detail about how Godot creates nodes when running the game, in which order it adds them to the scene tree, and when it calls the function for each node.
In this study guide, we will dive into:
  • How Godot creates nodes when running the game.
  • The order in which the engine adds nodes to the scene tree at runtime.
  • How we usually use the _ready() function.
  • When Godot calls the _ready() function for each node, and in which order.

How Godot creates nodes when running the game

When you run your game or a scene, the engine creates all the nodes required for the game to work based on the scene you run and all the scene instances it contains.
You can visualize this by opening the remote scene tree in the editor when the game runs.
To do so, head back to the editor while the game is running and click the Remote button at the top of the Scene dock.
Remote button in the Scene dock
If we take the space-level scene at the end of module 5, we can see it contains an instance of the ship, the random item placer, and the space background.
Remote scene tree
In the remote scene tree, we can expand the scene instances to see that all the nodes from their respective scenes are present at runtime and merged into a single node tree. Also, more nodes appear as the random item placer creates them.
Remote scene tree expanded

In which order Godot adds nodes to the scene tree

The tree of all the nodes in the game is called the scene tree. It's a hierarchy of nodes starting with the game window node (a viewport) that the engine automatically creates for us at the root. This node represents the game window and contains all the other nodes in the game.
Scene tree with root window node
Am I limited to one window node?
No, you're not! You can have as many viewports and window nodes as you need in a Godot game or application.
That's how Godot gives you windows that you can pop out of the editor for dual-monitor setups, for example.
That's also how the popular indie game Windowkill works (it's a cool Godot game, you should check it out!).
Screenshot of the game Windowkill
When the game starts, the engine creates all the nodes required for the game to work and adds them to the scene tree.
Creating nodes happens so quickly that even with the remote scene tree, we immediately get a snapshot of the entire game's node hierarchy after creating it.
But the engine creates and adds nodes to the scene tree one at a time, from top to bottom. Parent nodes always get added before their children.
Illustration of the node creation order
So, in the ship's case, Godot creates the nodes in this order:
  • Ship
  • Sprite2D
  • MainThruster
  • GPUParticles2D
  • SideThruster
  • ...
It literally creates them in the order you see nodes in the remote scene tree, from top to bottom.
The order in which Godot calls the _ready() function for each node is different. To understand why, let's first see how we usually use the _ready() function.

How we usually use the _ready() function

The _ready() function is a tool to reliably set up and access child nodes from a script. We used this when connecting the Timer node's timeout signal in the random item placer script.
func _ready() -> void:
	get_node("Timer").timeout.connect(_on_timer_timeout)
The _ready() function guarantees that the Timer node has been added to the scene tree, which is required to get a reference to it and connect its timeout signal.

When Godot calls the _ready() function for each node

Once every node has been added to the scene tree, the engine makes them all "ready" and calls their _ready() function. This time, the order of the function calls is different.
For the _ready() function, Godot first calls the function for children nodes before calling it for their parents. It means that when the engine calls the _ready() function for a given node, it has already called it for all its children.
As it's common for parent nodes to access and run code depending on their children in Godot, this order makes sure that you can put all the code to set up and access children nodes in the _ready() function of any given node.
This technical detail may be confusing now, but it will make more sense as you get more experience with Godot.
For now, remember that the _ready() function is a great place to set up and access children nodes in your scripts, for example, for connecting signals and manipulating variables.
Finally, note that whenever we create a scene instance via code and add it to the scene tree with add_child(), the engine also calls these nodes' _ready() functions.
Precisely, whenever you add a node to the scene tree, the engine calls its _ready() function after adding it.
What if my script doesn't have a _ready() function?
No problem! The engine has a mechanism to check if a script has a _ready() function and only calls it if it does. If the script doesn't have a _ready() function, the engine doesn't call it.

Recap

To wrap this up, let's summarize what we learned in this guide:
  • The _ready() function is a special function recognized by Godot and called when a node and all its children are ready and accessible in the code. It helps ensure nodes are fully initialized before you interact with them.
  • Godot creates and adds nodes to the scene tree at runtime, starting with parent nodes and moving down to their children. Godot adds nodes to the scene tree in the same order you see them in the remote scene tree.
  • The engine calls the _ready() function for child nodes before their parents.
  • Whenever you instantiate a scene at runtime and add it to the scene tree using add_child(), Godot calls the _ready() function for these newly added nodes.
Feel free to revisit this guide to refresh your memory about how Godot creates nodes and when it calls the _ready() function.
We'll use the function a lot in the course, so you'll also see many examples of how to use it in practice to help solidify your understanding.
PreviousNext

Lesson Q&A

Use this space for questions related to what you're learning. For any other type of support (website, learning platform, payments, etc...) please get in touch using the contact form.

  • To simplify the ready function...BoomsquallyI'm an apples and oranges kind of guy, so can we say that using the ready function for a tiny game wouldn't be necessary, but for a large game, the ready function is meant to get the necessary things loaded before the game starts so it doesn't try loading stuff while at the same time running code when you're playing, thus causing possible timing or chugging issues? An analogy would be like: you can't just drive, you need a road, signs, etc. first. Other wise it would be a mess to put down a road while you're driving... Also, would that be the reason why some games have to "load" before you can play? 4 2 Feb. 24, 2024
  • Why not run everything under the _ready() function?high-level-eelSo if the ready function is about ensuring our child nodes are ready to execute before running, why is it that we don't just throw all of our functions under it? Wouldn't it be advantageous to ensure all the code is loaded before running it? 1 0 Jul. 15, 2024
  • Seeking Advice on Scene Script and Signal Management mealy-armadilloAfter finishing this module, I've been practicing on my own and came across a few questions I think the professional could help: 1. When deciding which scene should handle specific functionality, like in the "Loot It All" example, both the ship and health pack can detect `area_entered` and send signals to update the UI. Should this functionality be coded within the ship or health pack, or should I attach a script to the UI or Main and connect signals from either the ship or health pack? 2. For spawning scenes, when using a timer to control the next spawn, is it better to put the timer directly in the spawning scene and control it from the Main scene using `get_node()`, or should I create the timer in the Main scene and use the `timeout` signal to trigger actions in the spawning scene? 3. How can I better organize code when there are many signals, nested signals, and cross references? In my practice, the gameplay works, but the code feels unorganized, and the signal connections are hard to trace as they are scattered everywhere. For example, I have signals emitting, calling child node functions, and those functions emitting other signals and calling functions in other nodes. Your insights would be greatly appreciated. Thank you! 5 0 Jul. 03, 2024
  • Is it a typo?mealy-armadillo> Creating nodes happens so quickly that even with the remote same tree, we immediately get a snapshot of the entire game's node hierarchy after creating it. remote ~~same~~ tree -> remote scene tree 1 0 Jul. 01, 2024
  • In what order does Godot run the _ready() functions for the children of a root node?leafFor our case in this workbook... We have the *Level* node and its children, *Ship*, *SpaceBackground*, and *RandomItemPlacer*. In what order would Godot call the `_ready()` functions of these children, before moving to the root node? Or are the children's `_ready()` functions all called simultaneously? While reading the text, it sounds to me like they are all called simultaneously, and then Godot immediately moves over to the root node and then calls its `_ready()` function. 1 0 Apr. 28, 2024
  • Does the _process() function starts executing the same time as the _ready() function?unhappy-dolphinFor the _process() function, dose it wait the _ready() function to execute fully before it can starts? I tried using the below example and found out that the _process function starts before the _ready() function fully executed. Is it because I created a timer and awaited it? or do they start in parallel? ```gdscript func _ready() -> void: await get_tree().create_timer(3).timeout #Do something func _process(delta: float) -> void: #Do something ``` 1 0 Feb. 25, 2024
Site is in BETA!found a bug?