Desarrollo / ROBLOX
Developer Product o Pass en Roblox: elegir el tipo antes de crear la tienda
Compara una compra repetible con un privilegio adquirido una vez. Documenta la oferta, alinea su ficha con el efecto del servidor y prepara comprobaciones distintas para Developer Products y Passes.
Empieza por la promesa al jugador #
Antes de elegir el tipo, escribe exactamente qué recibe el jugador. VIP, bonus y mejora son términos imprecisos: pueden significar acceso, un consumible o un efecto temporal. Define el resultado, dónde se aplica y qué sucede después de utilizarlo o volver a entrar.
El ejercicio utiliza dos ofertas ficticias: un paquete de fichas de práctica y acceso a una sala de entrenamiento. No son productos de pago reales de nuestros juegos. No se crearon Passes ni Developer Products, se cambiaron precios o se realizaron compras para el artículo. Diseñamos una decisión y su revisión, no lanzamos una tienda operativa.
Distingue compra repetible y privilegio #
Un Developer Product corresponde a algo que puede comprarse varias veces. Un Pass representa la compra única de un privilegio. Pregunta primero si el mismo jugador puede adquirir de nuevo la oferta con sentido y después qué debe seguir disponible tras la adquisición anterior.
Responde según la mecánica. Si las fichas se consumen y una compra nueva debe añadir otro paquete, considera un Developer Product. Si la oferta desbloquea un privilegio sin necesidad de comprarlo de nuevo, considera un Pass. Son candidatos del ejemplo, no una recomendación universal de monetización ni una predicción de ingresos.
Abrir imagen a tamaño completo ↗Completa una especificación de oferta #
Incluye nombre claro, efecto, repetibilidad, tipo propuesto, ID correspondiente y regla de aplicación. Deja el ID vacío hasta que exista el objeto real; no uses uno ajeno ni un número de funcionamiento inventado. Identifica por separado la lógica del servidor que confirma el derecho y la que cambia el estado.
Añade la pregunta de una entrada posterior. La sala necesita aplicar acceso a quien ya posee el Pass; las fichas necesitan un modelo definido de cantidad, almacenamiento y entrega. El nombre del producto no resuelve estas tareas. La especificación muestra el trabajo pendiente antes de enseñar una ficha atractiva al jugador.
Abrir imagen a tamaño completo ↗Examina un paquete consumible #
Supongamos que la mecánica de práctica consume fichas. Una compra nueva confirmada debe entregar el nuevo paquete previsto. Distingue dos compras diferentes del mismo Developer Product de procesar nuevamente una sola compra. En el segundo caso no debe repetirse una entrega ya realizada.
Planifica ambos casos por separado con cambio de cantidad esperado y método de confirmación. El artículo no implementa un controlador de recibos, saldo persistente ni entrega. Un aumento después de una pulsación normal no demuestra que el sistema esté listo: faltan repeticiones, errores y futuras entradas.
Examina acceso mediante un Pass #
Un Pass de sala puede representar el acceso después de adquirirlo una vez. Crear el Pass no implementa la puerta, reglas del servidor o aplicación del privilegio. La documentación describe aparte la comprobación de propiedad y la asignación del beneficio a quien ya lo tiene al entrar.
Incluye tanto un comprador nuevo como un jugador propietario antes de la entrada actual. La lógica debe usar jugador y Pass correctos, y el acceso coincidir con la descripción. No sustituyas la promesa concreta por un «para siempre» indefinido. Describe el derecho que concede este proyecto y dónde tiene efecto.
Mantén separados los caminos de confirmación #
Developer Product se procesa mediante ProcessReceipt. PromptProductPurchaseFinished no confirma una compra exitosa y no debe sustituir el tratamiento de la entrega. Pass utiliza sus propias comprobaciones de propiedad y eventos; botones parecidos no hacen intercambiables estas reglas.
El esquema separa caminos después de elegir tipo. Cada uno tiene identificador, confirmación y aplicación propios. Es un mapa conceptual, no un script. Antes de implementar, revisa la referencia actual de la API elegida y tus casos. Evita un controlador genérico de cierre de ventana que conceda efectos sin distinguir tipos.
Alinea ficha y efecto de juego #
La ficha explica resultado y repetibilidad. En un paquete, indica qué aporta una compra; en la sala, qué privilegio tiene el propietario. Una imagen y título compartidos por dos tipos no reemplazan esta explicación. El botón debe referirse al ID escrito en la especificación.
Obtén y muestra información de precio y venta según la implementación actual de Roblox, sin fijar cifras inventadas de una guía. Este artículo no contiene precios. Antes de vender, comprueba descripción, tipo y controlador juntos. Una parte del efecto sin implementar no debe anunciarse como función disponible.
Separa falta de propiedad y error de consulta #
Una comprobación de Pass puede confirmar propiedad, confirmar ausencia o fallar. Un error no demuestra que el jugador no lo posea. Planifica un mensaje de imposibilidad temporal de consulta y el comportamiento de la puerta, distinguiendo resultado desconocido de ausencia verificada del derecho.
Para Developer Product, contempla ID desconocido, efecto imposible de aplicar y fallo de registro por separado. No confirmes una entrega que el sistema no pudo ejecutar y registrar fiablemente según su modelo. Son requisitos de implementación, no un protocolo completo de reintentos ni garantía frente a fallos entre servidores.
Prepara una matriz de revisión #
Para Passes, lista propietario existente al entrar, comprador nuevo, cancelación y fallo de consulta. Para Developer Products, lista compras diferentes del mismo artículo, procesamiento repetido de una compra e imposibilidad temporal de entregar. Anota derecho o cambio esperado; las observaciones reales se completan después de tu prueba.
No hagas un pago real solo para seguir esta guía. Discute y revisa el plan primero en un prototipo independiente, y aclara medios y condiciones del test concreto antes de realizarlo. La tabla es una especificación original de tareas. No contiene pagos, entregas ni historial de compras reales de nuestros juegos.
| Pregunta | Aclarar |
|---|---|
| ¿Puede comprarse otra vez? | Definir repetibilidad de la mecánica |
| ¿Qué queda tras comprar? | Determinar cantidad o privilegio |
| ¿Cómo se entrega Product? | Procesamiento de recibos verificado aparte |
| ¿Cómo se aplica Pass? | Consulta de propiedad y aplicación del servidor |
Documenta la decisión antes de vender #
El resultado responde qué se promete, si puede comprarse de nuevo, qué tipo se eligió y cómo se confirma y aplica el efecto. Comparte especificación, matriz y pendientes con otro desarrollador. Así implementará el camino correcto sin decidir el tipo después de dibujar toda la tienda.
Elegir tipo no deja lista una tienda de pago. Procesamiento de Products, derechos de Pass, interfaz y persistencia requieren revisiones. Un clic no confirma entrega y una visita al sitio no demuestra compra en Roblox. Esta guía ofrece esquemas originales y un plan sin lanzar ventas ni prometer ganancias.
| Comprobación | Registrar |
|---|---|
| Promesa | Efecto exacto y alcance |
| Identificador | Tipo e ID correspondiente |
| Confirmación | Derecho y aplicación real |
| Repetición | Entradas posteriores y procesamiento repetido |
Fuentes originales
Roblox Creator Hub — Developer ProductsRoblox Creator Hub — Passes
Roblox Creator Hub — MarketplaceService API
