• Tutorials

  • Is there a graphic or explanation of the order of events that happen in the Godot game loop?

I just recently had an issue where two signals did not fire on the same frame and that was due to an objects physics_process function being called before another objects methods were being called (I assume). Basically a move_and_slide was called which moved the position of the target object which then made the signal I thought would fire, not fire from another object.

What I learned from this is that I don't know the order of operations that happen in the loop. In order for me to get a grasp of potential issues or to properly program interactions between two objects I need a better understanding of this. I tried looking in Godot's tutorials and only found the Main Loop documentation but that doesn't really give me a good idea of objects inside the loop: https://docs.godotengine.org/en/3.1/classes/class_mainloop.html

Is there a document or resource I missed that fully illustrates the order of events that happen on each frame to show the order in which each objects are executed in?

For example, in this tree structure:

  • World
  • - Player
  • - Enemy

Which objects have their methods called first and in which order (including signals) do they execute in?

Based on my own observations using Godot, not based on the source code, but I wrote a brief overview of how Godot typically operates and the order things are called in:

1: Godot engine initialization and scene loading

2: The root node of the scene has _ready called

2.1: Then all of the children nodes of the root have _ready called from top to bottom, depth first style, one node at a time. For example, say you have the following node tree:

  • Scene_Root
  • * Level
  • Key
  • Door
  • * Player
  • * Enemy

In this example, the _ready function will be called in the following order: Scene_Root -> Level -> Key -> Door -> Player -> Enemy

If you instance a node in _ready, I believe it will be called after all of the other children. For example, if in Level you spawn a scene called Button, it will be called after _ready is called in Door.

Edit: See comment by @SIsilicon28 below! The order described above is backwards/opposite of how it works in Godot.

3: Start of game loop. The steps 4-6 will be called until the game is told to quit.

4: Input is queued and placed into _input and the Input singleton is updated.

5: _process is called every frame for every object. It is called in the same order as _ready.

5.1: I do not remember if signals are called after _physics_process or as soon as they are called. I think when you emit a signal, the function attached to that signal is called instantly, but I might be wrong.

Edit: 5.2: The order _process is called in can be changed by calling set_process_priority

6: _physics_process is called every physics frame, which is set to 30 FPS by default (the game renders at 60 FPS by default). The order is the same as detailed in _ready.

6.1: I could be wrong on this, but I believe the physics actually updates after _physics_process is called. This is so you can set physics properties on the nodes and then have them update.

7: any queue_free calls, or anything else queued, is called at this point. Any nodes deleted using queue_free are freed from memory and the cycle begins anew, starting at step 4. This process continues until the game receives an exit/shut-down event.

7.1: Scenes changed also happen in this step. In this case, all of the nodes are notified of the change in the same order as in _ready, and are deleted (if necessary) in the same order.

8: When the game is shut down, all nodes have their cleanup function called. It can be accessed using _notification, and it is called in the same order as _ready.

8.1: It should be noted that _notification gets called several times, based on what has happened to the node and the type of notification passed. I have not used _notification very much myself, so I'm not 100% sure where it fits into the process.

9: Godot frees engine resources and shuts down.

I wrote all of this from memory and I have not looked into the source code to confirm this order, so please take it with a grain of salt. That said, hopefully this helps explain the order that Godot uses.

(Also: Welcome to the forums!)

About the _ready function. I'm pretty sure it goes the opposite direction. Sort of. It's normally called whenever all the children of a node are ready too. So in your example it would be more like.

Key -> Door -> Level -> Player -> Enemy -> Scene Root Notice how Level's ready function gets called only after it's children have done it too. So _ready actually gets called going up the scene hierarchy.

Also, it might be fun to know that the order in which _process is called can change with the function set_process_priority(int).

@SIsilicon28 said: About the _ready function. I'm pretty sure it goes the opposite direction. Sort of. It's normally called whenever all the children of a node are ready too. So in your example it would be more like.

Key -> Door -> Level -> Player -> Enemy -> Scene Root Notice how Level's ready function gets called only after it's children have done it too. So _ready actually gets called going up the scene hierarchy.

Good to know! I was just writing from memory and I couldn't remember if which order it was in. This actually makes a lot more sense, because often the parent node needs the child node(s) to be ready so it can use them.

Also, it might be fun to know that the order in which _process is called can change with the function set_process_priority(int).

Interesting! I actually didn't know about this function. That would definitely change the process up a bit :smile:

Awesome, thanks.

Another question about the order of functions called. What is the priority of 2 signals that get called on the same frame?

Is it the order in which you connect them in Godot or does Godot have a set order of operations for things to check.

For example: if you connect an on_area_entered and on_body_entered and those two were the same size and position, which order would they fire in? Is it the order in which you connect them in your code (if doing it programmatically) or does it follow a consistent order all the time?

I believe different signals are called in the order of occurrence of the events, where whatever event happened first is called first. From what I remember, signals are called as soon as the event is registered. For multiple nodes attached to the same signal, I believe they are called in the order they were connected (the first node connected gets called first, the last signal connected is called last). That said, I have not looked at the source code to confirm.

In the case of an Area node with both on_area_entered and on_body_entered signals where both objects were placed at exactly the same time, I do not know which would be called first. Probably whichever is defined first in the C++ source code, though it is equally likely that the GDScript connection order decides. I haven't really had a situation where the signal timing was crucial, so I haven't done much research into it.

If I had to make a guess, I would say the order is defined in C++, and probably on_body_enter is called first, but that is totally just a guess on my part.

2 years later

Is this documented anywhere? Were there changes in this in Godot 4? Currently porting a Godot 3 project to 4, and I'm finding stuff that is firing _ready() not when I expect it to, based on Godot 3...

The way ready is called is that each child is initialized first (from the lowest branch in the tree, but going down from the top), then once all of them are ready, the direct parent is ready, and it continues recursively up the chain until all objects are initialized and then your root node becomes ready. I just tested it, and it has not changed from 3.x to 4.0.

Thanks, I just found out the issues were due to something else, but the scene tree order is something worth having an explicit mention in the docs...

11 days later

For accuracy, I must ask: Why isn't _init() included in this? And what about the autoload singleton?

And why are people speculating, when all that's needed is a print() to see the order of things?

Edit:

Signals are just code added to the end of the frame. I'm not adding those, or notifications, because there's so many. If there's a specific order of execution, it needs to be tested on a case-by-case-basis.

There's also a notification for errors.

I did test it, but maybe I got mixed up. Also, you can do this all with one script and just print the node name:

extends Node

func _ready():
	print("I am ready: " + str(name))

Okay, so I've updated my script to include the autoload and notifications.

AutoLoad: init() Main: init() ---- UNKNOWN NOTIFICATION -- NOTIFICATION_PARENTED ---- UNKNOWN NOTIFICATION -- NOTIFICATION_ENTER_TREE AutoLoad: ready() Child1_1: ready() Child1_2: ready() Child1: ready() Child2_1: ready() Child2_2: ready() Child2: ready() ---- UNKNOWN NOTIFICATION Main: ready() ---- UNKNOWN NOTIFICATION ---- UNKNOWN NOTIFICATION ---- UNKNOWN NOTIFICATION ---- UNKNOWN NOTIFICATION ---- UNKNOWN NOTIFICATION Main: process() Main: process() -- NOTIFICATION_PROCESS Child1: process() Child1_1: process() Child1_2: process() Child2: process() Child2_1: process() Child2_2: process() Main: process() Main: process() -- NOTIFICATION_PROCESS Child1: process() Child1_1: process() Child1_2: process() Child2: process() Child2_1: process() Child2_2: process() Main: process() Main: process() -- NOTIFICATION_PROCESS Child1: process() Child1_1: process() Child1_2: process() Child2: process() Child2_1: process() Child2_2: process() Main: process() Main: process() -- NOTIFICATION_PROCESS Child1: process() Child1_1: process() Child1_2: process() Child2: process() Child2_1: process() Child2_2: process() --- Debugging process stopped ---

It's noteworthy that Main's _process runs twice. Why?

print("I am ready: " + str(name))

Or to get the same information with less typing: print_debug(name)