Servidores autoritativos
Usar un server para sincronizar cambios en la escena para todos los jugadores
Decentraland ejecuta las escenas localmente en el navegador del 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 escena 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.
Marcar una entidad como sincronizada: La opción más fácil. Ver Entidad marcada como sincronizada
Enviar mensajes explícitos por MessageBus: Enviar y escuchar manualmente mensajes específicos. Ver Enviar mensajes explícitos por MessageBus
Usar un servidor: Este documento trata sobre esta opción. Esta opción requiere más trabajo para configurarla, pero es recomendable si hay incentivos para explotar tu escena.
Tipos de servidores
Un servidor puede tener diferentes niveles de implicación con la escena:
API + DB: Esto es útil para escenas 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 solicitud HTTP a una API REST que almacena el nuevo estado de la escena en una base de datos. Los cambios permanecen almacenados para cualquier nuevo jugador que visite la escena en una fecha posterior. La limitación principal es que los nuevos cambios de otros jugadores no se notifican a los jugadores que ya están allí; no se pueden enviar mensajes desde el servidor a los jugadores. Los jugadores deben enviar solicitudes regularmente al servidor para obtener el estado más reciente.
💡 Tip: También es posible optar por un enfoque híbrido donde los cambios se notifican entre jugadores mediante 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 enviarse desde el servidor; incluso podrías tener lógica de juego ejecutándose o validándose en el servidor. Esto permite interacción en tiempo real y hace posibles juegos de ritmo más rápido. También es más seguro, ya que cada mensaje entre jugador y servidor forma parte de una sesión que se abre, sin necesidad de validar cada mensaje.
Escenas de ejemplo con servidor dedicado
API + DB:
Previsualizar escenas con servidores dedicados
Para previsualizar una escena que usa un servidor de terceros, debes ejecutar tanto la escena 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 o ws para una configuración más fácil.
Para iniciar el servidor, ve a la /server carpeta y ejecuta npm run start.
Una vez que el servidor esté en funcionamiento, ya sea de forma remota o local, puedes ejecutar tu escena como lo haces normalmente.
Probar una escena multijugador localmente
Si inicias una vista previa de la escena y la abres en dos (o más) ventanas diferentes del Explorer, cada ventana abierta se interpretará 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 sean visibles allí.
Usando el Creator Hub, haz clic en el botón Preview una segunda vez, y eso abrirá una segunda ventana del Explorer de Decentraland. Debes conectarte en ambas ventanas con direcciones distintas. Las mismas sesiones permanecerán abiertas mientras la escena se recarga.
Como alternativa, puedes abrir una segunda ventana del Explorer de Decentraland escribiendo lo siguiente en la URL 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 reinos no pueden verse entre sí, ni interactuar o chatear entre ellos, incluso si están parados en los mismos parcels. Dividir a los jugadores así permite a Decentraland manejar una cantidad ilimitada de jugadores sin encontrarse con limitaciones. También empareja a jugadores que están en regiones cercanas, para asegurar que los tiempos de ping entre jugadores que interactúan sean aceptables.
Si tu escena 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 tratar todos los cambios que pertenecen a un realm como separados de los de otro realm. De lo contrario, los jugadores verán cambios de manera extraña, sin que nadie los haya realizado.
Consulta cómo obtener el realm para cada jugador en obtener datos del jugador
Persistencia multijugador
A diferencia de las escenas locales que se montan de nuevo cada vez que un jugador entra en ellas, las escenas 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 escena.
Por lo tanto, debes diseñar la experiencia teniendo en cuenta que el jugador no siempre encontrará la escena en el mismo estado inicial. Cualquier cambio realizado en la escena 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 escena, asegúrate de que se construya en base a la información compartida almacenada en el servidor, y no en un estado predeterminado.
En algunos casos, tiene sentido incluir algún tipo de botón de reinicio en la escena. Pulsar el botón de reinicio restablecería la escena de forma ordenada.
A veces, esto implica simplemente establecer las variables del estado de la escena a sus valores predeterminados. Pero restablecer la escena también podría implicar darse de baja de listeners y detener bucles en el lado del servidor. Si quedan bucles vacíos cada vez que se restablece la escena, estos se acumularán y tendrán un efecto negativo en el rendimiento de la escena.
Última actualización