🎮 El Game Loop en Blender Game Engine (BGE)
Si estás leyendo esto, lo más probable es que estés pensando en crear un juego.
El Range Game Engine, UPBGE o incluso el antiguo Blender Game Engine (BGE) es una gran plataforma para hacerlo 🚀.
Esta guía debería ayudarte a entender cómo funciona el motor de juegos y, en consecuencia, cómo funciona tu juego internamente.
Hay una cosa que todo juego tiene:
🔁 EL GAME LOOP
¿Qué es el Game Loop?
El Game Loop (o bucle del juego) es el corazón de cualquier videojuego.
Es un ciclo que se ejecuta constantemente mientras el juego está activo y se encarga de que todo funcione, se actualice y se renderice en tiempo real.
En términos simples:
👉 el game loop es lo que hace que el juego “esté vivo”.
¿Qué hace el Game Loop?
En cada iteración (cada “vuelta” del ciclo), el game loop suele realizar estas tareas, en este orden lógico:
-
🎮 Leer la entrada del jugador (Input)
Teclado, mouse, control, pantalla táctil, etc. -
🧠 Actualizar la lógica del juego (Update)
-
Movimiento de personajes
-
IA de enemigos
-
Colisiones
-
Estados del juego
-
Lógica de scripts y logic bricks
-
-
🎨 Renderizar la escena (Render)
-
Dibujar modelos 3D
-
Aplicar shaders
-
Iluminación
-
Efectos visuales (como Lens Flare, Bloom, etc.)
-
-
⏱ Controlar el tiempo (Timing)
Mantener una velocidad estable (FPS) para que el juego no dependa de la potencia del hardware.
Este ciclo se repite decenas de veces por segundo.
Entender estos conceptos te ayudará a explicar muchos de esos comportamientos “misteriosos” que probablemente hayas notado alguna vez 🤔.
🔄 El Game Loop
Cada ciclo dentro del Game Loop representa un frame lógico, también conocido como logic tick.
Este es el intervalo de tiempo más pequeño dentro de tu juego.
Cada ciclo realiza los siguientes pasos:
1️⃣ Las escenas son procesadas
2️⃣ Los dispositivos de entrada son revisados
3️⃣ La imagen final es renderizada
⚠️ Es importante saber que el render puede ser omitido si el frame anterior consumió demasiado tiempo de procesamiento (lag).
Existe un límite de renders que pueden ser omitidos (por defecto = 5).
Si este límite se supera, el render se ejecutará sin importar cuánto tiempo tome.
Este tipo de render lag provoca logic lag, haciendo que el juego se ejecute más lento de lo esperado 🐌.
🎬 El Scene Loop (Ciclo de Escena)
Este ciclo es un poco más complejo.
El Scene Loop recorre todas las escenas activas y ejecuta los siguientes pasos para cada escena:
1️⃣ Evaluación de sensores
2️⃣ Ejecución de controladores
3️⃣ Ejecución de actuadores
4️⃣ Actualización de físicas
5️⃣ Reproducción de sonido 🔊
Los pasos 1 al 3 conforman el concepto SCA (Sensors, Controllers, Actuators), que es lo que configuramos como Logic Bricks.
👉 Este orden es muy importante. Tenlo siempre en mente:
- Nunca verás un controlador ejecutarse antes de que un sensor sea evaluado
- Nunca verás un actuador ejecutarse antes de que todos los controladores hayan sido ejecutados
- La actualización de físicas ocurre después de los actuadores, pero antes del render
🧩 SCA – Sensores
Los sensores activos siempre son evaluados, sin importar los parámetros que se les asignen.
No existe ningún parámetro que evite que un sensor sea evaluado en cada frame.
Un sensor es considerado activo si:
- Está conectado a un controlador
- Y ese controlador pertenece a un estado activo
Si un sensor no está conectado a un controlador en un estado activo, no será evaluado.
Esto es muy útil cuando quieres desactivar sensores “pesados”, como Ray o Radar, para ahorrar recursos ⚡.
Dependiendo de sus parámetros, los sensores evaluados disparan los controladores conectados.
🧠 SCA – Controladores
Todos los controladores disparados son ejecutados, sin importar si el estado del sensor es True o False.
⚠️ Solo los controladores disparados se ejecutan.
No existe forma de ejecutar un controlador si no ha sido activado por un sensor.
Por esta razón, elegir correctamente los sensores es fundamental.
Los controladores ejecutados envían señales de:
- Activación
- Desactivación
a los actuadores conectados, dependiendo de la entrada del sensor.
⚙️ SCA – Actuadores
Los actuadores reciben señales de activación o desactivación desde los controladores.
Sin embargo, recibir una señal no significa necesariamente que el actuador se active o desactive.
Su comportamiento depende de:
- El tipo de actuador
- Sus parámetros internos
La duración de un actuador activo varía:
- Algunos se desactivan en un solo frame
- Otros esperan una señal de desactivación
- Otros permanecen activos hasta terminar su acción, ignorando la desactivación
🐍 Python dentro del sistema SCA
El sistema SCA es un sistema de eventos muy eficiente, ya que separa:
- Los eventos
- De las tareas resultantes
Esto permite ejecutar tareas costosas solo cuando es necesario.
La interfaz gráfica de Blender facilita mucho la configuración de la lógica, pero por su naturaleza:
- Está limitada a estados True / False
- Y a señales de Activación / Desactivación
Para mayor flexibilidad, se puede usar Python como Logic Brick, disponible únicamente como controlador.
Con esto puedes:
- Crear controladores personalizados
- Ejecutar tareas que normalmente harían los actuadores
- Cambiar el estado actual del juego
⚠️ Importante:
El código Python se ejecuta antes de que los actuadores corran, ya que los controladores se ejecutan primero dentro del Scene Loop.
⏳ Nota importante sobre el procesamiento
Algunos cambios no se aplican inmediatamente, por ejemplo:
- Eliminar objetos
- Cambiar de escena
Estos cambios se colocan en una cola y se procesan más tarde, lo cual puede causar confusión si no se conoce este comportamiento.
🚀 Rendimiento y buenas prácticas
✔️ El código Python debe ejecutarse lo más rápido posible
❌ Código largo provoca lag
❌ Bucles infinitos congelan el juego
Es mejor no ejecutar un controlador, que ejecutar uno que no hace nada.
⚠️ El controlador Python es el más pesado en términos de rendimiento.
Úsalo solo cuando sea necesario.
Los Logic Bricks suelen ser más rápidos que Python, por lo que no es recomendable recrear lógica existente en Python (como un AND o un Motion Actuator).
Python resulta eficiente cuando:
- Un solo script reemplaza múltiples Logic Bricks
- Se validan entradas complejas
- Se realizan acciones agrupadas en un solo paso
🧠 Resumen visual
Finalmente, ambos loops (Game Loop y Scene Loop) pueden representarse en un solo esquema.
🔹 Los shaders no influyen en la lógica ni en las físicas
🔹 La lógica sí influye en los shaders
🎯 Conclusión
Ahora ya sabes cómo se ejecuta el Game Loop en el BGE y qué ocurre en cada etapa.
Esto debería ayudarte a entender qué sucede y cuándo sucede dentro de tu juego.
El camino hacia un buen juego es largo, y espero que esta información te ayude a evitar obstáculos innecesarios en el proceso 🚧➡️🎮.
¡Mucho éxito!
✍️ Créditos
Autor: Monster
Publicado en: www.blenderartists.org
Traducción y adaptación al español con fines educativos y de divulgación.
Leave a Reply