¿Por qué los juegos están tan mal optimizados?#

Si juegas con frecuencia, seguramente lo has notado: en los últimos años, muchos títulos han estado “optimizados” de manera desastrosa.

Como últimamente he estado investigando el desarrollo de juegos indie, reuní algunas notas sobre optimización. En este artículo comparto por qué tantos juegos terminan con una mala optimización.

TL; DR#

El tamaño de los juegos y la complejidad de los motores han explotado. Bajo la presión de los plazos, con fe en la nueva tecnología y en que “la próxima GPU lo solucionará”, los equipos a menudo no tratan la optimización continua como una tarea central. Resultado: el hardware no se aprovecha, y aun así el juego se congela.

---

Claro que, si fuera tan simple, no valdría la pena escribir un artículo entero. Primero definamos qué es “mala optimización”.

Optimización#

¿Bajos FPS?

¿Tirones?

¿Red deficiente?

Entonces, ¿qué cuenta realmente como mala optimización?

Cuellos de botella#

El clásico cuello de botella de la GPU—la tarjeta gráfica al 100%, limitando los FPS—ya no es el único ni el más común. Los juegos modernos presentan cuellos de botella diversos y sutiles.

Un culpable muy común es el cuello de botella de un solo hilo de CPU.

Aunque los procesadores modernos tienen muchos núcleos, bucles centrales del motor—física, IA, gestión de recursos, envío de draw calls—siguen atados a un hilo principal o de renderizado.

El uso global de CPU en el Administrador de Tareas es engañoso, pues promedia todos los núcleos. Si ese hilo crítico llega al 100% en su núcleo, toda la tubería espera, aunque los demás núcleos estén ociosos.

Es como una autopista de ocho carriles con uno bloqueado: aunque los demás estén libres, la eficiencia general cae en picado. Puedes ver solo 25% de uso total, pero los FPS ya topados y tirones por retraso en comandos.

---

La latencia de memoria y caché es otro asesino silencioso.

El rendimiento fluido depende del flujo eficiente entre RAM, cachés de CPU (L1/L2/L3) y VRAM. Si los datos no llegan a tiempo, CPU/GPU se detienen, desperdiciando ciclos.

Ejemplo: memoria sin XMP/EXPO activado en BIOS, o patrones de acceso a datos ineficientes.

---

También existen cuellos de botella de I/O y almacenamiento.

Con mundos cada vez más grandes, cargar texturas y modelos desde HDD/SSD en tiempo real afecta directamente la experiencia—crítico en mundos abiertos. La velocidad de lectura/escritura del disco marca la diferencia entre carga fluida y tirones.

Stutter de recorrido#

El stutter de recorrido es muy común en mundos abiertos o semiabiertos.

Al moverse rápido a nuevas áreas, aparecen congelamientos breves o caídas súbitas de FPS.

Técnicamente se debe a sistemas de streaming de niveles o particionamiento de mundos. Para encajar mundos enormes en memoria limitada, el motor carga y descarga recursos según la posición del jugador.

Si la carga es lenta o choca con el hilo principal, el render debe esperar a texturas, geometrías o scripts, causando tirones.

(El peor que me pasó fue con Starfield—incluso al cambiar un valor en el creador de personaje se congelaba. Sorprendente.)

Compilación de shaders#

Entre todos los tirones, el de compilación de shaders es de los más frustrantes para PC, porque ocurre incluso con hardware de primera.

Los shaders son pequeños programas en la GPU que definen color, luz, sombras, reflejos, transparencia. Compilar los convierte en código máquina específico del GPU.

El problema: consolas vs. PC.

Consolas (PS5, Xbox Series X/S) tienen hardware fijo. Los devs precompilan todos los shaders y los incluyen en el juego. Al jugar, la GPU los ejecuta directamente.

En PC hay miles de GPUs distintas (NVIDIA/AMD/Intel). No se puede distribuir un binario único. Se envía bytecode, y el driver lo traduce en tiempo real al código máquina—eso es la compilación.

(Entre bytecode y máquina, ya entienden 🤔)

---

Con APIs antiguas (DirectX 11), los drivers manejaban gran parte de esto, pero mal. Con DirectX 12 y Vulkan, la carga cae en los desarrolladores.

Deben declarar Pipeline State Objects (PSO) y, si no precompilan durante pantallas de carga, la primera vez que aparece un efecto o enemigo se compila en vivo—bloqueando el render por decenas o cientos de ms, causando un tirón inevitable.

(The Callisto Protocol es ejemplo famoso; algunos incluso editaban archivos para forzar precompilación.)

Mentalidad de consolas#

Cuellos de botella de CPU, stutter de recorrido y compilación de shaders comparten raíz:

Un pipeline centrado en consolas.

El diseño gira en torno a hardware fijo de consolas, subestimando la diversidad, drivers y APIs de PC. Así, la versión PC se trata al final y con pocos recursos.

El resultado: lanzamientos con defectos básicos, parches “post-lanzamiento” normalizados, QA transferido al jugador. El ciclo se repite y la optimización en PC cae.

Entonces, ¿qué es mala optimización?#

En breve: hitches repentinos y mal uso del hardware. Si CPU/GPU están bajos pero el juego tartamudea, eso es mala optimización.

(Los problemas online son distintos; a menudo no es “servidor patata” sino lógica cliente-servidor mal diseñada.)

Unreal Engine 5#

UE5 trae Nanite y Lumen, que prometen fidelidad casi de CG.

Pero el costo de rendimiento es alto. UE5 ha cambiado el balance entre calidad y FPS.

Nanite#

Resuelve el presupuesto de polígonos. Automatiza los LOD y permite usar modelos de millones de tris.

Pero no es gratis: tiene sobrecarga. En escenas ya bien optimizadas, usarlo puede empeorar el rendimiento. Su fuerza es densidad extrema; en escenarios simples, no conviene.

Limitaciones: soporte experimental para esqueletos, no soporta transparencias bien, y depende de SSD rápidos.

Lumen#

GI y reflejos totalmente dinámicos.

Antes, la luz indirecta se horneaba en lightmaps (rápido pero estático). Lumen calcula rebotes infinitos en tiempo real, logrando gran realismo.

Epic apunta a 30/60 FPS en PS5/XSX, a resoluciones internas de 1080p y escalado a 4K con TSR.

Modos:

• RT por software: rápido pero menos preciso.
• RT por hardware: usa núcleos dedicados de RTX/RDNA2+, mayor calidad y costo.

Escalado#

Con Nanite + Lumen, lograr 1440p/4K y 60 FPS ya requiere escalado.

¿Insistir en resolución nativa es necio, o es mejor aceptar el diseño basado en upscaling?

DLSS / FSR#

El escalado (DLSS de NVIDIA, FSR de AMD) es ineludible.

¿Es una muleta que oculta mala optimización o motor de la nueva generación?

Necesidad#

Antes, eran para PCs de gama baja. Ahora son asunción de base. Incluso con hardware tope, muchos AAA solo van fluidos con DLSS/FSR.

Estudios como los de Remnant II ya diseñan con escalado en mente. El objetivo: 60 FPS con DLSS/FSR en modo calidad, no nativo.

Realidad#

En la práctica, muchos sienten que se abusa de ellos como cortina para mala optimización. En vez de invertir en ajustes nativos, basta con integrar DLSS/FSR.

Aunque se promete “sin pérdida”, en movimiento surgen defectos:

• Ghosting/trailing: bordes de objetos en movimiento generan estelas.
• Pérdida de detalle y suavizado: al reconstruir desde menos píxeles, se pierden texturas finas, aparece efecto “acuarela”.

Para muchos, es un pacto faustiano: más FPS a cambio de calidad visual y respuesta.

(DLSS 4 mejora, pero vender FPS de DLSS como “upgrade de potencia” es atrevido.)

Personas#

Los juegos los hacen y juegan personas. El problema raíz de optimización en PC está en la economía y producción AAA.

Coste#

Los AAA ya rivalizan con Hollywood. Hoy 200–300 M USD son normales; con marketing, hasta 500 M–1 B.

Esto ata lanzamientos a trimestres fiscales y temporadas. Retrasar cuesta millones y golpea acciones. Resultado: se prioriza fecha sobre calidad técnica.

Crunch#

Cuando plazos y realidad chocan, surge el crunch: semanas de 80–100h. Está normalizado.

La optimización es trabajo lento: perfilar, refactorizar, ajustar algoritmos. En crunch, se pospone hasta que no queda tiempo.

Y muchos problemas son arquitectónicos—imposibles de arreglar en semanas.

Basura#

Un AAA mal optimizado no es solo técnica; es fallo de planificación y organización.

Marketing vende sueños imposibles con fecha fija. Desarrollo no puede cumplir. El resultado: crunch, sacrificio de optimización de PC, y un producto incompleto.

Los parches día uno y actualizaciones solo desplazan QA a los jugadores. El modelo de precompra + live service no castiga esto—lo incentiva. Ingresos asegurados antes de que se descubra la verdad. Promesas de “arreglar luego” son PR vacío.

El sistema permite a compañías lanzar basura cibernética sin consecuencias inmediatas.

Conclusión#

“Mala optimización” no debería ser tu primera impresión de un juego. Lo que importa es que sea divertido. Si la optimización se vuelve el tema central, es señal de lo mal que estamos.

El arte visual es un plus, no la base. Jugábamos clásicos de 8 bits durante días—¿era por gráficos? Outer Wilds tiene estilo caricaturesco y fue aclamado—¿por gráficos?

El juego vive o muere por la diversión.

(La optimización debe empezar desde el inicio del proyecto. Muchos creen que es tarea final, pero después es imposible arreglarlo solo con parches—basta ver ejemplos como Project Zomboid o Escape from Tarkov.)