Pautas para MVP
Pautas recomendadas para producir tu primera escena o experiencia MVP usando el SDK
El propósito de este documento es ayudarte a guiarte en el proceso de construir las primeras iteraciones de escenas en Decentraland. Nos referiremos a estas como un Producto Mínimo Viable (MVP).
Al crear el Producto Mínimo Viable (MVP) para tu escena, debes pensar en dos áreas de enfoque:
La experiencia de usuario básica y la funcionalidad de tu proyecto.
La creación de una "pipeline" básica, o flujo de trabajo del equipo y sistema de gestión de contenido para construir tu experiencia y mejorarla iterativamente.
Un MVP no debe intentar demostrar cada posible resultado de cada posible experiencia. En su lugar, un MVP debe ser la mejor primera impresión de tu experiencia que puedas lograr usando el SDK de Decentraland.
Es importante considerar tus propias limitaciones, cómo planeas proporcionar contenido a tus usuarios y las expectativas de tus usuarios. Abordar tu MVP de esta manera requiere tres perspectivas diferentes:
Como desarrollador o productor, ¿cómo entrego una experiencia a mi usuario/jugador?
Como usuario o jugador, ¿qué espero de esta experiencia?
Como contribuyente o parte interesada, ¿cómo contribuyo a la pipeline o experiencia?
Es importante distinguir este enfoque del desarrollo ágil tradicional, porque puede que tengas que usar métodos no óptimos para cumplir tus metas de diseño.
Tendrás que examinar tus propias metas en el contexto de las expectativas de tus usuarios para decidir si cierto lanzamiento está más enfocado en el jugador, en la pipeline y los contribuyentes de contenido, o en poco de ambos.
Al planear cada lanzamiento, es crítico que establezcas consciente y deliberadamente tus prioridades de acuerdo con cada una de estas tres perspectivas.
Puedes esperar que tu backlog de desarrollo siga dos vías:
El backlog de experiencias de usuario que quieres crear.
El desarrollo de las herramientas e interfaces necesarias para construir tu pipeline de entrega. (O para optimizar tu pipeline existente para los contribuyentes así como para tu equipo de desarrollo.)
Estas dos vías también seguirán dos enfoques diferentes para las pruebas:
Probar tus experiencias de usuario es más parecido a las pruebas tradicionales de interfaz de usuario, y no requiere los mismos recursos de scripting.
Probar tus herramientas e interfaces de pipeline requerirá más recursos técnicos.
Cuanto antes puedas poner una propuesta de valor frente a tu usuario o jugador, antes podrás obtener feedback para confirmar o rechazar esa propuesta. Confirmar valor rápidamente es crítico. Muchos desarrolladores experimentados comparten historias de cómo estaban absolutamente seguros de lo increíble que sería una nueva mecánica hasta que la usaron y se sintió torpe y con fallos, los jugadores no respondieron en absoluto, o no resolvió una necesidad/deseo del consumidor. Quieres fallar rápido con el menor esfuerzo posible, para poder aprender de tu fallo y planear la siguiente iteración.
¿Cómo fallas rápidamente? Haces lo mínimo necesario para que tu jugador toque tu producto.
Factores para Productos Mínimos Viables
Aquí está la lista de factores a considerar para tu MVP básico. Es aceptable indicar que usarás algo como marcador de posición y luego lo reemplazarás a medida que desarrolles una solución más sólida.
Creación de arte
Primero, comienza con imágenes fijas básicas
Tu primera prueba debe ser de estilo: ¿el estilo que has elegido atrae a tus usuarios?
Esto podría ser el inicio de una guía de estilo para proporcionar a un artista externo
Creación de la escena
Desarrolla una sensación básica de tu espacio
El jugador debe sentir que está en un espacio nuevo y único
Delimita tu espacio respecto a los espacios vecinos
Las fronteras son evidentes y obvias – aunque sea por una línea dibujada
Cubre toda el área con contenido/arte estático
Arte renderizado en la escena
Usar billboards está bien u otra señalización (esto podría ser simplemente carteles reales o sprites que miran a la cámara más sofisticados)
Establece el tono y la estética de tu espacio (p. ej., estilo, claro, oscuro)
Anota tu proceso: ¿cómo se creó el arte y cómo se desplegó en la escena?
¿Cómo quieres organizar tus archivos de arte para despliegues repetidos?
Experiencia del jugador
Los jugadores pueden visitar tu espacio/escena
Los jugadores pueden distinguir tu espacio de los espacios vecinos
Objetivos de la pipeline
Desplegar escena estática de ejemplo: sin interacción con el jugador
Desplegar escena animada: elementos como fuentes de agua o banderas ondeando repiten sus animaciones
Desplegar escena interactiva: incluyendo interacción del jugador
Demostrar la pipeline de despliegue re-desplegando contenido: desde la creación del arte hasta en la escena incluyendo scripting + QA]
Exponer las brechas de la pipeline: identificar las incógnitas en áreas específicas de despliegue de contenido
Niveles de prototipos
Fallar rápidamente te permite desarrollar tu experiencia creando prototipos sucesivos, con cada iteración construyendo sobre la anterior.
Comienza con un prototipo para un solo jugador. Luego puedes planear el scripting de interacciones multijugador. Finalmente, puedes abordar tu bucle central persistente que demuestra capas transaccionales.
¿Qué es un bucle central persistente?
En diseño de juegos, un bucle central persistente es el “game loop” fundamental que impulsa las acciones del jugador y la respuesta del juego a esas acciones. Estos bucles persistentes se extienden a cualquier forma de experiencia virtual (como las proporcionadas por Districts).
📔 Nota: El cliente de Decentraland toma prestadas algunas ideas arquitectónicas de React.js y solo renderiza una escena cuando ha ocurrido un cambio, no a una tasa constante.
¿Qué son las capas transaccionales?
Las capas transaccionales son las interfaces entre sistemas como una actualización a la blockchain u otra aplicación que se haya conectado con tu experiencia para mantener un registro persistente de las acciones del jugador. Crear y mantener este registro persistente es lo que construye una experiencia más personal.
Recomendamos crear tu MVP como una experiencia para un solo jugador.
Por ejemplo, podrías diseñar una escena con las siguientes experiencias sucesivas:
Un solo jugador puede entrar al mundo.
El jugador puede interactuar con una o dos entidades simples dentro de la escena.
Otros jugadores pueden unirse e interactuar con el mundo y con el otro jugador.
Finalmente, puedes añadir la capacidad de recordar que cada jugador entró en la escena y de rastrear los eventos y actividades de los jugadores.
Cómo compartir tu MVP
Aunque el mundo de Decentraland aún no está abierto a todos, puedes subir una vista previa de la escena a un servidor y compartir fácilmente un enlace con personas que puedan darte feedback.
Incluso una vez que Decentraland esté disponible para todos, todavía recomendamos probar cambios con usuarios de prueba en un servidor de vista previa separado primero, antes de subir una nueva versión de tu escena a Decentraland.
Leer este artículo del blog para detalles sobre cómo subir la vista previa de tu escena a un servidor gratuito.
Consideraciones adicionales
Una vez que se cubran los casos de uso básicos, puedes empezar a ser más sofisticado con tu estrategia de gestión de lanzamientos centrándote en las mecánicas. Mecánicas es un término amplio que cubre todas las acciones que un jugador puede realizar y las respuestas que el sistema proporcionará basadas en esas acciones del jugador.
Interoperabilidad de dispositivos es algo importante a tener en cuenta. Los usuarios de tu escena pueden acceder usando un escritorio, un dispositivo móvil o un casco de VR. Los usuarios deberían poder interactuar con tu escena razonablemente bien con cualquiera de ellos. Para quienes usan un casco de VR intenta evitar movimientos que causen mareos o náuseas.
Audio es otro aspecto crítico de la atmósfera de una escena. Sonidos de fondo como viento, grillos, conversaciones lejanas, quizá incluso música pueden ser una forma muy poderosa de aumentar la inmersión y dar contexto. También puedes cambiar cómo los niveles de volumen se relacionan con la distancia a la fuente sonora para poner más o menos énfasis en la ubicación de un sonido.
Leer restricciones de diseño para juegos para un análisis detallado de varias otras consideraciones.
Considera el MVP como uno de muchos prototipos que puedes usar para establecer tu cadencia de lanzamientos una vez que hayas establecido tu pipeline. El enfoque de cada lanzamiento puede variar, o puede ser un híbrido de cada aspecto de la experiencia. Sin embargo, debes aspirar a entregar experiencias sucesivamente más complicadas, con cada iteración construyendo sobre la anterior.
MVP: Un solo jugador
Lanzamiento 2: Añadir soporte de multijugador y/o interacción
Lanzamiento 3: Introducir tu primera mecánica
Lanzamiento 4: Añadir soporte de audio
Lanzamiento 5: Finalizar tu pipeline de arte
Por ejemplo, digamos que estamos construyendo un MVP para un juego de frisbee golf. El MVP incluirá algunas imágenes fijas del campo. El jugador incluso puede ser capaz de lanzar un disco, de forma muy rudimentaria y estilo en bloques. Esto nos permite trabajar nuestras mecánicas básicas de lanzamiento. El siguiente lanzamiento puede incluir un prototipo de soporte multijugador para que podamos demo y probar dos usuarios conectados y jugando en nuestro LAND al mismo tiempo.
Recuerda, aunque la meta final es un mundo 3D realmente inmersivo, ese no es el punto de partida de tu MVP. Lograr que un jugador entre en tu mundo lo más rápido posible debe ser tu primer objetivo. Tomar semanas, no meses, para probar tus lanzamientos es crítico para aprender e iterar sin desperdiciar esfuerzo.
Recomendamos encarecidamente que tengas presente la primera impresión que presenta tu experiencia. Una experiencia vacía dejará a los jugadores decepcionados. Por otro lado, una escena con contenido inicial y experiencias básicas muestra a los jugadores el potencial de lo que vendrá y los anima a interactuar con tu comunidad y volver a los siguientes lanzamientos.
Factores de persistencia a considerar
En última instancia, quieres alcanzar un nivel de persistencia donde puedas demostrar que las capas transaccionales de tu arquitectura están operativas. Transaccional no se limita a las acciones de los jugadores, sino también a las reacciones del sistema ante los jugadores.
Información de la cuenta: nombre de inicio de sesión, zona horaria, ubicación para tu experiencia/juego específico
Estadísticas de la tabla de clasificación: resultados de jugadas anteriores, posiciones globales/regionales, competiciones
Validación de identidad: dirección de wallet de Ethereum, o cualquier otra gestión de identidad en backend
Actualizaciones de blockchain: según se requiera en función de tu experiencia/juego para actualizar el ledger de la blockchain para transparencia transaccional
Persistencia en tiempo de ejecución: datos temporales para persistencia a través de una plataforma potencialmente distribuida (p. ej., la salud solo para la experiencia de juego única)
Última actualización