Studio / ROBLOX
Cliente y servidor en Roblox Studio: comparar el estado durante una prueba
Identifica qué lado observas, localiza un objeto y relaciona Explorer con Output. Con un marcador de práctica, un registro claro y una comprobación después de detener la simulación.
Formula una pregunta precisa #
«El objeto cambió» no basta para investigar un problema. Indica dónde lo viste: en la vista del cliente, en el árbol del servidor o en un registro. Elige un elemento inofensivo de un prototipo separado, como un Part anclado llamado ContextMarker. No utilices monedas, compras ni datos guardados del jugador como indicador de práctica.
Nuestra pregunta es: «¿Qué valor de propiedad observo a cada lado de esta prueba?». Es distinta de comparar varios jugadores o comprobar la persistencia entre visitas. Anota Workspace → ContextMarker y una propiedad, por ejemplo Color. El marcador es una propuesta; para este artículo no se modificaron juegos propios ni se realizaron pruebas en Studio.
Inicia un modo adecuado #
Selecciona Test o Test Here en el menú de pruebas e inicia la simulación. La documentación describe simulaciones separadas de cliente y servidor para estos modos individuales. Test inserta un personaje; Test Here utiliza el área frente a la cámara actual. El ejercicio no requiere abrir varias ventanas de cliente.
No sustituyas sin revisar un recorrido normal por Run: ese modo no inserta un avatar. Registra el modo y las condiciones iniciales antes de comparar. Si el prototipo necesita un personaje, comprueba que aparece. Dos registros de modos diferentes pueden reflejar distintos puntos de partida; empieza con una configuración constante.
Identifica el lado activo #
Durante la prueba individual utiliza el selector Client/Server. Su estado indica la simulación que observas. Anota el lado antes de leer cualquier propiedad y revísalo tras cambiar. Una cámara junto al mismo objeto no confirma el mismo contexto: vistas parecidas del mundo pueden pertenecer a lados distintos.
Etiqueta los registros «Client» y «Server», manteniendo los nombres de Studio. Una captura del árbol sin esa indicación puede confundirse más tarde con otra observación. Los dos paneles de nuestro dibujo representan contextos, no dos jugadores reales. No son capturas de Studio ni pruebas del estado de un proyecto en ejecución.
Busca la ruta completa del objeto #
En Client abre Explorer y encuentra la ruta elegida. Cambia a Server y revisa la misma ruta y propiedad. Comprueba padre y nombre: otro ContextMarker en un modelo diferente es otro objeto. Si el elemento no está, registra su ausencia en vez de inventar el valor esperado.
Las jerarquías dependen del contexto. La documentación muestra PlayerScripts en el cliente y ServerScriptService y ServerStorage en el servidor. Que un objeto exista en almacenamiento del servidor no confirma el acceso desde el cliente. Con streaming activado, el cliente también puede recibir inicialmente solo parte de Workspace; es una cuestión distinta de un nombre mal escrito.
Abrir imagen a tamaño completo ↗Guarda el par inicial de observaciones #
Antes de cambiar algo, anota dos filas: Client, ruta completa, valor observado; Server, la misma ruta, valor observado. Añade el momento o paso del escenario. No declares iguales los valores hasta leer ambos. La tabla del artículo propone un formato, no un registro completado de una prueba nuestra.
Si ya difieren, revisa primero si un script existente modifica la propiedad o si comparaste objetos o momentos distintos. Evita añadir comportamiento nuevo sobre un estado inicial sin explicar. Un prototipo sencillo y separado facilita la práctica, porque puedes identificar qué podría afectar la propiedad elegida del marcador.
Abrir imagen a tamaño completo ↗Cambia una cosa y compara otra vez #
En una prueba de práctica separada, elige Client y edita una sola propiedad del marcador mediante Properties. Registra inmediatamente dónde se hizo el cambio y lee luego el valor en ambos lados. El objetivo es distinguir lugar de acción y lugar de observación, no demostrar una regla universal para todas las propiedades de Roblox.
Detén la prueba, recupera las condiciones iniciales y realiza una comparación aparte con un cambio en Server. No mezcles ambos cambios en una secuencia sin registro: un script, una demora o otra edición pueden influir. Si el resultado no es el esperado, conserva ambos registros y condiciones; un solo color no demuestra que la replicación esté rota.
Relaciona el resultado con Output #
Abre Output y revisa el origen de los mensajes. Roblox describe etiquetas azules para cliente y verdes para servidor; en ModuleScript el lado depende de quién llama al módulo. El color es una pista adicional, pero también necesitas el texto del mensaje y la ruta a su origen para investigar.
Si el prototipo ya incluye diagnósticos, compara su momento y objeto con el registro de Explorer. Un mensaje «listo» sin lado o valor relevante explica poco. En un caso ficticio, la interfaz dice «seleccionado» mientras el registro corresponde a otro objeto. Coincidir en palabras no demuestra que el servidor confirmó esta acción concreta.
Revisa tipo y ubicación del script #
Cuando falta el mensaje esperado, comprueba el tipo, ubicación y RunContext si se trata de un Script. Su icono o el nombre Script no determinan por sí solos el lado de ejecución. Roblox explica que Script puede ejecutarse en cliente o servidor según contexto y lugar; LocalScript se ejecuta en el cliente.
No muevas scripts que funcionan al azar para obtener una línea en Output. Registra primero sus rutas y ajustes y compáralos con la guía oficial. En ModuleScript también importa quién lo llama. Cambiar código de lugar puede introducir otra ejecución o un problema diferente; cada cambio requiere una observación independiente.
| Comprobar | Por qué importa |
|---|---|
| Script | Ubicación y RunContext |
| LocalScript | Contexto de cliente y lugar adecuado |
| ModuleScript | Qué lado llama al módulo |
Distingue detener de guardar #
Stop termina la simulación y devuelve los objetos a su estado anterior a la prueba. Después revisa el marcador inicial en modo edición. Un cambio visto solo durante la simulación no es automáticamente una edición guardada del proyecto. Registra el lugar real donde editaste, en vez de deducir persistencia de un resultado temporal.
El ejercicio no verifica DataStore, una compra ni una nueva visita a una experiencia publicada. Comparar correctamente dos contextos no demuestra que los datos persistan entre sesiones. Esas preguntas requieren otro escenario con fuentes y condiciones adecuadas. No añadas una conclusión de guardado permanente a un registro sobre un color.
Escribe una conclusión limitada #
Registra modo, lado del cambio, ambos lados de observación, ruta, propiedad, secuencia y mensaje de Output relacionado. Describe con precisión: «Este valor se observó en este lado durante este paso». Enumera aparte lo que no se probó: otros clientes, red, nueva entrada o lógica real de juego.
Tras corregir, repite el mismo escenario desde las condiciones iniciales. Si preguntas qué ven otros jugadores, usa una prueba separada Server & Clients; el selector no la sustituye. Este artículo aporta un método y dibujos originales. No afirma resultados reales de Studio, cambios en juegos propios ni mediciones de replicación.
| Registro | Qué guardar |
|---|---|
| Inicio | Modo y condiciones iniciales |
| Cambio | Lado, ruta y una propiedad |
| Observación | Ambos lados y mensaje de Output |
| Límite de conclusión | Preguntas todavía no probadas |
Fuentes originales
Roblox Creator Hub — Studio testing modesRoblox Creator Hub — Client-server runtime
Roblox Creator Hub — Script types and locations
