Cómo evalúa Roblox la creación de juegos «Build»

Build, nuestra nueva herramienta de creación diseñada prioritariamente para dispositivos móviles, permite a los usuarios de Roblox crear un juego mediante indicaciones de texto y publicarlo para que lo disfruten jugadores de todo el mundo. La generación de un juego integral requiere un sistema autónomo de principio a fin para la creación de juegos: uno que coordine el código, los recursos visuales, los sistemas de jugabilidad, la interfaz de usuario y los controles en un único artefacto compuesto. Este sistema debe gestionar de forma robusta los diversos escenarios que surgen con las acciones de los jugadores y las interacciones multijugador. Desde el lanzamiento de la versión alfa en Nueva Zelanda, más de 100 000 jugadores han utilizado Build para intentar crear un juego, y se han publicado aproximadamente 9 000 juegos creados con Build.¹ De los miles de usuarios que han utilizado Build para crear un juego, el 71 % nunca había utilizado Roblox Studio antes,¹ lo que demuestra que están probando algo nuevo con Build.

Pero los creadores solo utilizarán esta nueva herramienta si es fácil de usar y la calidad de los juegos que genera es lo suficientemente alta como para poder seguir desarrollándolos. Para comprender la calidad de los juegos creados con Build, evaluamos el proceso de creación de principio a fin y utilizamos esas evaluaciones, así como los comentarios de los creadores, para mejorar el producto. Nuestro marco de evaluación (eval) nos ha ayudado a priorizar y mejorar la comprensión de la intención, la jugabilidad en 3D y el acabado. Desde el lanzamiento de la versión alfa de Build en Nueva Zelanda, la satisfacción de los creadores ha mejorado un 10 %, los resultados no deseados han descendido del 18 % al 3 %, y se publican aproximadamente el 14 % de las sesiones guiadas y el 19 % de las pruebas de juego.² Se trata de indicadores descriptivos del progreso, no de estimaciones causales del impacto de la evaluación por sí solas.

Por qué la evaluación de la creación de juegos es diferente

Los juegos comparten algunos de los mismos retos de evaluación que se dan en otros sistemas que generan artefactos compuestos, como aplicaciones, vídeos y modelos del mundo. Por ejemplo, la calidad depende de cómo interactúan múltiples componentes, y la puntuación de un solo componente no describe por sí sola el resultado. 

Lo que distingue a los juegos es que el artefacto es un sistema ejecutable en tiempo real impulsado por los jugadores. Propiedades como la capacidad de respuesta, la agencia, la progresión y la sensación que transmite el juego surgen a través de la interacción y no pueden evaluarse plenamente solo inspeccionando el código o los recursos. Por lo tanto, un juego tiene que superar un listón excepcionalmente alto tanto en cuanto a la corrección de bajo nivel (libre de defectos y jugable) como a la experiencia del jugador de alto nivel (un juego que dé la sensación de estar terminado, no un prototipo). 

La pregunta que buscamos responder mediante la evaluación no es si algún elemento concreto es correcto, sino si el producto en su conjunto se ajusta a la intención del creador y si los jugadores pueden disfrutar de la experiencia completa. Para responder a eso se necesita más de una métrica.

Cuatro indicadores, un marco

Nuestro marco de evaluación de la creación «Build» combina cuatro indicadores. Cada uno responde a una pregunta diferente, detecta un tipo distinto de fallo y arroja una puntuación cuantitativa concreta:

1. Calidad de la especificación del juego (puntuación de 0 a 100): Build es el agente de creación de principio a fin: traduce las instrucciones del creador en una especificación y, a continuación, la utiliza para generar el juego. El evaluador valora si la especificación toma decisiones importantes de forma explícita, preserva la intención del creador, tiene en cuenta la viabilidad dentro del entorno de ejecución de Roblox y evita inventar requisitos que nunca se hayan expresado.

2. Calidad estática del juego (puntuación de 0 a 100): El evaluador de aspectos estáticos examina el juego generado en el modo de edición de Roblox Studio. Esto incluye la estructura del juego, los scripts, los recursos, las propiedades, las conexiones y los límites entre cliente y servidor. En esta fase buscamos responder a dos preguntas. La primera es si el juego está construido correctamente: implementación de los sistemas requeridos, elección de la API del motor y de las opciones de red, presencia de los controles y componentes de la interfaz de usuario esperados, así como la solidez y coherencia de la arquitectura del juego. 

La segunda es si está diseñado para ser divertido: profundidad del bucle principal, variedad y escalada del contenido, progresión, rejugabilidad e innovación más allá de lo habitual en el género. Un juego puede tener una arquitectura impecable pero carecer de profundidad en el contenido, o estar lleno de ideas pero mal estructurado. 

Separar estas dos perspectivas y evaluarlas según las mejores prácticas nos ofrece una idea más detallada de en qué aspectos falla el juego.

3. Prueba de juego (índice de superación del 0 al 100 %): El evaluador de la prueba de juego ejecuta el juego y lleva a cabo un plan de pruebas con entradas reales similares a las de un jugador, incluyendo toques, clics, pulsaciones de teclas y navegación, en lugar de disparar eventos desde el código. Un plan de pruebas caso por caso comprueba que el juego se inicie, responda, avance, se recupere de los fallos y no presente errores de ejecución. Cada elemento se evalúa de forma binaria (aprobado/suspenso) y se presenta como una tasa de aprobación ponderada por niveles, junto con un veredicto sencillo de «jugable» o «no jugable». Repetimos las ejecuciones para medir la consistencia.

4. Calidad visual y experiencial (puntuación de 0 a 100): Algunos de los aspectos más importantes para el aspecto y la sensación que transmite un juego no se pueden deducir del código, por lo que el evaluador visual puntúa la presentación por sí mismo utilizando grabaciones del juego en ventanas de visualización que representan diferentes dispositivos. Esta rúbrica se centra únicamente en el aspecto y el sonido del juego, basándose en el diseño de los recursos, el acabado de la interfaz de usuario, el movimiento, la iluminación y el audio. La pregunta fundamental es: ¿el juego da la impresión de ser un producto listo para su lanzamiento o más bien un prototipo? Separar los aspectos visuales de la mecánica significa que «el código funciona» y «el juego parece terminado» no se promedian en una única puntuación engañosa.

Además de las señales puntuadas, cada ejecución captura métricas de carácter meramente informativo, como el uso de tokens, las llamadas a herramientas, las habilidades activadas y la latencia. Estas métricas no influyen en la puntuación de la evaluación, pero pueden explicar cómo se obtuvo un resultado y detectar regresiones que las rúbricas pasan por alto, como una compilación que ha duplicado su coste para el mismo juego.

Las señales se corresponden con los fallos que detectan:

Recorrido por un circuito 3D de tipo «obby» con indicaciones

Las señales se aprecian mejor en una indicación real. Por ejemplo: «Un auténtico juego de obstáculos en 3D, con una plataforma de salida, obstáculos móviles, puntos de control y línea de meta». Los juegos de obstáculos son un tipo de juego de plataformas muy popular en Roblox. La intención del creador queda clara, aunque no especifique todos los detalles de implementación. El desarrollador debe completar los detalles con suposiciones razonables.

Plan y especificaciones

El equipo de desarrollo elaboró un documento de especificaciones para un nuevo juego, llamado Skyforge Ascent, en el que se detallaba un recorrido de cinco secciones con puntos de control y tres tipos de peligros. En él se definían el bucle principal, la curva de dificultad, la dirección artística, las pantallas, las superposiciones y los controles. La evaluación de las especificaciones le otorgó una puntuación de 91/100, obteniendo la máxima puntuación en cuanto a exhaustividad, cumplimiento de los plazos, viabilidad y coherencia interna. La deducción se debió a dos aspectos concretos: los detalles de implementación y la cobertura de los criterios de aceptación. 

Las especificaciones nunca fijaron sus constantes numéricas, como las velocidades de giro, las distancias de deslizamiento, los tiempos de los mosaicos, las dimensiones de las plataformas o la altura del plano de reinicio, por lo que un ingeniero aún tiene que determinarlas. Además, algunos criterios de aceptación (como «unas 24 plataformas» o «paleta de colores de Celestial Forge») no son estrictamente falsificables. Una puntuación alta en las especificaciones solo demuestra que el documento está listo para la construcción. Lo que miden las tres etapas siguientes es si esos compromisos se mantienen tras el contacto con el desarrollo real del juego.

Comprobaciones estáticas: calidad del código y calidad del contenido

El juez virtual inspeccionó el archivo de ubicación de Skyforge Ascent sin jugar al juego, y las dos perspectivas de evaluación llegaron a conclusiones diferentes.

El criterio de ingeniería, al leer el mismo archivo de mapa, le otorgó una puntuación de 98/100. Consideró que se trataba de una construcción ejemplar con cinco secciones y tres obstáculos móviles, que satisfacía plenamente la intención del creador mediante puntos de control secuenciales controlados por el servidor, sistemas de reinicio por caída y una interfaz de usuario basada en el marco StyleSheet. Se cumplió todo lo descrito en las especificaciones. El único problema fueron dos exportaciones de funciones auxiliares sin utilizar.

La perspectiva de diseño le otorgó una puntuación de 31/100. Todo funcionaba, pero el juego obtuvo un cero en progresión, rejugabilidad, autonomía del jugador y gancho original. El bucle principal era sencillo y lineal —llegar a cada punto de control, cruzar la meta— con poca variedad entre partidas y sin motivo para volver a jugar una segunda vez. Es un elemento básico del género «obby», no un juego con un gancho propio.

Esa discrepancia es la conclusión. La calidad del código y la calidad del contenido son dimensiones fundamentalmente diferentes, y una versión puede ser casi perfecta en una de ellas y fallar en la otra. Una única puntuación de calidad combinada habría promediado ambas en algo sin sentido.

Prueba de juego

El agente de pruebas jugó al juego utilizando entradas similares a las de un jugador real y superó los nueve puntos del plan de pruebas: generar un personaje en la plataforma de inicio, desplazarse por la geometría 3D sorteando huecos, recibir impactos de peligros, activar puntos de control y la recuperación automática tras una caída, completar la partida y reiniciar, todo ello sin ningún error de ejecución. En esta partida concreta, Skyforge Ascent obtuvo una puntuación de 100/100 en la prueba de juego.

Una puntuación perfecta en la prueba de juego simplemente demuestra que la mecánica funciona y que el juego es técnicamente jugable de principio a fin. No dice nada sobre si el juego es realmente atractivo o divertido de jugar; esa distinción es precisamente la razón por la que la perspectiva de diseño le otorgó una puntuación de 31.

Calidad visual

Por último, el sistema de evaluación puntuó la sesión grabada en una ventana de visualización del tamaño de un teléfono en cuanto a presentación visual. Skyforge Ascent obtuvo una puntuación de 86/100: limpio, coherente y en consonancia con los gráficos típicos de un juego de plataformas; geometría de plataformas clara; peligros fácilmente identificables; y un HUD moderno y discreto. Algunas limitaciones visuales menores le impiden alcanzar la perfección, pero no hay nada que falle ni nada que haga que el jugador deje de desplazarse por la pantalla.

Métricas de ejecución

La misma partida también registró métricas de proceso. El juego tardó aproximadamente ocho minutos en compilarse, no hubo ningún error de herramientas y la compilación utilizó las habilidades de 3D, interfaz de usuario, edición de scripts, inserción de recursos y audio del juego. Estas métricas no afectan directamente a la puntuación de la evaluación, pero nos indican cómo se creó el juego y señalarían una futura compilación que resultara más lenta o costosa sin aportar ninguna mejora.

A lo largo de cinco etapas, «Skyforge Ascent» obtuvo puntuaciones diferentes en especificaciones del juego, calidad del código, calidad del contenido, pruebas de juego y calidad visual. Cuatro de esas dimensiones indican que «Build» puede convertir una simple indicación en una experiencia de Roblox completa, correcta, jugable y presentable. Una dimensión señala que no es un juego al que nadie elegiría jugar dos veces. Medir esa diferencia, en lugar de ignorarla calculando una media, es el objetivo principal de la evaluación de «Build».

Cómo ha mejorado Build gracias a la evaluación temprana 

Los resultados de la evaluación hacen más que generar puntuaciones: también proporcionan una orientación práctica para mejorar el producto. Al combinar la depuración de componentes individuales con pruebas holísticas a nivel de sistema, las evaluaciones por lotes fuera de línea con conjuntos de indicaciones estandarizados han moldeado directamente el desarrollo de Build. 

1. Resolución rápida de los puntos débiles de los creadores en la fase alfa: en nuestro lanzamiento alfa en Nueva Zelanda, los usuarios nos comentaron que Build a veces creaba un juego en 2D cuando ellos querían uno en 3D. El marco de evaluación ayudó a nuestro equipo a mejorar rápidamente las capacidades 3D de Build. En dos semanas, mejoramos la capacidad de Build para comprender la intención del usuario de crear un juego en 3D, incluso si no lo indicaba explícitamente. También perfeccionamos la jugabilidad y el acabado en 3D corrigiendo problemas habituales relacionados con la posición de los objetos, la iluminación, etc. Desde entonces, las quejas del tipo «no es lo que quiero» se redujeron del 18 % al 3 % del total de quejas; la insatisfacción general tras las pruebas de juego descendió 10 puntos porcentuales. Además, acumulamos conocimientos al iterar sobre el propio marco de trabajo. 
2. Evaluación comparativa entre modelos y arquitecturas: utilizamos nuestro marco de evaluación para comparar rigurosamente las configuraciones del sistema Build con conjuntos de indicaciones estandarizados. Antes de implementar los cambios en producción, los informes de evaluación A/B fuera de línea comparan las versiones candidatas con nuestras referencias de producción en las cuatro dimensiones: 

Por ejemplo, estas comparaciones offline nos permiten aislar cómo las distintas actualizaciones del modelo y las decisiones de enrutamiento de los agentes afectan a las señales de calidad individuales:

• Rendimiento del modelo base: la actualización de nuestro modelo base proporcionó mejoras constantes en todas las señales, lo que se tradujo en menos compilaciones fallidas en el primer intento, un acabado visual superior y un contenido de juego más profundo.
• Arquitectura de enrutamiento de agentes: por el contrario, delegar subtareas específicas a un modelo ligero en una configuración de doble agente preservó la profundidad y la diversidad del contenido, pero provocó fuertes retrocesos en la jugabilidad y el acabado visual.

1. Seguimiento de los niveles de referencia de calidad en distintos paradigmas de creación: También utilizamos el marco para comprender la calidad actual de la compilación en diferentes momentos con el conjunto de evaluación más relevante. Estos conjuntos ofrecen instantáneas de tareas de creación cada vez más amplias y complejas.
   El conjunto más antiguo está compuesto íntegramente por juegos en 2D con mecánicas relativamente sencillas. La lógica del juego era fácil de desarrollar, por lo que la puntuación de las pruebas de juego tendía a ser más alta; por otro lado, la puntuación del contenido se mantuvo baja precisamente por esa misma razón.
   A medida que centramos la atención en los juegos en 3D, la distribución de las puntuaciones cambia de forma natural: jugar sin errores se vuelve más complicado, lo que reduce las puntuaciones de las pruebas de juego. Las puntuaciones visuales se mantienen estables debido a la falta de pulido de los recursos, lo que da a los juegos un aspecto de prototipo. Las puntuaciones de contenido son más altas, ya que los juegos en 3D tienen el potencial de ser más profundos; sin embargo, las puntuaciones generales tienden a mantenerse bajas, ya que las indicaciones de un solo turno ofrecen un margen limitado para la expansión del contenido.

1. Identificación de cuellos de botella específicos de cada género: Los datos de evaluación también ponen de relieve variaciones significativas en el rendimiento entre los distintos géneros. Los géneros que hacen un uso intensivo de la mecánica de juego (por ejemplo, los juegos de rol, los shooters o los de carreras) tienden a presentar más problemas de jugabilidad. Los géneros con una lógica relativamente sencilla (por ejemplo, los juegos de supervivencia y de magnates) suelen obtener mejores resultados en las pruebas de juego, lo que convierte el pulido visual y el diseño de la interfaz de usuario en el siguiente hito que hay que resolver. Conocer la diferencia entre géneros nos anima a ampliar nuestro conjunto de evaluación con un muestreo más equilibrado entre los juegos de Build.
2. Lecciones aprendidas en el diseño del marco de evaluación: Las iteraciones en el propio marco nos han enseñado lecciones fundamentales sobre la fiabilidad del mismo:

• Métricas del sistema frente a métricas de los componentes: una estructura de código limpia o el uso de la API no garantizan que un juego sea jugable. Mantenemos una distinción clara entre corrección, diseño y presentación para evitar que se oculten errores que se puedan solucionar.
• Debilidades del marco de evaluación y calibración humana: Las comprobaciones estáticas pueden pasar por alto errores de tiempo de ejecución que bloquean el juego, mientras que las pruebas de juego automatizadas tienen dificultades con la física compleja. Los «jueces virtuales» se calibran continuamente comparándolos con desarrolladores de videojuegos profesionales y revisores experimentados de la comunidad.
• Ampliación a múltiples turnos y tráfico real: dado que los creadores reales iteran continuamente (añadiendo sistemas, ajustando la dificultad, corrigiendo errores), estamos ampliando nuestro marco de evaluación para evaluar ediciones de múltiples turnos y distribuciones de indicaciones del mundo real.

Próximos pasos

Actualmente nos centramos en ampliar nuestro sistema de evaluación de creaciones «Build» en cinco direcciones:

1. Una cobertura más amplia que abarque distintos géneros, experiencias en 2D, 2,5D y 3D, escenarios multijugador y distintos niveles de complejidad
2. Mayor compatibilidad con las ediciones de múltiples turnos
3. Pruebas de juego, capturas de pantalla, vídeos y pruebas de audio más fiables
4. Calibración con valoraciones humanas a gran escala y casos de referencia propuestos por los creadores
5. Mejor integración entre la evaluación offline, las señales del producto online y las pruebas de regresión

Nuestro objetivo a largo plazo es un sistema de evaluación transparente y en continua mejora que mida Build en el aspecto que más importa a los creadores: la calidad de las experiencias que pueden crear, probar, compartir y seguir desarrollando. En la actualidad, estas señales se utilizan para evaluar los juegos generados por Build. Con el tiempo, a medida que las perfeccionemos y calibramos en función del criterio humano, podrán generalizarse a otros flujos de trabajo de creación y ayudar a proporcionar un lenguaje común para comprender la calidad de los juegos en todo el ecosistema de Roblox.

Para obtener información relacionada con la evaluación de sistemas agenticos para Roblox Assistant, consulta «Uso de OpenGameEval para evaluar asistentes de IA agenticos para Roblox Studio».