En resumen: una enorme parte de los jugadores está en hardware modesto (laptops, portátiles como la Steam Deck, GPUs más viejas), y un entorno que solo corre en un equipo de gama alta los deja fuera. La buena noticia: la mayor parte del rendimiento de entorno se pierde en unos pocos lugares predecibles (overdraw, draw calls, follaje denso, texturas sobredimensionadas) y se recupera con unos pocos hábitos disciplinados. Este es un playbook práctico para alcanzar un presupuesto de frame bajo sin destripar tu arte, más el método de la cámara fija para atrapar regresiones antes de que salgan.
Este es el tipo de escena más caro de correr: capas de hojas transparentes, miles de instancias, overdraw pesado. También es donde viven las victorias más grandes y fáciles una vez que sabes a dónde va el tiempo de frame.
Fija primero un presupuesto, en milisegundos
Elige un tiempo de frame objetivo en tu hardware soportado más débil (16,6 ms para 60 fps, 33,3 ms para 30) y trátalo como un límite duro. «Optimizar después» significa «reconstruir después»; presupuestar por adelantado es mucho más barato.
La optimización sin un número es solo intuición. Decide el frame que apuntas en tu hardware suelo (la Steam Deck, un laptop medio, cualquiera que sea tu especificación mínima) y conviértelo a milisegundos, porque los milisegundos se suman y los porcentajes mienten. Luego sujeta cada escena a eso mientras construyes, no al final. Los equipos que sacan suave en gama baja no optimizan más duro; simplemente nunca dejan que una escena reviente el presupuesto en primer lugar, lo que cuesta una fracción de arañar el rendimiento de vuelta después de que el arte está terminado y todo depende de él.
Sabe a dónde va el tiempo
El tiempo de frame de entorno lo suele comer el overdraw (follaje transparente), demasiados draw calls (objetos no batcheados), texturas sobredimensionadas (ancho de banda de memoria), e iluminación/sombras caras. Perfila para encontrar TU cuello de botella antes de optimizar a ciegas.
Adivinar optimizaciones desperdicia días. Abre un profiler, encuentra si estás CPU-bound (normalmente draw calls) o GPU-bound (normalmente overdraw, shading o ancho de banda), y ataca el cuello de botella real. Dicho eso, los entornos fallan de formas predecibles, y casi siempre es uno de: overdraw de follaje transparente en capas; draw calls de miles de objetos no instanciados; memoria/ancho de banda de textura de texturas sobredimensionadas o demasiadas; y coste de iluminación/sombra de demasiadas luces dinámicas o shadow maps de alta resolución. El resto de este playbook los recorre en orden de impacto habitual.
Follaje y overdraw: el villano habitual
Las cards de follaje transparente se solapan y re-shadean los mismos píxeles muchas veces: eso es overdraw, y es el asesino número uno de la gama baja. Reduce el solape de cards de hoja, usa LODs agresivos, y culla duro el follaje lejano.
La vegetación densa es donde mueren la mayoría de los presupuestos de frame de gama baja, porque cada card de hoja semitransparente fuerza a la GPU a shadear píxeles que luego dibujará por encima otra vez, a veces diez o más veces por píxel en un dosel espeso. Los arreglos: usa cards de hoja más ceñidas con menos área transparente desperdiciada, cae rápido a LODs más baratos a medida que el follaje retrocede, y fija distancias de cull duras para que la hierba y arbustos lejanos simplemente dejen de dibujar. En una portátil, la diferencia entre «hierba hasta el horizonte» y «hierba cullada a una distancia sensata» puede ser toda la diferencia entre 25 y 40 fps. Bake el follaje a instancias nativas para que la GPU pueda batchearlo, y deja que el instancing del engine haga el trabajo pesado.
Draw calls e instancing
Cada objeto único enviado por separado es un draw call, y miles de ellos atascan la CPU. Instancia meshes repetidos para que cientos de copias cuesten un call; fusiona el clutter estático donde tenga sentido.
Si estás CPU-bound, los draw calls suelen ser por qué. Cada cosa distinta que pides al engine que renderice lleva overhead, y una escena colocada a mano con mil rocas y arbustos individuales ahoga la CPU en coste de envío. El instancing es la cura: meshes repetidos dibujados como instancias colapsan cientos de copias en un solo call, que es exactamente por qué las herramientas de scatter que bakean a instancias nativas del engine importan para el rendimiento: el scatter que parece mil plantas cuesta como un puñado. Donde el instancing no aplica, fusionar clutter estático pequeño en meshes combinados también corta el número de calls. Este es un lugar donde un workflow como el de Numivo (pintar densidad, luego bake a meshes instanciados simples) paga directamente en hardware débil, porque la salida es la cosa barata que la GPU quiere.
No toda escena tiene que ser máximamente densa. Los espacios tranquilos y abiertos cuestan casi nada y dan tanto al hardware como al jugador un descanso: pautar tu densidad es en sí una optimización.
LODs, distancias de cull y tamaños de textura
Da a cada mesh significativo LODs para que las copias lejanas sean baratas, fija distancias de cull para que los objetos diminutos-en-pantalla dejen de dibujar, y limita la resolución de textura a lo que la cámara resuelve a distancia. Estos tres recuperan mucho por poco esfuerzo.
Tres hábitos sin glamur cargan el grueso del presupuesto restante. LODs: los meshes lejanos deberían cambiar a versiones de menor polígono, porque el detalle completo en un árbol de 20 píxeles está desperdiciado. Distancias de cull: cualquier cosa demasiado pequeña en pantalla para notarse debería dejar de renderizar por completo (props pequeños, guijarros, hierba fina), ajustado por tipo de objeto. Tamaños de textura: limita la resolución a lo que realmente es resoluble a la distancia del jugador (ver la lógica de densidad de téxeles: las cosas lejanas necesitan muchos menos téxeles), porque las texturas sobredimensionadas queman ancho de banda de memoria que las GPUs de gama baja no pueden permitirse. Ninguno daña el look cuando se ajusta bien; solo te dejan de hacer pagar por detalle que nadie ve.
Encuentra regresiones con cámaras fijas
Define unas pocas «cámaras de presupuesto» (tu peor vista, el espacio de combate más denso, el interior más ajetreado) y verifica su tiempo de frame en cada build. Los flythroughs aleatorios esconden regresiones; las mismas vistas brutales cada vez las exponen.
El rendimiento se pudre en silencio a medida que se añade contenido, y no lo atraparás vagando por el nivel casualmente. En cambio, fija tu puñado de vistas peores (el mirador de bosque denso, el mercado abarrotado, la pelea cargada de efectos) y mide exactamente esas, en cada build, contra el presupuesto. Cuando un número se pone rojo, sabes que un cambio reciente lo causó, y aproximadamente dónde. Esta es la diferencia entre un equipo que descubre una crisis de rendimiento al final y uno que arregla una regresión de 2 ms el día que aparece. En objetivos de gama baja, haz que una de esas cámaras corra en la Steam Deck real o la máquina de spec mínima, no solo una estimación de editor.
Cifras de campo que vale la pena robar
- Presupuestos de frame: 16,6 ms (60 fps) / 33,3 ms (30 fps), fíjalo en tu hardware suelo
- El asesino habitual de gama baja: overdraw de follaje (cards más ceñidas, LODs rápidos, cull duro)
- Meshes repetidos → instancias: cientos de copias por un draw call
- Limita el tamaño de textura al detalle resoluble por la cámara: lo lejano necesita muchos menos téxeles
- Atrapa regresiones con cámaras de presupuesto fijas, medidas en cada build
Mini-FAQ
¿Tengo que elegir entre bonito y gama baja? Menos de lo que crees. La mayor parte del coste de gama baja es desperdicio (overdraw, calls no batcheados, texturas sobredimensionadas), no calidad visible. Corta el desperdicio y el arte sobrevive; los jugadores en hardware débil rara vez echan de menos el detalle por el que pagabas pero que no podían ver.
¿La iluminación dinámica está prohibida en Steam Deck? No prohibida, pero presupuestada. Limita el número de luces dinámicas y proyectores de sombra, apóyate en iluminación baked donde la escena es estática, y reserva el coste dinámico para donde importa. Es una línea de presupuesto, no una prohibición.
¿Qué cambio único ayuda más en una portátil? Normalmente domar el follaje: cards de hoja más ceñidas, LODs agresivos y distancias de cull duras en hierba y arbustos. El overdraw es el cuello de botella más común en portátil, y la vegetación es donde vive el overdraw.
¿Qué tan temprano debería probar en el hardware objetivo? Desde el primer vertical slice. Una estimación de editor en una máquina de dev potente esconde exactamente los problemas que tendrá la portátil. Consigue un build en el dispositivo de spec mínima real temprano y mantenlo en el bucle.
Correr en una patata no es hacer feo tu juego, sino no pagar por detalle que los jugadores no pueden ver. Presupuesta en milisegundos, mata el overdraw, instancia las repeticiones, culla lo invisible, y vigila tus peores cámaras en cada build, y tu entorno se verá genial y correrá para la enorme audiencia que no está en un equipo de gama alta.
