Físicas en Godot 4: Entendiendo el Game Loop y los nodos de colisión

Al empezar con Godot, y viniendo del desarrollo de software tradicional, uno de los conceptos que más cuesta interiorizar es el Game Loop (el bucle del juego) y cómo el motor gestiona las actualizaciones en cada frame.

En los primeros módulos de la formación que estoy siguiendo, el movimiento básico siempre lo programábamos dentro de la función _process(). Sin embargo, al llegar al módulo de movimiento Top-Down y empezar a lidiar con colisiones reales y obstáculos, la regla cambió: todo el código debía moverse a _physics_process().

He querido dejar plasmada esta diferencia en mi cuaderno devBitácora, junto con una pequeña guía rápida de nodos, para tenerlo claro a medida que el proyecto escale.

_process() vs _physics_process()

A nivel de código, la diferencia parece sutil, pero su comportamiento por debajo es totalmente distinto:

• _process(delta): Se ejecuta en cada frame renderizado. Esto significa que si el juego va a 144 FPS, esta función se llama 144 veces por segundo; pero si hay una caída de rendimiento y baja a 30 FPS, se llamará 30 veces. Se usa principalmente para actualizar temporizadores, animaciones o la interfaz, usando el parámetro delta (el tiempo transcurrido desde el último frame) para que el comportamiento sea homogéneo independientemente del hardware.
• _physics_process(delta): Se ejecuta a un intervalo de tiempo fijo (por defecto, 60 veces por segundo en Godot). Al estar sincronizado con el motor de físicas, garantiza que los cálculos de colisiones sean consistentes, deterministas y no se rompan si el framerate del jugador fluctúa.

# Ejemplo de movimiento gestionado por físicas
func _physics_process(delta: float) -> void:
    var direction := Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")
    velocity = direction * speed
    move_and_slide()

Guía rápida de Nodos Físicos en Godot 2D

En Godot, la física utiliza una filosofía orientada a objetos donde debes elegir (o heredar de) el nodo físico correcto según el comportamiento que esperes.

Repasando las notas, así es como he categorizado los cuatro principales para tener claro cuándo usar cada uno:

1. Area2D: No gestiona colisiones reales (los objetos lo atraviesan), pero detecta solapamientos. Es el nodo que utilizo para triggers: detectar si el jugador entra en una zona, si recoge un objeto o para programar las hitboxes de las balas.
2. StaticBody2D: La opción por defecto para paredes, suelos y obstáculos. Como su nombre indica, no se mueve (aunque existe la variante AnimatableBody2D si necesitas hacer plataformas móviles).
3. RigidBody2D: Es el nodo que le cede el control al motor de físicas de Godot. Simula físicas del mundo real: gravedad, rebotes, impulsos y fricción. Útil para elementos dinámicos del escenario, cajas que se pueden empujar o escombros.
4. CharacterBody2D: El punto intermedio perfecto para el jugador y los enemigos. Detecta colisiones (evitando que atravieses el StaticBody2D de una pared), pero no está gobernado por las físicas reales. El movimiento se controla estrictamente por código (mediante la función move_and_slide()), lo que da un control total y preciso, sin inercias inesperadas.

Entender qué hace cada bucle y elegir el nodo correcto desde el principio me está ahorrando muchos dolores de cabeza a la hora de refactorizar el código de los personajes.