¿Cómo sincronizar el "estado" de todo el juego en cadena?

Por Fiona, IOSG Ventures

TL;DR

*La cadena completa de juegos/mundos autónomos (“FOG/AW”) es una de las pocas narrativas importantes que rodean a Web 3. En comparación con las aplicaciones Web2.5 que solo se conectan a Web3 a través de NFT, FOG/AW pone la lógica del juego en la cadena. Utiliza blockchain como servidor de juegos, convirtiéndose en una fuente descentralizada de confianza para el estado del juego. Esto trae ventajas como la persistencia, la resistencia a la censura, la composición, etc., pero también limita la variedad y complejidad de los juegos construidos sobre él.

• Con la creciente complejidad y los requisitos de jugabilidad del juego, se presentan más desafíos para la arquitectura del motor: como retraso de fotogramas, número aleatorio, recuperación de salud, efecto pasivo continuo, temporizador, etc. El concepto de unidades de tiempo y Ticks son diferentes en la cadena de bloques. Mud proporciona muchas ideas para simular el paso del tiempo y habilidades de recuperación pasiva. Por ejemplo, cuando el jugador se mueve en la habitación, la transacción consiste en mover todos los elementos de la habitación de acuerdo con un diseño predefinido. Use esto para percibir cambios en el tiempo y el estado.
• La pila de tecnología FOG/AW se puede resumir como: los desarrolladores escriben códigos front-end y back-end para ui/ux y la lógica central del juego, luego sincronizan todos los cambios a través del bucle de estado del juego y finalmente reflejan el nuevo estado en el dispositivo local front-end mediante el indexador.
• Dado que muchos tipos de juegos, como RTS, requieren altas tasas de ticks, y las cadenas de bloques producidas por consenso solo pueden manejar cambios en los tiempos de bloque, la tasa de ticks es un gran problema que debe resolverse aquí. Curio y Argus son líderes en este sentido y están aumentando el tickrate del juego en el nivel de la cadena de balones sueltos. Mud intenta maximizar la cadena completa y todo el estado de la aplicación se almacena en el EVM. No hay ningún plan para introducir la integración fuera de la cadena para lograr una mayor tasa de ticks para el juego.
• Para la selección de diferentes cadenas, Dojo lidera toda la ecología de cadenas de Starknet. De acuerdo con la descripción de @tarrenceva, Starknet tiene diferencias de estado, que son diferentes de los resúmenes optimistas y se centran en la salida de ejecución en lugar de la entrada. Es probable que el impacto en los juegos principalmente optimice el costo, por ejemplo, un juego de ajedrez: en un juego de tres minutos, pueden ocurrir 50 movimientos. A través de las diferencias de estado, una prueba única y el estado final pueden probar la “salida”. Los paquetes acumulativos optimistas, por otro lado, requieren “entradas” de todos los estados intermedios.

Definir FOG/AW: cómo se sincroniza el estado del juego

Creo que para juzgar si es FOG, el punto de referencia es cómo se sincroniza el estado del juego (fuente de la verdad).

Para juegos Web 2.5 o juegos multijugador tradicionales, hay un servidor centralizado que define el estado actual del juego, y cuando los jugadores envían acciones, el servidor recopila estas entradas y devuelve resultados actualizados al dispositivo de cada jugador conectado. El servidor maneja todas las entradas (ticks), resuelve inconsistencias y periódicamente envía actualizaciones al jugador, brindando una instantánea de todos los elementos en el juego, actualizando el estado del juego en cada tick. El **estado del juego (“estado del juego o marca”) es una instantánea en el tiempo de las propiedades de cada objeto en el mundo del juego. Tickrate es la cantidad de veces por segundo que el servidor del juego calcula y transmite el estado actualizado del juego a los jugadores. Cuanto mayor sea el Tickrate, más precisa y de alta fidelidad será la experiencia de juego. En general, la estrategia en tiempo real o los juegos de acción requieren un alto nivel de exigencia. tickrate, mientras que los juegos por turnos, como los juegos de cartas, no.

Fuente:

Para los juegos que se ejecutan completamente en cadena, la cadena de bloques es el servidor del juego y actúa como una fuente de confianza descentralizada para el estado del juego. En este caso, no solo los NFT o tokens tienen propiedad real, sino que incluso los ticks del jugador y la lógica del juego están en cadena. Es por eso que la verdadera propiedad, la persistencia, la resistencia a la censura, la composición y más son posibles. Idealmente, cada acción de un jugador debe enviarse a la cadena de bloques y, una vez que se alcanza un consenso, el estado del juego se actualiza y se devuelve al dispositivo local. Entonces, naturalmente, los tipos de juegos que requieren menos tickrate son más adecuados para jugar completamente en cadena.

** Resuelve los desafíos de retraso del juego, tiempo, etc. **

Con el aumento de la complejidad del juego y los requisitos de jugabilidad, se presentan más desafíos para la arquitectura del motor: como retraso de cuadro, números aleatorios, recuperación de vida, efectos pasivos continuos, temporizadores, etc.

Retraso en el número de cuadro De hecho, también es muy común en el mundo Web2, incluidos los retrasos en la representación del cliente y las operaciones del usuario. Especialmente para juegos de alta tasa de ticks como FPS, una vez que hay un retraso, la experiencia del jugador será muy pobre. Una de las soluciones en Web2 es la actualización de estado de bloqueo, que permite que todos los jugadores se sincronicen de acuerdo con el estándar de retraso más alto entre los jugadores, para resolver la experiencia justa del jugador. Este retraso puede ser aún peor cuando se introduce la cadena de bloques y es necesario confirmar las transacciones. Con este fin, Mud también agrega el mecanismo de representación optimista que se usa comúnmente en los juegos, asumiendo que la operación del usuario es exitosa y la presenta en el cliente antes de que el servidor esté de acuerdo (o en este caso, antes de que se confirme la transacción).

Generar números aleatorios en la cadena es un tema que se discute a menudo. Mud cree que el comportamiento del usuario puede usarse como entrada de resultados aleatorios, que pueden generarse después de que ocurra la interacción.

El concepto de unidades de tiempo y Ticks son diferentes en la cadena de bloques. @SebastienGllmt cree que es difícil usar temporizadores en cadenas que usan conceptos a prueba de fraude (como Op), porque una vez que algo sale mal, será necesario revertirlo. Si se usan temporizadores en el juego, la experiencia será deficiente. Mud proporciona muchas ideas para simular el paso del tiempo y habilidades de recuperación pasiva. Por ejemplo, aumentando las monedas de oro con el tiempo, cada vez que el jugador realiza una operación que requiere monedas de oro, calcule la cantidad de monedas de oro del jugador en función del recuento de monedas de oro anterior del jugador, el último recuento de actualización y la frecuencia de actualización. Para otro ejemplo, cuando el jugador se mueve en la habitación, la transacción consiste en mover todos los elementos de la habitación de acuerdo con un diseño predefinido. Use esto para percibir cambios en el tiempo y el estado.

** Escribir guiones para “hacer trampa” puede no ser un problema. **@BriefKandle no cree que MEV del sistema de juego sea una trampa. Evitar MEV con scripts simples es algo que el equipo del juego debe considerar. El desarrollo del juego Web2 debe cambiar la forma de pensar. Un buen robot MEV es un NPC en el juego.

Parte de esta funcionalidad se ha implementado en algunos juegos en cadena lanzados recientemente, como Rhascau, donde usan temporizadores y efectos pasivos continuos. Básicamente usando el tiempo de bloque como un tic. (En L2 actual, tiempo de bloque = tasa de ticks).

Pila de tecnología FOG/AW

El marco del motor FOG/AW es una pila de herramientas para desarrolladores que permite a los desarrolladores crear juegos utilizando la cadena de bloques como servidor y fuente de confianza. Además, puede solucionar algunos problemas actuales:

• Ineficiencia en la construcción de FOG/AW en cadena debido a la falta de un marco estándar/listo para usar;
• Falta de modularidad y reutilización de código;
• Falta de componibilidad. Con el desarrollo del motor FOG/AW, los juegos en cadena pueden ser más interesantes e imaginativos.

Para facilitar la comprensión, el proceso técnico generalmente simplificado de este tipo de motor es: los desarrolladores escriben códigos front-end y back-end para ui/ux y la lógica central del juego, y luego sincronizan todos los cambios a través del bucle del estado del juego y finalmente reflejan el nuevo estado en el dispositivo local front-end mediante el indexador.

Para que los juegos que se ejecutan en blockchain funcionen sin problemas, Mud, Dojo, Curio, Argus, Paima Engine y Lootchain están desarrollando sus propias pilas de tecnología para este propósito. La pila de tecnología consta de 3 partes clave: cadena, pila de desarrollo central y front-end del juego. Todos tienen sus propias innovaciones, haciendo concesiones entre la descentralización y la complejidad del juego.

• Front-end del juego: contiene motores tradicionales como Unity, Unreal, etc. y react/Threejs y otros lenguajes y herramientas poderosas para proporcionar renderizado y otras funciones, lo cual es una parte indispensable para mejorar la jugabilidad y la experiencia del juego. Los proyectos anteriores básicamente pueden proporcionar SDK relevantes para que los usen los desarrolladores.
• Pila de desarrollo principal: diseñe un conjunto de soluciones para permitir que la lógica del juego se ejecute en la cadena de bloques y se sincronice con el front-end a tiempo. Los componentes clave incluyen una estructura de base de datos adecuada (que define el comportamiento y la lógica del juego) y la sincronización y el retorno del estado del juego.
• Cadena: la mayoría elige construir sobre Ethereum, Optimism y Starknet.

La siguiente figura muestra cómo los diferentes protocolos diseñan sus respectivas pilas de tecnología. Tome Mud V2 como ejemplo para ver su flujo de operación:

1. Un desarrollador llamará a algunas herramientas front-end de Web2 en Mud para escribir código y usará estas potentes funciones, como el renderizado, para hacer que el juego sea más visual y más divertido;
2. Al mismo tiempo, los desarrolladores escribirán los personajes, elementos y la lógica operativa específica del juego de acuerdo con el marco de contrato inteligente de Mud (Mud World), como cuando el héroe A se mueve de X a Y e inicia una cruzada contra la tierra Y, qué probabilidad o bajo qué circunstancias se puede ocupar la tierra con éxito;
3. Las acciones anteriores y el estado del juego se registrarán en Mud Store, que es una base de datos en cadena responsable del estado global del juego y una fuente de confianza para la sincronización del estado del juego;
4. Cuando el héroe A ataca a Y, el jugador en realidad hace clic con el mouse en la máquina local front-end y envía el comando para que se cargue en la cadena. El comando se basa en la lógica de diseño del juego del desarrollador y el estado actual del juego en la Tienda, lo que da como resultado un resultado. El resultado se actualiza al nuevo estado global del juego y se sincroniza con la cadena;
5. Games on Mud admite varios front-end, como Web y Mobile, pero puede enfrentar requisitos de indexación complejos. Mode es un indexador fuera de la cadena desarrollado para este propósito.

Ahora, hablemos de los diseños comunes y diferentes de estos marcos básicos.

• La mayoría sigue el diseño de Mud v1 y utiliza ECS como estructura de datos para el desarrollo de juegos. Así es como se escribe y presenta la lógica del juego. Mud V2 lo ha mejorado, y los datos se definen en tablas y s, lo que permite otros estándares de datos (no tiene que cumplir con el estándar de modelado de datos ECS como V1), lo que brinda a los desarrolladores más opciones y lo hace más inclusivo.
• La mayoría usa bases de datos descentralizadas, ya que la cadena de bloques es naturalmente la fuente de confianza para el estado del juego y la base de datos. Mud intenta maximizar la cadena completa y todo el estado de la aplicación se almacena en el EVM. No se sacrifica la descentralización ni la introducción de esquemas de integración fuera de la cadena para lograr una mayor tasa de ticks para el juego.
• Dado que muchos tipos de juegos, como FPS, requieren altas tasas de ticks, y las cadenas de bloques producidas por consenso solo pueden manejar cambios en los tiempos de bloqueo, la tasa de ticks es un gran problema que debe resolverse aquí. En sus diseños innovadores, Curio y Argus son los primeros en esperar aumentar las tasas de cotización a nivel de la cadena.
• Para la selección de diferentes cadenas, tanto Curio como Loot usan Caldera para construir cadenas de pilas Op. Además, Dojo lidera toda la ecología de cadenas de Starknet. De acuerdo con la descripción de @tarrenceva, Starknet tiene diferencias de estado, que son diferentes de los resúmenes optimistas y se enfocan en la salida de ejecución en lugar de la entrada. Es probable que el impacto en los juegos principalmente optimice el costo, por ejemplo, un juego de ajedrez: en un juego de tres minutos, pueden ocurrir 50 movimientos. A través de las diferencias de estado, una prueba única y el estado final pueden probar la “salida”. Los paquetes acumulativos optimistas, por otro lado, requieren “entradas” de todos los estados intermedios.

Ya hay algunos juegos creados con estos motores. Tanto Mud como Dojo están organizando hackatones para atraer a los desarrolladores a crear aplicaciones. Curio acaba de lanzar la demostración del minijuego de Warcraft en ETHCC.

Obviamente, FOG/AW se está convirtiendo en una ecología clave para la competencia de las cadenas públicas. El AW (Mundo Autónomo) propuesto por Lattice es un gran concepto, que no se limita a los juegos, sino que también incluye muchos atributos, como los sociales y los financieros. Entonces, construido encima de eso hay un mundo virtual imaginativo, el Metaverso. Podemos esperar algunas formas nuevas de aplicaciones integradas, como juegos, redes sociales y finanzas.

Referencia: