Studio / ROBLOX
Pantalla de teléfono en Roblox Studio: comprobar inventario y controles
Usa Device Simulator para una tarea completa: abrir un panel, elegir un artículo, escribir una búsqueda y salir. Distingue orientación, escala y límites de la simulación sin prometer el mismo rendimiento en todos los teléfonos.
Elige una tarea pequeña con un resultado claro #
Para la primera pasada, usa un inventario de práctica: abre el panel, elige un artículo, lee su descripción y ciérralo. Es más repetible que simplemente «comprobar la versión móvil». Anota el estado inicial: panel cerrado, ningún artículo elegido y personaje siempre en el mismo lugar.
Es un ejercicio propuesto, no un inventario que el simulador crea automáticamente. Necesitas un panel de prueba propio o un prototipo existente. Define el resultado esperado: por ejemplo, el artículo elegido sigue legible y salir no requiere una tecla de ordenador. Este artículo no contiene pruebas reales de nuestros juegos publicados.
Encuentra el Device Simulator actual y considera su beta #
La documentación de Roblox revisada el 7 de octubre de 2026 describe el nuevo Device Simulator como beta. Su ruta de activación es File → Beta Features → New Device Simulator, seguida de un reinicio de Studio. Guarda antes el proyecto de práctica. La guía trata de esta herramienta concreta; una interfaz beta puede cambiar.
Con un place abierto, la barra está sobre el visor 3D y disponible durante edición y pruebas. Si ves la herramienta antigua, registra la versión y si existe la opción nueva en lugar de dar por hecho dónde está un botón. Comprobar la distribución no requiere conectar el prototipo con guardados reales de jugadores.
Elige un perfil y registra sus ajustes iniciales #
La categoría Phone contiene teléfonos y tabletas. Pulsar una categoría elige su dispositivo predeterminado; el elemento con el nombre del dispositivo activo abre el menú de perfiles. Empieza con un teléfono y anota nombre, dimensiones, orientación y modo Display scaling. Son datos de tu prueba, no del hardware de un visitante real.
Distingue los perfiles simulados de Current device: la documentación describe este último como tu monitor y entrada sin simulación. Una pasada con Current device no debe etiquetarse como prueba de teléfono. Mantén el mismo comienzo de la tarea para comparar el comportamiento visual del siguiente perfil, no otra situación de juego aleatoria.
Repite el recorrido en ambas orientaciones #
Abre el panel, elige el mismo artículo, lee la descripción y encuentra la salida. Después usa Rotate para teléfono o tableta y repite. Examina elementos concretos: título, fila seleccionada, descripción, desplazamiento y botón de cierre. No basta con que el panel entero quepa de alguna manera.
Un resultado esperado del ejercicio sería que, tras girar, la selección siga clara, el texto no tape la salida y cerrar no active un artículo debajo. Son requisitos del prototipo que debes comprobar, no garantías de la herramienta. Si falla, registra el paso y la orientación antes de cambiarlo.
Abrir imagen a tamaño completo ↗No confundas el zoom cómodo con el tamaño físico #
Display scaling ofrece distintas formas de mostrar el dispositivo en el monitor. Physical size busca su tamaño físico, Actual resolution relaciona píxeles y Fit to window ocupa el área disponible. Una escala física correcta necesita información del monitor mediante detección automática o calibración manual.
Usa primero una vista cómoda para encontrar solapamientos y evalúa después texto y botones con una calibración física adecuada. Un botón grande en una imagen ampliada no demuestra comodidad en el teléfono. Registra siempre el modo: dos capturas del mismo perfil pueden dar impresiones diferentes sin cambiar el juego.
| Display scaling | Qué compara |
|---|---|
| Physical size | Tamaño físico con calibración |
| Actual resolution | Correspondencia de píxeles |
| Fit to window | Ajuste al área disponible |
Comprueba el recorrido de entrada disponible #
Con el perfil de teléfono, realiza la tarea por la ruta táctil prevista: abrir, elegir, desplazar y cerrar. Touch controls enumera los atajos de teclado y ratón que simulan gestos. Sigue esas indicaciones en lugar de adivinar qué gesto representa un arrastre.
Que un botón sea visible no demuestra que su acción funcione. Anota qué elemento activaste y qué estado cambió. Para un inventario resulta útil volver a abrir después del cierre: ¿queda un panel invisible que bloquea la siguiente entrada? Es una pregunta sobre tu implementación que la simulación ayuda a observar.
Abre la búsqueda y observa el teclado en pantalla #
Si el panel de práctica tiene buscador, registra primero su estado sin foco; después elige el campo y escribe un nombre corto. Device Simulator también permite examinar el teclado en pantalla. Compara si siguen accesibles el campo, el resultado, el artículo elegido y la acción necesaria para terminar de escribir.
Defecto ficticio: el teclado tapa la única salida y el cierre previsto deja de funcionar. Registra la secuencia exacta en lugar de «el teléfono está roto». Repite tras girar y tras quitar el foco. No necesitas añadir una búsqueda solo por el artículo si tu tarea real no la utiliza.
Compara teléfono, tableta y escritorio #
Después del primer teléfono, repite la misma ruta con tableta y perfil de escritorio. Cambia una variable cada vez: primero el perfil con la misma escala, después la orientación. Anota qué problemas se repiten y cuáles aparecen solo en una combinación. Es más fácil de interpretar que tres sesiones de juego distintas.
Empieza con un conjunto pequeño que puedas repetir habitualmente. Tres pasadas documentadas con honestidad ayudan más que una larga lista de dispositivos sin resultados. Una imagen de escritorio no demuestra entrada táctil; un perfil de teléfono no demuestra condiciones de red. La conexión requiere otro plan con Network Simulator.
Corrige un problema y reproduce su ruta #
Describe el defecto con elemento y paso: «La descripción del artículo elegido tapa la salida después de girar». Examina distribución y estados de tu panel; el simulador no los repara automáticamente. Cambia una causa y repite las condiciones iniciales anteriores antes de pasar a otra mejora.
Otro artículo con un nombre más corto no demuestra que se corrigió el problema anterior. Usa el mismo texto y estado que lo provocaron. Conserva registros de antes y después, y comprueba brevemente un perfil cercano: un cambio local puede modificar otra distribución. El artículo describe un plan, no una reparación ejecutada.
Registra resultados aparte de las pruebas reales #
Un registro útil incluye perfil, orientación, escala, estado inicial, pasos, resultado esperado y observado. Marca por separado «planificado», «reproducido en simulación» o «probado en dispositivo real». Elegir un modelo conocido en el menú no justifica el último estado.
La simulación ayuda a examinar distribución y entrada, pero no demuestra por sí sola los mismos FPS, calidad de conexión o ausencia de todos los errores en un teléfono concreto. Prueba hardware y red por separado cuando estén disponibles. Nuestros diagramas originales muestran la tarea y el registro de comprobación, no capturas de Studio ni mediciones.
Abrir imagen a tamaño completo ↗| Estado | Qué permite afirmar |
|---|---|
| Planificado | Existe ruta, aún no hay resultado |
| Simulación realizada | Observación en el perfil registrado |
| Dispositivo real probado | Pasada real separada |
Fuentes originales
Roblox Creator Hub — Device SimulatorRoblox Creator Hub — Studio testing modes
