Projetar Jogos

O que você precisa ter em mente ao projetar um jogo para o Decentraland.

Este documento aborda alguns pontos-chave a considerar ao projetar um jogo para Decentraland. Considerações como a adjacência de outras scenes e a propriedade distribuída das LAND tornam Decentraland um lugar único que exige que você reconsidere pressupostos que pode ter de jogos anteriores.

Por exemplo, você deve entender que, ao contrário de outras plataformas de jogos, os jogos em Decentraland não existem em um vácuo. Você não tem controle sobre o que há em scenes adjacentes, e não tem controle sobre certos detalhes como os avatares dos jogadores ou itens que eles possam trazer de outros jogos. Isso abre a porta para possibilidades empolgantes e exige que você pense de forma diferente sobre mecânicas de jogo.

O mais próximo nos jogos mainstream atualmente é o Roblox, onde conteúdo gerado por usuários na comunidade pode então ser um ponto de encontro para outros explorarem, jogarem e interagirem. Ao contrário do Roblox, você navega por scenes não navegando em um menu de experiências não relacionadas, mas explorando fisicamente um terreno onde todas as scenes são adjacentes umas às outras. Decentraland também faz uso da blockchain como forma de gerenciar a propriedade de land, avatares, assets, etc.

Estamos continuamente melhorando o SDK, então algumas das limitações a seguir serão removidas em atualizações futuras antes que Decentraland seja aberto aos usuários finais.

Limites da scene

Seu jogo deve caber inteiramente no _LAND_** sobre o qual sua scene é construída.** Para scenes pequenas, pense em jogos como o futebol, onde as regras do jogo mantêm a interação relevante dentro de um espaço confinado, embora os jogadores possam sair do campo. Jogadores podem andar para fora dos limites de uma scene, mas qualquer asset ou entity que pertença à scene deve permanecer dentro da scene.

Jogadores que saem da sua scene continuam a renderizá‑la enquanto ela estiver em um alcance visível. Se eles se afastarem demais, deixarão de renderizá‑la completamente.

Você também poderia criar um jogo que se espalha por vários plots de land desconectados e desconhecidos para os jogadores, onde a exploração do restante do mundo se torna parte da jogabilidade. Um jogo assim seria composto por múltiplas separadas scenes, que poderiam compartilhar dados entre si via um servidor.

Inventário do usuário

Atualmente não existe um inventário onde os jogadores possam armazenar itens do jogo enquanto caminham entre scenes. As seguintes alternativas estão disponíveis hoje:

• Você pode armazenar informações de inventário na própria scene e vinculá‑las ao endereço Ethereum de cada jogador (isso pode ser usado como um id persistente). Essa informação seria legível apenas pela sua scene.

• Você pode usar um armazenamento externo customizado e sincronizar todas as suas scenes com ele. Esta é uma solução mais robusta que pode lidar com volumes maiores de jogadores. Também pode estender o acesso a esse inventário para múltiplas scenes separadas que você ou outros possuam.

• Use tokens na blockchain para gerenciar a propriedade de itens.

Ao ganhar um item de jogo, ele poderia ser armazenado como um token especial na carteira Ethereum do jogador. Quando um jogador que possui o token entrar na sua scene, sua scene poderia conceder ao jogador certas características dentro do jogo.

Outras scenes também poderiam potencialmente responder ao mesmo token de maneiras diferentes, o que pode criar interações interessantes entre jogos.

A desvantagem de usar a blockchain para armazenar itens de inventário é que todas as transações têm um custo para o jogador e não são imediatas. Leia mais sobre a blockchain em uma seção especializada mais abaixo.

Em versões futuras, os jogadores terão um inventário que carregam para qualquer lugar e que incluirá assets on-chain e off-chain.

Experiências portáteis

📔 Nota: Experiências portáteis e smart wearables ainda estão em estágio exploratório e ainda não estão disponíveis para criadores da comunidade.

Experiências portáteis são partes da jogabilidade que os jogadores levam consigo enquanto se movem pelo metaverso. Estas não estão amarradas a parcels de land, às vezes estão vinculadas a tokens, ou às vezes são iniciadas pelo Explorer. Por exemplo, um jogador poderia pegar uma bolinha de neve na sua scene, sair para outra scene e arremessar a bolinha de neve para outro jogador que também esteja jogando o mesmo jogo.

Smart wearables são um tipo de experiência portátil que está vinculada a um wearable token e é ativada quando o jogador veste o item de roupa. Smart wearables podem conceder novas habilidades aos jogadores, como um jetpack que permite voar, ou adicionar uma nova camada de conteúdo sobre o restante do mundo, como posicionar moedas aleatoriamente para serem coletadas por toda a Genesis City.

Tenha em mente que os jogadores podem estar usando a experiência portátil de outra pessoa enquanto estiverem na sua scene. Veja User Data para aprender como verificar quais experiências portáteis um jogador tem atualmente ativadas.

Persistência do jogo

Decentraland é um mundo persistente, sua scene pode ser visitada por jogadores a qualquer momento. Sua scene não tem fase de startup nem fim, portanto você deve projetar as mecânicas de jogo de forma que permita que jogadores que entram ou saem a qualquer momento também possam participar.

Sua scene pode ter um mecanismo de reset que a defina para um estado inicial, mas você deve ter cuidado para não interromper o jogo de jogadores que já estão participando.

Sincronizar estado da scene

Atualmente, estados de scene não são compartilhados entre jogadores a menos que sejam implementados manualmente. Esta é a maneira mais simples de construir uma scene, mas não é ideal para experiências sociais.

Você pode usar o MessageBus para utilizar a mesma arquitetura de mensagens usada para compartilhar mudanças de posição dos players e chat. Essas mudanças de estado não são armazenadas em lugar nenhum. Se nenhum jogador estiver atualmente próximo da scene e carregando‑a, a scene será reiniciada para um estado padrão na próxima vez em que for carregada.

Você pode hospedar seu próprio servidor para armazenar informações sobre sua scene e manter todos os jogadores sincronizados com ela. Isso garante boas velocidades de conexão e mantém a scene rodando continuamente mesmo quando nenhum jogador está por perto. Se você fizer isso, suas limitações de latência não seriam diferentes das de outros jogos online com grande número de jogadores.

Hospedar seu próprio servidor também é uma medida de segurança recomendada para jogos que envolvem transações com itens valiosos, pois você pode manter certas informações como tokens de segurança somente no servidor, nunca expondo essas informações externamente.

📔 Nota: Em lançamentos futuros, forneceremos soluções prontas e exemplos de código de como implementar seu próprio servidor.

Tempo de jogo

Jogos que usam a arquitetura de comunicações padrão devem levar em conta que pode haver lag entre jogadores e não devem confiar em reações rápidas entre as ações de diferentes jogadores. Recomendamos jogos por turnos, ou que sejam majoritariamente baseados em interações jogador versus ambiente.

Para jogos onde o tempo das ações entre jogadores é crítico, como um first person shooter, você deve implementar seu próprio servidor como uma fonte autoritativa em tempo real entre todos os jogadores na sua scene.

Jogadores na scene

Jogadores são identificados em Decentraland usando seu endereço de carteira Ethereum. Essa carteira é usada como um ID persistente que já está associado a todos os tokens que o jogador possui.

Atualmente não há como limitar quantos jogadores podem estar presentes em Decentraland ao mesmo tempo. Ao contrário de muitos outros jogos onde podem haver diferentes sessões hospedadas em servidores separados, existe apenas uma instância de Decentraland compartilhada entre todos os jogadores, pelo menos por enquanto.

Você precisa ter em mente que pode haver vários jogadores andando pela sua scene a qualquer momento. Alguns deles podem estar apenas passando e não participando do jogo. Certifique‑se de que as mecânicas de jogo não possam ser facilmente interrompidas por isso.

O game loop da sua scene não pode afetar os jogadores diretamente, a scene tem uma abordagem reativa às ações do jogador. Se um jogador estiver em pé sobre uma entity e a entity se mover ou girar, o jogador se moverá com essa entity. Isso é especialmente útil para elevadores, plataformas flutuantes e similares.

Como proprietário de uma scene, você não pode forçar empurrar ou teleportar à força um jogador infrator para fora da sua scene. Entretanto, você poderá colocar jogadores em blacklist no signaling server. Você também pode implementar uma blacklist no código da sua scene e negar certos serviços a jogadores listados na blacklist.

Limitações de conteúdo da scene

Por favor, construa sua scene tendo extremo cuidado com a eficiência do seu código. Decentraland precisa rodar em navegadores web e dispositivos móveis, e os jogadores estarão renderizando múltiplas scenes ao mesmo tempo enquanto caminham pelo metaverso.

Você também deve tentar manter a scene leve. Ao contrário de outros jogos online onde as mesmas textures e assets são convenientemente repetidos por um grande mundo aberto, em Decentraland cada scene pode ter seu próprio conjunto completamente diferente de assets. À medida que os jogadores caminham por múltiplas scenes, eles devem ser capazes de baixar a totalidade do conteúdo da scene, incluindo textures, arquivos de som, etc., em uma velocidade razoável.

Por causa disso, impusemos alguns limites para prevenir uso excessivo de recursos computacionais. Veja limitações da cena para detalhes sobre quais são esses limites.

Acesso às scenes

O mapa de Decentraland é projetado de forma que existam roads e public plazas, estes garantem acesso fácil a várias partes do mapa, independentemente do que outras pessoas construam. Plots de land que não são adjacentes a nenhuma road ou plaza correm o risco de serem isolados por scenes vizinhas, embora esperemos que a maioria das scenes seja caminhável e não bloqueie as outras.

Novos jogadores iniciarão sua experiência em Genesis Plaza, no centro do mapa, onde serão incentivados a seguir algumas atividades tutoriais e então explorar o mundo.

Os jogadores também podem digitar manualmente uma URL para coordenadas específicas no mapa de Decentraland para spawnar nessa localização. Você também pode compartilhar links para URLs que possuam coordenadas iniciais codificadas.

Tenha em mente que se um jogador começar em uma localização que esteja isolada por paredes ou abaixo do nível do terreno, não será uma experiência agradável. Para evitar isso, há uma forma de definir um conjunto de localizações específicas na sua scene que são seguras para spawnar. Veja metadados da cena para detalhes.

Em lançamentos futuros, os jogadores também poderão navegar pelo mundo rapidamente usando mapas com spawn points, listas de locais populares e locations de amigos. O SDK também tornará possível adicionar teleports na sua scene que possam transportar para outras partes do mundo.

UI do usuário

A UI sobreposta padrão que os jogadores veem ao entrar em Decentraland possui apenas o essencial. Você pode adicionar elementos extras a essa UI enquanto um jogador estiver na sua scene. Tenha em mente que a UI padrão do Decentraland é exibida acima de qualquer coisa da sua scene, então projete sua UI para que ela não se sobreponha a isso.

Quando um jogador sai da scene, todos os elementos de UI são removidos para não interferir com outras scenes. Os jogadores também têm um botão disponível na tela para desativar todos os elementos de UI da scene; isso é principalmente útil para prevenir comportamento abusivo por scenes que queiram cobrir todo o campo de visão do jogador.

Física

Tenha em mente que o SDK não fornece seu próprio engine de física. Se quiser usar física na sua scene, você pode importar uma library ou codificar o comportamento você mesmo.

Entradas do controle

Os controles do seu jogo devem ser limitados a movimentos básicos, pular, apontar e clicar, assim como um botão primário e um secundário. Nós daremos suporte a controles mobile e de Virtual Reality, então não podemos assumir que todos tenham um teclado.

Temos suporte para eventos globais de button up e button down para os três botões. Todos os três botões também têm eventos de hit que permitem identificar se uma entity estava na mira do jogador.

Avatares

Os jogadores podem construir seus avatares com base em um conjunto de wearables padrão. Expanderemos a lista de wearables e opções disponíveis, e no futuro também tornaremos possível que terceiros criem e vendam wearables.

Comunicação entre jogadores

Usuários podem conversar entre si. Avatares atualmente não têm como transmitir linguagem corporal além do uso de controles básicos de movimento.

Em lançamentos futuros eles também poderão fazer voice chat e executar gestos como dançar ou franzir a testa com seus avatares. Também poderão exibir um emoji temporário acima de seu avatar para se expressar. Os jogadores também poderão exibir tokens que possuam para que outros jogadores possam vê‑los.

Notificações do jogo

Atualmente não existe um sistema de notificações entre scenes. Qualquer jogo que requeira notificações exibidas fora da scene atual terá que implementá‑las usando um serviço externo.

Usando a blockchain

Em Decentraland, a blockchain é usada para armazenar informações sobre propriedade. Hoje isso se refere principalmente à propriedade de LAND, mas também pode ser usado para propriedade de itens de jogo, wearables, avatares especiais, emotes, e tokens que podem garantir certos privilégios de jogo ou acesso a jogos.

A blockchain não é usada para armazenar o estado do jogo, posição do jogador ou qualquer coisa que precise mudar em tempo real.

LAND e MANA

Os jogadores não precisam possuir parcels de land para participar do metaverso. De fato, a grande maioria dos jogadores não possuirá. Avatares dos jogadores e os tokens de LAND que eles possuem não estão conectados de forma direta.

Os jogadores não precisam possuir previamente uma carteira Ethereum ou tokens MANA para entrar em Decentraland. Se sua jogabilidade depender fortemente da posse de tokens, você estaria excluindo a maioria dos jogadores. Um modelo de jogo freemium pode ser uma forma ideal de atender a ambas as bases de usuários.

Outros NFTs

Você pode usar NFTs especiais para representar itens de jogo, avatares customizados ou wearables. Se um jogador possuir um desses tokens, sua scene poderia responder a ele de diferentes maneiras.

Leia sobre o que são NFTs em este post no blog.

Transações dentro do jogo

Sua scene pode suportar transações na blockchain para jogadores comprarem ou ganharem tokens.

Transações na blockchain não são imediatas, requerem tempos de verificação e têm um custo em Ether; tanto o tempo quanto o custo variam dependendo do uso atual da rede.

Decentraland está trabalhando na criação de uma side-chain que será capaz de processar transações mais rápido e mais barato que a rede Ethereum. Essa side-chain será ideal para transações dentro do jogo, pois mudanças podem ocorrer mais próximas do tempo real e a um custo muito baixo. A cadeia principal Ethereum ainda será recomendada para transações que requerem maior segurança e que podem custar mais e demorar mais.

O jogador deve sempre aprovar essas transações explicitamente em seu cliente Ethereum. Por exemplo, ao usar Metamask, o Metamask solicita ao jogador que aceite cada transação antes que ela seja processada.

Os jogadores também poderiam assinar um contrato que aprove automaticamente todas as transações solicitadas por um endereço específico ou dentro de certos limites, de modo a evitar interrupções para aprovar transações.

Você também pode usar smart contracts para condicionar transações com base em condições customizadas. Por exemplo, os jogadores poderiam apostar no resultado de um jogo, e os pagamentos correspondentes ocorreriam automaticamente assim que o resultado fosse conhecido.

Para implementar interações com a blockchain no código da sua scene, você deve usar libraries externas que façam interface com a rede Ethereum. Lançamentos futuros do SDK fornecerão uma API customizada para expor essas funcionalidades de forma mais simples.