Diseñar juegos
Lo que debes tener en cuenta al diseñar un juego para Decentraland.
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 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 el vacío. No tienes control sobre lo que hay en las escenas adyacentes, y no tienes control sobre ciertos detalles como los avatares del jugador o los objetos que podría traer de otros juegos. Esto abre la puerta a posibilidades emocionantes y requiere que pienses de forma diferente sobre las mecánicas de juego.
Lo más parecido en los juegos convencionales ahora mismo es Roblox, donde el contenido generado por 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 scenes no explorando 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, por lo 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 se construye 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 pertenezca a la escena debe 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 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 formado por múltiples escenasseparadas, que podrían compartir datos entre sí a través de un server.
Si tu juego se publica en un World de Decentraland, tienes más control sobre lo que los jugadores ven 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 si choca con el entorno de tu juego, por ejemplo un juego que transcurre en aguas abiertas o en el espacio.
Inventario del usuario
Actualmente no existe un inventario donde los jugadores puedan guardar objetos del juego mientras se desplazan entre scenes. Hoy en día están disponibles las siguientes alternativas:
Puedes almacenar la información del inventario en la propia escena 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 escena.
Puedes usar un storage externo personalizado y sincronizar con él todas tus scenes. Esta es una solución más robusta que puede manejar mayores volúmenes de jugadores. También puede extender 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 los objetos.
Al obtener un objeto del juego, podría almacenarse como un token especial en el wallet Ethereum de un jugador. Cuando un jugador que posee el token entra en tu escena, tu escena podría otorgarle ciertas características dentro del juego.
Otras scenes también podrían responder al mismo token de diferentes maneras, lo que puede dar lugar a una interacción interesante 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 a todas partes e incluirá tanto assets on-chain como off-chain.
Experiencias portables
Las experiencias portables son partes del gameplay que los jugadores llevan consigo mientras se mueven por el metaverso. No están ligadas a parcelas de land, a veces están ligadas a tokens, o a veces se activan desde el Explorer. Por ejemplo, un jugador podría llevar una bola de nieve desde tu escena, alejarse a otra escena y lanzar la bola de nieve a otro jugador que también esté jugando al mismo juego.
Los wearables inteligentes son un tipo de experiencia portable que está ligada a un token wearable y se activa cuando el jugador se pone la prenda. Los wearables inteligentes pueden otorgar nuevas habilidades a los jugadores, como una mochila cohete que les permita volar, o añadir una nueva capa de contenido sobre el resto del mundo, como colocar monedas aleatoriamente para recogerlas 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 escena. Consulta User Data para saber cómo comprobar qué experiencias portables 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 debes diseñar las mecánicas del juego de una manera que permita participar también a los jugadores que entren o salgan en cualquier momento.
Tu escena podría tener un mecanismo de reinicio que la devuelva 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 estado entre jugadores es marcar las entities como sincronizadas, usando la syncEntity función. Consulta Multiplayer Server sin server. Con este enfoque, los cambios de estado no se almacenan en ningún sitio: si no hay jugadores cerca de la escena cargándola en ese momento, la escena se reiniciará a un estado predeterminado la próxima vez que se cargue.
También puedes usar un server para almacenar información sobre tu escena y mantener sincronizados a todos los jugadores con ella. Esto mantiene el estado de la escena coherente 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, que Decentraland hospeda y despliega por ti como parte de la publicación de tu escena. También puedes alojar tu propio server, lo que te permite mantener cierta información, como los tokens de seguridad, solo en el server, sin exponer nunca esa información fuera de él.
Tiempo 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 el tiempo de las acciones entre jugadores es crítico, como un juego de disparos en primera persona, deberías implementar tu propio server como una fuente autorizada 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 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 distintas 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 escena en cualquier momento. Algunos de ellos podrían estar pasando de largo y no participar en el juego. Asegúrate de que las mecánicas del juego no puedan verse fácilmente alteradas por esto.
El bucle de juego de tu escena no puede afectar directamente a los jugadores, la escena tiene un enfoque reactivo a las acciones del jugador. Si un jugador está de pie sobre una entity y la entity se mueve o gira, el jugador se moverá con esta entity. Esto es especialmente útil para ascensores, plataformas flotantes y similares.
Como propietario de una escena, no puedes expulsar a la fuerza ni teletransportar a un jugador problemático fuera de tu escena. Sin embargo, podrás poner jugadores en una blacklist en el server de señalización. También puedes implementar una blacklist en el código de tu escena y denegar ciertos servicios a los jugadores en blacklist.
Limitaciones del contenido de la escena
Por favor, construye tu escena teniendo un cuidado extra con la eficiencia de tu código. Decentraland necesita funcionar 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 escena ligera. A diferencia de otros juegos online donde las mismas textures y assets se repiten cómodamente a lo largo de un gran mundo abierto, en Decentraland cada escena 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 escena, incluidas textures, 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 las limitaciones de la escena para obtener detalles sobre cuáles son estos límites.
Acceso a las scenes
El mapa de Decentraland está diseñado para que haya carreteras y plazas públicas, estas garantizan un fácil acceso a diversas partes del mapa, independientemente de lo que construyan otras personas. Las parcelas de land que no están adyacentes a ninguna carretera o plaza corren el riesgo de quedar bloqueadas por 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 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 de forma fija.
Ten en cuenta que si un jugador empieza en una ubicación que está bloqueada por muros o por debajo del nivel del terreno, no será una experiencia agradable. Para evitar esto, existe una forma de definir un conjunto de ubicaciones específicas en tu escena que sean seguras para aparecer. Consulta los metadatos de la escena 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 teleports que transporten a los jugadores a otras partes del mundo, consulta Teleports.
UI del usuario
La UI superpuesta predeterminada que ven los jugadores al entrar en Decentraland solo tiene lo esencial. Puedes añadir elementos extra a esa UI mientras un 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 forma que no se superponga con esto.
Cuando un jugador sale de la escena, se eliminan todos los elementos de UI para no interferir con otras scenes. Los jugadores también tienen un botón disponible en su pantalla para desactivar todos los elementos de UI de la escena; esto es principalmente útil para evitar comportamientos abusivos por parte de scenes que quieran cubrir todo el campo de visión del jugador.
Física
Ten en cuenta que el SDK no proporciona un motor de física completo para entities. Puedes aplicar fuerzas e impulsos al avatar del jugador, consulta Física del jugador. Para la física entre entities, como colisiones o gravedad, puedes importar una library o programar el comportamiento tú mismo.
Entradas del controlador
Los controles de tu juego deberían limitarse al conjunto de input actions compatibles con el SDK: las teclas de movimiento, saltar, point and click, los botones primario (E) y secundario (F), y los botones de acción numerados (1 a 4). Estas entradas están abstraídas de las teclas físicas, de modo que también pueden mapearse a los controles en pantalla de la app móvil o a otros dispositivos; no des por hecho que todo el mundo tiene un teclado. Consulta botones de puntero para ver la lista completa, y Entrada en dispositivos móviles para saber qué preferir al dirigirte a jugadores móviles.
Todas estas entradas admiten tanto eventos globales botón arriba y botón abajo eventos, como eventos de impacto que te permiten identificar si una entity estaba en la mira del jugador.
Avatares
Los jugadores pueden construir sus avatares a partir de un amplio catálogo de wearables, incluyendo 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 a ello, consulta User data.
Comunicación entre jugadores
Los jugadores pueden chatear entre sí, hablar por voz y transmitir lenguaje corporal jugando 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 Player plays animation y Activar emotes.
Notificaciones del juego
Actualmente no existe un sistema de notificaciones entre scenes. 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 en día 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 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 haber tenido previamente un wallet Ethereum o 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 adaptarlo a ambas bases de usuarios.
Otros NFTs
Puedes usar tokens no fungibles especiales (NFTs) para representar objetos del juego, avatares personalizados o wearables. Si un jugador posee uno de estos tokens, tu escena podría responder a ello de diferentes maneras.
Lee sobre qué son los NFTs en esta entrada del blog.
Transacciones dentro del juego
Tu escena puede admitir transacciones blockchain para que los jugadores compren o ganen tokens.
Las transacciones blockchain no son inmediatas; requieren tiempos de verificación y tienen un coste en Ether. Tanto el tiempo como el coste varían en función del uso actual de la red.
Decentraland usa la side-chain de Polygon para gestionar las transacciones de forma más rápida y barata que la red Ethereum. Esta side-chain es ideal para las transacciones dentro del juego, ya que los cambios pueden ocurrir más cerca del tiempo real y con 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 Capa secundaria.
El jugador debe aprobar siempre estas transacciones explícitamente en su cliente 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 ciertas restricciones, para evitar interrupciones al aprobar transacciones.
También puedes usar smart contracts para condicionar transacciones en función de condiciones personalizadas. Por ejemplo, los jugadores podrían apostar por el resultado de un juego, y los pagos correspondientes se realizarían automáticamente en cuanto se conociera el resultado.
Para implementar interacciones blockchain en el código de tu escena, debes usar libraries externas que interactúen con la red Ethereum. Las futuras versiones del SDK proporcionarán una API personalizada para exponer estas funcionalidades de una forma más sencilla.
Última actualización