Servidores autorizados

Usar un servidor para sincronizar cambios en la escena para todos los jugadores

Decentraland ejecuta las scenes localmente en el navegador de un jugador. Por defecto, los jugadores pueden verse entre sí e interactuar directamente, pero cada uno interactúa con el entorno de forma independiente. Los cambios en el entorno no se comparten entre jugadores por defecto. Debes implementar esto manualmente.

Permitir que todos los jugadores vean una scene con el mismo contenido en el mismo estado es extremadamente importante para que los jugadores interactúen de formas más significativas. Sin esto, si un jugador abre una puerta y entra en una casa, otros jugadores verán esa puerta todavía cerrada, y el primer jugador parecerá atravesar la puerta cerrada para los demás jugadores.

• Marcar una entidad como sincronizada: La opción más sencilla. Ver Entidad marcada como sincronizada

• Enviar mensajes explícitos con MessageBus: Enviar manualmente y escuchar mensajes específicos. Ver Enviar mensajes explícitos de MessageBus

• Usar un servidor: Este documento trata sobre esta opción. Esta opción requiere más trabajo para configurarla, pero es recomendable si existen incentivos para explotar tu scene.

Tipos de servidores

Un servidor puede tener diferentes niveles de implicación con la scene:

• API + DB: Esto es útil para scenes donde los cambios no ocurren constantemente y donde es aceptable tener pequeños retrasos en la sincronización. Cuando un jugador cambia algo, envía una petición HTTP a una REST API que almacena el nuevo estado de la scene en una base de datos. Los cambios quedan almacenados para cualquier jugador nuevo que visite la scene en una fecha posterior. La principal limitación es que los cambios nuevos de otros jugadores no se notifican a los jugadores que ya están allí; no se pueden push los mensajes del servidor a los jugadores. Los jugadores deben enviar regularmente solicitudes al servidor para obtener el estado más reciente.

💡 Consejo: También es posible optar por un enfoque híbrido donde los cambios se notifican entre jugadores vía mensajes de MessageBus, pero el estado final también se almacena vía una API para visitantes futuros.

• Websockets: Esta alternativa es más robusta, ya que establece un canal de comunicación bidireccional entre el jugador y el servidor. Las actualizaciones pueden ser enviadas desde el servidor; incluso podrías ejecutar o validar la lógica del juego en el servidor. Esto permite la interacción en tiempo real y hace posibles juegos con un ritmo más rápido. También es más seguro, ya que cada mensaje entre jugador y servidor es parte de una sesión que se abre, sin necesidad de validar cada mensaje individualmente.

Scenes de ejemplo con servidor dedicado

API + DB:

• Tabla de clasificación

• Libro de visitas

• Validar autenticidad

Previsualizar scenes con servidores dedicados

Para previsualizar una scene que utiliza un servidor de terceros, debes ejecutar tanto la scene como el servidor del que depende. El servidor puede ejecutarse localmente en la misma máquina que la previsualización, como una forma más sencilla de probarlo. Al ejecutarlo localmente, el servidor puede usar conexiones inseguras http u ws para una configuración más fácil.

Para iniciar el servidor, ve a la carpeta /server y ejecuta npm run start.

Una vez que el servidor esté en funcionamiento, ya sea de forma remota o local, puedes ejecutar tu scene como lo haces normalmente.

Probar una escena multijugador localmente

Si lanzas una vista previa de la escena y la abres en dos (o más) ventanas diferentes del Explorer, cada ventana abierta será interpretada como un jugador separado, y un servidor de comunicaciones simulado mantendrá a estos jugadores sincronizados.

Interactúa con la escena en una ventana, luego cambia a la otra para ver que los efectos de esa interacción también son visibles allí.

Usando el Creator Hub, haz clic en el botón Vista previa una segunda vez, y eso abre una segunda ventana del Explorer de Decentraland. Debes conectarte en ambas ventanas con direcciones diferentes. Las mismas sesiones permanecerán abiertas mientras la escena se recarga.

Como alternativa, puedes abrir una segunda ventana del Explorer escribiendo lo siguiente en la barra de direcciones del navegador:

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

Reinos separados

Los jugadores en Decentraland existen en muchos realms. Los jugadores en diferentes realms no pueden verse entre sí, interactuar ni chatear entre ellos, incluso si están parados en los mismos parcels. Dividir a los jugadores de esta manera permite a Decentraland manejar una cantidad ilimitada de jugadores sin encontrarse con limitaciones. También agrupa a jugadores que están en regiones cercanas, para asegurar que los tiempos de ping entre jugadores que interactúan sean aceptables.

Si tu scene envía datos a un servidor de terceros para sincronizar cambios entre jugadores en tiempo real, entonces es importante que los cambios solo se sincronicen entre jugadores que estén en el mismo realm. Debes manejar todos los cambios que pertenecen a un realm como separados de los de otro realm diferente. De lo contrario, los jugadores verán cambios de manera extraña, sin que nadie haga el cambio.

Consulta cómo obtener el realm para cada jugador en get player data

Persistencia multiplayer

A diferencia de las scenes locales que se montan de nuevo cada vez que un jugador entra en ellas, las scenes que usan servidores de terceros tienen una vida útil que se extiende mucho más allá de cuando el jugador entra y sale de la scene.

Por lo tanto, debes diseñar la experiencia teniendo en cuenta que el jugador no siempre encontrará la scene en el mismo estado inicial. Cualquier cambio realizado en la scene persistirá para que otros jugadores lo encuentren; debes asegurarte de que estos no interfieran de forma indeseada con las experiencias de futuros jugadores.

Restablecer el estado

Al cargar la scene, asegúrate de que esté construida basándose en la información compartida almacenada en el servidor, y no en un estado por defecto.

En algunos casos, tiene sentido incluir algún tipo de botón de restablecer en la scene. Pulsar el botón de restablecer devolvería la scene a su estado de forma controlada.

A veces, esto solo implica volver a establecer las variables del estado de la scene a sus valores por defecto. Pero restablecer la scene también podría implicar cancelar la suscripción de listeners y detener bucles en el lado del servidor. Si quedan bucles vacíos cada vez que la scene se restablece, estos se acumularán y tendrán un efecto negativo en el rendimiento de la scene.