# Diretrizes de MVP

O objetivo deste documento é ajudar a orientá-lo no processo de construção das primeiras iterações de scenes em Decentraland. Vamos nos referir a isso como um Produto Mínimo Viável (MVP).

**Ao criar o Produto Mínimo Viável (MVP) para a sua scene, você precisa pensar em duas áreas de foco:**

1. A experiência básica do usuário e a funcionalidade do seu projeto.
2. A criação de um "pipeline" básico, ou fluxo de trabalho da equipe e sistema de gerenciamento de conteúdo para construir a sua experiência e melhorá-la iterativamente.

Um MVP não deve tentar demonstrar todos os resultados possíveis de toda experiência possível. Em vez disso, um MVP deve ser a melhor primeira impressão da sua experiência que você consegue criar usando o SDK de Decentraland.

É importante considerar suas próprias limitações, como você planeja fornecer conteúdo aos seus usuários e as expectativas dos seus usuários. Abordar o seu MVP dessa forma requer três perspectivas diferentes:

1. Como desenvolvedor ou produtor, como entrego uma experiência ao meu usuário/jogador?
2. Como usuário ou jogador, o que espero desta experiência?
3. Como colaborador ou stakeholder, como contribuo para o pipeline ou a experiência?

É importante distinguir essa abordagem do desenvolvimento ágil tradicional, porque talvez você tenha de usar métodos não ideais para atingir seus objetivos de design.

Você precisará examinar seus próprios objetivos no contexto das expectativas dos seus usuários para decidir se um determinado lançamento está mais focado no jogador, no pipeline e nos colaboradores de conteúdo, ou um pouco de ambos.

Ao planejar cada lançamento, é fundamental que você defina suas prioridades de forma consciente e deliberada de acordo com cada uma dessas três perspectivas.

Você pode esperar que o seu backlog de desenvolvimento siga dois caminhos:

* O backlog de experiências de usuário que você quer criar.
* O desenvolvimento das ferramentas e interfaces necessárias para construir o seu pipeline de entrega. (Ou para otimizar o seu pipeline existente tanto para os colaboradores quanto para a sua equipe de desenvolvimento.)

Esses dois caminhos também seguirão duas abordagens diferentes para testes:

* Testar suas experiências de usuário é mais parecido com testes tradicionais de interface do usuário e não exige os mesmos recursos de scripting.
* Testar suas ferramentas e interfaces do pipeline exigirá mais recursos técnicos.

Quanto mais cedo você conseguir apresentar uma proposta de valor ao seu usuário ou jogador, mais cedo poderá obter feedback para confirmar ou rejeitar essa proposta. Confirmar valor rapidamente é fundamental. Muitos desenvolvedores experientes contarão histórias de como tinham certeza absoluta de que um novo mechanic seria incrível, até usá-lo e ele parecer estranho e cheio de glitches, os jogadores não reagirem a ele de forma alguma, ou ele não resolver uma necessidade/desejo do consumidor. Você quer falhar rapidamente com o mínimo de esforço possível, para que possa aprender com a sua falha e planejar a próxima iteração.

Como falhar rapidamente? Você faz o mínimo necessário para levar o seu jogador a tocar no seu produto.

## Fatores para Produtos Mínimos Viáveis

Aqui está a lista de fatores a considerar para o seu MVP básico. É aceitável declarar que você usará algo como placeholder e depois o substituirá à medida que desenvolver uma alternativa mais sólida.

1. Criação de Arte
   * Primeiro, comece com imagens estáticas básicas
   * Seu primeiro teste deve ser de estilo: o estilo que você escolheu agrada aos seus usuários?
   * Este pode ser o início de um guia de estilo para fornecer a um artista terceirizado
2. Criação de Scene
   * Desenvolva uma noção básica do seu espaço
   * O jogador deve sentir que está em um espaço novo e único
   * Delineie o seu espaço em relação aos espaços vizinhos
   * Os limites são evidentes e óbvios – mesmo que apenas por uma linha desenhada
   * Cubra toda a área com conteúdo/arte estática
3. Arte Renderizada na Scene
   * Usar billboards é aceitável, ou outra sinalização (isso pode ser simplesmente billboards reais ou sprites mais sofisticados voltados para a câmera)
   * Estabeleça o tom e a estética do seu espaço (ou seja, estilo, claro, escuro)
   * Registre o seu processo: como a arte foi criada e implantada na scene?
   * Como você quer organizar seus arquivos de arte para implantação repetida?
4. Experiência do jogador
   * Os jogadores conseguem visitar o seu espaço/scene
   * Os jogadores podem distinguir o seu espaço dos espaços vizinhos
5. Objetivos do Pipeline
   * Implantar scene estática de exemplo: sem interação com o jogador
   * Implantar scene animada: elementos como fontes de água ou bandeiras tremulando repetem suas animações em loop
   * Implantar scene interativa: incluindo engajamento do jogador
   * Demonstrar o pipeline de implantação reimplantando conteúdo: da criação da arte até a scene, incluindo scripting + QA]
   * Expor lacunas do pipeline: identificar as incógnitas em áreas específicas de implantação de conteúdo

## Níveis de protótipos

Falhar rapidamente permite que você desenvolva sua experiência criando protótipos sucessivos, com cada iteração construída sobre a anterior.

**Comece com um protótipo para um único jogador. Depois, você pode planejar o scripting de interações multiplayer. Por fim, você pode enfrentar o seu loop central persistente que demonstra camadas transacionais.**

**O que é um loop central persistente?**

No design de jogos, um loop central persistente é o “game loop” fundamental que impulsiona as ações do jogador e a resposta do jogo a essas ações. Esses loops persistentes se estendem a qualquer forma de experiência virtual (como as fornecidas por Districts).

{% hint style="warning" %}
**📔 Nota**: O client de Decentraland pega emprestadas algumas ideias arquiteturais de [React.js](https://reactjs.org/) e só renderiza uma scene quando ocorreu uma mudança, não em uma taxa constante.
{% endhint %}

**O que são camadas transacionais?**

As camadas transacionais são as interfaces entre sistemas, como uma atualização da blockchain ou outra aplicação que foi integrada à sua experiência para manter um registro persistente das ações do jogador. Criar e manter esse registro persistente é o que constrói uma experiência mais pessoal.

Recomendamos criar o seu MVP como uma experiência para um único jogador.

Por exemplo, você pode projetar uma scene com as seguintes experiências sucessivas:

* Um único jogador pode entrar no mundo.
* O jogador pode interagir com uma ou duas entidades simples dentro da scene.
* Outros jogadores podem entrar e interagir com o mundo e com o outro jogador.
* Por fim, você pode adicionar a capacidade de lembrar que cada jogador entrou na scene e de acompanhar os eventos e atividades dos jogadores.

## Como compartilhar o seu MVP

Embora o mundo de Decentraland ainda não esteja aberto para todos, você pode enviar uma prévia da scene para um server e compartilhar facilmente um link com pessoas que possam lhe dar feedback.

Mesmo depois que Decentraland for disponibilizado para todos, ainda recomendamos testar alterações com usuários de teste em um server de preview separado primeiro, antes de enviar uma nova versão da sua scene para Decentraland.

Leia [este blogpost](https://decentraland.org/blog/announcements/decentraland-on-now/) para detalhes sobre como enviar a prévia da sua scene para um server gratuito.

## Considerações adicionais

Depois que os casos de uso básicos estiverem cobertos, você pode começar a sofisticar mais sua estratégia de gerenciamento de lançamentos, focando nos mechanics. **Mechanics** é um termo amplo que abrange todas as ações que um jogador pode realizar e as respostas que o sistema fornecerá com base nessas ações do jogador.

**Interoperabilidade entre dispositivos** é algo importante de se observar. Os usuários da sua scene podem estar acessando sua scene por um desktop, um dispositivo móvel ou um headset de VR. Os usuários devem conseguir interagir com sua scene razoavelmente bem usando qualquer um deles. Para aqueles que usam um headset de VR, tente evitar movimentos que causem tontura e que possam provocar enjoo de movimento.

**Audio** é outro aspecto crítico da atmosfera de uma scene. Sons de fundo como vento, grilos, conversas distantes, talvez até música, podem ser uma forma muito poderosa de aumentar a imersão e dar contexto. Você também pode alterar como os níveis de volume se relacionam com a distância da fonte sonora para dar mais ou menos ênfase à localização de um som.

Leia [restrições de design para jogos](/creator/content-creator-pt/scenes-sdk7/desenhar-a-experiencia/design-games.md) para uma análise detalhada de várias outras considerações.

Considere o MVP como um dos muitos protótipos que você pode usar para estabelecer a sua cadência de lançamentos depois que o seu pipeline estiver definido. O foco de cada lançamento pode variar, ou pode ser um híbrido de cada aspecto da experiência. No entanto, você deve buscar entregar experiências progressivamente mais complexas, com cada iteração construída sobre a anterior.

1. **MVP**: Um jogador
2. **Lançamento 2**: Adicionar suporte a multiplayer e/ou interações
3. **Lançamento 3**: Introduzir o seu primeiro mechanic
4. **Lançamento 4**: Adicionar suporte a áudio
5. **Lançamento 5**: Finalizar o seu pipeline de arte

Por exemplo, digamos que estamos construindo um MVP para um jogo de Frisbee golf. O MVP incluirá algumas imagens estáticas do campo. O jogador talvez até consiga lançar um disco, de uma forma muito rudimentar, estilo blocos. Isso nos permite desenvolver os nossos mechanics básicos de arremesso. O próximo lançamento pode incluir um protótipo de suporte a multiplayer para que possamos demonstrar e testar dois usuários conectados e jogando em nosso LAND ao mesmo tempo.

Lembre-se: embora o objetivo final seja um mundo 3D verdadeiramente imersivo, é aí que o seu MVP começará. Levar o jogador ao seu mundo o mais rápido possível deve ser o seu primeiro objetivo. Levar semanas, não meses, para testar os seus lançamentos é fundamental para aprender e iterar sem desperdiçar esforço.

Recomendamos fortemente que você se mantenha atento à primeira impressão que a sua experiência transmite. Uma experiência vazia deixará os jogadores desapontados. Por outro lado, uma scene com algum conteúdo inicial e experiências básicas mostra aos jogadores o potencial do que está por vir e os incentiva a interagir com a sua comunidade e voltar para os próximos lançamentos.

## Fatores de persistência a considerar

No final, você quer alcançar um nível de persistência em que possa demonstrar que as camadas transacionais da sua arquitetura estão operacionais. Transacional não se limita às ações dos jogadores, mas também às reações do sistema aos jogadores.

1. **Informações da conta**: nome de login, fuso horário, localização para a sua experiência/jogo específico
2. **Estatísticas do leaderboard**: resultados de partidas anteriores, classificações globais/regionais, competições
3. **Validação de identidade**: endereço da wallet Ethereum, ou qualquer outro gerenciamento de identidade no backend
4. **Atualizações da blockchain**: conforme necessário, com base na sua experiência/jogo, para atualizar o ledger da blockchain para transparência transacional
5. **Persistência em runtime**: dados temporários para persistência em uma plataforma potencialmente distribuída (ou seja, health apenas para a experiência de jogo única)


---

# 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-pt/scenes-sdk7/desenhar-a-experiencia/mvp-guidelines.md?ask=<question>
```

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.