> 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/design-games.md). # Desenvolver 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 do LAND tornam Decentraland um lugar único que exige que reconsidere pressupostos que possa ter de jogos anteriores. Por exemplo, deve entender que, ao contrário de outras plataformas de jogos, os jogos do Decentraland não existem no vácuo. Não tem controlo sobre o que há nas scenes adjacentes, nem sobre certos detalhes como os avatars do jogador ou itens que ele possa trazer de outros jogos. Isto abre a porta a possibilidades empolgantes e exige que pense nas mecânicas de jogo de forma diferente. A coisa mais próxima nos jogos mainstream atualmente é o Roblox, onde conteúdo gerado por utilizadores na comunidade pode depois ser um ponto de encontro para que outros explorem, joguem e interajam. Ao contrário do Roblox, navega pelas scenes não através de um menu de experiências sem relação entre si, mas explorando fisicamente um terreno onde todas as scenes são adjacentes umas às outras. Decentraland também faz uso da blockchain como uma forma de gerir a propriedade de LAND, avatars, assets, etc. Estamos a melhorar continuamente o SDK, por isso algumas das limitações seguintes poderão ser removidas em atualizações futuras. ## Limites da scene **O seu jogo deve caber inteiramente no \_LAND**\_\*\* sobre o qual a sua scene está construída.\*\* Para scenes pequenas, pense em jogos como futebol, em que as regras do jogo mantêm a interação relevante dentro de um espaço confinado, mesmo que os jogadores possam sair do campo de jogo. Os jogadores podem caminhar para fora dos limites de uma scene, mas qualquer asset ou entities que pertençam à scene deve permanecer dentro da scene. Os jogadores que saem da sua scene continuam a renderizá-la enquanto estiver dentro do alcance visível. Se se afastarem demasiado, deixarão de a renderizar por completo. Também poderia criar um jogo que se espalha por vários parcels de LAND desconectados e desconhecidos pelos jogadores, e em que a exploração do resto do mundo se torna parte da jogabilidade. Um jogo assim seria composto por várias *scenes*, que poderiam partilhar dados entre si por meio de um server. Se o seu jogo for publicado para um [Decentraland World](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md), tem mais controlo sobre o que os jogadores veem para além dos limites da sua scene. Worlds são normalmente rodeados por uma paisagem gerada automaticamente de prados, árvores e mar, mas pode [desativar esta paisagem](/creator/content-creator-pt/scenes-sdk7/tipos-de-projetos/scene-metadata.md#landscape-terrain) se isso entrar em conflito com o ambiente do seu jogo, por exemplo, um jogo que decorre em mar aberto ou no espaço. ### Inventário do utilizador **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: * Pode armazenar as informações do inventário na própria scene e ligá-las ao endereço Ethereum de cada jogador (isto pode ser usado como um id persistente). Essas informações só poderiam ser lidas a partir da sua scene. * Pode usar um armazenamento personalizado externo 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 este inventário a várias scenes separadas que você ou outros possuam. * Use tokens na blockchain para lidar com a propriedade dos itens. Ao ganhar um item do jogo, ele poderia ser armazenado como um token especial na wallet Ethereum de um jogador. Quando um jogador que possui o token entra na sua scene, a sua scene poderia conceder ao jogador certas características dentro do jogo. Outras scenes também poderiam potencialmente responder ao mesmo token de formas diferentes, o que pode gerar uma interação interessante entre jogos. A desvantagem de usar a blockchain para armazenar itens do 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 numa secção especializada mais abaixo. Em lançamentos futuros, os jogadores terão um inventário que levarão consigo para todo o lado, o qual incluirá tanto assets on-chain como off-chain. ### Experiências portáteis {% hint style="info" %} **💡 Dica**: Veja [Experiências portáteis](/creator/content-creator-pt/scenes-sdk7/tipos-de-projetos/portable-experiences.md) e [Smart wearables](/creator/content-creator-pt/scenes-sdk7/tipos-de-projetos/smart-wearables.md) sobre como criar estes. {% endhint %} Experiências portáteis são partes da jogabilidade que os jogadores levam consigo à medida que se movem pelo metaverse. Estas não estão ligadas a parcels de LAND; por vezes estão ligadas a tokens, ou por vezes são lançadas pelo Explorer. Por exemplo, um jogador poderia levar uma bola de neve da sua scene, afastar-se para outra scene e atirar a bola de neve a outro jogador que também esteja a jogar o mesmo jogo. Smart wearables são um tipo de experiência portátil ligada a um wearable token e ativada quando o jogador veste o item de roupa. Smart wearables podem conceder aos jogadores novas habilidades, como um jetpack que lhes permite voar, ou adicionar uma nova camada de conteúdo sobre o resto do mundo, como colocar aleatoriamente moedas para serem recolhidas em toda a Genesis City. Tenha em mente que os jogadores podem estar a usar a experiência portátil de outra pessoa enquanto estiverem na sua scene. Veja [Dados do utilizador](/creator/content-creator-pt/scenes-sdk7/interatividade/user-data.md#get-portable-experiences) para saber como verificar quais experiências portáteis um jogador tem atualmente ativadas. ## Persistência do jogo **Decentraland é um mundo persistente, por isso a sua scene pode ser visitada por jogadores a qualquer momento.** A sua scene não tem fase de arranque nem fim, por isso deve desenhar as mecânicas de jogo de forma a permitir que os jogadores que entrem ou saiam a qualquer momento também participem. A sua scene pode ter um mecanismo de reset que a coloque num estado inicial, mas deve ter cuidado para não perturbar o jogo dos jogadores que já estiverem a jogar. ### Sincronizar o estado da scene **Por padrão, os estados da scene não são partilhados entre jogadores.** Cada jogador executa a sua própria cópia local da scene. Esta é a forma mais simples de criar uma scene, mas não é ideal para experiências sociais. A forma mais fácil de partilhar o estado entre jogadores é marcar entities como sincronizadas, usando o `syncEntity` função. Veja [Multijogador sem servidor](/creator/content-creator-pt/scenes-sdk7/rede/serverless-multiplayer.md). Com esta abordagem, as alterações de estado não são armazenadas em lado nenhum: se não houver jogadores perto da scene e a carregá-la, a scene será reposta para um estado predefinido da próxima vez que for carregada. **Também pode usar um server para armazenar informações sobre a sua scene e manter todos os jogadores sincronizados com ela.** Isto mantém o estado da scene consistente e persistente mesmo quando não há jogadores por perto, e permite validar alterações para que os jogadores não possam fazer batota. A opção recomendada é usar um [Multiplayer Server](/creator/content-creator-pt/scenes-sdk7/rede/authoritative-servers.md), que Decentraland hospeda e faz o deploy para si como parte da publicação da sua scene. Também pode hospedar [o seu próprio server](/creator/content-creator-pt/scenes-sdk7/rede/third-party-servers.md), o que lhe permite manter certas informações, como security tokens, apenas no server, sem nunca expor essas informações para fora. ### Tempo de jogo **Os jogos que usam a arquitetura de comunicações padrão devem ter em conta que pode haver lag entre jogadores** e não devem depender de reações rápidas entre as ações de diferentes jogadores. Recomendamos jogos por turnos, ou que sejam maioritariamente baseados em interações player versus environment. Para jogos em que o timing das ações entre jogadores é crítico, como um first person shooter, deve implementar o seu próprio server como uma fonte autoritária da verdade em tempo real entre todos os jogadores na sua scene. ## Jogadores na scene **Os jogadores são identificados em Decentraland usando o endereço da sua wallet Ethereum.** Esta wallet é usada como um ID persistente que já está associado a todos os tokens que o jogador possui. **Atualmente não há forma de limitar quantos jogadores podem estar presentes em Decentraland ao mesmo tempo.** Ao contrário de muitos outros jogos, em que pode haver diferentes sessões de jogo alojadas em servers separados, existe apenas uma instância de Decentraland partilhada entre todos os jogadores, pelo menos por enquanto. Precisa de ter em mente que pode haver vários jogadores a circular pela sua scene a qualquer momento. Alguns deles podem estar apenas de passagem e não participar no jogo. Certifique-se de que as mecânicas do jogo não podem ser facilmente perturbadas 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 cima de uma entity e a entity se mover ou rodar, o jogador mover-se-á com essa entity. Isto é especialmente útil para elevadores, plataformas flutuantes e semelhantes. Como proprietário de uma scene, não pode empurrar à força nem teleportar um jogador infrator para fora da sua scene. No entanto, poderá colocar jogadores numa blacklist no signaling server. Também pode implementar uma blacklist no código da sua scene e negar certos serviços a jogadores na blacklist. ## Limitações de conteúdo da scene **Por favor, construa a sua scene tendo cuidado redobrado com a eficiência do seu código.** Decentraland precisa de correr em web browsers e dispositivos móveis, e os jogadores estarão a renderizar várias scenes ao mesmo tempo enquanto percorrem o metaverse. **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 ao longo de um grande open world, em Decentraland cada scene pode ter o seu próprio conjunto de assets completamente diferente. À medida que os jogadores percorrem várias scenes, devem ser capazes de descarregar todo o conteúdo da scene, incluindo textures, ficheiros de som, etc., a uma velocidade razoável. Por causa disso, impusemos alguns limites para evitar o uso excessivo de recursos computacionais. Veja [limitações da scene](/creator/content-creator-pt/scenes-sdk7/otimizacao/scene-limitations.md) para detalhes sobre quais são estes limites. ## Acesso às scenes **O mapa de Decentraland foi concebido de forma a haver estradas e praças públicas,** o que garante acesso fácil a várias partes do mapa, independentemente do que outras pessoas construam. Parcelas de LAND que não sejam adjacentes a qualquer estrada ou praça correm o risco de ficar cercadas por scenes vizinhas, embora esperemos que a maioria das scenes seja percorrível e não bloqueie as outras. Os novos jogadores iniciarão a sua experiência na Genesis Plaza, no centro do mapa, onde serão incentivados a seguir algumas atividades de tutorial e depois a explorar o mundo. Os jogadores também podem escrever manualmente um URL para uma coordenada específica no mapa de Decentraland para aparecer nessa localização. Também pode partilhar links para URLs que tenham coordenadas iniciais hard-coded. Tenha em mente que, se um jogador começar numa localização cercada 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 é seguro para spawn. Veja [metadados da cena](/creator/content-creator-pt/scenes-sdk7/tipos-de-projetos/scene-metadata.md) para mais detalhes. Os jogadores também podem navegar rapidamente pelo mundo usando o mapa e as listas de locais e eventos populares. A sua scene pode incluir teleports que transportem os jogadores para outras partes do mundo, veja [Teletransportes](/creator/content-creator-pt/scenes-sdk7/interatividade/external-links.md#teleports). ## UI do utilizador **A UI sobreposta padrão que os jogadores veem ao entrar em Decentraland tem apenas o essencial.** Pode adicionar elementos extra a essa UI enquanto um jogador está na sua scene. Tenha em mente que a UI padrão do Decentraland é apresentada acima de qualquer coisa da sua scene, por isso desenhe a sua UI de forma a não se sobrepor a esta. Quando um jogador sai da scene, todos os elementos da UI são removidos para não interferirem com outras scenes. Os jogadores também têm um botão disponível no ecrã para desligar todos os elementos da UI na scene; isto é útil sobretudo para evitar comportamentos abusivos por parte de scenes que possam querer cobrir todo o campo de visão do jogador. ## Physics Tenha em mente que o SDK não fornece um motor de física completo para entities. Pode aplicar forças e impulsos ao avatar do jogador, veja [Física do jogador](/creator/content-creator-pt/scenes-sdk7/interatividade/player-physics.md). Para física entre entities, como colisões ou gravidade, pode importar uma library ou programar o comportamento você mesmo. ## Controller Inputs **Os controlos do seu jogo devem limitar-se ao conjunto de input actions suportadas pelo SDK**: as teclas de movimento, saltar, point and click, os botões primário (E) e secundário (F), e os botões de ação numerados (1 a 4). Estes inputs são abstraídos das teclas físicas, para que também possam mapear para os controlos no ecrã da aplicação móvel ou para outros devices; não assuma que toda a gente tem um keyboard. Veja [Botões do Pointer](/creator/content-creator-pt/scenes-sdk7/interatividade/eventos-de-botao/click-events.md#pointer-buttons) para a lista completa, e [Input no mobile](/creator/content-creator-pt/criar-para-mobile/desenvolver/input-on-mobile.md) para o que deve preferir ao visar jogadores móveis. Todos estes inputs suportam tanto global *button up* e *button down* events e eventos de hit que lhe permitem identificar se uma entity estava na mira do jogador. ## Avatars **Os jogadores podem criar os seus avatars a partir de um vasto catálogo de wearable items**, incluindo wearables criados e vendidos por criadores da comunidade no Decentraland Marketplace. A sua scene pode ler o que um jogador está a vestir e reagir a isso, veja [Dados do utilizador](/creator/content-creator-pt/scenes-sdk7/interatividade/user-data.md#get-player-data). ## Comunicação entre jogadores **Os jogadores podem conversar entre si, falar por voice chat e transmitir linguagem corporal ao executar emotes** como dançar, aplaudir ou acenar, incluindo emotes vendidos por criadores da comunidade. A sua scene pode detetar quando um jogador executa um emote e também pode fazer o avatar de um jogador reproduzir uma animação. Veja [Player reproduz animação](/creator/content-creator-pt/scenes-sdk7/interatividade/event-listeners.md#player-plays-animation) e [Animações de Avatar](/creator/content-creator-pt/scenes-sdk7/interatividade/avatares/avatar-animations.md). ## Notificações do jogo **Atualmente não existe um sistema de notificações entre scenes.** Qualquer jogo que exija notificações exibidas fora da scene atual terá de as implementar usando um serviço externo. ## Usando a blockchain **Em Decentraland, a blockchain é usada para armazenar informações sobre propriedade.** Hoje isso refere-se sobretudo à propriedade de LAND, mas também pode ser usado para a propriedade de itens do jogo, wearables, avatars 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, a posição do jogador ou qualquer coisa que precise de mudar em tempo real. ### LAND e MANA **Os jogadores não precisam de possuir quaisquer parcels de LAND para participar no metaverse.** Na verdade, a grande maioria dos jogadores não o fará. Os avatars dos jogadores e os tokens LAND que possuem não estão ligados de forma direta. **Os jogadores não precisam de possuir previamente uma wallet Ethereum ou tokens MANA para entrar no Decentraland.** Se a sua jogabilidade depender muito da posse de tokens, estará a excluir a maioria dos jogadores. Um modelo de jogo freemium pode ser uma forma ideal de se adequar a ambas as bases de utilizadores. ### Outros NFTs **Pode usar tokens não fungíveis (NFTs) especiais para representar itens de jogo, avatars personalizados ou wearables.** Se um jogador possuir um destes tokens, a sua scene poderá responder de diferentes formas. Leia sobre o que são NFTs em [este blogpost](https://decentraland.org/blog/technology/what-are-nfts/). ### Transações dentro do jogo **A sua scene pode suportar transações na blockchain para os jogadores comprarem ou ganharem tokens.** As transações na blockchain não são imediatas, requerem tempos de verificação e têm um custo em Ether; tanto o tempo como o custo variam consoante a utilização atual da network. Decentraland usa a side-chain Polygon para lidar com transações de forma mais rápida e barata do que a network Ethereum. Esta side-chain é ideal para transações dentro do jogo, uma vez que as alterações podem ocorrer mais perto do tempo real e a um custo muito baixo. A main chain Ethereum continua a ser recomendada para transações que exijam maior segurança e que possam ser mais caras e demoradas. Veja [Segunda camada](/creator/content-creator-pt/scenes-sdk7/blockchain/second-layer.md). O jogador deve sempre aprovar explicitamente estas transações no seu client Ethereum. Por exemplo, ao usar Metamask, o Metamask pede ao jogador para aceitar cada transação antes de ser processada. Os jogadores também poderiam assinar um contrato que aprova automaticamente todas as transações solicitadas por um endereço específico ou dentro de certas restrições, de modo a evitar interrupções para aprovar transações. Também pode usar smart contracts para condicionar transações com base em condições personalizadas. Por exemplo, os jogadores poderiam fazer uma aposta 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, deve usar bibliotecas externas que façam interface com a network Ethereum. Futuras versões do SDK fornecerão uma API personalizada para expor estas funcionalidades de uma forma mais simples. --- # 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/design-games.md?ask=&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.