Servers de terceiros
Crie cenas multiplayer do Decentraland com um server de terceiros.
A abordagem recomendada para interações multiplayer na sua scene é usar o authoritative-server. Este documento abrange outras opções que também são suportadas.
REST API + DB: Bom para dados que mudam com pouca frequência (leaderboards, guestbooks). Os players fazem polling da API para atualizações; o state persiste entre sessões. Veja Network Connections para saber como fazer
fetchrequests a partir de uma scene.WebSocket server: Permite comunicação bidirecional em tempo real. Veja Network Connections para uso de WebSocket. Libraries como Colyseus funcionam bem com o Decentraland SDK.
📔 Observação: Servers de terceiros não se integram com syncEntity, validateBeforeChange, ou Storage — você terá de implementar o seu próprio state management e lógica de sync.
Também é possível optar por uma abordagem híbrida, em que as mudanças são notificadas entre players via serverless-multiplayer, mas o state final também é armazenado via uma REST API para visitantes futuros.
Aqui estão alguns exemplos de scenes que usam um server de terceiros:
Testing Locally
Para fazer preview de uma scene que usa um server de terceiros, você deve executar tanto a scene quanto o server de que ela depende. O server pode ser executado localmente na mesma máquina que o preview, como uma forma mais fácil de testá-lo. Ao executar localmente, o server pode usar conexões inseguras http ou ws , para facilitar a configuração.
Para iniciar o server, vá até a pasta /server e execute npm run start.
Abra o preview em duas janelas separadas; cada janela é tratada como um player separado. Conecte cada janela com um endereço diferente. Ambos os clients se conectarão à mesma instância local do server.
Usando o Creator Hub, clique no botão Preview uma segunda vez, e isso abrirá uma segunda janela do explorer do Decentraland. Você deve se conectar em ambas as janelas com endereços diferentes. As mesmas sessões permanecerão abertas enquanto a scene 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&multi-instance=true
Separate realms
Os players no Decentraland existem em muitos realmsseparados. Players em realms diferentes não podem ver uns aos outros, interagir nem conversar entre si, mesmo que estejam em cima dos mesmos parcels. Dividir os players dessa forma permite que o Decentraland lide com uma quantidade ilimitada de players sem encontrar limitações. Isso também emparelha players que estão em regiões próximas, para garantir que os tempos de ping entre players que interagem sejam aceitáveis.
Se a sua scene envia dados para um server de terceiros para sincronizar mudanças entre players em tempo real, então é importante que as mudanças sejam sincronizadas apenas entre players que estejam no mesmo realm. Você deve tratar todas as mudanças que pertencem a um realm como separadas daquelas de um realm diferente. Caso contrário, os players verão as coisas mudarem de forma assustadora, sem que ninguém tenha feito a mudança.
Veja como obter o realm de cada player em get player data
Multiplayer persistance
Ao contrário de scenes locais que são montadas novamente sempre que um player entra nelas, scenes que usam servers de terceiros têm uma vida útil que se estende muito além do momento em que o player entra e sai da scene.
Portanto, você deve projetar a experiência levando em conta que o player nem sempre encontrará a scene no mesmo state inicial. Quaisquer mudanças feitas na scene permanecerão para que outros players as encontrem; você deve garantir que isso não interfira nas experiências de future players de forma indesejada.
Reset the state
Ao carregar a scene, certifique-se de que ela seja construída com base nas informações compartilhadas armazenadas no server, e não em um state padrão.
Em alguns casos, faz sentido incluir algum tipo de botão de reset na scene. Pressionar o botão de reset reiniciaria a scene de forma adequada.
Às vezes, isso apenas implica definir as variables no scene state de volta aos valores padrão. Mas reiniciar a scene também pode envolver cancelar a subscrição de listeners e parar loops no lado do server. Se loops vazios permanecerem cada vez que a scene for reiniciada, eles continuarão se acumulando e terão um efeito negativo no desempenho da scene.
Atualizado