Diseñar juegos

Qué 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 escenas y la propiedad distribuida del LAND hacen de Decentraland un lugar único que requiere que reconsidere supuestos que pueda tener a partir de juegos anteriores.

Por ejemplo, debe entender que, a diferencia de otras plataformas de juegos, los juegos de Decentraland no existen en el vacío. No tiene control sobre lo que hay en las escenas adyacentes, y no tiene control sobre ciertos detalles como los avatares de los jugadores o los objetos que podrían traer de otros juegos. Esto abre la puerta a posibilidades emocionantes y requiere que piense en la mecánica del juego de manera diferente.

Lo más parecido en los juegos convencionales ahora mismo 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, usted navega por las escenas no navegando un menú de experiencias no relacionadas sino explorando físicamente un terreno donde todas las escenas son adyacentes entre sí. Decentraland también hace uso de la blockchain como una forma de gestionar la propiedad de la tierra, avatares, activos, etc.

Estamos mejorando continuamente el SDK, por lo 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 escena

Su juego debe caber completamente en el _LAND_** sobre el que se construye su escena.** Para escenas pequeñas, piense en juegos como el fútbol donde las reglas del juego mantienen la interacción relevante dentro de un espacio confinado, aunque los jugadores puedan salir del campo de juego. Los jugadores pueden caminar fuera de los límites de una escena, pero cualquier activo o entidad que pertenezca a la escena debe permanecer dentro de la escena.

Los jugadores que salgan de su escena seguirán renderizándola mientras esté a un rango visible. Si se alejan demasiado, dejarán de renderizarla por completo.

También podría construir un juego que se extienda a lo largo de varias parcelas de tierra desconectadas que sean desconocidas para los jugadores, y donde la exploración del resto del mundo se convierta en 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.

Inventario del usuario

Actualmente no existe un inventario donde los jugadores puedan almacenar objetos del juego mientras caminan entre escenas. Las siguientes alternativas están disponibles hoy:

• Puede 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 su escena.

• Puede usar un almacenamiento externo personalizado y sincronizar todas sus escenas con él. Esta es una solución más robusta que puede manejar volúmenes más grandes de jugadores. También puede extender el acceso a este inventario a múltiples escenas separadas que usted u otros posean.

• Use tokens en la blockchain para gestionar la propiedad de los objetos.

Al ganar un objeto del juego, podría almacenarse como un token especial en la wallet Ethereum de un jugador. Cuando un jugador que posee el token entre en su escena, su escena podría otorgarle al jugador ciertas características dentro del juego.

Otras escenas podrían potencialmente también responder al mismo token de diferentes maneras, lo que puede generar una interacción interesante entre juegos.

La desventaja de usar la blockchain para almacenar objetos de inventario es que todas las transacciones tienen un costo para el jugador y no son inmediatas. Lea 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á activos tanto on-chain como off-chain.

Experiencias portables

📔 Nota: Las experiencias portables y los wearables inteligentes aún están en una fase exploratoria y todavía no están disponibles para que los creadores de la comunidad los creen.

Las experiencias portables son partes de la jugabilidad que los jugadores se llevan consigo mientras se mueven por el metaverso. Estas no están vinculadas a parcelas de tierra; a veces están vinculadas a tokens, o a veces son lanzadas por el Explorer. Por ejemplo, un jugador podría tomar una bola de nieve de su escena, caminar a otra escena y lanzarla a otro jugador que también esté jugando el mismo juego.

Los wearables inteligentes son un tipo de experiencia portable que está vinculada a un token de wearable y se activa cuando el jugador se pone la prenda. Los wearables inteligentes pueden otorgar a los jugadores nuevas habilidades, como una mochila propulsora que les permita volar, o añadir una nueva capa de contenido sobre el resto del mundo, como colocar monedas aleatoriamente para ser recogidas en toda Genesis City.

Tenga en cuenta que los jugadores podrían estar usando la experiencia portable de otra persona mientras están en su escena. Vea Datos de usuario para aprender cómo comprobar qué experiencias portables tiene activadas actualmente un jugador.

Persistencia del juego

Decentraland es un mundo persistente, su escena puede ser visitada por los jugadores en cualquier momento. Su escena no tiene una fase de inicio ni un final, por lo que debe diseñar la mecánica del juego de manera que permita que los jugadores que entren o salgan en cualquier momento también puedan participar.

Su escena podría tener un mecanismo de reinicio que la establezca en un estado inicial, pero debe tener cuidado de no interrumpir el juego para los jugadores que ya estén jugando.

Sincronizar el estado de la escena

Actualmente, los estados de la escena no se comparten entre jugadores a menos que se implementen manualmente. Esta es la forma más simple de construir una escena, pero no es ideal para experiencias sociales.

Puede usar el MessageBus para usar la misma arquitectura de mensajería utilizada para compartir cambios de posición de los jugadores y chat. Estos cambios de estado no se almacenan en ningún lugar. Si no hay jugadores cerca de la escena cargándola, la escena se restablecerá a un estado predeterminado la próxima vez que se cargue.

Puede alojar su propio servidor para almacenar información sobre su escena y mantener a todos los jugadores sincronizados con ella. Esto garantiza buenas velocidades de conexión y mantiene la escena en funcionamiento continuamente incluso cuando no hay jugadores cerca. Si hace esto, sus limitaciones de latencia no serían diferentes a las de cualquier otro juego en línea jugado masivamente.

Alojar su propio servidor también es una medida de seguridad recomendada para juegos que involucran transacciones con objetos valiosos, ya que puede mantener cierta información como tokens de seguridad solo en el servidor, sin exponer nunca esa información fuera.

📔 Nota: En futuras versiones, proporcionaremos soluciones listas para usar y ejemplos de código sobre cómo implementar su propio servidor.

Temporización del juego

Los juegos que usan la arquitectura de comunicaciones por defecto deben tener en cuenta que podría haber lag entre jugadores y no deberían confiar en reacciones rápidas entre las acciones de diferentes jugadores. Recomendamos juegos por turnos, o que se basen principalmente en interacciones jugador contra entorno.

Para juegos donde la sincronización de acciones entre jugadores sea crítica, como un shooter en primera persona, debe implementar su propio servidor como una fuente autoritativa en tiempo real entre todos los jugadores en su escena.

Jugadores en la escena

Los jugadores se identifican en Decentraland usando su dirección de wallet Ethereum. Esta wallet se usa como un ID persistente que ya está asociado con todos los tokens que el jugador posee.

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 servidores separados, solo hay una instancia de Decentraland compartida entre todos los jugadores, al menos por ahora.

Debe tener en cuenta que puede haber varios jugadores caminando por su escena en cualquier momento. Algunos de ellos podrían estar de paso y no participando en el juego. Asegúrese de que la mecánica del juego no pueda ser fácilmente interrumpida por esto.

El bucle de juego de su escena no puede afectar a los jugadores directamente, la escena tiene un enfoque reactivo a las acciones del jugador. Si un jugador está parado sobre una entidad y la entidad se mueve o rota, el jugador se moverá con esa entidad. Esto es especialmente útil para elevadores, plataformas flotantes y similares.

Como propietario de una escena, no puede forzar empujar o teletransportar a un jugador infractor fuera de su escena. Sin embargo, podrá poner jugadores en una lista negra en el servidor de señalización. También puede implementar una lista negra en el código de su escena y denegar ciertos servicios a jugadores en la lista negra.

Limitaciones del contenido de la escena

Por favor, construya su escena teniendo especial cuidado con la eficiencia de su código. Decentraland necesita ejecutarse en navegadores web y dispositivos móviles, y los jugadores estarán renderizando múltiples escenas al mismo tiempo mientras caminan por el metaverso.

También debe intentar mantener la escena ligera. A diferencia de otros juegos en línea donde las mismas texturas y activos se repiten convenientemente a lo largo de un gran mundo abierto, en Decentraland cada escena podría tener su propio conjunto completamente diferente de activos. A medida que los jugadores caminan por múltiples 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 el uso excesivo de recursos computacionales. Vea limitaciones de la escena para detalles sobre cuáles son estos límites.

Acceso a las escenas

El mapa de Decentraland está diseñado de manera que haya carreteras y plazas públicas, esto garantiza un fácil acceso a varias partes del mapa, independientemente de lo que otras personas construyan. Las parcelas de tierra que no son adyacentes a ninguna carretera o plaza corren el riesgo de ser cerradas por escenas vecinas, aunque esperamos que la mayoría de las escenas sean transitable y no bloqueen a otras.

Los jugadores nuevos empezarán su experiencia en Genesis Plaza, en el centro del mapa, donde se les animará a seguir algunas actividades tutoriales y luego a explorar el mundo.

Los jugadores también pueden escribir manualmente una URL para unas coordenadas específicas en el mapa de Decentraland para aparecer en esa ubicación. También puede compartir enlaces a URLs que tengan coordenadas iniciales codificadas.

Tenga en cuenta que si un jugador comienza en una ubicación que está cerrada o por debajo del nivel del terreno, no será una experiencia agradable. Para evitar esto, hay una forma en la que puede definir un conjunto de ubicaciones específicas en su escena que son seguras para aparecer. Vea metadatos de la escena para más detalles.

En futuras versiones, los jugadores también podrán navegar por el mundo rápidamente usando mapas con puntos de aparición, listas de ubicaciones populares y ubicaciones de amigos. El SDK también hará posible añadir teleports en su escena que puedan transportar a otras partes del mundo.

UI del usuario

La UI superpuesta por defecto que los jugadores ven al entrar en Decentraland tiene solo lo esencial. Puede añadir elementos extra a esa UI mientras un jugador está en su escena. Tenga en cuenta que la UI por defecto de Decentraland se muestra por encima de cualquier cosa de su escena, así que diseñe su UI para que no se solape con esta.

Cuando un jugador sale de la escena, todos los elementos de la UI se eliminan para no interferir con otras escenas. Los jugadores también tienen un botón disponible en su pantalla para desactivar todos los elementos de la UI en la escena; esto es principalmente útil para prevenir comportamientos abusivos de escenas que puedan querer cubrir todo el campo de visión del jugador.

Física

Tenga en cuenta que el SDK no proporciona su propio motor de física. Si desea usar física en su escena, puede importar una librería o codificar el comportamiento usted mismo.

Entradas de controlador

Los controles de su juego deben limitarse a movimientos básicos, salto, apuntar y hacer clic, así como un botón primario y uno secundario. Soportaremos móviles y controladores de Realidad Virtual, por lo que no podemos asumir que todos tengan un teclado.

Tenemos soporte para globales button up y button down eventos para los tres botones. Los tres botones también tienen eventos de impacto que le permiten identificar si una entidad estaba en la mira del jugador.

Avatares

Los jugadores pueden construir sus avatares basándose en un conjunto de wearables 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 chat de voz y realizar gestos como bailar o fruncir el ceño con sus avatares. También podrán mostrar un emoji temporal sobre su avatar para expresarse. Los jugadores también podrán mostrar los tokens que poseen para que otros jugadores los vean.

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 de 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 parcelas de tierra 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 posean no están conectados de forma directa.

Los jugadores no necesitan poseer previamente una wallet Ethereum o tokens MANA para entrar en Decentraland. Si su jugabilidad depende en gran medida de poseer tokens, estaría 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

Puede usar tokens no fungibles especiales (NFTs) para representar objetos del juego, avatares personalizados o wearables. Si un jugador posee uno de estos tokens, su escena podría responder a él de diferentes maneras.

Lea sobre qué son los NFTs en este artículo del blog.

Transacciones dentro del juego

Su escena puede soportar transacciones en la blockchain para que los jugadores compren o ganen tokens.

Las transacciones en la 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 está trabajando en la creación de una side-chain que podrá manejar transacciones más rápidas y baratas que la red 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 coste muy bajo. La cadena principal de Ethereum seguirá recomendándose para transacciones que requieran mayor seguridad y que puedan permitirse ser más caras y tardar más.

El jugador debe aprobar siempre estas transacciones explícitamente en su cliente Ethereum. Por ejemplo, al usar Metamask, Metamask solicita al jugador que acepte cada transacción antes de que se procese.

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 limitaciones, para evitar interrupciones al aprobar transacciones.

También puede 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 realizarían automáticamente tan pronto como se conozca el resultado.

Para implementar interacciones con la blockchain en el código de su escena, debe usar librerías externas que interactúen con la red Ethereum. Las futuras versiones del SDK proporcionarán una API personalizada para exponer estas funcionalidades de una manera más sencilla.