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

joemoejoemoe Posts: 4Member

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?

Best Answer

  • TwistedTwiglegTwistedTwigleg Posts: 2,858
    edited January 14 Accepted Answer

    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!)

Answers

  • TwistedTwiglegTwistedTwigleg Posts: 2,858Admin
    edited January 14 Accepted Answer

    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!)

  • cyberealitycybereality Posts: 926Moderator

    Thanks for that. Also welcome to the forum!

  • SIsilicon28SIsilicon28 Posts: 748Moderator

    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).

  • TwistedTwiglegTwistedTwigleg Posts: 2,858Admin

    @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:

  • joemoejoemoe Posts: 4Member

    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?

  • TwistedTwiglegTwistedTwigleg Posts: 2,858Admin

    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.

Sign In or Register to comment.