# Diseñar juegos Este documento cubre algunos puntos clave a considerar al diseñar un juego para Decentraland. Consideraciones como la adyacencia de otras scenes y la propiedad distribuida del LAND hacen de Decentraland un lugar único que requiere que replantees supuestos que quizá tengas de juegos anteriores. Por ejemplo, debes entender que, a diferencia de otras plataformas de juego, los juegos de Decentraland no existen en el vacío. No tienes control sobre lo que hay en las scenes adyacentes, y no tienes control sobre ciertos detalles como los avatares del jugador o los items que podrían traer de otros juegos. Esto abre la puerta a posibilidades emocionantes y requiere que pienses de forma diferente sobre las mecánicas del juego. Lo más parecido en los juegos convencionales ahora mismo es Roblox, donde el contenido generado por los usuarios en la comunidad puede convertirse luego en un punto de encuentro para que otros exploren, jueguen e interactúen. A diferencia de Roblox, navegas por las scenes no navegando por un menú de experiencias no relacionadas, sino explorando físicamente un terreno donde todas las scenes son adyacentes entre sí. Decentraland también hace uso de la blockchain como una forma de gestionar la propiedad de land, avatares, assets, etc. Estamos mejorando continuamente el SDK, así que algunas de las siguientes limitaciones se eliminarán con futuras actualizaciones antes de que Decentraland se abra a los usuarios finales. ## Límites de la scene **Tu juego debe encajar por completo en el \_LAND**\_\*\* sobre el que está construida tu scene.\*\* Para scenes pequeñas, piensa en juegos como el fútbol, donde las reglas del juego mantienen la interacción relevante dentro de un espacio limitado, aunque los jugadores puedan salir del campo de juego. Los jugadores pueden caminar fuera de los límites de una scene, pero cualquier asset o entities que pertenezcan a la scene deben permanecer dentro de la scene. Los jugadores que salen de tu scene siguen renderizándola mientras esté dentro de un rango visible. Si se alejan demasiado, dejarán de renderizarla por completo. También podrías construir un juego que se extienda por varios terrenos desconectados que sean desconocidos para los jugadores, y donde la exploración del resto del mundo se convierta en parte del gameplay. Un juego así estaría compuesto por múltiples *scenes*separadas, que podrían compartir datos entre sí mediante un server. ### Inventario del usuario **Actualmente no hay un inventario donde los jugadores puedan almacenar items del juego mientras se desplazan entre scenes.** Las siguientes alternativas están disponibles hoy: * Puedes almacenar la información del inventario en la propia scene y vincularla a la dirección Ethereum de cada jugador (esto puede usarse como un id persistente). Esta información solo sería legible desde tu scene. * Puedes usar un almacenamiento externo personalizado y sincronizar todas tus scenes 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 scenes separadas que tú u otros posean. * Usa tokens en la blockchain para gestionar la propiedad de items. Al ganar un item del juego, podría almacenarse como un token especial en el wallet Ethereum de un jugador. Cuando un jugador que posee el token entre en tu scene, tu scene podría otorgarle al jugador ciertas características dentro del juego. Otras scenes también podrían responder al mismo token de diferentes maneras, lo que puede generar interacciones interesantes entre juegos. La desventaja de usar la blockchain para almacenar items de inventario es que todas las transacciones tienen un costo 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 a todas partes, que incluirá assets on-chain y off-chain. ### Experiencias portables {% hint style="warning" %} **📔 Nota**: Las experiencias portables y los smart wearables aún están en una etapa exploratoria y todavía no están disponibles para que los creadores de la comunidad las hagan. {% endhint %} Las experiencias portables son partes del gameplay que los jugadores llevan consigo a medida que se mueven por el metaverso. Estas no están vinculadas a parcelas de land, a veces están vinculadas a tokens, o a veces las lanza el Explorer. Por ejemplo, un jugador podría tomar una bola de nieve de tu scene, alejarse a otra scene y lanzar la bola de nieve a otro jugador que también esté jugando el mismo juego. Los smart wearables son un tipo de experiencia portable 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 sobre el resto del mundo, como colocar aleatoriamente monedas para recolectar por todo Genesis City. Ten en cuenta que los jugadores podrían estar usando la experiencia portable de otra persona mientras están en tu scene. Consulta [Datos del usuario](/creator/content-creator-es/scenes-sdk7/interactividad/user-data.md#get-portable-experiences) para saber cómo comprobar qué experiencias portables tiene activadas actualmente un jugador. ## Persistencia del juego **Decentraland es un mundo persistente, tu scene puede ser visitada por jugadores en cualquier momento.** Tu scene no tiene fase de inicio ni final, así que debes diseñar las mecánicas del juego de manera que permitan que los jugadores que entren o salgan en cualquier momento también puedan participar. Tu scene podría tener un mecanismo de reinicio que la establezca en 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 scene **Actualmente, los estados de las scenes no se comparten entre jugadores a menos que se implemente manualmente.** Esta es la forma más simple de construir una scene, pero no es ideal para experiencias sociales. Puedes usar el MessageBus para usar la misma arquitectura de mensajería que se utiliza para compartir cambios de posición de los jugadores y chat. Estos cambios de estado no se almacenan en ninguna parte. Si no hay jugadores actualmente cerca de la scene y cargándola, la scene se reiniciará a un estado predeterminado la próxima vez que se cargue. **Puedes alojar tu propio server para almacenar información sobre tu scene y mantener a todos los jugadores sincronizados con él.** Esto garantiza buenas velocidades de conexión y mantiene la scene ejecutándose continuamente incluso cuando no hay jugadores cerca. Si haces esto, tus limitaciones de latencia no serían diferentes a las de cualquier otro juego online masivamente jugado. Alojar tu propio server también es una medida de seguridad recomendada para juegos que implican transacciones con items del juego valiosos, ya que puedes mantener cierta información como los tokens de seguridad solo en el server, sin exponer esa información fuera de él. {% hint style="warning" %} **📔 Nota**: En futuras versiones, proporcionaremos soluciones listas para usar y ejemplos de código sobre cómo implementar tu propio server. {% endhint %} ### Temporización del 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 principalmente en interacciones jugador contra entorno. Para juegos en los que la temporización de las acciones entre jugadores sea crítica, como un first person shooter, debes implementar tu propio server como una fuente de verdad autoritativa en tiempo real entre todos los jugadores de tu scene. ## Jugadores en la scene **Los jugadores se identifican en Decentraland usando la dirección de su wallet Ethereum.** Este 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 donde puede haber diferentes sesiones de juego alojadas en servers 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 scene en cualquier momento. Algunos de ellos podrían estar de paso y no participar en el juego. Asegúrate de que las mecánicas del juego no puedan verse interrumpidas fácilmente por esto. **El game loop de tu scene no puede afectar directamente a los jugadores**, la scene tiene un enfoque reactivo a las acciones del jugador. Si un jugador está de pie sobre un entity y el entity se mueve o gira, el jugador se moverá con este entity. Esto es especialmente útil para ascensores, plataformas flotantes y similares. Como propietario de una scene, no puedes empujar a la fuerza ni teletransportar fuera de tu scene a un jugador infractor. Sin embargo, podrás incluir jugadores en una blacklist en el signaling server. También puedes implementar una blacklist en el código de tu scene y denegar ciertos servicios a los jugadores en la blacklist. ## Limitaciones del contenido de la scene **Por favor, construye tu scene teniendo especial cuidado con la eficiencia de tu código.** Decentraland necesita ejecutarse en navegadores web y dispositivos móviles, y los jugadores estarán renderizando múltiples scenes al mismo tiempo mientras recorren el metaverso. **También deberías intentar mantener la scene ligera.** A diferencia de otros juegos online donde las mismas textures y assets se repiten convenientemente a lo largo de un gran mundo abierto, en Decentraland cada scene podría tener su propio conjunto de assets completamente diferente. A medida que los jugadores recorren múltiples scenes, deberían poder descargar la totalidad del contenido de la scene, incluidas textures, archivos de sonido, etc., a una velocidad razonable. Debido a esto, hemos impuesto algunos límites para evitar el uso excesivo de recursos computacionales. Consulta [las limitaciones de la scene](/creator/content-creator-es/scenes-sdk7/optimizacion/scene-limitations.md) para obtener detalles sobre cuáles son estos límites. ## Acceso a las scenes **El mapa de Decentraland está diseñado de manera que haya roads y plazas públicas,** estas garantizan un fácil acceso a varias partes del mapa, independientemente de lo que construyan otras personas. Las parcelas de land que no son adyacentes a ningún road o plaza corren el riesgo de quedar bloqueadas por las scenes vecinas, aunque esperamos que la mayoría de las scenes 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 del 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á bloqueada o por debajo del nivel del terreno, no será una experiencia agradable. Para evitar esto, hay una forma en la que puedes definir un conjunto de ubicaciones específicas en tu scene que sean seguras para aparecer. Consulta [scene metadata](/creator/content-creator-es/scenes-sdk7/tipos-de-proyectos/scene-metadata.md) para obtener más detalles. En futuras versiones, los jugadores también podrán navegar rápidamente por el mundo usando mapas con spawn points, listas de ubicaciones populares y ubicaciones de amigos. El SDK también hará posible añadir teleports en tu scene que puedan transportarte a otras partes del mundo. ## UI del usuario **La UI superpuesta predeterminada que los jugadores ven al entrar en Decentraland solo tiene lo esencial.** Puedes añadir elementos extra a esa UI mientras un jugador esté en tu scene. Ten en cuenta que la UI predeterminada de Decentraland se muestra por encima de cualquier cosa de tu scene, así que diseña tu UI para que no se superponga con esta. Cuando un jugador sale de la scene, todos los elementos de UI se eliminan para no interferir con otras scenes. Los jugadores también tienen disponible en su pantalla un botón para desactivar todos los elementos de UI en la scene; esto es útil principalmente para evitar comportamientos abusivos de las scenes que podrían querer cubrir todo el campo de visión del jugador. ## Física Ten en cuenta que el SDK no proporciona su propio motor de física. Si quieres usar física en tu scene, puedes importar una library o programar el comportamiento tú mismo. ## Entradas del Controller **Los controles de tu juego deben limitarse a movimientos básicos, saltar, point and click, así como un botón primario y uno secundario.** Tendremos soporte para controles móviles y de Virtual Reality, así que no podemos asumir que todo el mundo tenga un teclado. Tenemos soporte para eventos globales de *button up* y *button down* para los tres botones. Los tres botones también tienen eventos de hit que te permiten identificar si un entity estaba en la mira del jugador. ## Avatares **Los jugadores pueden construir sus avatares a partir de un conjunto de wearable items predeterminados.** Ampliaremos la lista de wearables y opciones disponibles, y en el futuro también haremos posible que terceros creen y vendan wearables. ## Comunicación entre jugadores **Los usuarios pueden chatear entre sí. Actualmente, los avatares no tienen forma de transmitir lenguaje corporal más allá del uso de controles básicos de movimiento.** En futuras versiones también podrán hacer voice chat y realizar gestos como bailar o fruncir el ceño con sus avatares. También podrán mostrar un emoji temporal encima de su avatar para expresarse. Los jugadores también podrán mostrar tokens que poseen para que otros jugadores puedan verlos. ## Notificaciones del juego **Actualmente no existe un sistema de notificaciones entre scenes.** Cualquier juego que requiera notificaciones mostradas fuera de la scene 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 en día esto se refiere principalmente a la propiedad de LAND, pero también puede usarse para la propiedad de items del juego, wearables, avatares especiales, emotes y tokens que pueden garantizar ciertos privilegios 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 necesite cambiar en tiempo real. ### LAND y MANA **Los jugadores no necesitan poseer ninguna parcela de land para participar en el metaverso.** De hecho, la gran 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 un wallet Ethereum ni tokens MANA para entrar en Decentraland.** Si tu gameplay 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 tokens no fungibles especiales (NFTs) para representar items del juego, avatares personalizados o wearables.** Si un jugador posee uno de estos tokens, tu scene podría responder a él de diferentes maneras. Lee sobre qué son los NFTs en [este blogpost](https://decentraland.org/blog/technology/what-are-nfts/). ### Transacciones dentro del juego **Tu scene 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 costo en Ether; tanto el tiempo como el costo varían según el uso actual de la network. Decentraland está trabajando en la creación de una side-chain que podrá manejar transacciones más rápido y más barato que la network Ethereum. Esta side-chain será ideal para transacciones dentro del juego, ya que los cambios podrán ocurrir más cerca del tiempo real y a un costo muy bajo. La main Ethereum chain seguirá siendo recomendada para transacciones que requieran mayor seguridad y que puedan permitirse ser más caras y tardar más. El jugador siempre debe aprobar estas transacciones explícitamente en su cliente Ethereum. Por ejemplo, cuando se usa Metamask, Metamask solicita al jugador que acepte cada transacción antes de procesarla. Los jugadores también podrían firmar un contract que apruebe automáticamente todas las transacciones solicitadas por una dirección específica o dentro de ciertas limitaciones, para evitar interrupciones al aprobar transacciones. También puedes usar smart contracts para condicionar transacciones según condiciones personalizadas. Por ejemplo, los jugadores podrían apostar por el resultado de un juego, y los pagos correspondientes ocurrirían automáticamente tan pronto como se conociera el resultado. Para implementar interacciones de blockchain en el código de tu scene, debes usar external libraries que se integren con la network Ethereum. Futuras versiones del SDK proporcionarán una API personalizada para exponer estas funcionalidades de una manera más simple. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.decentraland.org/creator/content-creator-es/scenes-sdk7/disenar-la-experiencia/design-games.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.