Los ideales de la web3 parecen encajar perfectamente con la industria del juego y la tendencia de la gamificación de los últimos años. Durante bastante tiempo, se nos ha prometido una nueva disrupción en forma de una experiencia única: los juegos en cadena. Con propiedades como la descentralización, que desplazan el equilibrio de poder de los titulares de la industria del juego mucho más hacia las entidades creativas, la componibilidad que rompe los muros de los jardines cerrados durante mucho tiempo y la verdadera propiedad para los jugadores.

Pero estos poderosos ideales permanecen a un lado, ya que aún no los hemos visto en la práctica. MUD es el primer intento valiente de crear un marco completo para los juegos en cadena, una chispa que podría encender la próxima generación de juegos. Esto no es una quimera. En su breve período, el equipo de MUD es responsable de OPcraft, un juego real en 3D con temática de Minecraft completamente en cadena.

Lecciones de la industria tradicional del juego

Mucho se puede decir sobre la obsesión por innovar, construir todo desde cero y crear una criatura completamente nueva. Pero en lo que respecta a los juegos, hay docenas de años de lecciones sobre patrones de diseño y la creación de un nuevo nicho de ingeniería que debe tomarse en serio. Descartarlos es el equivalente a intentar crear un juego AAA con tecnología Atari.

Al observar los primeros años de desarrollo de juegos, podemos ver un parecido inconfundible con los juegos en cadena: una gran cantidad de talentos y proyectos altamente inspiradores, pero también una falta de coordinación y marcos claros.

En los primeros días de los videojuegos, antes de la aparición de los motores de juego, se establecieron convicciones y patrones de diseño. Los diferentes videojuegos tenían poco en común, hasta cierto punto, juegos similares podían tener una base de código completamente diferente. Pero con la introducción de los motores de juego, todo cambió.

Es difícil establecer exactamente una distinción clara entre los motores de juego y los juegos en sí. Generalmente, los motores de juegos son marcos con un conjunto de reglas y patrones de diseño que se pueden modificar y ampliar ligeramente para crear diferentes implementaciones de juegos. En los años 90, después de años de desarrollo fragmentado de juegos, algo cambió, y los motores de juego "basados en géneros" y algunos esfuerzos para desarrollar motores de propósito general tomaron la delantera. Juegos como Doom y Unreal tenían componentes básicos que podían reutilizarse para crear muchos juegos diferentes. Los juegos con géneros similares comenzaron a compartir muchas de sus implantaciones lógicas centrales. El costo y la complejidad del desarrollo de juegos de carreras, lucha y disparos en primera persona disminuyeron en órdenes de magnitud. Lo imposible se hizo posible, y generaciones de juegos y código actualizado se han acumulado uno encima del otro. Desde el punto de vista del software, esta es una de las principales razones por las que el desarrollo de juegos se convirtió en una gran industria.

Hay algunos problemas centrales asociados con los juegos en cadena:

1. Falta de marcos: Todos los equipos intentan construir todo desde cero, lo que resulta en una eficiencia deficiente y una falta de conocimiento sistémico después de la experiencia agregada de los constructores que abordan los mismos problemas y optimizan hacia las mejores soluciones.
2. Falta de reutilización del código: Tomemos como ejemplo muchos de los juegos on-chain que se desarrollan hoy en día. ¿Cuántos de ellos se pueden copiar con éxito para crear juegos ligeramente diferentes? ¿Cuántos de ellos tienen una clara distinción entre las diferentes capas y componentes del juego que permite construir una nueva generación con una base de código similar? La promesa de crear el proyecto de código abierto más significativo e interconectado para juegos parece lejana.
3. Falta de componibilidad de los datos: no termina con la reutilización del código. También se trata de la capacidad de los juegos on-chain para aprovechar el estado compartido de la cadena de bloques para construir uno encima del otro utilizando los datos del juego A en el juego B. En la práctica, se necesita mucho trabajo y recursos para incorporar los datos y la lógica de un juego en el otro.

La solución de la MUD:

Mud es el primer intento valiente de crear un motor y un marco para los juegos en cadena al proporcionar la estructura para la mantenibilidad, la capacidad de actualización y la capacidad de moldeo. El patrón del Sistema de Componentes de Entidad (ECS) defendido por el barro tiene sentido no solo en el sentido del desarrollo general de juegos, sino aún más para el desarrollo de juegos en cadena.

ECS en contratos inteligentes:

Los componentes básicos de MUD son los componentes. Son contratos desplegados que funcionan como bases de datos que almacenan datos sobre entidades. Por ejemplo, tomemos una entidad (una dirección) como la billetera del jugador. Esta entidad representada por una dirección puede tener diferentes propiedades, como el valor de posición (x,y) en el componente de posición, el nivel 10 en el componente de nivel y 50 en el componente de monedas. Los componentes consisten únicamente en una asignación y una configuración básica. Los sistemas son más complicados e implementan la lógica de cambiar el valor en componentes. Puede pensar en esto como sistemas específicos de la API para solicitudes POST en las bases de datos (componentes). Solo podían hacerlo si se les concedía acceso de escritura a componentes específicos. Aquí la cosa se pone interesante. Los sistemas pueden interactuar con diferentes componentes para crear una lógica detallada. Puedes tener un sistema de movimiento que especifique el movimiento válido que el jugador puede hacer (por ejemplo, dos pasos cada vez), y puedes tener un sistema de recompensas que dé monedas a los jugadores cada vez que suban de nivel. Todos ellos se registran en "Contacto mundial", de modo que cada cambio en los datos de los componentes va seguido de un evento emitido. Los contratos mundiales no tienen permisos. Cualquiera puede añadir nuevos sistemas y componentes. En teoría, los diferentes mundos pueden interactuar entre sí.

Llevar ECS a los juegos on-chain da como resultado una estructura muy elegante, de modo que OPcraft solo consta de 10 componentes y unos 15 sistemas. Puedes consultar esta gran publicación de blog en MUD.dev

Verdadera componibilidad

El sistema ECS no solo tiene mucho sentido en el desarrollo de juegos tradicionales, sino aún más en los juegos en cadena al proporcionar dos características importantes

1. Posibilidad de actualización del juego desplegado
2. El más alto grado de componibilidad

Imagina dos caminos. Una de ellas es conservar el diseño de la base. Y el otro es cambiar la lógica del juego principal.

Piensa en un juego de estrategia PVP estándar en el que los jugadores pueden construir ejércitos para luchar entre sí. La versión base era 2D, pero ahora el equipo ha decidido que quiere crear un render 3D detallado del juego. Todo lo que necesitan hacer es tomar todos los sistemas relacionados con la posición y crear versiones actualizadas con coordenadas (x,y,z) en lugar de (x,y). Todos los demás sistemas y componentes (como el sistema de ataque, los HP y la construcción del ejército) pueden seguir siendo los mismos. Incluso va más allá de los equipos de desarrollo iniciales, las comunidades pueden crear diferentes mods del juego mediante la reimplementación de sistemas y componentes o incluso interactuar con los mismos componentes otorgando acceso de escritura a nuevos sistemas (si se trata de un juego propiedad de la comunidad, se pueden aplicar varios modelos de gobernanza para este tipo de decisiones)

El otro enfoque mantendrá los mismos componentes y sistemas sin dar acceso a escritura a los nuevos sistemas. Pero con componentes y sistemas añadidos para ampliar las funcionalidades dentro del juego, ¿cómo podría ser? Considere un juego básico de ajedrez en cadena. Los sistemas de movimientos y reglas ya están implementados. Las personas pueden jugar el juego como si estuvieran jugando al ajedrez de la vida real, pero tal vez su equipo decida que necesita crear una capa adicional, una social que consista en un sistema de clasificación para el emparejamiento o cualquier otro caso de uso. Todo lo que necesita hacer es agregar un componente de calificación y un sistema con reglas de calificación. Esto da como resultado no solo un cambio muy fluido a nuevas versiones de juegos (experiencia de usuario mejorada), sino que también crea los medios técnicos para que las diferentes versiones coexistan una al lado de la otra o una encima de la otra a nivel de contrato inteligente. Los jugadores pueden permanecer en varias versiones del juego mientras interactúan con los mismos datos de los componentes principales, lo cual es muy innovador, aparte de las aplicaciones de componibilidad. Crea una característica de inmutabilidad opcional, creando otra dimensión de propiedad que proporcionarían los juegos en cadena. Verdadera propiedad de diferentes activos del juego (como puntuación, NFT, logros) que está asegurada por una lógica inmutable que puede ampliarse con actualizaciones adicionales, pero que no cambia en su núcleo. Resuelve uno de los principales problemas de los juegos web3, que es la capacidad de los creadores para nerfear activos sin consentimiento.

Del lado del cliente, una perspectiva general:

Observe que MUD es un proyecto en progreso. Es posible que la siguiente parte no esté actualizada y contenga algunas inexactitudes y distinciones aproximadas, pero no se espera que la arquitectura general cambie drásticamente.

Hasta ahora, hemos analizado MUD a nivel de contrato inteligente. Pero hay mucho más. MUD proporciona una suite completa con bibliotecas de cliente y capas. Hay algunas características únicas para las que MUD está diseñado.

1. Componibilidad del cliente
2. El cliente está completamente sincronizado con el cambio de estado de la cadena de bloques (datos del juego)
3. PhaserX como capa de renderizado

Profundicemos en los detalles técnicos para hacerlo más concreto.

Capa de red:

La capa de red es la capa base del cliente. Contiene la configuración básica (contrato mundial, juego y configuración de red) y la API para las interacciones del juego. Cuando se crea la capa de red, tiene una especificación de todos los diferentes componentes y sistemas con los que su cliente podrá interactuar, y puede optar por interactuar solo con componentes/sistemas específicos. Por ejemplo, si desea crear movimiento en su juego y darle representación en la interfaz, deberá crear una capa de red que se sincronice con el contrato inteligente implementado del componente de posición y también con el sistema de movimiento. Ahora puedes crear una API de movimiento que tome una posición y algún objeto (entidad) en el juego y establezca su posición o moverlo de un lugar a otro. Cada vez que los jugadores usaban la API de Move. Van a enviar una transacción a la cadena de bloques. En el caso del sistema de movimiento, van a ejecutar una función dentro del contrato inteligente del sistema de movimiento.

Esta estructura permite juegos basados en múltiples clientes. Todo el mundo podría crear clientes únicos, y todos ellos son igualmente válidos siempre que estén sincronizados con blockchain y sigan la estructura base de la capa de red. Hemos visto casos de uso muy interesantes para juegos multicliente, como en el caso de un bosque oscuro, en el que los jugadores compiten entre sí pero usan diferentes clientes y complementos. La estructura del cliente nos permite tomar la implantación de la capa de red y modificar la API para obtener diferentes versiones del cliente de forma muy rápida, logrando un alto nivel de moldeabilidad y componibilidad del cliente.

Es posible que se pregunte cómo se sincronizan exactamente los componentes del cliente con los componentes de la cadena. Este es uno de los principales retos a los que se enfrentan los constructores cuando se trata del lado del cliente de los juegos on-chain. MUD tiene algunas soluciones para ello.

En primer lugar, MUD implementó una función de instantánea que permite al cliente sincronizarse con el estado mundial (es decir, los valores de las entidades por componentes) sin procesar todos los eventos pasados para reconstruir el estado, lo que da como resultado una baja latencia y una menor complejidad.

Además, el sistema de identificación de MUD, en el que cada sistema y componente obtiene una identificación basada en su nombre y, al implementarse, se registran en el contrato mundial, lo que hace que sea mucho más accesible realizar un seguimiento de los cambios, interactuar con el juego y obtener eventos fácilmente.

Capa de renderizado: cuándo y cómo se renderizan los eventos

MUD viene con PhaserX, "un motor altamente escalable que se construye sobre el phaser", PhaserX no es obligatorio. En OPcraft, hay un motor de vóxeles Noa en lugar de PhaserX. En teoría, puede usar cualquier motor que desee siempre que siga la estructura.

Como se indicó anteriormente, cada componente y sistema se registra en el contrato mundial, y cuando se produce un cambio, se emitirá un evento (con datos identificados como el ID del componente y el ID de la entidad). Aquí, el servicio de transmisión de ECS puede proporcionar al cliente la opción de elegir a qué eventos suscribirse.

La representación gráfica de las entidades puede ser la que quieras. Un juego de lucha podría tener personajes de anime, caballeros o incluso tus influencers criptográficos favoritos. Todas ellas son versiones válidas siempre que representen y reaccionen a eventos on-chain.

Renuncia:

1. Este artículo es una reimpresión de [mirror], Todos los derechos de autor pertenecen al autor original [Matchbox DAO]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn ("Gate Learn") y ellos se encargarán de ello con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.