Studio / ROBLOX
La primera recompensa que nadie vio: una historia ficticia de un prototipo Roblox
Una historia didáctica sobre una batería entregada y una llave azul: mostrar la finalización, encontrar el objeto, distinguir entrega y guardado, y preparar pruebas sin resultados inventados.
Abrir imagen a tamaño completo ↗El taller que nunca dijo «terminado» #
Esta es una historia didáctica ficticia. El muelle, el prototipo «Taller de linternas», la desarrolladora Mira y la jugadora Lina son inventados para explicar un problema de interfaz. No es una reseña real, una biografía ni un informe de pruebas realizadas. No modificamos los cinco juegos del autor del sitio para esta escena. Los cambios son propuestas para este pequeño prototipo imaginario.
Una barca se balancea junto al muelle. La lámpara del taller se apagó y el encargado pide una batería. El primer encargo promete una llave inglesa azul para la siguiente reparación. Recoger, entregar y recibir: una tarea pequeña. Lina ya comprende el recorrido. El problema empieza al terminarlo: ¿cómo sabe que aceptaron su trabajo?
1. La batería desapareció, la pregunta siguió #
Lina deja la batería sobre la mesa. La lámpara se enciende, el objeto desaparece de su mano y el encargado mira hacia la barca. En la esquina sigue «Traer una batería». El contador de monedas no cambia, porque la recompensa no son monedas. Lina mira la lámpara y su mano vacía: «¿Ya recibí la llave o tengo que pulsar otra vez?»
Mira sabe que la llave debe aparecer entre las herramientas. Lina desconoce esa relación. La desaparición podría significar entrega, pérdida o fallo. Otra flecha de recorrido resolvería el problema equivocado: la jugadora llegó. Falta una respuesta a la acción completada. Mira anota una pregunta: ¿qué debería poder nombrar la jugadora después de entregar?
2. La celebración no respondió a la pregunta #
La primera propuesta de Mira son chispas sobre la mesa. En la siguiente escena imaginada, la lámpara tiene un brillo bonito. Resulta agradable, pero solo indica que algo sucedió. ¿Qué se entregó como recompensa? ¿Dónde está? ¿Debo repetir la entrega? Las preguntas siguen. Un sonido más fuerte tampoco nombra el objeto, especialmente con el audio desactivado.
Mira conserva un pequeño acento luminoso como decoración, pero deja de tratarlo como todo el sistema de confirmación. Dibuja tres espacios: encargo completado, objeto recibido y siguiente acción disponible. Si no puede rellenar uno con palabras sencillas, una animación no arregla el significado. Primero debe definir la respuesta y después un efecto que la acompañe.
3. El acuerdo de recompensa cabe en una línea #
Antes de decorar, Mira escribe: «El primer encargo de batería entrega una llave azul al inventario de herramientas». El personaje la conserva; otro intento de terminar ese mismo primer encargo no añade una segunda. Es la regla del prototipo ficticio, no una norma universal de recompensas Roblox. Un encargo repetible necesitaría condiciones distintas.
Ahora el indicador relevante está claro: la llave en el inventario y el estado del primer encargo, no un contador general de dinero. Mira define también qué significa completado, cuándo se permite reparar y qué datos deben sobrevivir a otra visita. Una línea relaciona interfaz y diseño. No prueba que la implementación funcione, pero hace visible una contradicción: dos llaves por una entrega inicial.
4. El mensaje sigue a una acción confirmada #
Mira propone «Batería entregada. Llave azul recibida» junto a la tarea actual. Debe aparecer después de comprobar la finalización y la recompensa en el estado del juego, no simplemente después de pulsar un botón. Durante la espera hace falta otra respuesta: «Comprobando entrega». Así se distingue una solicitud de su resultado.
Debajo aparece «Abrir herramientas». Un sonido corto y un brillo pueden acompañar el mensaje sin sustituirlo. El diario pasa a completado solo en el estado correspondiente. El texto nombra objeto y acción, en lugar de un «¡Éxito!» impreciso. Mira comprobará su posición: no debe cubrir los controles móviles ni desaparecer antes de que la jugadora pueda mirarlo.
5. La recompensa se encuentra después de cerrar el mensaje #
La Lina imaginaria abre las herramientas. En la propuesta, la tarjeta dice «Llave azul» y usa el mismo icono del mensaje. Un resaltado breve señala esa tarjeta concreta. Al lado figura su utilidad: «Para la siguiente reparación». Una imagen desconocida ya no obliga a adivinar qué objeto acaba de añadirse.
El inventario sigue siendo un lugar para verificar el resultado después de cerrar el aviso. Mira no destaca tienda, colección, ajustes y todas las tareas futuras a la vez. Ahora importa un encargo y una herramienta. Si se vuelve a consultar la entrada, los nombres deben coincidir. Es el inventario propio del prototipo, no una compra de avatar ni una entrega automática de un objeto para toda la plataforma Roblox.
6. El estado del encargo y el guardado son distintos #
Mira coloca tarjetas: encargo activo, entrega en comprobación, recompensa recibida y resultado guardado para la próxima visita. La última no aparece automáticamente porque se vea un objeto. La interfaz podría mostrar «Llave recibida. Guardando…» cuando la entrega de recompensa está confirmada y el guardado pendiente. «Guardado» necesita su propia base.
La desarrolladora necesita estados internos precisos; la jugadora, respuestas comprensibles. Una espera no debe parecer error y finalización al mismo tiempo. Si solo se conoce la solicitud, no presentes la llave como poseída. Si se conoce la recompensa pero no el guardado, no conviertas la sesión actual en una promesa sobre la próxima. El esquema permite debatirlo antes de programar.
Abrir imagen a tamaño completo ↗7. Pulsar de nuevo comprueba la regla, no da otra recompensa #
Lina puede perderse la respuesta y volver a pulsar. Mira propone cambiar temporalmente el botón a «Comprobando», para que la pantalla no invite a pulsaciones infinitas. Cambiar el botón por sí solo no protege la entrega: las solicitudes repetidas y el derecho a la recompensa pertenecen a la lógica del servidor, no solo al aspecto visual.
El primer encargo debería reconocer una finalización procesada y devolver su estado actual sin entregar otra llave. El plan técnico incluye solicitudes repetidas, respuestas retrasadas e interrupción entre modificar recompensa y guardar datos. Este artículo no proporciona una transacción terminada ni una garantía exactly-once. Hay que diseñar una regla coherente para objeto y finalización, y probarla en una versión separada.
8. Una nueva entrada plantea otra pregunta #
Mira casi declara victoria al ver la tarjeta. Después encuentra otra página: «¿Qué verá Lina si sale y vuelve?» Tener la llave ahora y restaurarla después son comprobaciones diferentes. Deben coincidir objeto, registro del primer encargo y permiso para la siguiente reparación; una etiqueta atractiva no basta.
Un guardado pendiente o incierto necesita un estado honesto, como «Comprobando guardado», no un «Todo guardado» incondicional. Perder la conexión no permite suponer que la recompensa desapareció y entregar inmediatamente otra. La recuperación tiene su propio escenario. Las pruebas de guardado usan una versión separada: el acceso de Studio a datos de producción puede afectar al progreso real, por lo que no proponemos activarlo en un juego en funcionamiento.
9. Las tablas convierten dudas en propuestas comprobables #
Mira deja de escribir solamente «hacer más clara la recompensa». Relaciona cada problema con un cambio visible y una pregunta. ¿Permanece el objetivo antiguo? Propone un estado completado coherente. ¿No se entiende qué se recibió? Nombre del objeto e inventario correcto. ¿No se encuentra después? Una entrada permanente, no un destello repetido sin fin.
La primera tabla contiene propuestas, no resultados. La segunda es un plan sin completar: dispositivo, versión y observación todavía deben anotarse. Un resultado vacío es mejor que una marca inventada. No pidas repetir una respuesta que acabas de explicar. Pregunta qué pasó y dónde comprobaría el objeto, y registra las acciones. Que los datos sean correctos no demuestra que el mensaje se viera.
| Antes | Propuesta | Cómo comprobar |
|---|---|---|
| La batería desaparece sin explicación | Nombrar entrega y llave tras la confirmación | ¿Puede describir qué ocurrió? |
| Solo se ven monedas | Abrir el inventario de herramientas pertinente | ¿Encuentra la tarjeta de la llave? |
| El diario conserva el objetivo antiguo | Coordinar finalización y siguiente reparación | ¿Coinciden diario y estado de recompensa? |
| Otra pulsación parece una nueva solicitud | Espera clara; servidor reconoce la finalización procesada | ¿La repetición cambia el número de llaves? |
| Se supone guardado un objeto visible | Separar entrega y estado del guardado | ¿Se recuperan objeto y tarea al volver? |
10. Aplica el método a tu primera recompensa #
Elige un encargo de tu juego. Escribe qué entrega o completa la persona, qué recibe y dónde lo puede ver después. Nombra únicamente el indicador relacionado: herramienta, entrada de colección, experiencia u otro resultado previsto. No obligues a mirar monedas cuando la recompensa pertenece a otro sistema.
Define los estados esperados antes de actuar, durante la comprobación, después de entregar y después del guardado confirmado, si está previsto. Prepara casos distintos para repetición, nueva entrada, sonido desactivado y pantalla pequeña. Cambia una causa de confusión cada vez y conserva la versión comparada. Creator Hub describe feedback como respuesta a una acción y recomienda priorizar información necesaria ahora. La llave y la escena son ejemplos propios.
| Escenario | Qué observar | Dispositivo / versión / resultado |
|---|---|---|
| Una primera entrega | Mensaje, una llave, finalización y siguiente acción | — |
| Solicitud repetida y respuesta retrasada | Sin segunda recompensa; estados coherentes | — |
| Mensaje cerrado y sonido desactivado | Objeto localizable y resultado entendido sin audio | — |
| Pantalla pequeña | Texto legible y controles accesibles | — |
| Nueva entrada tras guardado confirmado | Llave, estado del encargo y permiso de reparación | — |
| Guardado interrumpido o incierto | Estado honesto y recuperación sin adivinar otra entrega | — |
11. Lina ya sabe qué hay en su bolsa #
En la escena final ficticia, la lámpara se enciende sin fuegos artificiales prolongados. El mensaje nombra la batería entregada y la llave recibida. Lina abre herramientas, ve la misma etiqueta y entiende la siguiente reparación. Ya no intenta entregar de nuevo una batería desaparecida solo para descubrir si ocurrió algo.
Termina una historia, no una medición de retención mejorada. Mira conserva el plan, sobre todo para guardado y solicitudes repetidas. Pero la idea está completa: la primera recompensa necesita un lugar comprensible en la historia de la acción, además de existir en datos. Toma regla, tablas y preguntas, sustituye batería por tu encargo y comprueba tu escena sin copiar código ni inventar reseñas de jugadores.
Fuentes originales
Roblox Creator Hub — Onboarding techniquesUI and UX design
Onboarding
Data stores
Securing the client-server boundary
