Trabajo para cliente
PairPlays: un juego diario sobre un catálogo real
Trabajo para cliente, diseñado y programado por Riv Lux Media.
Un reto diario es, hoy por hoy, la mecánica de retención más resistente de la web. Una ronda al día, con una racha y un resultado que vale la pena compartir.
El reto es lo fácil. Lo difícil es todo lo que va debajo.
Lo que construimos
Un reto diario de maridaje con rotación, veinte niveles de progresión y una ficha de vino visible para el jugador, con precio y calificación reales sacados de un catálogo vivo de 690 botellas. También hay una herramienta para reportar errores, conectada a una vista de triage para administración, y un video tutorial para quien juega por primera vez.
Detrás: un backend en Supabase, una rotación diaria determinista y herramientas de actualización que mantienen el catálogo honesto con el tiempo.
Los tres problemas difíciles
Que el catálogo sea cierto. El juego le muestra al jugador precios, calificaciones y notas de cata reales. Los catálogos reales se desfasan: las botellas cambian de precio y las añadas se renuevan, y algunos vinos directamente desaparecen. Un juego de vinos construido sobre datos vivos vale tanto como su disciplina de actualización, y eso significa verificar el catálogo completo de forma programada, botella por botella, con herramientas que lo vuelvan rutina. No debería hacer falta ninguna hazaña.
Progresión que mida algo. Construir veinte niveles es fácil. Que signifiquen algo cuesta más. Algunos niveles evalúan de verdad el recuerdo y otros están para dar ritmo y confianza. Cuál es cuál tiene que ser una decisión de diseño explícita, porque si no, puede parecer que el juego mide habilidad cuando en realidad no mide nada.
Una economía atrae adversarios. Cualquier juego con moneda ganada invita a que alguien falsifique puntajes. Protegerlo bien exige aplicar las reglas en la base de datos, con la granularidad correcta. Las reglas por fila y los permisos por columna resuelven problemas distintos, y si eliges el mecanismo equivocado dejas un hueco que desde la aplicación parece cerrado.
Lo que se transfirió a todo lo demás
El muestreo esconde el desfase. Cualquier conjunto de datos que vea el usuario necesita verificación completa. Revisar una muestra no alcanza. Hoy es estándar en cada proyecto que hacemos.
Verifica un control de seguridad contra el mecanismo. Revisamos de forma adversarial los cambios de base de datos antes de aplicarlos, porque la intuición sobre cómo están protegidos los datos, por segura que sea, no equivale a leer los permisos reales.
Qué demuestra
Datos de catálogo a escala real, con herramientas para verificarlos. Diseño de progresión y de economía que aguanta a los jugadores que hacen trampa. Seguridad de base de datos con la granularidad correcta. Y un formato de visita diaria al que la gente vuelve.
Última actualización