Pautas de MVP
Pautas recomendadas para producir tu primera escena o experiencia MVP usando el SDK
El propósito de este documento es ayudarte a guiarte a través del proceso de construir las primeras iteraciones de scenes en Decentraland. Nos referiremos a estas como un Producto Mínimo Viable (MVP).
Al crear el Producto Mínimo Viable (MVP) para tu scene, necesitas pensar en dos áreas de enfoque:
La experiencia básica del usuario y la funcionalidad de tu proyecto.
La creación de un "pipeline" básico, o flujo de trabajo del equipo y sistema de gestión de contenido para construir tu experiencia e ir mejorándola de forma iterativa.
Un MVP no debería intentar demostrar todos los posibles resultados de cada posible experiencia. En su lugar, un MVP debería ser la mejor primera impresión de tu experiencia que puedas crear usando el SDK de Decentraland.
Es importante considerar tus propias limitaciones, cómo planeas प्रदानar 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 colaborador o parte interesada, ¿cómo contribuyo al pipeline o a la experiencia?
Es importante distinguir este enfoque del desarrollo ágil tradicional, porque puede que tengas que usar métodos no óptimos para alcanzar tus objetivos de diseño.
Tendrás que examinar tus propios objetivos en el contexto de las expectativas de tus usuarios para decidir si un determinado release está más enfocado en el jugador, en el pipeline y en los colaboradores de contenido, o en un poco de ambos.
Al planificar cada release, es fundamental que establezcas tus prioridades de manera consciente y deliberada de acuerdo con cada una de estas tres perspectivas.
Puedes esperar que tu backlog de desarrollo siga dos líneas:
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 tanto para los colaboradores como para tu equipo de desarrollo.)
Estas dos líneas también seguirán dos enfoques distintos para las pruebas:
Probar tus experiencias de usuario se asemeja más a las pruebas tradicionales de la interfaz de usuario y no requiere los mismos recursos de scripting.
Probar tus herramientas e interfaces del pipeline requerirá más recursos técnicos.
Cuanto antes puedas presentar una propuesta de valor a tu usuario o jugador, antes podrás obtener comentarios para confirmar o rechazar esa propuesta. Confirmar el valor rápidamente es fundamental. Muchos desarrolladores experimentados compartirán historias de cómo estaban seguros, más allá de toda duda, de lo increíble que sería una nueva mecánica hasta que la usaron y se sintió torpe y llena de fallos, los jugadores no reaccionaron en absoluto o no resolvió una necesidad/deseo del consumidor. Quieres fallar rápido con el menor esfuerzo posible, para poder aprender de tu fracaso y planear la siguiente iteración.
¿Cómo fallas rápido? 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 gradualmente a medida que desarrollas una sustitución más sólida.
Creación de arte
Primero, comienza con imágenes estáticas 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 proporcionársela a un artista subcontratado
Creación de la scene
Desarrolla una noción básica de tu espacio
El jugador debe sentir que está en un espacio nuevo y único
Delimita tu espacio de los espacios vecinos
Los límites son evidentes y obvios, aunque sea solo mediante una línea dibujada
Cubre toda el área con contenido/arte estático
Arte renderizado en la scene
Usar billboards está bien, u otra señalización (esto podría ser simplemente billboards reales o sprites más sofisticados orientados hacia la cámara)
Establece el tono y la estética de tu espacio (es decir, estilo, claro, oscuro)
Anota tu proceso: ¿cómo se creó el arte y se desplegó en la scene?
¿Cómo quieres organizar tus archivos de arte para un despliegue repetido?
Experiencia del jugador
Los jugadores pueden visitar tu espacio/scene
Los jugadores pueden distinguir tu espacio de los espacios vecinos
Objetivos del pipeline
Desplegar una scene estática de ejemplo: sin interacción con el jugador
Desplegar una scene animada: elementos como fuentes de agua o banderas ondeantes repiten sus animaciones en loop
Desplegar una scene interactiva: incluyendo la participación del jugador
Demostrar el pipeline de despliegue volviendo a desplegar contenido: desde la creación del arte hasta su inclusión en la scene, incluyendo scripting + QA]
Exponer lagunas del pipeline: identificar los desconocidos en áreas específicas de despliegue de contenido
Niveles de prototipos
Fallar rápido te permite desarrollar tu experiencia creando prototipos sucesivos, con cada iteración construyendo sobre la anterior.
Empieza con un prototipo de un solo jugador. Luego puedes planificar el scripting de interacciones multijugador. Finalmente, puedes abordar tu bucle central persistente que demuestre 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).
¿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 ha 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 de un solo jugador.
Por ejemplo, podrías diseñar una scene con las siguientes experiencias sucesivas:
Un solo jugador puede entrar al world.
El jugador puede interactuar con una o dos entidades simples dentro de la scene.
Otros jugadores pueden unirse e interactuar con el world y con el otro jugador.
Por último, puedes añadir la capacidad de recordar que cada jugador entró en la scene, y de hacer seguimiento de los eventos y actividades de los jugadores.
Cómo compartir tu MVP
Recomendamos probar los cambios con usuarios de prueba antes de subir una nueva versión de tu scene a Decentraland. Puedes publicar tu scene en un Decentraland World para compartirla mediante un enlace sin necesidad de ningún LAND, y sin afectar el contenido en producción.
Consideraciones adicionales
Una vez que se cubren los casos de uso básicos, puedes empezar a sofisticar tu estrategia de gestión de releases enfocándote en las mecánicas. Mecánicas es un término amplio que abarca todas las acciones que un jugador puede realizar y las respuestas que el sistema proporcionará en función de esas acciones del jugador.
La interoperabilidad de dispositivos es algo importante de tener en cuenta. Los usuarios de tu scene pueden acceder a ella mediante un escritorio, un dispositivo móvil o un visor de VR. Los usuarios deberían poder interactuar con tu scene razonablemente bien usando cualquiera de ellos. Para quienes usan un visor de VR, intenta evitar movimientos vertiginosos que puedan causar mareo por movimiento.
El Audio es otro aspecto crítico de la atmósfera de una scene. Sonidos de fondo como el viento, los grillos, conversaciones lejanas, 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 de sonido para dar más o menos énfasis a la ubicación de un sonido.
Lee las restricciones de diseño para juegos para un análisis detallado de otras consideraciones.
Considera el MVP como uno de muchos prototipos que puedes usar para establecer tu cadencia de releases una vez que hayas establecido tu pipeline. El enfoque de cada release puede variar, o puede ser un híbrido de cada aspecto de la experiencia. Sin embargo, deberías aspirar a entregar experiencias sucesivamente más complejas, construyendo cada iteración sobre la anterior.
MVP: Un solo jugador
Release 2: Añadir soporte multijugador y/o de interacción
Release 3: Introduce tu primera mecánica
Release 4: Añade soporte de audio
Release 5: Finaliza tu pipeline de arte
Por ejemplo, supongamos que estamos construyendo un MVP para un juego de Frisbee golf. El MVP incluirá algunas imágenes estáticas del recorrido. Incluso es posible que el jugador pueda lanzar un disco, de una forma muy rudimentaria, estilo bloques. Esto nos permite definir nuestras mecánicas básicas de lanzamiento. El siguiente release puede incluir un prototipo de soporte multijugador para que podamos mostrar y probar a dos usuarios conectados y jugando en nuestro LAND al mismo tiempo.
Recuerda que, aunque el objetivo final es un mundo 3D verdaderamente inmersivo, ahí no es donde comenzará tu MVP. Lograr que un jugador entre en tu world lo antes posible debería ser tu primer objetivo. Tardar semanas, no meses, en probar tus releases es fundamental para aprender e iterar sin desperdiciar esfuerzo.
Recomendamos encarecidamente que seas consciente de la primera impresión que presenta tu experiencia. Una experiencia vacía dejará decepcionados a los jugadores. Por otro lado, una scene con algo de contenido inicial y experiencias básicas muestra a los jugadores el potencial de lo que está por venir y los anima a interactuar con tu comunidad y volver a los siguientes releases.
Factores de persistencia a considerar
En última instancia, quieres alcanzar un nivel de persistencia en el que 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 del leaderboard: resultados de partidas anteriores, clasificaciones globales/regionales, competiciones
Validación de identidad: dirección de la wallet de Ethereum, o cualquier otra gestión de identidad del backend
Actualizaciones de Blockchain: según lo requiera tu experiencia/juego para actualizar el libro mayor de Blockchain y lograr transparencia transaccional
Persistencia en runtime: datos temporales para persistencia a lo largo de una plataforma potencialmente distribuida (es decir, salud solo para la experiencia de un solo juego)
Última actualización