Studio / ROBLOX
El botón calla: una historia de rechazo comprensible en Roblox
Historia ficticia de un taller: pieza incorrecta, mensaje claro, consulta del estado y siguiente intento seguro. Distingue espera, rechazo, aceptación, finalización y fallo de visualización.
Abrir imagen a tamaño completo ↗Un taller ficticio y una flecha que no encaja #
Esta es una historia educativa ficticia, no una reseña, biografía ni informe de arreglos en nuestros juegos. Mara imagina un prototipo pequeño de Roblox: sobre una mesa hay un poste indicador, una flecha corta y una tabla larga. El jugador debe seleccionar la flecha corta e instalarla en la ranura libre. El botón dice Instalar flecha.
Leo toma la tabla larga y pulsa. El botón se oscurece, pero el poste sigue igual. Espera, pulsa otra vez y mueve la cámara. No sabe si la pieza es incorrecta, está demasiado lejos o la solicitud continúa pendiente. En la premisa, se rechazó la pieza equivocada. La pantalla no lo dice. La historia empieza con silencio tras un rechazo, no con una ruta perdida ni una recompensa inadvertida.
1. El silencio obliga a adivinar #
Mara propone primero destacar más el botón. En la escena imaginaria Leo responde: «Ya veo dónde pulsar. No sé qué ocurrió». El resaltado demuestra reacción a la entrada, no la decisión de la operación. Un borde rojo sigue dejando varias causas posibles si falta explicación dentro.
En el papel aparecen tres mensajes débiles: Error, No permitido e Inténtalo otra vez. El primero no identifica el problema, el segundo no explica una condición y el tercero puede repetir la misma acción inválida. No necesitan ser falsos para resultar poco útiles. Mara conserva el botón y cambia la pregunta: ¿qué estado confirmado debemos nombrar, qué causa podemos explicar y qué puede hacer Leo realmente después?
2. Escribe la regla antes de embellecer la frase #
El poste imaginario tiene tres condiciones elegidas: personaje cerca, flecha corta seleccionada y ranura libre. Son reglas de este prototipo ficticio, no requisitos universales de Roblox. Si una acción modifica el mundo, el servidor comprueba las condiciones pertinentes. Un botón local visible o una indicación oculta no concede permiso por sí mismo.
Mara separa texto y decisión. Un mensaje explica un resultado conocido de la comprobación, no la sustituye. Para la pieza incorrecta: «Necesitas la flecha corta. Selecciónala en la bandeja izquierda y pulsa Instalar flecha». Nombra objeto y siguiente paso. Si cambia la posición de la bandeja, también debe cambiar la frase. Una explicación bonita que señala el lugar equivocado crea otro acertijo.
3. Dale a la espera un nombre propio #
En la segunda versión, enviar la acción muestra «Solicitud enviada. Esperando el resultado». Es espera, no rechazo ni flecha instalada. Permanece una salida clara del panel. Mara no dibuja una marca verde de antemano: después Leo tendría que averiguar por qué desapareció el éxito.
Mientras se desconoce el resultado, otra pulsación no debería crear copias descontroladas. Desactivar el botón ayuda a la interfaz; gestionar repeticiones en el servidor necesita diseño propio. Una espera prolongada pasa a «Resultado todavía desconocido. Consulta el estado». Solo sirve si existe una vía de consulta. El equipo ficticio la especifica antes. Aquí no hay una solicitud de estado funcional, script ni duración de espera válida universalmente. La animación de espera tampoco establece el resultado.
4. Aceptar todavía no es finalizar #
La siguiente tarjeta dice «Solicitud aceptada. Instalando la flecha». Úsala solo si la implementación distingue de verdad aceptación y finalización. Confirmar recepción no puede convertirse por nombre en una acción terminada. Si la operación es inmediata y no tiene esa fase, sobra inventar otra tarjeta.
En nuestro diseño, una operación aceptada espera su resultado final. El permiso no es el poste modificado. El botón no promete que la pieza ya esté instalada ni invita a ejecutar otra vez la operación aceptada. Mara mantiene estados simples sin fusionarlos por una animación breve. Leo explica: «El sistema se ha hecho cargo, pero todavía no tengo confirmación del final». Es una frase del personaje ficticio, no un hallazgo de pruebas de usuarios.
5. Un rechazo útil ofrece un paso posible #
Con la pieza incorrecta aparece la frase de la flecha corta. A demasiada distancia: «Acércate al poste y después prueba Instalar flecha». Si está ocupado: «Hay una operación en este poste. Espera su resultado y consulta el estado». Cada causa corresponde a una condición de esta escena concreta.
«Lo hiciste todo mal» no describe un estado ni indica cómo avanzar. Tampoco hace falta explicar cada error con un relato técnico largo. Basta un hecho claro y una acción. Si el rechazo confirma que nada cambió, se puede decir «Flecha no instalada». Sin confirmación sería demasiado seguro. La tabla reúne sustituciones propuestas. Compáralas con la implementación real en lugar de asociarlas indiscriminadamente a cualquier respuesta. Una frase amable no debe ocultar incertidumbre.
| Texto débil / estado | Mensaje propuesto | Estado conocido y siguiente paso |
|---|---|---|
| Error / pieza incorrecta | Hace falta flecha corta. Elígela en la bandeja izquierda e instálala. | Rechazo confirmado; corregir selección y enviar otra acción |
| No permitido / lejos | Acércate al poste y prueba Instalar flecha. | Rechazo por distancia actual; cambiar posición |
| Repetir / otra operación | Hay una operación en este poste. Espera su resultado y consulta el estado. | No promete nueva instalación; aclarar estado primero |
| Ranura ocupada | Ranura ocupada. Mira el poste: no hace falta repetir instalación. | Ranura ocupada conocida; no prueba éxito de tu solicitud |
| Listo / solo aceptación | Solicitud aceptada. Instalando la flecha. | Aceptación confirmada, finalización todavía no |
| Fallo / resultado desconocido | Resultado aún desconocido. Consulta el estado. | Desconocido no es rechazo; debe existir vía de consulta |
| Error / panel tras cambio | No se actualizó el panel. Consulta el poste antes de repetir. | Fallo visual separado del estado de operación |
6. Resultado desconocido no significa rechazo #
Mara dibuja un caso incómodo: se envió la solicitud, la flecha pudo instalarse, pero la respuesta no apareció en el panel. El silencio solo no justifica «Acción fallida». «Instala otra vez» podría repetir innecesariamente la operación. Lo desconocido debe seguir siendo desconocido hasta aclarar el estado.
La vía propuesta consulta el mismo poste y relaciona su estado con la acción concreta. El contrato incluye identificador de operación, estado conocido y siguiente paso permitido. El estado del mundo no demuestra el resultado de tu solicitud concreta; comprueba esa relación por separado. Es un esquema de diseño, no garantía de entrega ni protección lista contra duplicados. Si se permite repetir, el servidor vuelve a comprobar condiciones actuales y tiene en cuenta una acción ya procesada. Reintentar automáticamente sin fin no resulta seguro por tener un indicador atractivo.
Abrir imagen a tamaño completo ↗7. Un fallo visual no desinstala la flecha #
Ahora la flecha ficticia está en su ranura, pero actualizar el texto genera un error. Antes Mara habría llamado Fallo a todo. Ahora separa resultado y visualización: «No se pudo actualizar el panel. Consulta el estado del poste antes de repetir». Eso no demuestra que fracasara la instalación.
Una llamada protegida pcall en Luau puede capturar un error de función y devolver un estado de fallo; por sí misma no deshace un cambio previo del mundo. Gestionar excepciones no sustituye el contrato de operación. Los detalles técnicos ayudan al desarrollador a diagnosticar; el jugador necesita una continuación segura. No ofrecemos código pcall, registros de un proyecto real ni afirmamos que la frase esté conectada a una estación funcional. Son dos capas que deben observarse por separado.
8. El mensaje necesita espacio y accesibilidad #
Mara reserva una zona estable cerca de la interacción: el estado no desaparece inmediatamente bajo el siguiente resaltado. Elige un TextLabel legible y TextButtons claros. Roblox proporciona esos elementos; significado del rechazo y elección del siguiente paso siguen siendo trabajo de quien diseña el prototipo.
El color no lleva todo el significado. Junto al acento aparecen Esperando o No instalada y una explicación. El sonido puede acompañar, pero el silencio no debe ocultar el mensaje. Comprueba contraste, tamaño y preferencias de texto mayor. Acorta una causa por su significado antes de reducirla a letras minúsculas. En una pantalla pequeña importan tanto explicación como acción disponible, no solo decoración. El lector debe ver dónde continuar después de entender el motivo.
9. Traduce la acción, no la longitud #
El equipo imaginario admite seis idiomas. Short arrow required y el alemán Ein kurzer Pfeil wird benötigt tienen longitudes distintas. La traducción debe mantener la flecha corta como pieza concreta, no referirse por accidente a cualquier poste. Leo lee una instrucción localizada; los estados internos mantienen identificadores separados del proyecto.
Roblox ofrece herramientas de localización y traducción manual. Ayudan a preparar texto sin eliminar revisión de contexto y composición. En chino comprueba saltos y legibilidad; en árabe dirección y etiquetas mixtas. Cada idioma necesita causa y siguiente paso completos. No traduzcas Consultar estado como Ejecutar otra vez: son acciones diferentes. Una traducción automática no demuestra que el jugador entienda el rechazo. La frase y el botón deben expresar la misma acción en su contexto.
10. Empieza las pruebas por casos negativos #
En su última hoja Mara anota más que una instalación correcta. Incluye pieza equivocada, personaje lejos, estación ocupada, espera sin resultado, otra pulsación antes de respuesta y fallo visual tras cambio confirmado. Define mensaje esperado, estado conocido y siguiente paso permitido para cada caso. La tabla de pruebas queda sin completar.
Otro jugador puede ocupar la ranura entre mostrar el botón y enviar la solicitud. Una interfaz antigua no anula la comprobación actual. Considera además respuestas tardías: no deben sustituir mensajes de otra acción más reciente. Son requisitos futuros, no pruebas realizadas. Vincula acción y respuesta en el registro para investigar sin adivinar. Unos conflictos concretos ayudan más que el punto general «probar errores», especialmente cuando dos acciones parecen iguales en pantalla.
| Escenario | Contrato esperado | Versión / observación |
|---|---|---|
| Tabla larga en vez de flecha | Rechazo: pieza necesaria, ausencia de cambio conocida, nueva selección | — |
| Personaje lejos | Causa de distancia y siguiente paso posible | — |
| Otro jugador llenó ranura | Estado ocupado actual; no prueba éxito de nuestra solicitud | — |
| Pulsar antes y recibir respuesta tardía | Asociar solicitud/respuesta; no borrar otra acción más reciente | — |
| Falta respuesta, resultado desconocido | Consultar estado; sin repetición infinita ni rechazo falso | — |
| Operación confirmada, panel falla | Estado de operación separado de fallo visual | — |
| Cada idioma, texto mayor, sin sonido | Causa y acción legibles; significado no solo color/sonido | — |
11. Leo cambia la pieza y entiende el nuevo intento #
Al final ficticio Leo lee el rechazo, selecciona la flecha corta y comprueba que la ranura esté libre. Envía una nueva acción permitida. El panel muestra espera y después resultado confirmado: «Flecha instalada. Mira el poste». Es otro paso tras corregir una condición, no una cola automática de pulsaciones idénticas. Mara cierra su contrato de mensajes.
La historia termina; la implementación sigue pendiente. Se comprobaron fuentes y estructura del material, pero este prototipo no se ejecutó en Studio ni recogió métricas. El éxito no significa conservar el resultado en otra visita; ese comportamiento no se diseñó. Entrega a otro desarrollador reglas, estados, frases y plan vacío. Un rechazo útil ofrece un camino claro para continuar, conservando la honestidad cuando todavía no se conoce el resultado.
Fuentes originales
Roblox Creator Hub — Accessibility guidelinesText & image labels
Text & image buttons
Localization
Securing the client-server boundary
Luau standard library — pcall
TextLabel
