> 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-es/scenes-sdk7/networking/third-party-servers.md).

# Servidores de terceros

Crea escenas multijugador de Decentraland con un servidor de terceros.

El enfoque recomendado para las interacciones multijugador en tu escena es usar [Multiplayer Server](/creator/content-creator-es/scenes-sdk7/networking/authoritative-servers.md). Este documento cubre otras opciones que también son compatibles.

* **REST API + DB**: Es bueno para datos que cambian con poca frecuencia (tablas de clasificación, libros de visitas). Los jugadores consultan la API para obtener actualizaciones; el estado persiste entre sesiones. Consulta [Network Connections](/creator/content-creator-es/scenes-sdk7/networking/network-connections.md) para ver cómo hacer `fetch` peticiones desde una escena.
* **servidor WebSocket**: Permite comunicación bidireccional en tiempo real. Consulta [Network Connections](/creator/content-creator-es/scenes-sdk7/networking/network-connections.md) para ver el uso de WebSocket. Bibliotecas como [Colyseus](https://colyseus.io/) funcionan bien con el SDK de Decentraland.

{% hint style="warning" %}
**📔 Nota**: Los servidores de terceros no se integran con `syncEntity`, `validateBeforeChange`, o `Storage` — tendrás que implementar tu propia gestión de estado y lógica de sincronización.
{% endhint %}

También es posible optar por un enfoque híbrido en el que los cambios se notifican entre jugadores mediante [serverless-multiplayer](/creator/content-creator-es/scenes-sdk7/networking/serverless-multiplayer.md), pero el estado final también se almacena mediante una API REST para los futuros visitantes.

Aquí tienes algunos ejemplos de escenas que usan un servidor de terceros:

* [Tabla de clasificación](https://github.com/decentraland/sdk7-goerli-plaza/tree/main/leader-board)
* [Libro de visitas](https://github.com/decentraland/sdk7-goerli-plaza/tree/main/guest-book-api)
* [Validar autenticidad](https://github.com/decentraland/sdk7-goerli-plaza/tree/main/validate-player-authenticity)

## Pruebas locales

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 vista previa, como una forma más sencilla de probarlo. Cuando se ejecuta localmente, el servidor puede usar conexiones http `http` o `ws` no seguras, para facilitar la configuración.

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

Abre la vista previa en dos ventanas separadas; cada ventana se trata como un jugador distinto. Conecta cada ventana con una dirección diferente. Ambos clientes se conectarán a la misma instancia local del servidor.

Usando Creator Hub, activa **Vista previa con múltiples instancias** en el **Desktop Client** el submenú de **Opciones de reproducción**, luego haz clic en el **Play** botón una segunda vez para abrir 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 de Decentraland escribiendo lo siguiente en la URL de un navegador:

> `decentraland://realm=http://127.0.0.1:8000&local-scene=true&debug=true&multi-instance=true`

## Reinos separados

Los jugadores en Decentraland existen en muchos *realms*. Los jugadores en diferentes realms no pueden verse, interactuar ni chatear entre sí, incluso si están de pie sobre los mismos parcels. Dividir a los jugadores de esta manera permite que Decentraland gestione una cantidad ilimitada de jugadores sin encontrarse con limitaciones. También empareja a los jugadores que están en regiones cercanas, para garantizar que los tiempos de ping entre los 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 distinto. De lo contrario, los jugadores verán cómo las cosas cambian de forma extraña, sin que nadie haya hecho el cambio.

Consulta cómo obtener el realm de cada jugador en [obtener datos del jugador](/creator/content-creator-es/scenes-sdk7/interactividad/user-data.md)

## 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 permanecerá para que otros jugadores lo encuentren; debes asegurarte de que esto no interfiera de forma no deseada con las experiencias de los futuros jugadores.

### Restablecer el estado

Al cargar la escena, asegúrate de que esté construida en función de 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 restablecimiento en la escena. Al pulsar el botón de restablecimiento, la escena se restablecería correctamente.

A veces, esto simplemente implica volver a establecer las variables del estado de la escena en sus valores predeterminados. Pero restablecer la escena también podría implicar cancelar la suscripción de listeners y detener loops en el lado del servidor. Si quedan loops vacíos cada vez que se restablece la escena, estos seguirán acumulándose y tendrán un efecto negativo en el rendimiento de la escena.


---

# 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-es/scenes-sdk7/networking/third-party-servers.md?ask=<question>&goal=<user_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.
