Servidores Autoritativos

Usando um servidor para sincronizar mudanças na cena para todos os jogadores

Decentraland executa cenas localmente no navegador do jogador. Por padrão, os jogadores conseguem se ver e interagir diretamente, mas cada um interage com o ambiente de forma independente. Alterações no ambiente não são compartilhadas entre os jogadores por padrão. Você precisa implementar isso manualmente.

Permitir que todos os jogadores vejam uma cena com o mesmo conteúdo no mesmo estado é extremamente importante para que os jogadores possam interagir de maneira mais significativa. Sem isso, se um jogador abre uma porta e entra em uma casa, outros jogadores verão essa porta como ainda fechada, e o primeiro jogador parecerá atravessar diretamente a porta fechada para os outros jogadores.

• Marcar uma entidade como sincronizada: A opção mais fácil. Veja Entidade marcada como sincronizada

• Enviar mensagens explícitas via MessageBus: Envie e escute manualmente mensagens específicas. Veja Enviar mensagens explícitas pelo MessageBus

• Usar um servidor: Este documento trata dessa opção. Essa opção requer mais trabalho para configurar, mas é recomendável se houver incentivos para explorar sua cena.

Tipos de servidores

Um servidor pode ter diferentes níveis de envolvimento com a cena:

• API + DB: Isso é útil para cenas onde as alterações não acontecem constantemente e onde é aceitável ter pequenos atrasos na sincronização. Quando um jogador altera algo, ele envia uma solicitação HTTP para uma API REST que armazena o novo estado da cena em um banco de dados. As alterações permanecem armazenadas para qualquer novo jogador que visite a cena em uma data posterior. A principal limitação é que novas alterações de outros jogadores não são notificadas aos jogadores que já estão lá; mensagens não podem ser empurradas do servidor para os jogadores. Os jogadores precisam enviar solicitações regularmente ao servidor para obter o estado mais recente.

💡 Tip: Também é possível optar por uma abordagem híbrida onde as alterações são notificadas entre jogadores via mensagens do MessageBus, mas o estado final também é armazenado via API para visitantes futuros.

• Websockets: Esta alternativa é mais robusta, pois estabelece um canal de comunicação bidirecional entre jogador e servidor. Atualizações podem ser enviadas a partir do servidor; você pode até ter lógica de jogo rodando ou sendo validada no servidor. Isso permite interação em tempo real e torna possíveis jogos de ritmo mais rápido. Também é mais seguro, pois cada mensagem entre jogador e servidor faz parte de uma sessão que é aberta, não havendo necessidade de validar cada mensagem individualmente.

Cenas de exemplo com servidor dedicado

API + DB:

• Leaderboard

• Guestbook

• Validar autenticidade

Pré-visualizar cenas com servidores dedicados

Para pré-visualizar uma cena que usa um servidor de terceiros, você deve executar tanto a cena quanto o servidor do qual ela depende. O servidor pode ser executado localmente na mesma máquina da pré-visualização, como uma forma mais simples de testá-lo. Ao executar localmente, o servidor pode usar conexões inseguras http ou ws para facilitar a configuração.

Para iniciar o servidor, vá para a pasta /server e execute npm run start.

Uma vez que o servidor esteja em execução, seja remotamente ou localmente, você pode executar sua cena normalmente.

Testar uma cena multiplayer localmente

Se você iniciar uma pré-visualização da cena e abri-la em duas (ou mais) janelas diferentes do Explorer, cada janela aberta será interpretada como um jogador separado, e um servidor de comunicações simulado manterá esses jogadores sincronizados.

Interaja com a cena em uma janela, depois mude para a outra para ver que os efeitos dessa interação também são visíveis lá.

Usando o Creator Hub, clique no botão Preview uma segunda vez, e isso abrirá uma segunda janela do Explorer do Decentraland. Você deve conectar-se em ambas as janelas com endereços diferentes. As mesmas sessões permanecerão abertas enquanto a cena recarrega.

Como alternativa, você pode abrir uma segunda janela do Decentraland Explorer escrevendo o seguinte em uma URL do navegador:

decentraland://realm=http://127.0.0.1:8000&local-scene=true&debug=true

Reinos separados

Jogadores em Decentraland existem em muitos realms. Jogadores em reinos diferentes não podem se ver, interagir ou conversar entre si, mesmo que estejam nas mesmas parcelas. Dividir os jogadores dessa forma permite que Decentraland lide com uma quantidade ilimitada de jogadores sem enfrentar limitações. Também agrupa jogadores que estão em regiões próximas, para garantir que os tempos de ping entre jogadores que interagem sejam aceitáveis.

Se sua cena envia dados para um servidor de terceiros para sincronizar mudanças entre jogadores em tempo real, então é importante que as alterações sejam sincronizadas apenas entre jogadores que estejam no mesmo reino. Você deve tratar todas as alterações que pertencem a um reino como separadas daquelas de outro reino. Caso contrário, os jogadores verão coisas mudarem de forma estranha, sem que ninguém tenha feito a alteração.

Veja como obter o realm para cada jogador em get player data

Persistência multiplayer

Ao contrário das cenas locais que são montadas novamente cada vez que um jogador entra nelas, cenas que usam servidores de terceiros têm uma duração que se estende muito além do momento em que o jogador entra e sai da cena.

Você deve, portanto, projetar a experiência levando em conta que o jogador nem sempre encontrará a cena no mesmo estado inicial. Quaisquer alterações feitas na cena permanecerão para outros jogadores encontrarem; você deve garantir que essas alterações não interfiram negativamente nas experiências dos jogadores futuros.

Redefinir o estado

Ao carregar a cena, certifique-se de que ela seja construída com base nas informações compartilhadas armazenadas no servidor, e não em um estado padrão.

Em alguns casos, faz sentido incluir algum tipo de botão de redefinição na cena. Pressionar o botão de redefinir faria com que a cena voltasse ao estado inicial de forma graciosa.

Às vezes, isso implica apenas definir as variáveis no estado da cena de volta aos valores padrão. Mas redefinir a cena também pode envolver cancelar a inscrição de listeners e parar loops no lado do servidor. Se loops vazios permanecerem cada vez que a cena for redefinida, eles continuarão se acumulando e terão um efeito negativo no desempenho da cena.