Análisis en Profundidad del Sistema Adaptive Performance en el Desarrollo de Juegos Móviles con el Motor Unity

En el ecosistema moderno de desarrollo de juegos móviles, el aumento geométrico de las capacidades de hardware ha allanado el camino para ejecutar en dispositivos portátiles juegos que desafían los límites gráficos. Sin embargo, a diferencia de los sistemas de escritorio o consolas, las plataformas móviles carecen de mecanismos de refrigeración activa (ventiladores o sistemas de refrigeración líquida). En una arquitectura System-on-Chip (SoC), la unidad central de procesamiento (CPU), la unidad de procesamiento gráfico (GPU), los controladores de memoria y los módulos de red se encuentran juntos dentro de un espacio milimétrico.¹ La ejecución continua de estos componentes a altas velocidades de reloj (clock speed) genera inevitablemente una cantidad masiva de calor residual.

Cuando la temperatura del dispositivo alcanza umbrales críticos, el sistema operativo activa un mecanismo de defensa llamado "Thermal Throttling" (Estrangulamiento Térmico) para proteger el hardware de daños físicos y evitar la degradación de la estructura química de la batería.² Este mecanismo reduce de manera repentina y agresiva las frecuencias de reloj de la CPU y la GPU. Para los desarrolladores de juegos, esto significa una caída repentina en el número de fotogramas por segundo (FPS), un aumento en el retraso de entrada (input lag) y una degradación total de la experiencia del jugador.³ Justo en este punto entra en juego el sistema Unity Adaptive Performance (Rendimiento Adaptativo), que actúa como un puente entre el software y el hardware con el objetivo de que el motor del juego se adapte de forma proactiva a la dinámica térmica del dispositivo. Este informe examina, con una profundidad académica y profesional, la arquitectura básica del paquete Adaptive Performance, sus algoritmos de escalado, las estrategias de integración y las ventajas de optimización que proporciona, comenzando por la anatomía de las advertencias de configuración que se encuentran frecuentemente durante el proceso de desarrollo.

Causas Raíz y Soluciones de Configuración de la Advertencia "Adaptive Performance Settings"

Cuando se inicia un nuevo proyecto móvil en el motor de juego Unity o cuando se configura un proyecto existente para ser compilado en plataformas móviles (Android, iOS), suele aparecer en la pantalla de la consola el siguiente mensaje o una variante del mismo: "No Adaptive Performance provider package installed. Adaptive Performance requires a provider to get information during runtime. Please install a provider such as Adaptive Performance Samsung (Android) from the Adaptive Performance Settings".⁴ La causa fundamental detrás de esta advertencia que detiene los procesos de desarrollo de los desarrolladores es el principio de funcionamiento del sistema de gestión de paquetes modular de Unity y de su capa de abstracción de hardware (Hardware Abstraction Layer).

Unity incluye el paquete básico de Adaptive Performance preinstalado (pre-installed) en el proyecto, especialmente cuando se crean proyectos con plantillas como "Mobile 2D", "Mobile 3D" o "Universal Render Pipeline (URP)".⁵ Sin embargo, el paquete básico no posee por sí solo las bibliotecas nativas (native) capaces de leer datos del hardware del dispositivo o de interferir con el sistema operativo. Para que el paquete se vuelva funcional, es necesario añadir y configurar en el proyecto un módulo "Provider" (Proveedor) específico para el sistema operativo de destino (Android, etc.) o para el entorno de prueba.⁶ Si falta el módulo proveedor, el paquete básico no puede acceder a los sensores de hardware en tiempo de ejecución (runtime) y lanza esta advertencia para notificar al desarrollador. La solución a la advertencia y los pasos de configuración muestran diferencias metodológicas significativas según la plataforma de destino en la que se desarrolla y la versión de Unity utilizada.

La solución a esta advertencia encontrada durante el proceso de desarrollo debe abordarse en función de la plataforma. Dado que los permisos de acceso a las API de hardware de los sistemas operativos son diferentes, las soluciones ofrecidas por Unity también varían.

Plataforma de DestinoCausa Técnica de la AdvertenciaMetodología de Solución que Debe AplicarseAndroidAusencia en el proyecto del complemento nativo que se comunicará con ADPF o Samsung GameSDK.A través de Unity Package Manager, se debe instalar el paquete Adaptive Performance Android Provider o, si hay un destino específico del dispositivo, el paquete Samsung (Android) Provider.⁶ Luego, se debe activar el proveedor correspondiente desde el menú Edit > Project Settings > Adaptive Performance.iOS (Apple)Inexistencia de un proveedor (provider) de hardware oficial compatible con Unity para Adaptive Performance en el ecosistema iOS.⁴Cuando se añade el conjunto de características Mobile al proyecto, Adaptive Performance viene como una dependencia (dependency) y no se puede eliminar. Para las compilaciones de iOS, esta advertencia es inofensiva y se puede ignorar (ignore), o bien se puede eliminar el módulo Mobile del administrador de paquetes para romper la dependencia.⁴Editor de Escritorio (PC/Mac)Inexistencia de sensores térmicos y arquitecturas SoC específicos de dispositivos móviles en los sistemas operativos Windows o macOS.Para poder simular las condiciones móviles en la computadora de desarrollo, se debe instalar el proveedor Simulator (Desktop) y se debe crear un entorno térmico virtual utilizando la ventana Device Simulator.²Unity 6 (Build Profiles)Olvido de la configuración específica del perfil además de la configuración de Adaptive Performance del proyecto principal en los perfiles de compilación (Build Profiles) que vienen con Unity 6.En el menú File > Build Profiles, se debe hacer clic en el botón Add Settings > Adaptive Performance Settings para la plataforma seleccionada con el fin de asignar el proveedor. En las versiones de Unity 6.000.x, la omisión de estos ajustes provoca el error "No default loader found".⁹

Esta advertencia no es en esencia un error de compilación (compile), sino una notificación de falta de optimización. El desarrollador puede ejecutar el juego en el dispositivo ignorando esta advertencia; sin embargo, en este caso, el juego funcionará completamente a ciegas (blind) sobre el estado térmico del hardware y estará expuesto inevitablemente a las implacables intervenciones de estrangulamiento térmico del sistema operativo.

Arquitectura del Sistema Adaptive Performance y Ecosistema de Proveedores (Providers)

Adaptive Performance establece un puente de comunicación bidireccional entre los mecanismos de toma de decisiones del motor de juego y el hardware físico. La capa de recolección de datos de esta arquitectura está formada por los proveedores (providers). Dado que la naturaleza sumamente fragmentada (fragmented) del ecosistema Android hace imposible que una sola API de hardware funcione en todos los dispositivos, Unity supera este problema con proveedores específicos que se integran en diferentes marcos de hardware (frameworks).

Integración con Android Dynamic Performance Framework (ADPF)

El módulo básico "Android Provider" de Unity está construido sobre la arquitectura Android Dynamic Performance Framework (ADPF) introducida por Google a partir del sistema operativo Android 12.² ADPF es un conjunto de API revolucionario que permite establecer un diálogo directo entre los juegos y la gestión térmica del sistema operativo. En los enfoques tradicionales, el sistema operativo intenta adivinar qué fotograma (frame) del juego necesita cuánta potencia de procesamiento, y estas suposiciones a menudo resultan en la asignación de velocidades de reloj de CPU incorrectas.

Por su parte, el proveedor de Android de Unity Adaptive Performance proporciona un flujo de datos continuo al sistema operativo a través de la "Performance Hint API" (Interfaz de Sugerencias de Rendimiento).⁶ Cada vez que se renderiza un fotograma, el motor informa al sistema ADPF sobre el tiempo objetivo de ese fotograma (por ejemplo, 16.6 milisegundos si se apuntan a 60 FPS) y el tiempo real (actual duration) que la CPU y la GPU gastaron para completar este fotograma.⁶ Gracias a este preciso bucle de retroalimentación, el sistema operativo Android eleva la frecuencia de los núcleos de la CPU solo tanto como el juego lo necesita. Cuando el dispositivo comienza a calentarse, el sistema operativo envía las advertencias térmicas de vuelta a Unity, por lo que los escaladores gráficos dentro del motor se activan antes de que se experimente una ralentización a nivel de hardware.⁶ Las versiones 1.2 y superiores, que son la versión estable de Android Provider (versiones que superan la limitación del dispositivo Pixel), son compatibles a partir de Adaptive Performance 5.0 y Unity 2021.3.⁶

Samsung GameSDK y Optimizaciones de Hardware Específicas

Dado que Samsung posee una de las mayores cuotas de mercado en el ecosistema Android, ofrece una interfaz de hardware personalizada llamada GameSDK con el fin de poder llevar al límite su propio hardware. El proveedor Adaptive Performance Samsung (Android) de Unity va más allá de las características estándar de ADPF y permite obtener métricas que profundizan directamente en los SoC de Samsung.²

El proveedor de Samsung abarca una gama masiva de dispositivos con el sistema operativo Android 10 y superior, compatibles con GameSDK 3.2 y versiones más recientes. Este alcance se extiende desde los dispositivos de gama de entrada hasta los de gama alta (buques insignia), ofreciendo a los desarrolladores una amplia área de optimización.

Series Galaxy de Samsung CompatiblesModelos (GameSDK 3.2+ / Android 10+)Serie Galaxy SS9, S10e, S10, S10+, S10 Lite, S20, S20+, S20 Ultra, S20 Lite, S21, S21+, S21 Ultra, S22, S22+, S22 Ultra¹³Serie Galaxy NoteNote9, Note10, Note10+, Note10 Lite, Note20, Note20 Ultra¹³Serie Galaxy Z (Plegables)Z Fold2¹³Serie Galaxy AA10s, A11, A21s, A31, A41, A50s, A51, A51 5G, A71, A71 5G, A80, A8 2018, A9 2018, A90 5G¹³Serie Galaxy XcoverXcover 4s, Xcover Pro¹³

Una de las ventajas de hardware más importantes que proporcionan estos dispositivos es la tecnología de "Tasa de Refresco Variable" (Variable Refresh Rate - VRR).¹³ Actualmente, la compatibilidad con VRR se puede utilizar activamente en los dispositivos Galaxy S20, S21, S22 y Note 20.¹³ Cuando Adaptive Performance detecta que el dispositivo ha alcanzado sus límites y decide reducir el valor de FPS del juego, por ejemplo, de 60 a 45, envía un comando a la API VRR de Samsung para reducir también la tasa de refresco física de la pantalla a 45 Hz.¹⁶ Esta sincronización no solo evita el parpadeo o desgarro de pantalla (screen tearing), sino que también previene que el panel de la pantalla consuma energía adicional y contribuye significativamente a que el dispositivo se enfríe más rápido. Además, el proveedor de Samsung también ofrece la oportunidad de acceder a los datos de "Cluster Info", que muestran la distribución de carga de los núcleos grandes y pequeños en la arquitectura big.LITTLE del procesador en dispositivos con GameSDK 3.5 (Android 12) y versiones posteriores.¹³

Métricas Térmicas y Algoritmos de Detección de Cuellos de Botella (Bottlenecks)

La ingeniería detrás de la capacidad de Adaptive Performance para ofrecer una optimización proactiva se basa en sistemas de análisis de sensores que recopilan datos continuamente. La interfaz IAdaptivePerformance creada en tiempo de ejecución del juego lee conjuntos de datos del hardware en dos categorías principales: Retroalimentación del Estado Térmico (Thermal State Feedback) y Temporización de Fotogramas (Frame Timing). En función de estos datos, se determina cuál es el elemento principal (cuello de botella) que limita el rendimiento del sistema en ese momento.

Retroalimentación Térmica y Niveles de Advertencia

El estado térmico del dispositivo no se evalúa simplemente mediante una lectura en grados centígrados. La dinámica térmica se monitorea a través de tres métricas diferentes normalizadas y procesadas analíticamente ²:

La primera métrica, TemperatureLevel (Nivel de Temperatura), es un valor de punto flotante (float) normalizado entre 0.0 y 1.0 (0.0 es la temperatura ambiente/de trabajo estándar y 1.0 es el umbral térmico máximo absoluto).² Los desarrolladores pueden utilizar este valor para presentar el estado de calentamiento del dispositivo al jugador en la interfaz del juego como una barra gráfica o para estructurar su propia lógica de optimización personalizada.

La segunda métrica, más predictiva, es TemperatureTrend (Tendencia de Temperatura), que es un valor que varía entre -1.0 y

1.0 y representa la derivada matemática de la temperatura, es decir, la tasa de cambio. 2 Un valor de 1.0 indica que el dispositivo se está calentando extremadamente rápido, mientras que un valor de 0 indica que la temperatura se mantiene estable, y -1.0 muestra que se ha entrado en un periodo de enfriamiento agresivo. Para que el sistema detecte estas tendencias y obtenga un promedio válido, generalmente se requiere un proceso de análisis de unos diez segundos. 2 La tercera y más crítica métrica es una clasificación categórica denominada WarningLevel (Nivel de Advertencia), que especifica la reacción que tendrá el sistema operativo ante la situación térmica. 2

Nivel de Advertencia (WarningLevel) Estado del Sistema Operativo Reacción de Adaptive Performance en el Motor de JuegoNoWarning (0) El dispositivo se encuentra a temperaturas óptimas. No existe ninguna ralentización térmica. Se permite renderizar el juego a la resolución, tasa de fotogramas y calidad visual más altas seleccionadas. 2 ThrottlingImminent (1) La capacidad térmica está a punto de llenarse. El sistema operativo aún no ha reducido las frecuencias de hardware, pero el peligro es inminente. Comienza la intervención proactiva. Se ponen en marcha escaladores de bajo impacto visual (por ejemplo, acortando la distancia de las sombras) para intentar evitar que el dispositivo pase a la siguiente fase. 2 Throttling (2) El hardware ha alcanzado una temperatura crítica y el sistema operativo ha reducido agresivamente las frecuencias de reloj de la CPU/GPU para protegerse. Se paga la factura de optimización más agresiva. La tasa de fotogramas objetivo (Target FPS) se reduce drásticamente, se restringe la resolución de renderizado principal y se hacen concesiones radicales para que el dispositivo vuelva a una temperatura normal. 2

Cronograma de fotogramas y detección de cuellos de botella (Bottleneck)

Que un juego no logre alcanzar una velocidad de 60 fotogramas por segundo puede deberse a múltiples deficiencias de hardware. El primer regla de la optimización es averiguar si el problema proviene de la insuficiencia de la unidad de procesamiento gráfico (GPU) o del agotamiento de la potencia de cálculo de la unidad central de procesamiento (CPU). Para realizar este análisis, Adaptive Performance realiza un seguimiento de los datos de averageFrameTime (tiempo de fotograma total promedio) y averageGpuFrameTime (tiempo de funcionamiento promedio de la GPU) en cada fotograma. El tiempo de CPU de 17 abarca los procesos en los que el hilo principal (main thread) de Unity ejecuta la lógica del juego y el hilo de renderizado (render thread) prepara los datos para enviarlos a la GPU (lotes de llamadas de dibujo o draw call batching, etc.). 17 Como detalle importante, la medición del tiempo de CPU no incluye los bloqueos a nivel del sistema operativo ni los tiempos de inactividad o espera (idle/wait times) en los que la CPU espera a que la GPU termine su trabajo. 17 Como resultado del análisis de estos tiempos, el sistema asigna el cuello de botella actual (PerformanceBottleneck) a una de las cuatro categorías: ● CPU: Los algoritmos de inteligencia artificial dentro del juego, los cálculos físicos complejos o un número excesivo de instancias de objetos (instantiation) están saturando el procesador. 20

● GPU: Los efectos de transparencia multicapa (overdraw), la lectura de texturas de alta resolución y los efectos de post-processing pesados (por ejemplo, SSAO o Bloom) están limitando la unidad gráfica. 22

● TargetFrameRate (Fillrate): El sistema ya ha alcanzado la velocidad de fotogramas objetivo, no hay ningún estrangulamiento de hardware y es suficiente incluso si el hardware funciona por debajo de su potencial. 2

● Unknown: Son situaciones intermedias en las que no se puede determinar con precisión el origen del retraso.

Los desarrolladores pueden suscribirse al evento PerformanceStatus.PerformanceBottleneckChangeEvent (mediante el patrón delegado o delegate pattern) para capturar los momentos en que cambia el estado del cuello de botella durante el juego y dar respuestas algorítmicas adecuadas. 23 Por ejemplo, cuando el cuello de botella cambia repentinamente a la CPU, la frecuencia de escaneo del campo de visión (raycast) de las unidades de inteligencia artificial en el mundo abierto se puede reducir de 60 veces por segundo a 15 veces por segundo, aliviando instantáneamente la carga matemática en el procesador.

Motor de toma de decisiones y ejecución: Indexer y escaladores (Scalers)

El mecanismo que permite que el sistema Adaptive Performance funcione de forma autónoma se basa en que dos componentes principales trabajan en perfecta armonía: el cerebro llamado "Indexer" (Indizador) y los órganos ejecutores llamados "Scalers" (Escaladores).

Mecanismo Indexer (Indizador)

El Indexer es el coordinador central que calcula el "Índice de Calidad" actual del juego pasando continuamente las tendencias térmicas complejas y los datos de cuellos de botella recibidos del dispositivo a través de un filtro matemático. 19 La tarea principal del Indexer es evitar la creación de una inconsistencia visual (oscillation) cambiando continuamente la calidad del juego ante cada pequeño cambio de temperatura o fluctuación de FPS en el hardware. Para garantizar esta estabilidad, Thermal Action Delay (Retraso de acción térmica) y Performance Action Delay (Retraso de acción de rendimiento) se pueden definir en segundos desde Project Settings. 23 Incluso si el sistema detecta un cuello de botella, se asegura de que la situación sea permanente durante este tiempo de retraso definido, luego toma una decisión de acción y envía una señal a los escaladores conectados para reducir la calidad (StateAction.Decrease). 23

Análisis de impacto matemático y visual de los escaladores (Scalers)

Los escaladores son scripts que modifican características específicas del Render Pipeline (canal de procesamiento) o del motor de física de Unity en tiempo de ejecución (runtime). 19 El nivel predeterminado (Level) de cada escalador es cero. Este nivel aumenta con cada señal de "reducir calidad" procedente del Indexer; a medida que el nivel aumenta, disminuye el detalle de la característica controlada por el escalador. 19 El momento y el orden en que se activarán los escaladores se determinan mediante una matriz de decisión tridimensional 19 :

1. Objetivo de cuello de botella (Targeting Bottleneck): Si el análisis determina que el cuello de botella es la GPU, el Indexer omite los escaladores que optimizan la CPU y presiona directamente a los escaladores dirigidos a la GPU (por ejemplo, la resolución).

2. Nivel más bajo (Lowest Level): Se da prioridad a las características cuyo nivel aún no se ha incrementado (que conservan su calidad original).

3. Impacto visual (Visual Impact): Es la probabilidad de que el jugador note cuando se reduce la calidad de la característica. Se clasifica como Bajo (Low), Medio (Medium) o Alto (High). 19 El sistema siempre comienza reduciendo primero las características con un impacto visual Bajo.

El sistema ofrece una gama extremadamente amplia de escaladores tanto para la canalización de renderizado estándar como para Universal Render Pipeline (URP). La siguiente tabla detalla los objetivos de hardware de estos escaladores y sus efectos teóricos dentro de la aplicación.

Clase de escalador Objetivo de cuello de botella Impacto visual Efecto teórico y práctico en el Render Pipeline AdaptiveFramerate CPU / GPU / Fillrate Alto Modifica la variable Application.targetFrameRate del juego entre límites. Es especialmente eficaz cuando el VSync está desactivado. Una caída de 60 FPS a 30 FPS crea un período de enfriamiento radical al aumentar el tiempo de inactividad de todos los componentes del chip. 19 AdaptiveResolution GPU / Fillrate Alto Reduce dinámicamente la escala de resolución de procesamiento de pantalla (Resolution Scale). 19

Funciona a través de Render Scale en proyectos URP. Al reducir la velocidad de relleno de píxeles (fillrate) en proporción geométrica, es el arma más potente para romper la carga térmica de la GPU, pero arruina directamente la nitidez de la imagen. 15 AdaptiveLOD CPU / GPU Medio Manipula las distancias de transición del Nivel de detalle (Level of Detail - LOD) de los modelos tridimensionales en la escena (LOD bias). 18 Garantiza que las versiones de bajo polígono permanezcan en la pantalla incluso cuando la cámara se acerque a los modelos, lo que reduce las llamadas de dibujo (draw calls) de la CPU y los cálculos de vértices de la GPU. 18 AdaptiveShadowmapResolution GPU Medio/Bajo Reduce la resolución en píxeles del mapa de sombras en URP. Dado que la pixelación de los bordes de las sombras cuando hay mucho movimiento en la pantalla es una situación difícil de percibir cognitivamente, alivia el ancho de banda de la memoria de la GPU sin sacrificar la calidad. 19 AdaptiveShadowCascade CPU / GPU Medio Reduce el número de cascadas en las luces direccionales de URP. Cada una de las cascadas de sombras requiere que los objetos que proyectan sombras en la escena se rendericen una vez más (draw call). La disminución del número de cascadas alivia directamente el cuello de botella de la CPU. 19 AdaptiveViewDistance CPU / GPU Yüksek Estrecha el plano de corte lejano (far clip plane) de la cámara principal para garantizar que los objetos distantes no se incluyan en el flujo de renderizado de ninguna manera (frustum culling). 19 Es uno de los pasos de optimización más críticos, especialmente en juegos de mundo abierto. 15 AdaptiveLayerCulling CPU / GPU Medio En lugar de recortar la distancia general de visualización, ajusta la distancia de visibilidad de capas específicas de Unity (Layers). 2

Por ejemplo, se restringe la distancia de renderizado de la capa de detalles del entorno (césped, decoraciones pequeñas) para aumentar el rendimiento al tiempo que se eliminan los pequeños detalles y se protegen las grandes estructuras alrededor del jugador. 16 AdaptivePhysics CPU Yüksek Aligera la carga de la CPU al modificar los pasos de actualización (fixedDeltaTime) o el número de iteraciones del motor de física de Unity (PhysX o Box2D). 2 Los cálculos de física son de los mayores culpables de los cuellos de botella basados en la CPU. 21 AdaptiveBatching CPU Bajo Controla los procesos de agrupamiento dinámico (Dynamic Batching). Alivia la CPU en situaciones que no requieren cálculos excesivos de vértices. 19 AdaptiveDecals CPU / GPU Bajo Reduce la carga de overdraw en la fase de dibujo de materiales al limitar la distancia de renderizado o el número de calcomanías (decals), como marcas de balas y manchas de sangre en las paredes, en el sistema URP. 2

Los desarrolladores no están obligados a ceñirse únicamente a los escaladores predeterminados. Se recomienda encarecidamente desarrollar "Escaladores personalizados" (Custom Scalers) adaptados a las mecánicas específicas del juego. 2 Para escribir un escalador personalizado, basta con heredar de la clase AdaptivePerformanceScaler y anular (override) características básicas como VisualImpact, Target, MaxLevel, así como el método OnLevel(). 19 Por ejemplo, en un juego ambientado en un entorno con niebla, se puede escribir un escalador personalizado para aumentar la densidad de la niebla a medida que aumenta la temperatura (Adaptive Fog). De este modo, mientras el campo de visión del jugador se reduce de forma natural, la distancia de dibujo de la cámara se acorta en segundo plano, creando una ilusión seria de optimización. 15

Modos de control de rendimiento y gestión de la frecuencia de reloj (Clock Frequency)

Adaptive Performance no solo reduce las funciones gráficas dentro del motor del juego, sino que también tiene la capacidad de intervenir directa o indirectamente en la energía eléctrica y las frecuencias de reloj proporcionadas por el sistema operativo a la CPU y la GPU. Hacer que los procesadores funcionen a sus velocidades de reloj máximas crea una ineficacia asintótica; es decir, se consume una cantidad masiva de energía y se genera calor a cambio de la pequeña cantidad de potencia de procesamiento adicional obtenida. 17

Para gestionar este equilibrio energético, la interfaz Adaptive Performance ofrece tres modos de control diferentes (PerformanceControlMode): Sistema, Manual y Automático. 20

1. Modo del Sistema (System Performance Control): Es el modo predeterminado aplicable en sistemas distintos del proveedor de Android (por ejemplo, simulación de escritorio). El propio sistema operativo determina las frecuencias de CPU/GPU utilizando métodos tradicionales, Adaptive Performance no interviene en el hardware, solo reduce los gráficos dentro de la aplicación. 20

2. Modo Manual (Manual Performance Control): Es el modo en que el desarrollador puede asignar directamente las variables Instance.DevicePerformanceControl.CpuLevel y GpuLevel entre 0 y el nivel máximo. 23 El uso de este modo de control no se recomienda en absoluto, excepto para pruebas de rendimiento (benchmark) muy específicas. 17 Si un desarrollador sin un conocimiento profundo de las limitaciones térmicas del hardware móvil y las características de descarga de la batería mantiene el nivel de la CPU alto constantemente, el dispositivo se sobrecalentará rápidamente, el sistema operativo activará sus mecanismos de defensa y atrapará el juego en la fase de "Throttling" (Estrangulamiento), y la batería se agotará sin sentido. 20

3. Modo Automático (Automatic Performance Control): Es el modo de control más seguro, eficiente y altamente recomendado. 17 Lo único que debe hacer el desarrollador es establecer la velocidad de fotogramas objetivo del juego (por ejemplo, 30 o 60) con Application.targetFrameRate. 23 El modo automático analiza en segundo plano la temperatura del dispositivo, el tiempo de renderizado y el entorno de ejecución (si está en el menú o en el juego). 20 Si el juego alcanza el objetivo de 60 FPS muy cómodamente, reduce silenciosamente las velocidades de reloj de la CPU y la GPU en lugar de hacer funcionar el procesador a plena capacidad innecesariamente. La velocidad de fotogramas sigue siendo 60, pero el hardware consume mucha menos electricidad, lo que permite que el juego se mantenga fresco y la batería dure horas (Battery Life Preservation). 20

Sobrecarga de energía temporal: Modo Boost (Modo de aceleración)

En algunos momentos de los juegos móviles, se necesita una gran capacidad de procesamiento instantánea en lugar de un rendimiento sostenible. Para escenarios tan específicos, Adaptive Performance incluye la API "Boost" (Aceleración). 23 Cuando se llama al modo Boost, la frecuencia de funcionamiento mínima (mínima) de la CPU o la GPU se iguala temporalmente a la frecuencia de funcionamiento máxima (máxima), lo que obliga al hardware a funcionar a todo su potencial. 23

Los lugares donde el modo Boost debe utilizarse estratégicamente son 23 :

● Minimizar los tiempos de carga (load time) de los modelos pesados que se llevarán a la memoria en las pantallas de carga al abrir el juego o los capítulos (Loading Screens).

● Eliminar los tiempos de espera que se producen durante la apertura de paquetes grandes descargados a través de la red (Network) u operaciones de procesamiento de datos asíncronos.

● Evitar microcongelaciones (hitches) de un segundo que el jugador pueda experimentar durante las fases de compilación de Shaders (Shader Compilation) o generación de contenido procedural.

Sin embargo, la activación del modo Boost extrae una corriente masiva de la batería del dispositivo y eleva instantáneamente la temperatura del SoC. 23 Si el sistema operativo ya ha entrado en la fase de Throttling (Estrangulamiento) (el dispositivo está demasiado caliente), para evitar daños en el hardware, las solicitudes de Boost de Unity o los comandos de ajuste de nivel manual de CPU/GPU son rechazados directamente por el sistema operativo y el control se transfiere por la fuerza al "Modo del Sistema". 23 Es de vital importancia que los desarrolladores utilicen esta interfaz únicamente en pantallas de carga donde el jugador espera pasivamente y durante períodos de un segundo.

Interfaz de Desarrollador: Uso de la API de C# y Visual Scripting

La flexibilidad del paquete Adaptive Performance permite a los desarrolladores utilizar el sistema autónomo sin escribir una sola línea de código si lo desean, o estructurar una lógica personalizada que vaya al corazón del juego.

Programación Basada en Eventos a Través de la API de C#

Los desarrolladores que deseen acceder programáticamente a los datos térmicos del sistema lo hacen a través del objeto Singleton UnityEngine.AdaptivePerformance.Holder.Instance creado con el paquete (o Mobile.AdaptivePerformance.Holder en versiones más recientes). 18 Específicamente, para detectar que el dispositivo está a punto de entrar en cuello de botella (ThrottlingImminent), se escucha el evento (delegate) IThermalStatus.ThermalStatus.ThermalEvent. 2

Cuando se desencadena un evento (por ejemplo, cuando llega una alarma de calentamiento), el estado se analiza con una estructura switch-case para intervenir en las mecánicas del juego. 2 Si el nivel de advertencia es Throttling, la velocidad de fotogramas se reduce de 60 a 15 o 30; si no hay advertencia, se vuelve al objetivo de 60. 2 Del mismo modo, si el cuello de botella está en el lado de la CPU, se pueden desactivar algunos de los agentes de IA activos en el mapa con un script personalizado (script) para aliviar el procesador al instante. 2

Integración de Visual Scripting

Para artistas técnicos (technical artists) que no son programadores y diseñadores de juegos, se ha introducido soporte completo para la API de C# a través de paquetes de Visual Scripting en Unity 5.0 y versiones posteriores. 29

Una vez que el paquete de Visual Scripting se incluye en el proyecto, se debe seguir la ruta Edit > Project Settings > Visual Scripting > Node Library > Regenerate Units para asegurar que los nodos (nodes) de Adaptive Performance se añadan a la interfaz de Fuzzy Finder. 27

Gracias a esta integración, se proporciona acceso a un conjunto de nodos especiales 30 :

● Nodos térmicos: El nodo On Thermal Metric se activa instantáneamente cuando cambian el nivel de advertencia térmica del dispositivo, el porcentaje de temperatura (Temperature Level) y la tendencia de temperatura (Trend). El pin de salida de este nodo se puede conectar a una lógica que apague directamente una fuente de luz pesada o un sistema de partículas en la escena.

● Nodos de rendimiento: El nodo On Bottleneck señala si el cuello de botella es la CPU, la GPU o el Fillrate; los nodos Frame Timing y FPS son ideales para imprimir datos de rendimiento en tiempo real en la pantalla del juego. Gracias al nodo Cluster Info, se pueden leer las cargas de los núcleos en la arquitectura big.LITTLE.

● Nodos Boost y Levels: Al añadir el nodo Set Boost al principio de los bloques de carga de escena en el gráfico de Visual Scripting, las velocidades de carga se pueden maximizar sin escribir código; con Get Performance Level se puede leer el estado actual del procesador.

Metodología de Pruebas, Perfilado y Optimización

Añadir el sistema Adaptive Performance al proyecto no resuelve todos los problemas por sí solo; un sistema mal configurado puede arruinar la calidad gráfica del juego demasiado pronto o no servir para nada. El proceso de desarrollo debe basarse en una metodología científica de medición y evaluación comparativa (profiling and benchmarking).

Creación de una Línea Base (Baseline) y Pruebas A/B

Según las prácticas de optimización conjuntas de los ingenieros de Google y Unity, el primer paso que se debe dar es medir el rendimiento del juego antes de activar ADPF o Adaptive Performance (Baseline). 6 El juego debe cargarse en un dispositivo móvil físico con los requisitos mínimos de sistema objetivo (min-spec) y jugarse durante unos veinte minutos hasta que el dispositivo se caliente. 21 Durante esta prueba, la herramienta Unity Profiler debe comunicarse con el dispositivo a través de una red inalámbrica (Wi-Fi) (Autoconnect Profiler) para registrar los minutos en que los FPS empiezan a caer y los valores de Frame Time. 1

A continuación, el sistema Adaptive Performance se activa en el proyecto con los escaladores predeterminados y se vuelve a ejecutar el mismo escenario de prueba. 6 A través de la nueva pestaña "Adaptive Performance" en el módulo del Profiler, se debe examinar en qué minuto el dispositivo dio la advertencia de ThrottlingImminent, qué escalador ejecutó el sistema (por ejemplo, AdaptiveResolution) y cómo afectó esto a los tiempos de CPU/GPU, comparándolo lado a lado con la primera prueba. 2 Si el desarrollador llega a conclusiones como "El juego sigue dando 60 FPS en el minuto 10 pero la resolución baja demasiado", debe jugar con los pesos de los escaladores en el Indexer y realizar un ajuste preciso (fine-tuning) específico para el juego. 6

Simulación en Entorno de Escritorio: Device Simulator

Aunque las pruebas en dispositivos son esenciales, esperar a que un teléfono físico se caliente y se enfríe reduce la velocidad de iteración en la fase de codificación. Para superar esta situación, se ha desarrollado el proveedor Simulator (Desktop) Provider. 2 Abriendo la ventana Window > General > Device Simulator en el ordenador de desarrollo de escritorio, se pueden activar artificialmente el nivel de batería, la tendencia térmica y los cuellos de botella del dispositivo virtual (artificial bottlenecks). 2 Con un solo clic, el desarrollador puede cambiar el estado del dispositivo virtual a la fase de Throttling y probar de forma instantánea en segundos cómo los escaladores personalizados que ha escrito (Custom Scalers) cambian la densidad de la niebla o los detalles de los modelos (LOD) en el juego. 2

Sinergia con Enfoques de Optimización Tradicionales

Adaptive Performance no es un algoritmo milagroso; no puede salvar por sí solo un juego cuya base esté mal estructurada. El sistema crea un efecto multiplicador masivo cuando se combina con prácticas clásicas de optimización móvil. 1

● Las texturas del juego (textures) deben diseñarse en tamaños que sean potencias de dos (POT - Power of Two) y se deben utilizar formatos de compresión de hardware móvil como ASTC y ETC2. 8

● Las opciones Read/Write Enabled de los modelos y texturas que no se modificarán en tiempo de ejecución deben desactivarse para evitar mantener copias innecesarias en la memoria de la CPU y la GPU. 31 El consumo de memoria (memory bandwidth) es una de las mayores fuentes de calor. 1

● Si el sensor del acelerómetro (accelerometer) en el hardware móvil no es utilizado activamente por el juego (por ejemplo, si no es un juego de carreras), reducir la frecuencia de escaneo del acelerómetro o desactivarlo a través de Player Settings alivia al sistema operativo de un gran problema y amplía el margen térmico (thermal envelope). 31

● Las matrices de ocultación de las cámaras de los dispositivos (Occlusion Culling) deben hornearse (baked) cuidadosamente, y los modelos de decenas de miles de polígonos que no están en el campo de visión de la cámara pero quedan detrás de las paredes deben eliminarse en la CPU (draw call) antes de ser enviados al procesador gráfico. 3

Cuando un juego cuyo tiempo de calentamiento se ha ampliado a 15 minutos con todas estas precauciones tradicionales es respaldado por los escaladores AdaptiveResolution o AdaptiveFramerate de Adaptive Performance —la última línea de defensa—, se transforma en una obra maestra móvil perfecta y sostenible donde las caídas de 60 FPS a 45 FPS durante horas de juego nunca son percibidas por el jugador.

La ausencia de ventiladores de refrigeración en el hardware móvil obliga a los desarrolladores de juegos a jugar al ajedrez con los límites térmicos del silicio. Este viaje técnico, que comienza con una simple advertencia de configuración de proveedor como "Adaptive Performance Settings", alcanza el dominio de acceder a las válvulas de gestión de energía del sistema operativo, leer derivados del análisis térmico y manipular los algoritmos de calidad en la tubería de renderizado en tiempo real. Cuando el proceso de optimización se centra en la sostenibilidad del rendimiento fluido (sustained performance) en lugar de alcanzar el rendimiento máximo (peak performance), maximiza tanto la satisfacción del jugador como desbloquea el éxito a largo plazo en plataformas móviles.

*Nota informativa: Las imágenes han sido generadas por Google Gemini.