Define un dispositivo y una escena antes de evaluar el rendimiento de un juego

Por Noe Guerrero III

“Corre fluido” necesita ir acompañado de un dispositivo, una versión del juego y una escena. Antes de aprobar una etapa del proyecto, acuerden dónde debe funcionar el juego, qué hará el jugador durante la prueba y qué mediciones respaldarán la decisión. De lo contrario, dos personas pueden dar reportes honestos de rendimiento sobre condiciones completamente distintas.

No necesitas empezar con un laboratorio enorme. Empieza con una prueba de referencia que puedas repetir y una lista clara de los dispositivos que todavía no has revisado. Así, el desarrollador tendrá un problema concreto que investigar y el dueño del proyecto tendrá un resultado que pueda interpretar.

Elige el dispositivo y la versión exacta del juego

Anota el modelo del dispositivo y sus especificaciones relevantes. Para una computadora, registra el procesador, el hardware gráfico y la memoria; para un teléfono, registra el modelo exacto. Incluye el sistema operativo y, si es un juego para navegador, la versión del navegador. “Una laptop” o “Android” deja demasiados detalles sin definir.

Elige un dispositivo representativo del público al que realmente quieres llegar. La potente computadora del desarrollador puede ser útil durante la producción, pero un resultado obtenido en esa máquina solo demuestra lo que pasó ahí. Si todavía no has conseguido el dispositivo previsto para el cliente, marca su rendimiento como no verificado.

La guía de Unity para recopilar datos de rendimiento explica que analizar el rendimiento en la plataforma objetivo es más representativo que hacerlo en el modo Play, donde el Editor afecta las mediciones. Pide evidencia del dispositivo previsto como parte de la revisión de esa etapa.

Identifica la compilación probada con una referencia de versión o revisión. Registra si es una compilación de desarrollo con herramientas de diagnóstico activadas o la compilación de lanzamiento destinada a los jugadores. Mantén esos resultados claramente identificados. Pide al desarrollador que explique qué configuración usó para investigar el problema y cuál usó para la revisión de entrega.

Registra también la resolución, los ajustes gráficos, el límite de fotogramas por segundo y los ajustes de sincronización. Si alguien reduce la resolución entre pruebas, puede ser un experimento útil, pero es una configuración diferente. No debería sustituir la referencia original sin dejarlo indicado.

Escribe un recorrido breve por una escena representativa

Imagina que un pequeño equipo del RGV encarga un juego de clasificación de paquetes con vista cenital. Este es un proyecto hipotético, no un caso de estudio de un cliente. Una sala de clasificación vacía no basta para representar la ronda más concurrida prevista, cuando aparecen paquetes, personajes y efectos al mismo tiempo.

Dale al recorrido de prueba un punto de partida reproducible. Usa el mismo estado guardado o configuración de la escena, el mismo recorrido y aproximadamente la misma secuencia de acciones. Si el juego genera su escena al azar, pregunta si hay una semilla repetible o un estado de prueba preparado. Documenta las variaciones que no puedas mantener constantes.

Un recorrido útil para este ejemplo podría ser:

1. Empieza desde el estado de prueba designado y entra a la sala de clasificación.

2. Juega la ronda concurrida acordada usando la misma secuencia de acciones de clasificación.

3. Abre la pantalla de resultados y reinicia la ronda.

Decide el periodo de medición y cuántas veces repetirás la prueba antes de comparar versiones. No existe una duración de sesión universal que demuestre que un juego está listo. Elige un periodo que incluya el comportamiento que necesitas evaluar y anota si estás revisando la primera entrada, las entradas repetidas o una sesión continua de juego.

Trata el inicio del juego y la carga de niveles como observaciones independientes. Una primera carga lenta y una pausa repetida durante el movimiento requieren preguntas diferentes. Registra el modo de energía, si el dispositivo está conectado a la corriente, las otras aplicaciones abiertas y cualquier condición inusual de la prueba. Para un juego en red, registra también la configuración de la conexión; probar una escena local no valida toda la experiencia en línea.

Revisa el tiempo por fotograma y los momentos que interrumpen el juego

Los fotogramas por segundo, o FPS, indican cuántos fotogramas se producen a lo largo del tiempo. El tiempo por fotograma describe la duración de cada uno. Si eliges una meta de 60 FPS, el intervalo correspondiente es de aproximadamente 16.7 milisegundos por fotograma; a 30 FPS es de unos 33.3 milisegundos. Son ejemplos para planear, no requisitos universales para todos los juegos.

Pide al desarrollador que muestre el registro de mediciones de todo el periodo de prueba, incluidos los momentos difíciles. La documentación del perfilador de Godot describe una gráfica del tiempo por fotograma medido en milisegundos y permite a los desarrolladores examinar un fotograma específico. Una sola cifra destacada de FPS no muestra dónde ocurrió una interrupción.

La guía general de optimización de Godot distingue entre una ejecución constantemente lenta, pausas intermitentes y demoras de carga. Mantén esas observaciones separadas en tu propio reporte. “El movimiento se pausó cuando se abrió el panel de resultados” es más útil que “el juego se sentía trabado”.

Para el juego de paquetes, marca el punto donde empieza la ronda concurrida, donde se abre el panel de resultados y donde ocurre el reinicio. Relaciona cualquier pausa momentánea observada con esa secuencia sin afirmar de inmediato cuál es su causa. Una pausa cerca de un efecto visual no demuestra que el problema sea el hardware gráfico.

Acuerden el criterio de aceptación antes de revisar el resultado: la tasa de fotogramas objetivo, la medida relevante del tiempo por fotograma, cómo se evaluarán las pausas y qué transiciones de carga se permiten. Pide al desarrollador que explique qué incluye la medida elegida. No inventes un umbral estricto solo porque una gráfica ofrece ese número.

El análisis de rendimiento también puede afectar la prueba. La documentación del perfilador de Godot señala expresamente que recopilar sus mediciones consume muchos recursos. Registra las herramientas de diagnóstico que estaban activas y mantén separada la investigación con esas herramientas de la revisión acordada de la compilación de lanzamiento.

Conserva una referencia para comparar con la siguiente compilación

Guarda un registro breve de la prueba con estos campos:

• Compilación y fecha: La revisión probada y cuándo se realizó la prueba.

• Dispositivo y entorno: Hardware, sistema operativo, navegador cuando corresponda, condiciones de energía y actividad relevante en segundo plano.

• Ajustes: Resolución, nivel de calidad, límite de fotogramas por segundo y configuración de sincronización.

• Escena y recorrido: El estado inicial, las acciones, el periodo de medición y el plan para repetir la prueba.

• Evidencia: Referencias a las capturas, mediciones observadas y marcas de tiempo de las interrupciones.

• Decisión: Aprobado, fallido o no verificado según el criterio acordado, con las limitaciones y la siguiente acción.

Conserva la captura original cuando el desarrollador proponga un cambio. Repite el mismo recorrido en el mismo dispositivo y con la misma configuración para hacer la comparación. Si cambia un ajuste, identifica la nueva prueba como tal. Si una mejora aparente no se repite, registra la incertidumbre en lugar de declarar una solución permanente.

El rendimiento es una parte de lo que determina si el juego funciona para un jugador. Nuestra guía para probar los primeros cinco minutos de un juego aborda cómo entender el objetivo y empezar a jugar; un reporte de tiempo por fotograma responde a otra pregunta. Puede que necesites ambas pruebas antes de aprobar esa etapa del proyecto.

Para la próxima revisión, lleva una referencia de la compilación, un dispositivo objetivo y un recorrido breve por una escena. “Corre fluido” resulta mucho más útil cuando todos pueden ver exactamente qué se probó y qué sigue sin conocerse.