Diretrizes de MVP
Diretrizes recomendadas para produzir sua primeira cena ou experiência MVP usando o SDK
O objetivo deste documento é ajudá-lo a orientar-se no processo de construir as primeiras iterações de cenas em Decentraland. Nos referiremos a estas como um Produto Mínimo Viável (MVP).
Ao criar o Produto Mínimo Viável (MVP) para sua cena, você precisa pensar em duas áreas de foco:
A experiência básica do usuário e a funcionalidade do seu projeto.
A criação de uma "pipeline" básica, ou fluxo de trabalho da equipe e sistema de gerenciamento de conteúdo para construir 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 você pode fazer usando o SDK da 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 seu MVP desta maneira requer três perspectivas diferentes:
Como desenvolvedor ou produtor, como eu entrego uma experiência ao meu usuário/jogador?
Como usuário ou jogador, o que eu espero desta experiência?
Como colaborador ou parte interessada, como eu contribuo para a pipeline ou experiência?
É importante distinguir essa abordagem do desenvolvimento ágil tradicional, porque você pode ter que usar métodos não ótimos para atender aos seus objetivos de design.
Você terá que 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, na pipeline e nos contribuintes de conteúdo, ou um pouco de ambos.
Ao planejar cada lançamento, é crucial que você defina conscienciosamente e deliberadamente suas prioridades de acordo com cada uma dessas três perspectivas.
Você pode esperar que seu backlog de desenvolvimento siga duas trilhas:
O backlog de experiências de usuário que você deseja criar.
O desenvolvimento das ferramentas e interfaces necessárias para construir sua delivery pipeline. (Ou para otimizar sua pipeline existente para contribuidores bem como para sua equipe de desenvolvimento.)
Essas duas trilhas também seguirão duas abordagens diferentes de teste:
Testar suas experiências de usuário é mais parecido com testes tradicionais de interface do usuário, e não requer os mesmos recursos de scripting.
Testar suas ferramentas e interfaces da pipeline exigirá mais recursos técnicos.
Quanto mais cedo você puder apresentar uma proposta de valor ao seu usuário ou jogador, mais cedo você poderá obter feedback para confirmar ou rejeitar essa proposta. Confirmar valor rapidamente é crítico. Muitos desenvolvedores experientes compartilham histórias de como tinham certeza absoluta de quão incrível uma nova mecânica seria até usá-la e ela parecer estranha e com falhas, os jogadores não reagirem a ela ou ela 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 sua falha e planejar a próxima iteração.
Como falhar rapidamente? Faça o mínimo necessário para que seu jogador toque no seu produto.
Fatores para Produtos Mínimos Viáveis
Aqui está a lista de fatores a considerar para seu MVP básico. É aceitável declarar que você usará algo como um placeholder e depois o substituirá à medida que desenvolver uma substituição mais sólida.
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 seus usuários?
Isto pode ser o início de um guia de estilo para fornecer a um artista terceirizado
Criação de Cena
Desenvolva uma noção básica do seu espaço
O jogador deve sentir que está em um espaço novo e único
Delimite seu espaço em relação aos espaços vizinhos
As bordas são evidentes e óbvias – mesmo que apenas por uma linha desenhada
Cubra toda a área com conteúdo/arte estática
Arte Renderizada na Cena
Usar billboards é aceitável ou outra sinalização (isto pode simplesmente ser outdoors reais ou sprites mais sofisticados voltados para a câmera)
Estabeleça o tom e a estética do seu espaço (por exemplo: estilo, claro, escuro)
Observe seu processo: como a arte foi criada e implantada na cena?
Como você quer organizar seus arquivos de arte para implantações repetidas?
Experiência do jogador
Os jogadores conseguem visitar seu espaço/cena
Os jogadores podem distinguir seu espaço dos espaços vizinhos
Objetivos da Pipeline
Implantar cena estática de exemplo: sem interação com o jogador
Implantar cena animada: elementos como fontes de água ou bandeiras ondulantes repetem suas animações
Implantar cena interativa: incluindo engajamento do jogador
Demonstrar a pipeline de deploy reimplantando conteúdo: desde a criação da arte até na cena incluindo scripting + QA]
Expor lacunas da pipeline: identificar os desconhecidos 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 construindo sobre a anterior.
Comece com um protótipo para um único jogador. Então você pode planejar o scripting de interações multiplayer. Finalmente, você pode enfrentar seu loop central persistente que demonstra camadas transacionais.
O que é um loop central persistente?
Em 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).
📔 Nota: O cliente Decentraland toma emprestadas algumas ideias arquiteturais de React.js e só renderiza uma cena quando ocorreu uma mudança, não a uma taxa constante.
O que são camadas transacionais?
As camadas transacionais são as interfaces entre sistemas como uma atualização na blockchain ou outra aplicação que foi integrada à sua experiência para manter um registro persistente das ações dos jogadores. Criar e manter esse registro persistente é o que constrói uma experiência mais pessoal.
Recomendamos criar seu MVP como uma experiência para um único jogador.
Por exemplo, você poderia projetar uma cena 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 cena.
Outros jogadores podem entrar e interagir com o mundo e com o outro jogador.
Finalmente, você pode adicionar a capacidade de lembrar que cada jogador entrou na cena e de rastrear os eventos e atividades dos jogadores.
Como compartilhar seu MVP
Embora o mundo da Decentraland ainda não esteja aberto a todos, você pode fazer upload de uma pré-visualização da cena para um servidor e compartilhar facilmente um link com pessoas que podem lhe dar feedback.
Mesmo quando a Decentraland estiver disponível para todos, ainda recomendamos testar alterações com usuários de teste em um servidor de pré-visualização separado primeiro, antes de enviar uma nova versão da sua cena para a Decentraland.
Leia este post no blog para detalhes sobre como fazer upload da pré-visualização da sua cena para um servidor gratuito.
Considerações adicionais
Uma vez que os casos de uso básicos estejam cobertos, você pode começar a se tornar mais sofisticado com sua estratégia de gerenciamento de lançamentos focando-se em mecânicas. Mecânicas são um termo amplo que cobre todas as ações que um jogador pode tomar e as respostas que o sistema fornecerá com base nessas ações do jogador.
Interoperabilidade de dispositivos é algo importante a ter em mente. Os usuários da sua cena podem estar acessando sua cena usando um desktop, um dispositivo móvel ou um headset VR. Os usuários devem conseguir interagir com sua cena de forma razoável usando qualquer um deles. Para quem usa um headset VR, evite movimentos que causem tontura e possam provocar enjoo de movimento.
Áudio é outro aspecto crítico da atmosfera de uma cena. Sons de fundo como vento, grilos, conversas distantes, talvez até música, podem ser uma maneira 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 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 seu ritmo de lançamentos uma vez que tenha estabelecido sua pipeline. O foco de cada lançamento pode variar, ou pode ser um híbrido de cada aspecto da experiência. No entanto, você deve visar entregar experiências sucessivamente mais complicadas, cada iteração construindo sobre a anterior.
MVP: Single player
Release 2: Add multiplayer and/or interaction support
Release 3: Introduce your first mechanic
Release 4: Add audio support
Release 5: Finalize your art pipeline
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 pode até ser capaz de lançar um disco, de uma forma muito rudimentar, estilo bloco. Isso nos permite resolver nossa mecânica básica de arremesso. O próximo lançamento pode incluir um protótipo de suporte multiplayer para que possamos demonstrar e testar dois usuários conectados e jogando em nosso LAND ao mesmo tempo.
Lembre-se: embora a meta final seja um mundo 3D verdadeiramente imersivo, esse não é o ponto de partida do seu MVP. Colocar um jogador em seu mundo o mais rápido possível deve ser seu primeiro objetivo. Levar semanas, não meses, para testar seus lançamentos é crucial para aprender e iterar sem desperdiçar esforço.
Recomendamos fortemente que você permaneça atento à primeira impressão que sua experiência apresenta. Uma experiência vazia deixará os jogadores desapontados. Por outro lado, uma cena com algum conteúdo inicial e experiências básicas mostra aos jogadores o potencial do que está por vir e os encoraja a interagir com sua comunidade e retornar para os próximos lançamentos.
Fatores de persistência a considerar
Em última análise, você quer alcançar um nível de persistência onde 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.
Informações da conta: nome de login, fuso horário, localização para sua experiência/jogo específico
Estatísticas do ranking: resultados de jogadas anteriores, classificações globais/regionais, competições
Validação de identidade: endereço de wallet Ethereum, ou qualquer outro gerenciamento de identidade de backend
Atualizações na blockchain: conforme necessário com base na sua experiência/jogo para atualizar o ledger da blockchain para transparência transacional
Persistência em runtime: dados temporários para persistência em uma plataforma potencialmente distribuída (por exemplo, vida apenas para a experiência de jogo única)
Atualizado