Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Notificaciones en Godot

Cada Object en Godot implementa un método _notification. Su propósito es permitir que Object responda a una variedad de callbacks a nivel de motor que puedan estar relacionados. Por ejemplo, si el motor le debe decir a un CanvasItem que tiene que "dibujar", este llamará a _notification(NOTIFICATION_DRAW).

Algunas de estas notificaciones, como draw, son útiles para anular en scripts. Incluso Godot expone muchos de estos con funciones dedicadas:

  • _ready(): NOTIFICATION_READY

  • _enter_tree(): NOTIFICATION_ENTER_TREE

  • _exit_tree(): NOTIFICATION_EXIT_TREE

  • _process(delta): NOTIFICATION_PROCESS

  • _physics_process(delta): NOTIFICATION_PHYSICS_PROCESS

  • _draw(): NOTIFICATION_DRAW

Lo que los usuarios pueden no entender es que las notificaciones existen para otros tipos aparte de Node, por ejemplo:

Y muchos de los callbacks que existen en Nodes no tienen ningún método dedicado, pero son igualmente útiles.

Se puede acceder a todas estas notificaciones personalizadas desde el método universal _notification().

Nota

Los métodos en la documentación etiquetados como "virtuales" también están destinados a ser sobrescritos por scripts.

Un ejemplo clásico es el método _init en Object. Este no posee un equivalente NOTIFICATION_*, pero el motor llamará igual al método. La mayoría de los lenguajes (excepto C#) dependen de este como constructor.

Entonces, en qué situaciones se deben usar cada una de esas notificaciones o funciones virtuales?

_process vs. _physics_process vs. *_input

Utiliza _process() cuando necesitas un delta tiempo dependiente del framerate entre cada frame. Si el código que actualiza los datos de un objeto necesita actualizarlo todas las veces que sea posible, este es el lugar ideal. Lógica recurrente que revisa y cachea datos a menudo se suele ejecutar aquí, pero depende de la velocidad en que se necesitan actualizar cosas, si no se necesita ejecutar en cada frame, se puede implementar un bucle Timer-timeout como otra opción.

# Allows for recurring operations that don't trigger script logic
# every frame (or even every fixed frame).
func _ready():
    var timer = Timer.new()
    timer.autostart = true
    timer.wait_time = 0.5
    add_child(timer)
    timer.timeout.connect(func():
        print("This block runs every 0.5 seconds")
    )

Utiliza _physics_process() cuando necesites un tiempo delta independiente de la velocidad de cuadros entre fotogramas. Si el código necesita actualizaciones constantes a lo largo del tiempo, independientemente de lo rápido o lento que avance el tiempo, este es el lugar indicado. Las operaciones cinemáticas recurrentes y de transformación de objetos deben ejecutarse aquí.

Mientras sea posible, para obtener el mejor desempeño, se debe evitar realizar chequeos de entrada durante callbacks. _process() y _physics_process() se dispararán en cada oportunidad (no "duermen" por defecto). En contraste, el callback *_input() disparará sólamente en los frames que el motor ha detectado realmente una entrada.

Se pueden revisar igualmente acciones de entrada dentro de los callback input. Si se quiere usar el delta tiempo, se puede tomar de los métodos relacionados al delta tiempo.

# Called every frame, even when the engine detects no input.
func _process(delta):
    if Input.is_action_just_pressed("ui_select"):
        print(delta)

# Called during every input event.
func _unhandled_input(event):
    match event.get_class():
        "InputEventKey":
            if Input.is_action_just_pressed("ui_accept"):
                print(get_process_delta_time())

_init versus inicialización versus export

Si los scripts inicializan su propia sub estructura de árbol de nodos, sin una escena, el código debería ejecutarse en _init(). Otras propiedades del inicializaciones independientes del árbol de escenas deberán realizarse aquí también.

Nota

El equivalente en C# al método _init() de GDScript es el constructor.

_init() se dispara antes de _enter_tree() o _ready(). pero después de que un script crea e inicializa sus propiedades. Cuando se instancia una escena, los valores de las propiedades se asignarán de acuerdo a la siguiente secuencia:

  1. Valor de asignación inicial: la propiedad tendr{a asignado su valor de inicialización o su valor por defecto si no es especificado. Si existe un setter, este no será usado.

  2. asignación de ``_init()``: la asignación del valor de la propiedad es reemplazado por cualquier asignación hecha en _init(), disparando el setter.

  3. Asignación de valores eportados: un valor exportado de una propiedad es reemplazado de nuevo por el valor asignado en el Inspector, disparando el setter.

# test is initialized to "one", without triggering the setter.
@export var test: String = "one":
    set(value):
        test = value + "!"

func _init():
    # Triggers the setter, changing test's value from "one" to "two!".
    test = "two"

# If someone sets test to "three" from the Inspector, it would trigger
# the setter, changing test's value from "two!" to "three!".

Como resultado, instanciar un script versus una escena afectará tanto a la inicialización como el número de veces que el motor llamará al setter.

_ready vs. _enter_tree vs. NOTIFICATION_PARENTED

Cuando se instancia una escena conectada a la primer escena ejecutada, Godot instanciará nodos en el árbol (haciendo llamadas a _init()) y construirá el árbol hacia abajo desde la raíz. Esto causa llamadas _enter_tree() en cascada hacia abajo. Una vez que el árbol esté completo, los nodos hoja llaman a _ready(). Un nodo llamará a este método una vez que todos los nodos hijos han finalizado su ejecución. Esto causa una cascada en reversa, hacia arriba hasta la raíz del árbol.

Cuando se instancia un script o una escena independiente, los nodos no son agregados al Árbol de Escenas en su creación, por lo que no se activan los callbacks _enter_tree(). En cambio, sólo se produce la llamada _init(). Cuando la escena se agrega al Árbol de Escenas, ocurren las llamadas _enter_tree() y luego _ready().

Si se necesita disparar un comportamiento que suceda cuando los nodos son asignados como hijos a otros, sin importar si ocurre como parte de una escena principal o activa, se puede utilizar la notificación PARENTED. Por ejemplo, aquí hay un fragmento de código que conecta un método de una señal personalizada al nodo padre sin fallar. Esto es útil en nodos centrados en datos que se pueden querer crear en tiempo de ejecución.

extends Node

var parent_cache

func connection_check():
    return parent_cache.has_user_signal("interacted_with")

func _notification(what):
    match what:
        NOTIFICATION_PARENTED:
            parent_cache = get_parent()
            if connection_check():
                parent_cache.interacted_with.connect(_on_parent_interacted_with)
        NOTIFICATION_UNPARENTED:
            if connection_check():
                parent_cache.interacted_with.disconnect(_on_parent_interacted_with)

func _on_parent_interacted_with():
    print("I'm reacting to my parent's interaction!")