Optimización del rendimiento y uso de memoria

Introducción a la optimización en videojuegos 2D

A lo largo de los módulos anteriores has construido un videojuego de plataformas 2D completamente funcional: tu personaje corre, salta, combate enemigos, recoge monedas, escucha música y navega por distintos niveles mediante transiciones pulidas. Sin embargo, un juego que funciona de forma impecable en un ordenador de desarrollo potente puede sufrir tirones, caídas de fotogramas o cierres inesperados al ejecutarse en equipos más modestos, consolas portátiles o dispositivos móviles. Aquí es donde entra en juego la optimización: el conjunto de técnicas orientadas a hacer que nuestro software consuma la menor cantidad posible de recursos (procesador, tarjeta gráfica y memoria RAM) manteniendo una experiencia visual fluida y estable.

Optimizar no consiste en transformar todo el código en fórmulas matemáticas crípticas desde el primer día ni en obsesionarse antes de tiempo. En el desarrollo de software existe un aforismo clásico atribuido a Donald Knuth: «la optimización prematura es la raíz de todos los males». Si intentas optimizar cada línea de código antes de comprobar si el juego realmente sufre ralentizaciones, perderás tiempo valioso y harás que tu proyecto sea más difícil de leer y mantener. El enfoque profesional consiste en escribir código limpio, ordenado y estructurado, identificar con precisión dónde están los cuellos de botella mediante herramientas de diagnóstico, y aplicar correcciones específicas donde verdaderamente existan pérdidas de rendimiento o consumo desmedido de memoria.

Métricas clave de rendimiento: FPS del juego versus FPS reales

Para medir el rendimiento de un juego en GameMaker, el primer indicador en el que nos fijamos suele ser la tasa de fotogramas por segundo (Frames Per Second o FPS). No obstante, dentro del motor existe una distinción crucial entre dos variables integradas que todo creador debe comprender con exactitud: la velocidad objetivo del juego y la velocidad real de procesamiento.

La velocidad del juego (representada históricamente por room_speed y configurada actualmente en GameMaker como la velocidad de actualización de la room, típicamente a 60 FPS) define cuántas veces por segundo se ejecutan los eventos de lógica (Create, Step, etc.) y dibujo. Por otro lado, la variable interna fps_real representa cuántos ciclos por segundo podría ejecutar tu ordenador si GameMaker no estuviese limitado artificialmente a la tasa de refresco del monitor o a los 60 cuadros programados. Si tu juego corre a 60 cuadros estables, la variable fps devolverá 60, pero fps_real podría marcar 450, 1200 o 3000, indicando que el procesador dispone de un margen holgado de tiempo libre entre fotograma y fotograma.

Cuando el valor de fps_real desciende por debajo de 60, el motor ya no dispone de tiempo suficiente dentro de la fracción de segundo (16.66 milisegundos a 60 Hz) para completar toda la lógica y el renderizado. Como consecuencia inmediata, la variable fps caerá, el juego se ralentizará visualmente y los controles responderán con retraso (input lag).

Gestión de memoria y fugas de recursos (Memory Leaks)

Uno de los problemas más graves en el desarrollo de videojuegos no es la lentitud visual instantánea, sino la degradación progresiva: un juego que arranca fluido, pero tras jugar 10 minutos se congela o colapsa el sistema operativo. Este fenómeno suele deberse a una fuga de memoria (Memory Leak). Una fuga de memoria ocurre cuando reservamos un espacio de memoria dinámica para almacenar datos o recursos, pero olvidamos destruirlo o liberarlo cuando ya no lo necesitamos. El sistema continúa acumulando esa basura en la memoria RAM hasta agotar la capacidad disponible.

GameMaker cuenta con un recolector de basura (Garbage Collector) automático para variables estándar, arrays convencionales y structs de GML. Sin embargo, existen recursos que operan de forma manual a bajo nivel y que el recolector de basura NO liberará automáticamente. Eres tú, como programador, quien tiene la responsabilidad absoluta de destruirlos cuando su ciclo de vida termine.

Analicemos un error típico muy común entre desarrolladores principiantes: crear una estructura de datos dentro de un evento repetitivo como el evento Step o el evento Draw sin destruirla en ese mismo bloque, o crearla en el evento Create sin destruirla en el evento Clean Up o Destroy.

// ========================================================
// OBJETO: obj_inventario
// EVENTO: Create
// ========================================================
// Creamos una lista dinámica para registrar los objetos recogidos
lista_items = ds_list_create();
ds_list_add(lista_items, "Espada de madera");
ds_list_add(lista_items, "Pocion de salud");


// ========================================================
// OBJETO: obj_inventario
// EVENTO: Clean Up
// ========================================================
// Verificamos si la lista existe antes de destruirla para evitar errores
if (ds_exists(lista_items, ds_type_list)) {
    ds_list_destroy(lista_items);
}

💡 Regla de oro de la memoria: Por cada función con la palabra create que uses para estructuras de datos, superficies o emisores de partículas, debe existir una función con la palabra destroy o free correspondiente en el evento Clean Up de ese objeto.

Optimización de la GPU: Páginas de texturas y llamadas de dibujo (Draw Calls)

Al renderizar un juego 2D, el procesador (CPU) envía instrucciones a la tarjeta gráfica (GPU) sobre qué dibujar en la pantalla. Cada instrucción o paquete de instrucciones que la CPU envía a la GPU se conoce como una llamada de dibujo o «Draw Call». Cuantas más llamadas de dibujo independientes deba procesar el hardware por fotograma, más se saturará el canal de comunicación entre la CPU y la tarjeta gráfica.

GameMaker optimiza esto internamente mediante una técnica llamada «Batching» (procesamiento por lotes). Si tienes 200 monedas en pantalla que comparten la misma imagen o provienen de la misma página de texturas, GameMaker no envía 200 órdenes individuales a la tarjeta gráfica; las agrupa en un único paquete y le dice a la GPU: «Dibuja estas 200 monedas de golpe». Esto consume apenas una sola llamada de dibujo.

Sin embargo, el procesamiento por lotes se rompe (se interrumpe) cada vez que ocurre un cambio de estado en la GPU. Los motivos más frecuentes por los que se rompe un lote son: 1. Cambiar de textura: Cuando el siguiente sprite que se debe dibujar pertenece a una página de texturas diferente (Texture Swap). 2. Cambiar de modo de fusión: Usar gpu_set_blendmode(bm_add) para efectos de iluminación o brillo y luego volver a bm_normal. 3. Activar o desactivar shaders o cambiar de superficie (surface).