> 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/disenar-la-experiencia/design-games.md). # Diseñar juegos Qué debes tener en cuenta al diseñar un juego para Decentraland. Este documento cubre algunos puntos clave que debes considerar al diseñar un juego para Decentraland. Aspectos como la adyacencia de otras escenas y la propiedad distribuida del LAND hacen de Decentraland un lugar único que requiere que reconsideres supuestos que quizá tengas de juegos anteriores. Por ejemplo, debes entender que, a diferencia de otras plataformas de juegos, los juegos de Decentraland no existen en un vacío. No tienes control sobre lo que hay en las escenas adyacentes, ni sobre ciertos detalles como los avatares del jugador o los objetos que podrían traer de otros juegos. Esto abre la puerta a posibilidades emocionantes y requiere que pienses de otra manera en las mecánicas del juego. Lo más parecido en los juegos convencionales hoy en día es Roblox, donde el contenido generado por los usuarios de la comunidad puede convertirse en un punto de encuentro para que otros exploren, jueguen e interactúen. A diferencia de Roblox, navegas por las escenas no buscando en un menú de experiencias no relacionadas, sino explorando físicamente un terreno en el que todas las escenas son adyacentes entre sí. Decentraland también hace uso de la blockchain como una forma de gestionar la propiedad de LAND, avatares, activos, etc. Estamos mejorando continuamente el SDK, así que algunas de las siguientes limitaciones podrían eliminarse con futuras actualizaciones. ## Límites de la escena **Tu juego debe caber por completo en el \_LAND**\_\*\* sobre el que está construida tu escena.\*\* Para escenas pequeñas, piensa en juegos como el fútbol, donde las reglas del juego mantienen la interacción relevante dentro de un espacio reducido, aunque los jugadores puedan salir del campo de juego. Los jugadores pueden caminar fuera de los límites de una escena, pero cualquier asset o entities que pertenezcan a la escena deben permanecer dentro de la escena. Los jugadores que salen de tu escena siguen renderizándola mientras esté dentro de un rango visible. Si se alejan demasiado, dejarán de renderizarla por completo. También podrías crear un juego que se extienda por varios terrenos desconectados que son desconocidos para los jugadores, y donde la exploración del resto del mundo forme parte de la jugabilidad. Un juego así estaría compuesto por múltiples *escenas*, que podrían compartir datos entre sí a través de un servidor. Si tu juego se publica en un [Decentraland World](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md), tienes más control sobre lo que ven los jugadores más allá de los límites de tu escena. Los Worlds normalmente están rodeados por un paisaje autogenerado de pradera, árboles y mar, pero puedes [desactivar este paisaje](/creator/content-creator-es/scenes-sdk7/tipos-de-proyectos/scene-metadata.md#landscape-terrain) si choca con la ambientación de tu juego, por ejemplo, un juego que transcurre en aguas abiertas o en el espacio. ### Inventario del usuario **Actualmente no existe un inventario en el que los jugadores puedan almacenar objetos del juego mientras caminan entre escenas.** Hoy están disponibles las siguientes alternativas: * Puedes almacenar la información del inventario en la propia escena y vincularla a la dirección de Ethereum de cada jugador (esto puede usarse como un id persistente). Esta información solo sería legible desde tu escena. * Puedes usar un almacenamiento externo personalizado y sincronizar todas tus escenas con él. Esta es una solución más robusta que puede manejar volúmenes mayores de jugadores. También puede ampliar el acceso a este inventario a múltiples escenas separadas que sean tuyas o de otros. * Usa tokens en la blockchain para gestionar la propiedad de los objetos. Cuando se obtiene un objeto del juego, podría almacenarse como un token especial en la wallet de Ethereum de un jugador. Cuando un jugador que posee el token entra en tu escena, tu escena podría concederle al jugador ciertas características dentro del juego. Otras escenas también podrían responder al mismo token de diferentes maneras, lo que puede dar lugar a interacciones interesantes entre juegos. La desventaja de usar la blockchain para almacenar objetos del inventario es que todas las transacciones tienen un coste para el jugador y no son inmediatas. Lee más sobre la blockchain en una sección especializada más abajo. En futuras versiones, los jugadores tendrán un inventario que llevarán consigo a todas partes, el cual incluirá tanto activos on-chain como off-chain. ### Portable experiences {% hint style="info" %} **💡 Consejo**: Consulta [Portable experiences](/creator/content-creator-es/scenes-sdk7/tipos-de-proyectos/portable-experiences.md) y [Smart wearables](/creator/content-creator-es/scenes-sdk7/tipos-de-proyectos/smart-wearables.md) para saber cómo crearlos. {% endhint %} Las Portable experiences son partes de la jugabilidad que los jugadores llevan consigo mientras se mueven por el metaverso. No están vinculadas a parcelas de tierra, a veces están vinculadas a tokens, o a veces se lanzan desde el Explorer. Por ejemplo, un jugador podría tomar una bola de nieve de tu escena, irse a otra escena y lanzar la bola de nieve a otro jugador que también esté jugando el mismo juego. Los Smart wearables son un tipo de Portable experience que está vinculada a un wearable token y se activa cuando el jugador se pone la prenda. Los Smart wearables pueden otorgar a los jugadores nuevas habilidades, como un jetpack que les permite volar, o añadir una nueva capa de contenido encima del resto del mundo, como colocar monedas aleatoriamente para recogerlas por toda Genesis City. Ten en cuenta que los jugadores podrían estar usando una portable experience ajena mientras están en tu escena. Consulta [Datos del usuario](/creator/content-creator-es/scenes-sdk7/interactividad/user-data.md#get-portable-experiences) para aprender a comprobar qué portable experiences tiene activadas actualmente un jugador. ## Persistencia del juego **Decentraland es un mundo persistente, tu escena puede ser visitada por jugadores en cualquier momento.** Tu escena no tiene fase de inicio ni final, así que deberías diseñar las mecánicas del juego de una manera que también permita participar a los jugadores que entren o salgan en cualquier momento. Tu escena podría tener un mecanismo de reinicio que la restablezca a un estado inicial, pero debes tener cuidado de no interrumpir el juego de los jugadores que ya estén jugando. ### Sincronizar el estado de la escena **De forma predeterminada, los estados de la escena no se comparten entre jugadores.** Cada jugador ejecuta su propia copia local de la escena. Esta es la forma más sencilla de construir una escena, pero no es ideal para experiencias sociales. La forma más sencilla de compartir el estado entre jugadores es marcar las entities como sincronizadas, usando `syncEntity` función. Consulta [multiplayer serverless](/creator/content-creator-es/scenes-sdk7/networking/serverless-multiplayer.md). Con este enfoque, los cambios de estado no se almacenan en ningún sitio: si no hay jugadores cerca de la escena en ese momento y la están cargando, la escena se restablecerá a un estado predeterminado la próxima vez que se cargue. **También puedes usar un servidor para almacenar información sobre tu escena y mantener sincronizados con él a todos los jugadores.** Esto mantiene el estado de la escena consistente y persistente incluso cuando no hay jugadores cerca, y te permite validar los cambios para que los jugadores no puedan hacer trampas. La opción recomendada es usar un [Multiplayer Server](/creator/content-creator-es/scenes-sdk7/networking/authoritative-servers.md), que Decentraland aloja y despliega por ti como parte de la publicación de tu escena. También puedes alojar [tu propio servidor](/creator/content-creator-es/scenes-sdk7/networking/third-party-servers.md), lo que te permite mantener cierta información, como tokens de seguridad, solo en el servidor, sin exponer nunca esa información fuera de él. ### Tiempo de juego **Los juegos que usan la arquitectura de comunicaciones predeterminada deben tener en cuenta que podría haber lag entre jugadores** y no deberían depender de reacciones rápidas entre las acciones de distintos jugadores. Recomendamos juegos por turnos, o que se basen mayoritariamente en interacciones de jugador contra entorno. Para juegos en los que el timing de las acciones entre jugadores sea crítico, como un first person shooter, deberías implementar tu propio servidor como una fuente autoritativa de verdad en tiempo real entre todos los jugadores de tu escena. ## Jugadores en la escena **Los jugadores se identifican en Decentraland usando la dirección de su wallet de Ethereum.** Esta wallet se usa como un ID persistente que ya está asociado con todos los tokens que posee el jugador. **Actualmente no hay forma de limitar cuántos jugadores pueden estar presentes en Decentraland al mismo tiempo.** A diferencia de muchos otros juegos en los que puede haber distintas sesiones de juego alojadas en servidores separados, solo hay una instancia de Decentraland compartida entre todos los jugadores, al menos por ahora. Debes tener en cuenta que puede haber varios jugadores caminando por tu escena en cualquier momento. Algunos podrían estar solo de paso y no participar en el juego. Asegúrate de que las mecánicas del juego no puedan verse fácilmente interrumpidas por esto. **El ciclo de juego de tu escena no puede afectar directamente a los jugadores**, la escena tiene un enfoque reactivo frente a las acciones del jugador. Si un jugador está de pie sobre una entidad y la entidad se mueve o gira, el jugador se moverá con esta entidad. Esto resulta especialmente útil para ascensores, plataformas flotantes y similares. Como propietario de una escena, no puedes empujar ni teletransportar por la fuerza a un jugador problemático fuera de tu escena. Sin embargo, podrás poner a los jugadores en lista negra en el servidor de señalización. También puedes implementar una lista negra en el código de tu escena y denegar ciertos servicios a los jugadores incluidos en ella. ## Limitaciones del contenido de la escena **Por favor, construye tu escena teniendo un cuidado extra con la eficiencia de tu código.** Decentraland necesita ejecutarse en navegadores web y dispositivos móviles, y los jugadores estarán renderizando varias escenas al mismo tiempo mientras recorren el metaverso. **También deberías intentar mantener la escena ligera.** A diferencia de otros juegos en línea en los que las mismas texturas y activos se repiten cómodamente a lo largo de un gran mundo abierto, en Decentraland cada escena podría tener su propio conjunto de activos completamente distinto. A medida que los jugadores recorran varias escenas, deberían poder descargar la totalidad del contenido de la escena, incluidas texturas, archivos de sonido, etc., a una velocidad razonable. Debido a esto, hemos impuesto algunos límites para evitar un uso excesivo de recursos computacionales. Consulta [limitaciones de la escena](/creator/content-creator-es/scenes-sdk7/optimizacion/scene-limitations.md) para obtener detalles sobre cuáles son estos límites. ## Acceso a las escenas **El mapa de Decentraland está diseñado para que haya caminos y plazas públicas,** estos garantizan un acceso fácil a varias partes del mapa, independientemente de lo que construyan otras personas. Las parcelas de tierra que no colindan con ningún camino o plaza corren el riesgo de quedar aisladas por escenas vecinas, aunque esperamos que la mayoría de las escenas sean transitables y no bloqueen a otras. Los nuevos jugadores comenzarán su experiencia en Genesis Plaza, en el centro del mapa, donde se les animará a seguir algunas actividades de tutorial y luego a explorar el mundo. Los jugadores también pueden escribir manualmente una URL para una coordenada específica en el mapa de Decentraland para aparecer en esa ubicación. También puedes compartir enlaces a URLs que tengan coordenadas iniciales codificadas. Ten en cuenta que, si un jugador comienza en una ubicación que está aislada o por debajo del nivel del terreno, no será una experiencia agradable. Para evitarlo, hay una forma de definir un conjunto de ubicaciones específicas en tu escena en las que sea seguro aparecer. Consulta [metadatos de la escena](/creator/content-creator-es/scenes-sdk7/tipos-de-proyectos/scene-metadata.md) para más detalles. Los jugadores también pueden navegar rápidamente por el mundo usando el mapa y las listas de ubicaciones y eventos populares. Tu escena puede incluir teletransportes que transporten a los jugadores a otras partes del mundo, consulta [Teleports](/creator/content-creator-es/scenes-sdk7/interactividad/external-links.md#teleports). ## UI del usuario **La UI superpuesta predeterminada que ven los jugadores al entrar en Decentraland solo incluye lo esencial.** Puedes añadir elementos extra a esa UI mientras el jugador esté en tu escena. Ten en cuenta que la UI predeterminada de Decentraland se muestra por encima de cualquier cosa de tu escena, así que diseña tu UI de modo que no se superponga con ella. Cuando un jugador sale de la escena, se eliminan todos los elementos de UI para no interferir con otras escenas. Los jugadores también tienen disponible en su pantalla un botón para desactivar todos los elementos de UI de la escena; esto es útil principalmente para evitar comportamientos abusivos de escenas que podrían querer cubrir todo el campo de visión del jugador. ## Physics Ten en cuenta que el SDK no proporciona un motor de físicas completo para las entities. Puedes aplicar fuerzas e impulsos al avatar del jugador, consulta [Física del jugador](/creator/content-creator-es/scenes-sdk7/interactividad/player-physics.md). Para las físicas entre entities, como colisiones o gravedad, puedes importar una librería o programar el comportamiento tú mismo. ## Entradas del controlador **Los controles de tu juego deberían limitarse al conjunto de acciones de entrada admitidas por el SDK**: las teclas de movimiento, saltar, apuntar y hacer clic, los botones primario (E) y secundario (F), y los botones de acción numerados (1 a 4). Estas entradas se abstraen de las teclas físicas, de modo que también pueden asignarse a los controles en pantalla de la app móvil o a otros dispositivos; no asumas que todo el mundo tiene un teclado. Consulta [Botones del puntero](/creator/content-creator-es/scenes-sdk7/interactividad/eventos-de-button/click-events.md#pointer-buttons) para ver la lista completa, y [Entrada en móvil](/creator/content-creator-es/desarrollar-para-movil/desarrollar/input-on-mobile.md) para saber qué conviene preferir cuando te diriges a jugadores móviles. Todas estas entradas admiten tanto eventos globales de *button up* y *button down* eventos, y eventos de hit que te permiten identificar si una entidad estaba en la mira del jugador. ## Avatares **Los jugadores pueden construir sus avatares a partir de un amplio catálogo de wearables**, incluidos wearables creados y vendidos por creadores de la comunidad en el Decentraland Marketplace. Tu escena puede leer lo que lleva puesto un jugador y reaccionar en consecuencia, consulta [Datos del usuario](/creator/content-creator-es/scenes-sdk7/interactividad/user-data.md#get-player-data). ## Comunicación entre jugadores **Los jugadores pueden chatear entre sí, hablar por chat de voz y transmitir lenguaje corporal al hacer emotes** como bailar, aplaudir o saludar, incluidos emotes vendidos por creadores de la comunidad. Tu escena puede detectar cuando un jugador ejecuta un emote, y también puede hacer que el avatar de un jugador reproduzca una animación. Consulta [El jugador reproduce una animación](/creator/content-creator-es/scenes-sdk7/interactividad/event-listeners.md#player-plays-animation) y [Animaciones de avatar](/creator/content-creator-es/scenes-sdk7/interactividad/avatares/avatar-animations.md). ## Notificaciones del juego **Actualmente no existe un sistema de notificaciones entre escenas.** Cualquier juego que requiera notificaciones mostradas fuera de la escena actual tendrá que implementarlas usando un servicio externo. ## Uso de la blockchain **En Decentraland, la blockchain se usa para almacenar información sobre la propiedad.** Hoy esto se refiere principalmente a la propiedad de LAND, pero también puede usarse para la propiedad de objetos del juego, wearables, avatares especiales, emotes y tokens que pueden garantizar ciertos privilegios dentro del juego o acceso a juegos. La blockchain no se usa para almacenar el estado del juego, la posición del jugador ni nada que deba cambiar en tiempo real. ### LAND y MANA **Los jugadores no necesitan poseer ninguna parcela de LAND para participar en el metaverso.** De hecho, la inmensa mayoría de los jugadores no lo hará. Los avatares de los jugadores y los tokens LAND que poseen no están conectados de ninguna manera directa. **Los jugadores no necesitan poseer previamente una wallet de Ethereum ni tokens MANA para entrar en Decentraland.** Si tu jugabilidad depende en gran medida de poseer tokens, estarías excluyendo a la mayoría de los jugadores. Un modelo de juego freemium podría ser una forma ideal de adaptarse a ambas bases de usuarios. ### Otros NFTs **Puedes usar NFTs especiales para representar objetos del juego, avatares personalizados o wearables.** Si un jugador posee uno de estos tokens, tu escena podría responder de distintas maneras. Lee sobre qué son los NFTs en [esta entrada del blog](https://decentraland.org/blog/technology/what-are-nfts/). ### Transacciones dentro del juego **Tu escena puede admitir transacciones de blockchain para que los jugadores compren o ganen tokens.** Las transacciones de blockchain no son inmediatas; requieren tiempos de verificación y tienen un coste en Ether. Tanto el tiempo como el coste varían según el uso actual de la red. Decentraland usa la side-chain de Polygon para gestionar las transacciones de forma más rápida y más barata que la red Ethereum. Esta side-chain es ideal para transacciones dentro del juego, ya que los cambios pueden producirse más cerca del tiempo real y a un coste muy bajo. La cadena principal de Ethereum sigue siendo la recomendada para transacciones que requieren mayor seguridad y que pueden permitirse ser más caras y tardar más. Consulta [Segunda capa](/creator/content-creator-es/scenes-sdk7/blockchain/second-layer.md). El jugador siempre debe aprobar explícitamente estas transacciones en su cliente de Ethereum. Por ejemplo, al usar Metamask, Metamask le pide al jugador que acepte cada transacción antes de procesarla. Los jugadores también podrían firmar un contrato que apruebe automáticamente todas las transacciones solicitadas por una dirección específica o dentro de ciertos límites, para evitar interrupciones al aprobar transacciones. También puedes usar smart contracts para condicionar las transacciones según condiciones personalizadas. Por ejemplo, los jugadores podrían apostar por el resultado de un juego, y los pagos correspondientes se producirían automáticamente en cuanto se conociera el resultado. Para implementar interacciones de blockchain en el código de tu escena, debes usar librerías externas que se integren con la red Ethereum. Las futuras versiones del SDK proporcionarán una API personalizada para exponer estas funcionalidades de una forma más sencilla. --- # 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/disenar-la-experiencia/design-games.md?ask=&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.