Ponentes: Andrea, Gabriele, cofundador de Magicblock
演讲标题:UN MARCO PARA JUEGOS EN CADENA
Prefacio del traductor: "BOLT es un motor de juego de cadena completa desarrollado por el equipo de Magicblock para el ecosistema Solana. Este artículo se recopila a partir de las presentaciones de los dos fundadores de Magicblock en el evento Breakpoint 2023. "
Hola a todos, este es el último discurso antes de Halloween, y espero que el contenido del discurso sea interesante para todos. Mi nombre es Andrea y soy mi cofundadora, Gabriele. Hoy, vamos a presentar un nuevo marco de juego de cadena completa (motor).
01.¿Por qué necesitas un juego de cadena completa
Voy a empezar por lo básico, por lo que me molesto en crear un juego de cadena completa con estado y lógica en la cadena, y lidiar con todas las complejidades que conlleva. La razón simple es obtener características que la infraestructura de juegos tradicional no tiene.
La primera característica son los mods sin permisos. Esto significa que todos los jugadores y desarrolladores pueden personalizar cualquier componente del juego, incluida la introducción de plugins o mods, a partir del cliente avanzado. Incluso la lógica subyacente del juego se puede extender a través de contratos inteligentes. Esencialmente, es un nuevo modo en el que cada juego es una nueva plataforma de forma predeterminada, y puedes convertirte en una potencia de contenido sin importar cuán pequeño sea tu equipo.
La segunda característica es la persistencia. Los mundos autónomos y el hecho de que estas experiencias virtuales puedan existir para siempre han causado muchas repercusiones. Debido a que ningún servidor puede ser censurado o cerrado, estas experiencias en realidad introducen un significado completamente nuevo. Los juegos se han convertido en una plataforma para que los jugadores jueguen, socialicen y realicen comercio global, que es más universal que las plataformas de juegos tradicionales.
La última característica son las economías abiertas. Los juegos pueden aprovechar el sistema de pago global abierto y sin fricciones de blockchain, especialmente los micropagos en nuestro ecosistema, y reutilizar la infraestructura existente en la cadena, como los DEX o los mercados NFT.
02.Solución existente
El problema actual con los juegos omnichain es que la experiencia de desarrollo es muy mala, y miramos las soluciones en el mercado y encontramos que hay algunos marcos de desarrollo que intentan simplificar la experiencia del desarrollador.
Algunos de ellos son muy interesantes en el sentido de que intentan iterar en sesiones demostrables, donde se pueden hacer cálculos fuera de la cadena y demostrar la integridad de los cálculos en la cadena. O introduzca un tiempo de ejecución basado en eventos que sea más adecuado para los motores de juegos de blockchain, en lugar de un tiempo de ejecución basado en bucles.
Sin embargo, todos estos marcos requieren compensaciones entre el rendimiento y la componibilidad para lograr un mayor rendimiento y un TPS más alto. Normalmente, creará un aislamiento o introducirá un entorno de ejecución diferente con particiones.
Pero no estamos contentos con esa compensación. Nos preguntamos, ¿qué pasaría si hubiera un marco que pudiera soportar el TPS que necesitábamos? Cuando tu juego tiene éxito, no tienes que sacrificar su experiencia de usuario, incluso con millones de jugadores, porque las guerras de gas no ocurrirán. Y el marco no requiere fragmentación ni fragmentación, por lo que puede usar sesiones de juego demostrables e incluso simular el paso del tiempo sin pagar tarifas de gas. No es necesario fragmentar el sistema ni utilizar la capa 3 en absoluto.
03.Motor de desarrollo de juegos de cadena completa en Solana: BOLT
Es por eso que nos complace presentar BOLT, un marco de desarrollo de juegos de cadena completa, componible y de alto rendimiento basado en SVM.
BOLT es modular y componible, lo que le permite utilizar toda la infraestructura existente en Solana. Trabaja con nuestras instalaciones existentes en la cadena, como la identidad en la cadena, la API sin gas, la clave de sesión, así como el marco de desarrollo Anchor existente y todos los programas existentes en Solana. Ambos pueden escalar en un orden de magnitud superior gracias a los Ephemeral Rollups, que son sesiones de juego que se abren y cierran según lo exija el usuario, y se escalan según sea necesario.
BOLT es ultrarrápido y podemos lograr el mismo nivel de rendimiento que un motor de juego tradicional antes de usar estos tiempos de ejecución dedicados para acelerar ciertas operaciones.
Esta es una pantalla panorámica del marco BOLT. Obviamente, está construido para Solana, pero puede usarlo en cualquier plataforma compatible con SVM, como la capa 2 compatible con SVM. BOLT tiene dos objetivos principales, la componibilidad y la escalabilidad.
El sistema ECS (Entity Component) es una de las formas en que simplificamos el uso de los componentes en cadena. El otro es el Ephemeral Rollup, que se ha mencionado brevemente anteriormente, y me sumergiré en ambas tecnologías en un momento.
BOLT se ha integrado con los motores de juegos heredados más utilizados, como Unity, que a menudo sirven como front-end de los juegos. Por supuesto, esto también incluye otros motores de juegos de código abierto y queridos como Godot y Phaser. Incluso estamos trabajando con un cliente de juego actualizado, Turbo, que se centra en mejorar la experiencia de los desarrolladores independientes y facilitar la creación rápida de juegos. Es posible que haya más socios en el futuro.
Comenzaré aquí y continuaré explicando por qué necesitamos un sistema de componentes de entidad ECS. La respuesta es sencilla, porque permite la máxima componibilidad, lo que significa que podemos crear y reutilizar componentes ya preparados.
Como su nombre indica, ECS se basa en tres elementos principales: entidades, que son esencialmente identificadores que se registran en una instancia separada del mundo del juego, componentes, que definen la estructura de datos para que sean básicamente los datos asociados con la entidad y, finalmente, el sistema, que es la lógica que manipula los componentes adjuntos a la entidad.
La ventaja de esta arquitectura es que todos los sistemas y componentes son reutilizables. Se pueden publicar en un registro público, y los desarrolladores pueden contribuir, construir, descubrir e integrar fácilmente cualquier tipo de componente, por lo que ya no tiene que escribir una sola línea de código desde cero, sino que puede reutilizar todos los componentes existentes y, finalmente, contribuir a ellos. Por ejemplo, podemos tener una estructura de datos de cuadrícula (como un laberinto o un campo de batalla), un sistema en movimiento o un sistema de prueba de conocimiento cero para la niebla de guerra.
04.Práctica de programación de ECS del motor BOLT
(Nota del traductor: Esta parte se recomienda para que los desarrolladores vean el video original, los no desarrolladores pueden omitir esta parte)
AHORA, VOY A CAMBIAR A MI IDE Y MOSTRARTE UN EJEMPLO DE JUEGO SIMPLE USANDO EL MOTOR BOLT ECS.
Definiremos varias entidades, un componente de ubicación y dos sistemas que manipularán y cambiarán los datos de este componente de ubicación. Por lo tanto, el primer punto de entrada es interactuar con el Programa Mundial. El Programa Mundial forma parte del marco BOLT y expone algunas extracciones que permiten registrar nuevas Instancias Mundiales.
Puede agregar entidades a su instancia mundial y puede registrar componentes con las entidades que acaba de definir, que son esencialmente definidas por el programa de componentes. El programa de componentes contiene dos directivas, la primera de las cuales es inicializar, crear y asignar espacio para almacenar filas de datos que se utilizarán en el componente. En este sencillo ejemplo, estamos definiendo un componente de ubicación, y si nos fijamos en el contexto de la directiva de inicialización, podemos ver que tenemos datos de componentes, y los datos de componentes solo definen una estructura con coordenadas XYZ que puede almacenar, por ejemplo, la ubicación del jugador.
Ahora bien, la segunda directiva es probablemente la más interesante, es un punto de entrada que nos permite ejecutar cualquier lógica. Recibirá nuestros componentes y sistemas arbitrarios como entradas, y ejecutará la lógica definida internamente en el sistema mediante la ejecución a través de ubicaciones de programación. Ahora, si nos fijamos en la línea 15, tenemos nuestra llamada CPI (Common Programming Interface), que ejecutará la lógica definida internamente a través del CPI. Realizará todos los cálculos definidos por el sistema y luego regresará a nuestra ubicación, donde el programa componente lo recuperará y lo volverá a configurar en nuestros datos.
Ahora, tratemos de ver el contexto de nuestra función apply, donde podemos ver que básicamente solo tenemos dos cuentas. La primera es la cuenta que contiene los datos de nuestros componentes, y la segunda es el programa del sistema. Como resultado, un programa del sistema es ahora una interfaz en lugar de un solo programa. Por lo tanto, cualquier programa que se adhiera a nuestra interfaz del sistema BOLT se puede ejecutar a través de esta aplicación.
05.Importancia del sistema ECS
Esencialmente, esto cambia la forma en que diseñas la lógica de tu juego y le da la vuelta a los procesos tradicionales. Anteriormente, si querías crear o encapsular alguna lógica en tu programa, normalmente añadías primero características, cada una de las cuales era una directiva en el programa, y luego, finalmente, en algún momento, bloqueabas el programa de juego que estabas desarrollando.
Con el modelo ECS, sin embargo, podemos tener un programa inmutable desde el principio, y luego, con este mecanismo proxy, podemos agregar un sistema construido internamente o por cualquiera, de modo que podamos tener un juego que pueda ejecutarse para siempre, que sea escalable y que cualquiera pueda cambiar realmente la lógica del juego.
Pueden implementar nuevos sistemas que operarán en esos componentes. Ahora, la interfaz también permite hacer algunas comprobaciones, por lo que podemos diseñar una mecánica de juego que haga que no haya permisos para añadir nuevos sistemas que puedan modificar los datos de los componentes.
O podemos configurar una interfaz para comprobar si el sistema permite la ejecución en el componente. Por ejemplo, puedes diseñar un sistema de gobernanza en el que si alguien propone una nueva lógica y esa lógica se aprueba, todos los jugadores puedan usar esa lógica en el juego.
Esto puede incluso llevar a una bifurcación en el mundo del juego (el Contrato Mundial). En un mundo, tú eres el dueño del sistema de vuelo. Y en otro mundo, si el sistema no se aprueba, es posible tener reglas diferentes y cada uno podrá seguir contribuyendo a su propia versión del mundo.
Ahora veamos cómo construir un sistema que pueda modificar ese componente. El sistema es esencialmente un programa en Solana que define una instrucción de ejecución, y la instrucción de ejecución es la que llamamos desde el programa componente en el CPI (Common Programming Interface). Aquí, simplemente encapsula una lógica muy simple en la que recibe la dirección de entrada, calcula el delta y luego cambia las posiciones X e Y del componente.
Así que echemos un vistazo a otro sistema que podría ser implementado por otra persona, incluso después de que lancemos el juego. Este es otro ejemplo de un sistema que implementa ute. Aquí, la posición Z se incrementa en 1, por lo que alguien está tratando de agregar un sistema de flanqueo, que podría ser una interfaz con una capa diferente en la parte superior de su juego.
Entonces, la idea ahora es que todos estos sistemas, todos estos componentes sean realmente componibles, los usuarios del juego ya no sean simples usuarios, el juego se ha convertido en una plataforma abierta, escalable y persistente. Así que voy a intentar ejecutar las pruebas unitarias que preparé en este ejemplo, y voy a usar la CLI de BOLT, que se basa en Anchor, un marco de contrato inteligente para Solana, por lo que si ya estás familiarizado con Solana, no necesitas aprender nada nuevo.
Ahora, puedes desarrollar programas en Solana, solo desarrollar programas, probar programas, así que aquí estoy ejecutando bolt build y bolt test, y aquí estoy implementando nuestro programa, y luego estoy haciendo la prueba de tipo que he preparado aquí.
Entonces, aquí la prueba es enviar una transacción para inicializar un nuevo mundo. Estamos registrando un par de entidades, estamos adjuntando componentes de ubicación a algunas de ellas, y luego tal vez la parte interesante es hacer algunos sistemas aquí. Entonces, aquí estamos llamando a la función apply, y luego estamos usando uno de esos sistemas. Entonces, aquí hay solo un sistema predeterminado.
Aquí estamos llamando a un movimiento simple, y luego estamos volando un movimiento aquí. Bien, ahora, si nos fijamos en los logaritmos de la prueba, en la primera operación, aquí usamos un sistema de movimiento con dirección ascendente, aumentando la posición Y en 1. En la segunda transacción, usamos el mismo sistema para movernos hacia la derecha, y luego, finalmente, ejecutamos el sistema de vuelo, que está haciendo lo contrario, aumentando nuestra posición Z en 1. Es solo un ejemplo simple, pero ofrece una mecánica muy poderosa que permite a cualquiera desarrollar, expandir y potencialmente hacer que su juego sea divertido.
06.Rollup efímero
Ahora que vamos a volver a la diapositiva, voy a describir el segundo aspecto interesante del framework BOLT, que es nuestra solución de escalabilidad, que llamamos Ephemeral Rollup.
En general, se asume que Solana ya es muy rápido y barato, y que actualmente genera un bloque cada 400 milisegundos y puede procesar miles de transacciones, por lo que en realidad está listo para construir un juego de cadena completa. Sin embargo, si tiene una cadena lógica antigua para el modo multijugador, las actualizaciones de ubicación serán demasiado lentas.
Por lo tanto, podemos construir una capa de aceleración de corta duración que sea totalmente compatible con el tiempo de ejecución de Solana. El tiempo utilizado es opcional, puede servir como una aceleración real de una operación en particular, mientras que la mayor parte de la lógica aún se ejecuta en la cadena principal, por lo que confía en la característica de que todo el estado en Solana se almacena en la cuenta.
Normalmente, tendrás un programa de juego que define la lógica, y luego todo el estado se almacenará en esta cuenta, por lo que podemos delegar algunas de esas cuentas a esta capa efímera que utiliza el motor BOLT.
En este ejemplo, hay dos cuentas autorizadas que almacenan la ubicación del reproductor y el proveedor está escuchando activamente las solicitudes de delegación y las solicitudes de aprovisionamiento. Va a iniciar un nuevo tiempo de ejecución según sea necesario, que es rápido, personalizable, no puede tener transacciones de gas ni ticks, y nos permite realizar transacciones por debajo de 50 ms, y tal vez escalar al tener múltiples tiempos de ejecución dedicados.
Ahora, la otra parte interesante es que toda esta complejidad se puede abstraer lejos del usuario. Tenemos un router RPC, que es esencialmente similar a un router RPC tradicional. El cliente RPC puede interactuar directamente con el RPC para enviar transacciones. Debido a que en Solana, todas las transacciones se declaran previamente para todas las cuentas mutables y legibles, los enrutadores RPC pueden esencialmente enrutar transacciones, consultas de datos y recuperación al nivel correcto.
Luego, en algún momento, la capa Efímera (como su nombre indica) se cerrará y todos los estados se liquidarán en la capa base de Solana, que es responsabilidad del secuenciador, que realiza un seguimiento de todas las cuentas.
Otra forma de ver este mecanismo es que tenemos dos capas, y ejecutan transacciones en paralelo. Hemos delegado cuentas que nos permiten actualizar con menor latencia sin utilizar el rendimiento de la cadena principal. Y luego tenemos otras cuentas, que no están delegadas, y se ejecutan en la cadena principal.
Ahora, una cosa muy interesante es que los programas, las herramientas, los marcos y la infraestructura están todos en la cadena principal. No es necesario implementar el programa en Rollup, aunque esto es común en muchas otras arquitecturas. Todo está en la misma capa, todo es componible y, como mencionamos, este runtime especializado también es extensible y se puede personalizar realmente.
Ahora, esto desbloquea una categoría completamente nueva de juegos, que se basa en la cadena de bloques y es de baja latencia. Al igual que lo harías con un servidor multijugador tradicional, pero aún así capaz de combinarse con todo lo disponible en el ecosistema de capa 1.
Obtiene acceso a la liquidez existente, puede enviar mensajes a través de protocolos, acuñar NFT, usar abstracciones de cuentas, claves de sesión, tablas de clasificación y un ecosistema unificado, todos están enriqueciendo el mismo ecosistema.
Muchas gracias por escucharnos. Puede registrarse para obtener acceso anticipado a nuestro marco utilizando códigos QR y consultar el repositorio. Ya puede encontrar documentación sólida y documentos técnicos que describen en detalle el marco que acabamos de presentar. Muchas gracias.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
BOLT: Motor de juego de cadena completa ECS basado en Solana
Enlaces de video:
Ponentes: Andrea, Gabriele, cofundador de Magicblock
演讲标题:UN MARCO PARA JUEGOS EN CADENA
Prefacio del traductor: "BOLT es un motor de juego de cadena completa desarrollado por el equipo de Magicblock para el ecosistema Solana. Este artículo se recopila a partir de las presentaciones de los dos fundadores de Magicblock en el evento Breakpoint 2023. "
Hola a todos, este es el último discurso antes de Halloween, y espero que el contenido del discurso sea interesante para todos. Mi nombre es Andrea y soy mi cofundadora, Gabriele. Hoy, vamos a presentar un nuevo marco de juego de cadena completa (motor).
01.¿Por qué necesitas un juego de cadena completa
Voy a empezar por lo básico, por lo que me molesto en crear un juego de cadena completa con estado y lógica en la cadena, y lidiar con todas las complejidades que conlleva. La razón simple es obtener características que la infraestructura de juegos tradicional no tiene.
La primera característica son los mods sin permisos. Esto significa que todos los jugadores y desarrolladores pueden personalizar cualquier componente del juego, incluida la introducción de plugins o mods, a partir del cliente avanzado. Incluso la lógica subyacente del juego se puede extender a través de contratos inteligentes. Esencialmente, es un nuevo modo en el que cada juego es una nueva plataforma de forma predeterminada, y puedes convertirte en una potencia de contenido sin importar cuán pequeño sea tu equipo.
La segunda característica es la persistencia. Los mundos autónomos y el hecho de que estas experiencias virtuales puedan existir para siempre han causado muchas repercusiones. Debido a que ningún servidor puede ser censurado o cerrado, estas experiencias en realidad introducen un significado completamente nuevo. Los juegos se han convertido en una plataforma para que los jugadores jueguen, socialicen y realicen comercio global, que es más universal que las plataformas de juegos tradicionales.
La última característica son las economías abiertas. Los juegos pueden aprovechar el sistema de pago global abierto y sin fricciones de blockchain, especialmente los micropagos en nuestro ecosistema, y reutilizar la infraestructura existente en la cadena, como los DEX o los mercados NFT.
02.Solución existente
El problema actual con los juegos omnichain es que la experiencia de desarrollo es muy mala, y miramos las soluciones en el mercado y encontramos que hay algunos marcos de desarrollo que intentan simplificar la experiencia del desarrollador.
Algunos de ellos son muy interesantes en el sentido de que intentan iterar en sesiones demostrables, donde se pueden hacer cálculos fuera de la cadena y demostrar la integridad de los cálculos en la cadena. O introduzca un tiempo de ejecución basado en eventos que sea más adecuado para los motores de juegos de blockchain, en lugar de un tiempo de ejecución basado en bucles.
Sin embargo, todos estos marcos requieren compensaciones entre el rendimiento y la componibilidad para lograr un mayor rendimiento y un TPS más alto. Normalmente, creará un aislamiento o introducirá un entorno de ejecución diferente con particiones.
Pero no estamos contentos con esa compensación. Nos preguntamos, ¿qué pasaría si hubiera un marco que pudiera soportar el TPS que necesitábamos? Cuando tu juego tiene éxito, no tienes que sacrificar su experiencia de usuario, incluso con millones de jugadores, porque las guerras de gas no ocurrirán. Y el marco no requiere fragmentación ni fragmentación, por lo que puede usar sesiones de juego demostrables e incluso simular el paso del tiempo sin pagar tarifas de gas. No es necesario fragmentar el sistema ni utilizar la capa 3 en absoluto.
03.Motor de desarrollo de juegos de cadena completa en Solana: BOLT
Es por eso que nos complace presentar BOLT, un marco de desarrollo de juegos de cadena completa, componible y de alto rendimiento basado en SVM.
BOLT es modular y componible, lo que le permite utilizar toda la infraestructura existente en Solana. Trabaja con nuestras instalaciones existentes en la cadena, como la identidad en la cadena, la API sin gas, la clave de sesión, así como el marco de desarrollo Anchor existente y todos los programas existentes en Solana. Ambos pueden escalar en un orden de magnitud superior gracias a los Ephemeral Rollups, que son sesiones de juego que se abren y cierran según lo exija el usuario, y se escalan según sea necesario.
BOLT es ultrarrápido y podemos lograr el mismo nivel de rendimiento que un motor de juego tradicional antes de usar estos tiempos de ejecución dedicados para acelerar ciertas operaciones.
Esta es una pantalla panorámica del marco BOLT. Obviamente, está construido para Solana, pero puede usarlo en cualquier plataforma compatible con SVM, como la capa 2 compatible con SVM. BOLT tiene dos objetivos principales, la componibilidad y la escalabilidad.
El sistema ECS (Entity Component) es una de las formas en que simplificamos el uso de los componentes en cadena. El otro es el Ephemeral Rollup, que se ha mencionado brevemente anteriormente, y me sumergiré en ambas tecnologías en un momento.
BOLT se ha integrado con los motores de juegos heredados más utilizados, como Unity, que a menudo sirven como front-end de los juegos. Por supuesto, esto también incluye otros motores de juegos de código abierto y queridos como Godot y Phaser. Incluso estamos trabajando con un cliente de juego actualizado, Turbo, que se centra en mejorar la experiencia de los desarrolladores independientes y facilitar la creación rápida de juegos. Es posible que haya más socios en el futuro.
Comenzaré aquí y continuaré explicando por qué necesitamos un sistema de componentes de entidad ECS. La respuesta es sencilla, porque permite la máxima componibilidad, lo que significa que podemos crear y reutilizar componentes ya preparados.
Como su nombre indica, ECS se basa en tres elementos principales: entidades, que son esencialmente identificadores que se registran en una instancia separada del mundo del juego, componentes, que definen la estructura de datos para que sean básicamente los datos asociados con la entidad y, finalmente, el sistema, que es la lógica que manipula los componentes adjuntos a la entidad.
La ventaja de esta arquitectura es que todos los sistemas y componentes son reutilizables. Se pueden publicar en un registro público, y los desarrolladores pueden contribuir, construir, descubrir e integrar fácilmente cualquier tipo de componente, por lo que ya no tiene que escribir una sola línea de código desde cero, sino que puede reutilizar todos los componentes existentes y, finalmente, contribuir a ellos. Por ejemplo, podemos tener una estructura de datos de cuadrícula (como un laberinto o un campo de batalla), un sistema en movimiento o un sistema de prueba de conocimiento cero para la niebla de guerra.
04.Práctica de programación de ECS del motor BOLT
(Nota del traductor: Esta parte se recomienda para que los desarrolladores vean el video original, los no desarrolladores pueden omitir esta parte)
AHORA, VOY A CAMBIAR A MI IDE Y MOSTRARTE UN EJEMPLO DE JUEGO SIMPLE USANDO EL MOTOR BOLT ECS.
Definiremos varias entidades, un componente de ubicación y dos sistemas que manipularán y cambiarán los datos de este componente de ubicación. Por lo tanto, el primer punto de entrada es interactuar con el Programa Mundial. El Programa Mundial forma parte del marco BOLT y expone algunas extracciones que permiten registrar nuevas Instancias Mundiales.
Puede agregar entidades a su instancia mundial y puede registrar componentes con las entidades que acaba de definir, que son esencialmente definidas por el programa de componentes. El programa de componentes contiene dos directivas, la primera de las cuales es inicializar, crear y asignar espacio para almacenar filas de datos que se utilizarán en el componente. En este sencillo ejemplo, estamos definiendo un componente de ubicación, y si nos fijamos en el contexto de la directiva de inicialización, podemos ver que tenemos datos de componentes, y los datos de componentes solo definen una estructura con coordenadas XYZ que puede almacenar, por ejemplo, la ubicación del jugador.
Ahora bien, la segunda directiva es probablemente la más interesante, es un punto de entrada que nos permite ejecutar cualquier lógica. Recibirá nuestros componentes y sistemas arbitrarios como entradas, y ejecutará la lógica definida internamente en el sistema mediante la ejecución a través de ubicaciones de programación. Ahora, si nos fijamos en la línea 15, tenemos nuestra llamada CPI (Common Programming Interface), que ejecutará la lógica definida internamente a través del CPI. Realizará todos los cálculos definidos por el sistema y luego regresará a nuestra ubicación, donde el programa componente lo recuperará y lo volverá a configurar en nuestros datos.
Ahora, tratemos de ver el contexto de nuestra función apply, donde podemos ver que básicamente solo tenemos dos cuentas. La primera es la cuenta que contiene los datos de nuestros componentes, y la segunda es el programa del sistema. Como resultado, un programa del sistema es ahora una interfaz en lugar de un solo programa. Por lo tanto, cualquier programa que se adhiera a nuestra interfaz del sistema BOLT se puede ejecutar a través de esta aplicación.
05.Importancia del sistema ECS
Esencialmente, esto cambia la forma en que diseñas la lógica de tu juego y le da la vuelta a los procesos tradicionales. Anteriormente, si querías crear o encapsular alguna lógica en tu programa, normalmente añadías primero características, cada una de las cuales era una directiva en el programa, y luego, finalmente, en algún momento, bloqueabas el programa de juego que estabas desarrollando.
Con el modelo ECS, sin embargo, podemos tener un programa inmutable desde el principio, y luego, con este mecanismo proxy, podemos agregar un sistema construido internamente o por cualquiera, de modo que podamos tener un juego que pueda ejecutarse para siempre, que sea escalable y que cualquiera pueda cambiar realmente la lógica del juego.
Pueden implementar nuevos sistemas que operarán en esos componentes. Ahora, la interfaz también permite hacer algunas comprobaciones, por lo que podemos diseñar una mecánica de juego que haga que no haya permisos para añadir nuevos sistemas que puedan modificar los datos de los componentes.
O podemos configurar una interfaz para comprobar si el sistema permite la ejecución en el componente. Por ejemplo, puedes diseñar un sistema de gobernanza en el que si alguien propone una nueva lógica y esa lógica se aprueba, todos los jugadores puedan usar esa lógica en el juego.
Esto puede incluso llevar a una bifurcación en el mundo del juego (el Contrato Mundial). En un mundo, tú eres el dueño del sistema de vuelo. Y en otro mundo, si el sistema no se aprueba, es posible tener reglas diferentes y cada uno podrá seguir contribuyendo a su propia versión del mundo.
Ahora veamos cómo construir un sistema que pueda modificar ese componente. El sistema es esencialmente un programa en Solana que define una instrucción de ejecución, y la instrucción de ejecución es la que llamamos desde el programa componente en el CPI (Common Programming Interface). Aquí, simplemente encapsula una lógica muy simple en la que recibe la dirección de entrada, calcula el delta y luego cambia las posiciones X e Y del componente.
Así que echemos un vistazo a otro sistema que podría ser implementado por otra persona, incluso después de que lancemos el juego. Este es otro ejemplo de un sistema que implementa ute. Aquí, la posición Z se incrementa en 1, por lo que alguien está tratando de agregar un sistema de flanqueo, que podría ser una interfaz con una capa diferente en la parte superior de su juego.
Entonces, la idea ahora es que todos estos sistemas, todos estos componentes sean realmente componibles, los usuarios del juego ya no sean simples usuarios, el juego se ha convertido en una plataforma abierta, escalable y persistente. Así que voy a intentar ejecutar las pruebas unitarias que preparé en este ejemplo, y voy a usar la CLI de BOLT, que se basa en Anchor, un marco de contrato inteligente para Solana, por lo que si ya estás familiarizado con Solana, no necesitas aprender nada nuevo.
Ahora, puedes desarrollar programas en Solana, solo desarrollar programas, probar programas, así que aquí estoy ejecutando bolt build y bolt test, y aquí estoy implementando nuestro programa, y luego estoy haciendo la prueba de tipo que he preparado aquí.
Entonces, aquí la prueba es enviar una transacción para inicializar un nuevo mundo. Estamos registrando un par de entidades, estamos adjuntando componentes de ubicación a algunas de ellas, y luego tal vez la parte interesante es hacer algunos sistemas aquí. Entonces, aquí estamos llamando a la función apply, y luego estamos usando uno de esos sistemas. Entonces, aquí hay solo un sistema predeterminado.
Aquí estamos llamando a un movimiento simple, y luego estamos volando un movimiento aquí. Bien, ahora, si nos fijamos en los logaritmos de la prueba, en la primera operación, aquí usamos un sistema de movimiento con dirección ascendente, aumentando la posición Y en 1. En la segunda transacción, usamos el mismo sistema para movernos hacia la derecha, y luego, finalmente, ejecutamos el sistema de vuelo, que está haciendo lo contrario, aumentando nuestra posición Z en 1. Es solo un ejemplo simple, pero ofrece una mecánica muy poderosa que permite a cualquiera desarrollar, expandir y potencialmente hacer que su juego sea divertido.
06.Rollup efímero
Ahora que vamos a volver a la diapositiva, voy a describir el segundo aspecto interesante del framework BOLT, que es nuestra solución de escalabilidad, que llamamos Ephemeral Rollup.
En general, se asume que Solana ya es muy rápido y barato, y que actualmente genera un bloque cada 400 milisegundos y puede procesar miles de transacciones, por lo que en realidad está listo para construir un juego de cadena completa. Sin embargo, si tiene una cadena lógica antigua para el modo multijugador, las actualizaciones de ubicación serán demasiado lentas.
Por lo tanto, podemos construir una capa de aceleración de corta duración que sea totalmente compatible con el tiempo de ejecución de Solana. El tiempo utilizado es opcional, puede servir como una aceleración real de una operación en particular, mientras que la mayor parte de la lógica aún se ejecuta en la cadena principal, por lo que confía en la característica de que todo el estado en Solana se almacena en la cuenta.
Normalmente, tendrás un programa de juego que define la lógica, y luego todo el estado se almacenará en esta cuenta, por lo que podemos delegar algunas de esas cuentas a esta capa efímera que utiliza el motor BOLT.
En este ejemplo, hay dos cuentas autorizadas que almacenan la ubicación del reproductor y el proveedor está escuchando activamente las solicitudes de delegación y las solicitudes de aprovisionamiento. Va a iniciar un nuevo tiempo de ejecución según sea necesario, que es rápido, personalizable, no puede tener transacciones de gas ni ticks, y nos permite realizar transacciones por debajo de 50 ms, y tal vez escalar al tener múltiples tiempos de ejecución dedicados.
Ahora, la otra parte interesante es que toda esta complejidad se puede abstraer lejos del usuario. Tenemos un router RPC, que es esencialmente similar a un router RPC tradicional. El cliente RPC puede interactuar directamente con el RPC para enviar transacciones. Debido a que en Solana, todas las transacciones se declaran previamente para todas las cuentas mutables y legibles, los enrutadores RPC pueden esencialmente enrutar transacciones, consultas de datos y recuperación al nivel correcto.
Luego, en algún momento, la capa Efímera (como su nombre indica) se cerrará y todos los estados se liquidarán en la capa base de Solana, que es responsabilidad del secuenciador, que realiza un seguimiento de todas las cuentas.
Otra forma de ver este mecanismo es que tenemos dos capas, y ejecutan transacciones en paralelo. Hemos delegado cuentas que nos permiten actualizar con menor latencia sin utilizar el rendimiento de la cadena principal. Y luego tenemos otras cuentas, que no están delegadas, y se ejecutan en la cadena principal.
Ahora, una cosa muy interesante es que los programas, las herramientas, los marcos y la infraestructura están todos en la cadena principal. No es necesario implementar el programa en Rollup, aunque esto es común en muchas otras arquitecturas. Todo está en la misma capa, todo es componible y, como mencionamos, este runtime especializado también es extensible y se puede personalizar realmente.
Ahora, esto desbloquea una categoría completamente nueva de juegos, que se basa en la cadena de bloques y es de baja latencia. Al igual que lo harías con un servidor multijugador tradicional, pero aún así capaz de combinarse con todo lo disponible en el ecosistema de capa 1.
Obtiene acceso a la liquidez existente, puede enviar mensajes a través de protocolos, acuñar NFT, usar abstracciones de cuentas, claves de sesión, tablas de clasificación y un ecosistema unificado, todos están enriqueciendo el mismo ecosistema.
Muchas gracias por escucharnos. Puede registrarse para obtener acceso anticipado a nuestro marco utilizando códigos QR y consultar el repositorio. Ya puede encontrar documentación sólida y documentos técnicos que describen en detalle el marco que acabamos de presentar. Muchas gracias.