Directrices para MVP
Directrices recomendadas para producir tu primera escena o experiencia MVP usando el SDK
El propósito de este documento es ayudar a guiarte a través del 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 básica del usuario 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 todos los posibles resultados 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. Enfocar 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 stakeholder, ¿cómo contribuyo a la 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 cumplir tus objetivos de diseño.
Tendrás que examinar tus propios objetivos en el contexto de las expectativas de tus usuarios para decidir si una determinada versión está enfocada más en el jugador, en la pipeline y los contribuidores de contenido, o en un poco de ambos.
Al planificar cada lanzamiento, es crítico que conscientemente y deliberadamente establezcas 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 tanto para los contribuidores 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 se asemeja más 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 presentar una propuesta de valor a tu usuario o jugador, antes podrás obtener retroalimentación para confirmar o rechazar esa propuesta. Confirmar el valor rápidamente es crítico. Muchos desarrolladores experimentados cuentan historias de cómo estaban absolutamente seguros de lo increíble que sería una nueva mecánica hasta que la usaron y resultó 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 declarar que usarás algo como marcador de posición y luego lo reemplazarás gradualmente a medida que desarrolles una alternativa 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 elegiste atrae a tus usuarios?
Esto podría ser el inicio de una guía de estilo para proporcionar a un artista subcontratado
Creación de 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
Los bordes son evidentes y obvios, aunque solo 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 carteleras reales o sprites más sofisticados orientados a la cámara)
Establece el tono y la estética de tu espacio (es decir, estilo, brillante, oscuro)
Anota tu proceso: ¿cómo se creó y desplegó el arte 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 muestra: sin interacción con el jugador
Desplegar escena animada: elementos como fuentes o banderas ondeando repiten sus animaciones
Desplegar escena interactiva: incluyendo la participación del jugador
Demostrar la pipeline de despliegue re-desplegando contenido: desde la creación de arte hasta la escena incluyendo scripting + QA]
Exponer brechas en 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 demuestre capas transaccionales.
¿Qué es un bucle central persistente?
En el 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 provistas por Districts).
📔 Nota: El cliente de Decentraland toma prestadas algunas ideas arquitectónicas de React.js y solo renderiza una escena cuando se ha producido 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 ha interconectado con tu experiencia para mantener un registro persistente de las acciones de los jugadores. 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 en el 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 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 retroalimentación.
Incluso una vez que Decentraland esté disponible para todos, aún 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 esta entrada 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 sofisticar tu estrategia de gestión de lanzamientos enfocándote en las mecánicas. Mecánicas es un término amplio que cubre todas las acciones que un jugador puede tomar 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 a ella usando un escritorio, un dispositivo móvil o un casco de VR. Los usuarios deberían poder interactuar razonablemente bien con tu escena usando cualquiera de ellos. Para quienes usan un casco de VR, intenta evitar movimientos mareantes que puedan causar cinetosis.
Audio es otro aspecto crítico de la atmósfera de una escena. Sonidos de fondo como el viento, los 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 desde la fuente de sonido para poner más o menos énfasis en la ubicación de un sonido.
Leer restricciones de diseño para juegos para una mirada detallada a 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, cada iteración construyendo sobre la anterior.
MVP: Un solo jugador
Lanzamiento 2: Añadir soporte 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 golf con frisbee. El MVP incluirá algunas imágenes fijas del recorrido. El jugador incluso puede ser capaz de lanzar un disco, de forma muy rudimentaria, al estilo de bloques. Esto nos permite trabajar nuestras mecánicas básicas de lanzamiento. El siguiente lanzamiento puede incluir un prototipo de soporte multijugador para poder demostrar y probar dos usuarios conectados jugando en nuestro LAND al mismo tiempo.
Recuerda, aunque la meta final es un mundo 3D verdaderamente 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 debería 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 te mantengas atento a la primera impresión que presenta tu experiencia. Una experiencia vacía dejará a los jugadores decepcionados. Por otro lado, una escena 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 participar en tu comunidad y volver para los próximos 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 hacia los jugadores.
Información de cuenta: nombre de inicio de sesión, zona horaria, ubicación para tu experiencia/juego específico
Estadísticas de clasificación: resultados de partidas previas, posiciones globales/regionales, competiciones
Validación de identidad: dirección de wallet de Ethereum, o cualquier otra gestión de identidad en el backend
Actualizaciones en la blockchain: según sea necesario 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., salud solo para la experiencia de juego individual)
Última actualización