> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-pt/scenes-sdk7/conceber-a-experiencia/mvp-guidelines.md).

# Diretrizes de MVP

Diretrizes recomendadas para produzir sua primeira scene ou experiência MVP usando o SDK

O objetivo deste documento é ajudá-lo a orientar-se no processo de construção das primeiras iterações de scenes em Decentraland. Vamos chamar a isto um Minimum Viable Product (MVP).

**Ao criar o Minimum Viable Product (MVP) para a sua scene, precisa de pensar em duas áreas de foco:**

1. A experiência básica do utilizador e a funcionalidade do seu projeto.
2. A criação de um "pipeline" básico, ou fluxo de trabalho da equipa e sistema de gestão 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 todas as experiências possíveis. Em vez disso, um MVP deve ser a melhor primeira impressão da sua experiência que consegue criar usando o SDK de Decentraland.

É importante considerar as suas próprias limitações, como planeia fornecer conteúdo aos seus utilizadores e as expectativas dos seus utilizadores. Abordar o seu MVP desta forma requer três perspetivas diferentes:

1. Como developer ou produtor, como entrego uma experiência ao meu utilizador/jogador?
2. Como utilizador ou jogador, o que espero desta experiência?
3. Como contribuidor ou stakeholder, como contribuo para o pipeline ou experiência?

É importante distinguir esta abordagem do desenvolvimento ágil tradicional, porque poderá ter de usar métodos não ideais para cumprir os seus objetivos de design.

Terá de examinar os seus próprios objetivos no contexto das expectativas dos seus utilizadores para decidir se um determinado lançamento está mais focado no jogador, no pipeline e nos contribuintes de conteúdo, ou um pouco de ambos.

Ao planear cada lançamento, é fundamental definir conscientemente e de forma deliberada as suas prioridades de acordo com cada uma destas três perspetivas.

Pode esperar que o seu backlog de desenvolvimento siga dois percursos:

* O backlog das experiências de utilizador que quer criar.
* O desenvolvimento das ferramentas e interfaces necessárias para construir o seu pipeline de entrega. (Ou para otimizar o seu pipeline existente para contribuidores, bem como para a sua equipa de desenvolvimento.)

Estes dois percursos também seguirão duas abordagens diferentes para testes:

* Testar as suas experiências de utilizador é mais semelhante ao teste tradicional de interface de utilizador, e não requer os mesmos recursos de scripting.
* Testar as suas ferramentas e interfaces do pipeline exigirá mais recursos técnicos.

Quanto mais cedo conseguir apresentar uma proposta de valor ao seu utilizador ou jogador, mais cedo poderá obter feedback para confirmar ou rejeitar essa proposta. Confirmar valor rapidamente é fundamental. Muitos developers experientes contarão histórias de como tinham a certeza absoluta de como uma nova mecânica seria incrível até a usarem e parecer desajeitada e com falhas, os jogadores não reagirem de todo, ou ela não resolver um desejo/necessidade do consumidor. Quer falhar rapidamente com o mínimo de esforço possível, para poder aprender com o seu fracasso e planear a próxima iteração.

Como falhar rapidamente? Faz o mínimo necessário para levar o teu jogador a interagir com o teu produto.

## Fatores para Minimum Viable Products

Aqui está a lista de fatores a considerar para o seu MVP básico. É aceitável afirmar que irá usar algo como placeholder e depois substituí-lo gradualmente à medida que desenvolver uma substituição mais sólida.

1. Criação de arte
   * Em primeiro lugar, comece com imagens estáticas básicas
   * O seu primeiro teste deve ser de estilo: o estilo que escolheu agrada aos seus utilizadores?
   * Isto pode ser o início de um style guide para fornecer a um artista externo
2. Criação da scene
   * Desenvolva uma noção básica do seu espaço
   * O jogador deve sentir que está num espaço novo e único
   * Delimite o seu espaço em relação aos espaços vizinhos
   * Os limites são evidentes e óbvios – mesmo que seja 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 (isto pode simplesmente ser billboards reais ou sprites mais sofisticados virados para a camera)
   * Estabeleça o tom e a estética do seu espaço (ou seja, estilo, claro, escuro)
   * Registe o seu processo: como a arte foi criada e implementada na scene?
   * Como quer organizar os seus ficheiros de arte para implementação repetida?
4. Experiência do jogador
   * Os jogadores conseguem visitar o seu espaço/scene
   * Os jogadores conseguem distinguir o seu espaço dos espaços vizinhos
5. Objetivos do pipeline
   * Implementar scene estática de exemplo: sem interação com o jogador
   * Implementar scene animada: elementos como fontes de água ou bandeiras ondulantes fazem as suas animações em loop
   * Implementar scene interativa: incluindo envolvimento do jogador
   * Demonstrar o pipeline de implementação reimplementando conteúdo: da criação da arte à scene, incluindo scripting + QA]
   * Expor lacunas do pipeline: identificar os desconhecidos em áreas específicas de implementação de conteúdo

## Níveis de protótipos

Falhar rapidamente permite-lhe desenvolver a sua experiência criando protótipos sucessivos, com cada iteração a construir sobre a anterior.

**Comece com um protótipo de um jogador. Depois, pode planear as interações multijogador com scripting. Por fim, pode abordar o seu ciclo principal persistente que demonstra camadas transacionais.**

**O que é um ciclo principal persistente?**

No design de jogos, um ciclo principal persistente é o "game loop" fundamental que conduz as ações do jogador e a resposta do jogo a essas ações. Estes ciclos persistentes estendem-se a qualquer forma de experiência virtual (como as fornecidas por Districts).

**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 com a sua experiência para manter um registo persistente das ações do jogador. Criar e manter este registo persistente é o que constrói uma experiência mais pessoal.

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

Por exemplo, poderia desenhar uma scene com as seguintes experiências sucessivas:

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

## Como partilhar o seu MVP

Recomendamos testar alterações com utilizadores de teste antes de carregar uma nova versão da sua scene para Decentraland. Pode publicar a sua scene num [Decentraland World](/creator/content-creator-pt/scenes-sdk7/publicacao/publishing-options.md#decentraland-worlds) para a partilhar através de um link sem necessidade de qualquer LAND, e sem afetar o conteúdo em produção.

## Considerações adicionais

Uma vez cobertos os casos de utilização básicos, pode começar a sofisticar mais a sua estratégia de gestão de lançamentos ao focar-se em mecânicas. **Mecânicas** é um termo abrangente que cobre todas as ações que um jogador pode realizar e as respostas que o sistema fornecerá com base nessas ações do jogador.

**A interoperabilidade de dispositivos** é um aspeto importante a ter em conta. Os utilizadores da sua scene podem estar a aceder à sua scene através de um desktop, de um dispositivo móvel ou de um headset de VR. Os utilizadores devem conseguir interagir com a sua scene razoavelmente bem usando qualquer um deles. Para quem usa um headset de VR, tente evitar movimentos que causem tonturas e que possam provocar enjoo de movimento.

**Áudio** é outro aspeto crítico da atmosfera de uma scene. Sons de fundo como vento, grilos, conversas ao longe, talvez até música, podem ser uma forma muito poderosa de aumentar a imersão e dar contexto. Também pode alterar a forma 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 [as design constraints for games](/creator/content-creator-pt/scenes-sdk7/conceber-a-experiencia/design-games.md) para uma análise detalhada de vários outros aspetos a considerar.

Considere o MVP como um de muitos protótipos que pode usar para estabelecer a sua cadência de lançamentos assim que tiver estabelecido o seu pipeline. O foco de cada lançamento pode variar, ou pode ser um híbrido de cada aspeto da experiência. No entanto, deve visar entregar experiências progressivamente mais complexas, com cada iteração a construir sobre a anterior.

1. **MVP**: jogador único
2. **Lançamento 2**: Adicionar suporte para multijogador e/ou interação
3. **Lançamento 3**: Introduzir a sua primeira mecânica
4. **Lançamento 4**: Adicionar suporte de áudio
5. **Lançamento 5**: Finalizar o seu pipeline de arte

Por exemplo, digamos que estamos a construir um MVP para um jogo de Frisbee golf. O MVP incluirá algumas imagens estáticas do percurso. O jogador pode até conseguir lançar um disco, de uma forma muito rudimentar, em estilo de blocos. Isto permite-nos definir os nossos mecanismos básicos de lançamento. O próximo lançamento pode incluir um protótipo de suporte multijogador para que possamos demonstrar e testar dois utilizadores com sessão iniciada a jogar no nosso LAND ao mesmo tempo.

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

Recomendamos fortemente que 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á para vir e incentiva-os a envolverem-se com a sua comunidade e a regressarem nos próximos lançamentos.

## Fatores de persistência a considerar

Em última análise, quer atingir 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 utilizador, fuso horário, localização para a sua experiência/jogo específico
2. **Estatísticas da leaderboard**: resultados de jogos anteriores, classificações globais/regionais, competições
3. **Validação de identidade**: endereço da Ethereum wallet, ou qualquer outra gestão de identidade backend
4. **Atualizações da blockchain**: conforme necessário com base na sua experiência/jogo para atualizar o registo da blockchain para transparência transacional
5. **Persistência em runtime**: dados temporários para persistência ao longo de uma plataforma potencialmente distribuída (ou seja, saúde apenas para a experiência de jogo individual)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/creator/content-creator-pt/scenes-sdk7/conceber-a-experiencia/mvp-guidelines.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.