# Pautas MVP El propósito de este documento es ayudarte 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, necesitas pensar en dos áreas de enfoque:** 1. La experiencia de usuario básica y la funcionalidad de tu proyecto. 2. 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 y mejorarla de forma iterativa. Un MVP no debe intentar demostrar todos los posibles resultados de cada experiencia posible. En su lugar, un MVP debe 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 proporcionar contenido a tus usuarios y las expectativas de tus usuarios. Enfocar tu MVP de esta manera requiere tres perspectivas diferentes: 1. Como desarrollador o productor, ¿cómo entrego una experiencia a mi usuario/jugador? 2. Como usuario o jugador, ¿qué espero de esta experiencia? 3. 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 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 un determinado lanzamiento está más enfocado en el jugador, en el pipeline y en los colaboradores de contenido, o un poco en ambos. Al planificar cada lanzamiento, es fundamental que establezcas tus prioridades de manera consciente y deliberada según cada una de estas tres perspectivas. Puedes esperar que tu backlog de desarrollo siga dos líneas: * El backlog de las 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 colaboradores como para tu equipo de desarrollo.) Estas dos líneas también seguirán dos enfoques diferentes para las pruebas: * Probar tus experiencias de usuario es más parecido 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 poner una propuesta de valor frente 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 con experiencia compartirán historias de cómo estaban absolutamente seguros de que una nueva mecánica sería increíble, hasta que la usaron y se sintió incómoda y con fallos, los jugadores no reaccionaron en absoluto o no resolvió una necesidad o deseo del consumidor. Quieres fallar rápido con el menor esfuerzo posible, para poder aprender de tu fallo y planificar 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 temporal y luego lo reemplazarás a medida que desarrolles una sustitución más sólida. 1. 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 proporcionar a un artista externo 2. 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 de 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 3. Arte renderizado en la escena * Está bien usar billboards u otra señalización (esto podría ser simplemente billboards 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) * Documenta 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 un despliegue repetido? 4. Experiencia del jugador * Los jugadores pueden visitar tu espacio/escena * Los jugadores pueden distinguir tu espacio de los espacios vecinos 5. Objetivos del pipeline * Desplegar una escena estática de ejemplo: sin interacción con el jugador * Desplegar una escena animada: elementos como fuentes de agua o banderas ondeando repiten sus animaciones en bucle * Desplegar una escena interactiva: incluyendo la participación del jugador * Demostrar el pipeline de despliegue redeplegando contenido: desde la creación de arte hasta la escena, incluyendo scripting + QA] * Exponer vacíos del pipeline: identificar las incógnitas 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 construida sobre la anterior. **Empieza con un prototipo de un solo jugador. Luego puedes planificar scripting para interacciones multijugador. Finalmente, puedes abordar tu bucle central persistente que demuestra 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 proporcionadas por Districts). {% hint style="warning" %} **📔 Nota**: El cliente de Decentraland toma prestadas algunas ideas arquitectónicas de [React.js](https://reactjs.org/) y solo renderiza una escena cuando se ha producido un cambio, no a una tasa constante. {% endhint %} **¿Qué son las capas transaccionales?** Las capas transaccionales son las interfaces entre sistemas, como una actualización de la blockchain u otra aplicación que se ha integrado 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 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 para todos, puedes subir una vista previa de la escena a un Server y compartir fácilmente un enlace con personas que puedan darte comentarios. Incluso una vez que Decentraland esté disponible para todos, seguimos recomendando probar los cambios con usuarios de prueba en un Server de vista previa separado primero, antes de subir una nueva versión de tu escena a Decentraland. Lee [esta entrada del blog](https://decentraland.org/blog/announcements/decentraland-on-now/) para obtener detalles sobre cómo subir la vista previa de tu escena a un Server gratuito. ## Consideraciones adicionales Una vez que se cubren los casos de uso básicos, puedes empezar a ser más sofisticado con tu estrategia de gestión de lanzamientos al centrarte 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á en función de esas acciones del jugador. **Interoperabilidad de dispositivos** es algo importante a tener en cuenta. Los usuarios de tu escena pueden estar accediendo a ella desde un escritorio, un dispositivo móvil o un visor de VR. Los usuarios deberían poder interactuar con tu escena de manera razonablemente buena usando cualquiera de ellos. Para quienes usen un visor 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 a la fuente de sonido para dar más o menos énfasis a la ubicación de un sonido. Lee [restricciones de diseño para juegos](/creator/content-creator-es/scenes-sdk7/disenar-la-experiencia/design-games.md) para un análisis detallado de 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, deberías aspirar a ofrecer experiencias cada vez más complejas, construyendo cada iteración sobre la anterior. 1. **MVP**: Un solo jugador 2. **Lanzamiento 2**: Añadir soporte multijugador y/o de interacción 3. **Lanzamiento 3**: Introducir tu primera mecánica 4. **Lanzamiento 4**: Añadir soporte de audio 5. **Lanzamiento 5**: Finalizar 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 campo. Incluso es posible que el jugador pueda lanzar un disco, de una manera muy rudimentaria, estilo bloques. Esto nos permite definir nuestras mecánicas básicas de lanzamiento. El siguiente lanzamiento podría incluir un prototipo de soporte multijugador para que podamos demostrar y probar a dos usuarios conectados y jugando en nuestro LAND al mismo tiempo. Recuerda, aunque el objetivo final sea 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. Tardar semanas, no meses, en probar tus lanzamientos es fundamental para aprender e iterar sin desperdiciar esfuerzo. Recomendamos encarecidamente que mantengas presente 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 interactuar con tu comunidad y a volver para los próximos lanzamientos. ## 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 frente a los jugadores. 1. **Información de la cuenta**: nombre de usuario, zona horaria, ubicación para tu experiencia/juego específico 2. **Estadísticas de leaderboard**: resultados previos de partidas, clasificaciones globales/regionales, competencias 3. **Validación de identidad**: dirección de la Wallet de Ethereum, o cualquier otro sistema backend de gestión de identidad 4. **Actualizaciones de la blockchain**: según sea necesario en función de tu experiencia/juego para actualizar el libro mayor de la blockchain y aportar transparencia transaccional 5. **Persistencia en tiempo de ejecución**: datos temporales para persistencia a través de una plataforma potencialmente distribuida (es decir, salud solo para la experiencia de juego individual) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.decentraland.org/creator/content-creator-es/scenes-sdk7/disenar-la-experiencia/mvp-guidelines.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.