Studio / ROBLOX
¿De quién es la pista? Historia de una ayuda personal en Roblox
En un taller de viento ficticio, Asya cambia su página de ayuda y Danya pierde la suya. Separa presentación personal, progreso compartido y estado del mundo antes de pedir una corrección.
Abrir imagen a tamaño completo ↗Un taller ficticio con dos páginas diferentes #
Esta es una historia didáctica ficticia sobre un prototipo independiente, no comentarios de jugadores ni un informe de reparación de nuestros juegos. Nika imagina un taller de viento donde dos participantes construyen juntos una rueda de maqueta. La tarea compartida tiene etapas Base, Aspas y Comprobación. El equipo está en Aspas. La rueda ocupa el centro y cada botón personal abre instrucciones.
Asya, A, lee Fijar un aspa. Danya, B, abrió Girar la cámara para observar la unión desde un lado. Asya pasa de página y Danya recibe esa misma página. Vuelve a la cámara, pero la siguiente acción de Asya reemplaza su texto otra vez. Nika identifica una frontera rota entre elecciones personales, no un problema con el tamaño del botón.
1. Un objetivo compartido no comparte todo #
En su conversación imaginada, Danya pregunta: «Construimos una rueda. ¿Por qué tengo que leer tu línea?» Nika confundió trabajar juntos con leer al mismo ritmo. Ambos necesitan conocer la etapa compartida, pero cada participante puede consultar una pista diferente y cerrarla cuando le convenga.
El diseño inicial utilizaba un único valor para la página de ayuda actual del equipo. Cada cambio se enviaba a todos. Esa es la causa elegida para esta ficción; un síntoma parecido en un proyecto real todavía requiere diagnóstico. Nika no acusa a Roblox de unir automáticamente paneles. Describe la conducta no deseada: una entrada de A cambia la elección de B sin motivo compartido. Esa frase ayuda más al desarrollador que «la interfaz está rota».
2. Da nombre a tres clases de estado #
Nika dibuja tres líneas. Presentación personal: ayuda abierta o cerrada, tema elegido y posición de lectura del participante. Progreso compartido: etapa de construcción del equipo. Estado del mundo: piezas realmente instaladas y apariencia de la rueda. Las reglas pueden conectar las dos últimas, pero ninguna reemplaza la primera.
Asya puede leer instrucciones de comprobación antes de tiempo. Leer no adelanta el equipo a esa etapa ni instala un aspa. Cerrar tampoco deshace el trabajo de Danya. Para cada campo Nika identifica responsable, origen del cambio y lectores. Responsable significa aquí pertenencia del estado, no propiedad intelectual del panel. La tabla de contrato describe la arquitectura elegida del prototipo, no reglas universales de todos los juegos cooperativos.
Abrir imagen a tamaño completo ↗3. PlayerGui permite encontrar la copia adecuada #
Roblox describe PlayerGui como contenedor de la interfaz de un jugador. StarterGui guarda elementos iniciales que se copian a PlayerGui en el momento documentado de aparición del personaje. Una plantilla idéntica puede proporcionar una instancia individual a cada participante, en lugar de una página de lectura para todo el equipo.
El contenedor no repara un controlador equivocado. Si la lógica sigue difundiendo el tema de Asya o modificando ambas copias, persiste la conducta indeseada pese a las instancias separadas. Nika distingue plantilla visual y estado del lector actual. Escribe: «Abrir, cerrar y elegir tema pertenecen a quien pulsó». No ofrecemos código ni prometemos que mover un objeto resolvió el problema. Primero hace falta contrato y después comprobar su implementación.
4. El contrato correctivo comienza con la lectura #
Nika elige una regla sencilla: abrir A muestra solo su panel; cambiar temas A modifica su selección; cerrar A deja intacto B. En el servidor S esas entradas no adelantan la construcción ni cambian piezas. La presentación personal de este prototipo se controla localmente, sin enviar cada cambio de página al equipo.
Eso no prohíbe datos personales en el servidor. Una preferencia guardada futura puede diseñarse aparte con pertenencia al jugador concreto. Esta historia no añade persistencia. Nika sustituye «actualizar ayuda» por una lista explícita de campos permitidos para cada acción. Otro desarrollador recibe los límites de la propuesta, en vez de tener que adivinar si toda entrada debe afectar a todas las pantallas o si la palabra compartido se aplica a todo.
| Estado | Responsabilidad | Origen del cambio | No cambia |
|---|---|---|---|
| Visibilidad de ayuda | UI personal de cada jugador | Abrir/cerrar propio | Panel de B o construcción de S |
| Tema y posición de lectura | Lector individual | Selección/desplazamiento propio | Elección de otro participante |
| Idioma del texto personal | Presentación del propio jugador | Ajuste de idioma personal | Idioma B o etapa compartida |
| Etapa de tarea del equipo | Fuente compartida del servidor | Trabajo según reglas del prototipo | No exige abrir todas las ayudas |
| Piezas instaladas | Mundo confirmado por el servidor | Acción de juego permitida | No se deduce de una página leída |
| Encabezado de etapa actual | Hecho común mostrado en UI personal | Información actual de S | No selecciona el tema de B |
5. La etapa del equipo sigue importando a ambos #
Nika descubre el extremo contrario: ignorar el progreso compartido podría dejar instrucciones de una etapa ya terminada. Conserva la fuente de estado del equipo en el servidor. El trabajo realmente realizado según las reglas del prototipo lo modifica; el texto cliente muestra información confirmada. Página siguiente no concede permiso para cambiar el mundo.
Una etapa nueva debe comunicar información actual a ambos sin obligarlos a abrir el mismo tema. En este diseño se actualiza el encabezado de etapa, la ayuda cerrada permanece cerrada y el tema aplicable sigue seleccionado. Un hecho compartido no ordena pasar todas las páginas. Si se usan mensajes a clientes, sus destinatarios dependen del significado: respuesta personal y actualización de equipo son distintas. El transporte no demuestra pertenencia correcta del estado.
6. Una pista antigua necesita una transición clara #
Asya lee instrucciones de aspas cuando el equipo llega a Comprobación. Nika decide antes el comportamiento: conservar la visibilidad personal, mostrar «La etapa cambió: ahora Comprobación» y ofrecer el tema vigente. El contenido que ya no aplica lleva una indicación explícita. No debe aparentar silenciosamente que sigue siendo la tarea actual.
Es una decisión de diseño, no una función automática de PlayerGui. La información tardía debe asociarse con etapa y tema actuales para no reemplazar una elección personal más reciente. Hasta implementarlo, queda como requisito. No hace falta abrir la ayuda de todos en cada evento. Cada participante conserva su recorrido de lectura y el equipo recibe un hecho común que puede comprobarse. Un criterio escrito todavía no acredita el comportamiento real.
7. Una ayuda accesible también es personal #
Nika rotula una zona del dibujo Mi ayuda y otra Etapa del equipo. Azul y naranja no bastan para comunicar la pertenencia: las palabras explican la diferencia. La página incluye título del tema y una acción de cierre comprensible. El texto ampliado no debe expulsar esas referencias del espacio accesible.
Roblox recomienda atender legibilidad, contraste y preferencias del jugador, sin transmitir significado únicamente mediante sonido o color. Las recomendaciones mejoran presentación sin elegir al responsable de los datos. Nika planea comprobaciones aparte de textos largos, navegación y cierre en los dispositivos necesarios. No declara medidas ideales ni llama captura de una interfaz funcionando a nuestro diagrama. La ayuda sirve cuando el participante entiende tanto el texto como qué acciones pueden cambiarlo.
8. Traducir cambia palabras, no la etapa compartida #
En el diseño Asya lee ruso y Danya inglés. Longitudes y órdenes distintos pueden describir una misma etapa. Su identificador interno no debe depender del encabezado traducido. Tampoco cambia el dueño del estado al elegir otro idioma.
Roblox ofrece herramientas de localización y traducciones manuales. Nika las usa para preparar frases con contexto, no para comparar palabras visibles en la lógica del juego. Mi ayuda y Etapa del equipo se traducen completas. En árabe se revisan dirección y etiquetas mezcladas; en chino, saltos de línea. La traducción automática no demuestra una distinción clara entre personal y compartido. Según el contrato, cambiar el idioma A no elige el de B ni adelanta la construcción. Habrá que verificar esa conducta.
9. Reaparecer no decide la pertenencia #
Nika incorpora la reaparición de A al plan futuro. Esta versión pretende devolver su ayuda cerrada y leer de nuevo la etapa compartida actual. B continúa usando su panel. Es una política elegida, no una promesa sobre el comportamiento predeterminado de cualquier juego.
La interfaz al aparecer un personaje depende de ajustes, entre ellos ResetOnSpawn de LayerCollector, heredado por ScreenGui. Conservar la instancia del panel y recuperar contenido correcto son cuestiones diferentes. Nika pide revisar jerarquía y ajustes reales, sin confiar en la propiedad general obsoleta ResetPlayerGuiOnSpawn. No cambiamos ningún proyecto ajeno. Nueva visita, reaparición y cierre permanecen casos separados; ninguno garantiza por sí mismo conservar lectura entre visitas.
10. Deja vacío el plan de observación #
La última hoja comienza con A leyendo Aspas, B leyendo Cámara y S en la etapa Aspas. Casos separados cubren pasar página, cerrar, entradas próximas de ambos, cambio compartido, actualización tardía, reaparición e idiomas. Las expectativas se definen primero; las celdas reales A/B/S quedan vacías.
Si una prueba futura encuentra cambios en B tras una entrada personal A, registra tema, orden y etapa antes de suponer una línea de código. Que ambos paneles reciban una etapa nueva después de trabajo compartido puede ser correcto. No copies el valor del servidor en la observación B. La guía vinculada explica cómo iniciar dos clientes. Esta historia entrega criterios de pertenencia en lugar de repetir botones de Studio; no certifica un prototipo sin ejecutarlo.
| Caso / entrada | Expectativa del contrato | A: real | B: real | S: real |
|---|---|---|---|---|
| A pasa página con temas A/B diferentes | Solo cambia lectura A; S no cambia | — | — | — |
| A cierra mientras B mantiene ayuda abierta | A cerrada; B sigue leyendo | — | — | — |
| A/B eligen temas próximos | Cada uno conserva elección; registrar orden | — | — | — |
| Equipo completa acción para nueva etapa | Etapa común actual; sin imponer visibilidad personal | — | — | — |
| Actualización antigua tras selección reciente | Asociar etapa/tema; no reemplazar selección nueva | — | — | — |
| A reaparece | Política elegida: A cerrada, B intacto, etapa actual | — | — | — |
| Idiomas A/B distintos y texto largo | Personal/equipo claros; idioma B y etapa intactos | — | — | — |
| Leer comprobación antes de tiempo | La lectura no adelanta construcción ni instala piezas | — | — | — |
11. Nika cierra el dibujo, no la investigación #
En el final imaginado Asya pasa su página, Danya continúa con la cámara y la lectura no altera la rueda. Nika adjunta estados, reglas de destinatario, transición de etapa y tabla vacía al encargo. Ese final representa el resultado deseado, no una prueba de juego realizada.
La implementación está pendiente. Se revisaron fuentes oficiales, texto y diagramas, pero no se ejecutaron Studio, servidores públicos ni nuestros juegos. Tras cambiarlo, un desarrollador debe confirmar el contrato con dos clientes y los dispositivos necesarios. El objetivo sigue compartido mientras cada participante lee a su ritmo. Lo útil es explicar exactamente qué pertenece al jugador, qué al equipo y qué confirma el mundo, en lugar de una sola variable ambigua llamada ayuda.
Fuentes originales
Roblox Creator Hub — PlayerGuiRoblox Creator Hub — StarterGui
Roblox Creator Hub — Client-server runtime
Roblox Creator Hub — Remote events and callbacks
Roblox Creator Hub — LayerCollector / ResetOnSpawn
Roblox Creator Hub — Localization
Roblox Creator Hub — Accessibility guidelines
