Por Ishanee @IOSG Ventures
Resumen de la premisa:
Brindamos una descripción general de los juegos en cadena y los motores de juegos en la primera parte de la serie FOG, gracias a Sylve, Tarrence, Andy, Alvirus, Kevin e Iain por apoyar este artículo.
Los motores y juegos en cadena aún se encuentran en sus primeras etapas. Aunque los motores de juegos como MUD y Dojo ya se pueden utilizar para el desarrollo de productos y los desarrolladores del ecosistema ya los utilizan, todavía queda un largo camino por recorrer. Los motores de juegos a menudo experimentan enormes efectos de red porque muchos juegos se basan en sus marcos y agregan funcionalidad a los marcos.
En el ecosistema de juegos en cadena, el mayor efecto de red proviene de la componibilidad y escalabilidad de los juegos, y de la combinación de los activos del juego con otros juegos basados en el mismo ecosistema y motor. La rigidez del motor también aumenta exponencialmente a medida que las bibliotecas de código abierto permiten a los desarrolladores resolver problemas técnicos con la ayuda de la comunidad.
Si imaginamos la evolución de los ecosistemas de los motores de juegos, sus efectos de red y capas de acumulación de valor podrían verse así. El mercado de módulos/validadores podría fácilmente ser absorbido por una capa de motor similar al módulo Gnosis Safe. De forma predeterminada, las capas AW son componibles, pero esto depende de la elección del nivel de componibilidad del desarrollador del juego y del jugador. Muchas empresas están intentando capturar 2 o más capas en esta pila.
En este punto, profundicemos en los principales desafíos del desarrollo de juegos en línea y cómo los resuelven los motores de juegos. Problemas que enfrentan los motores de juegos blockchain:
congestión de la red
Cuando se lanzaron Crypto Kitties, Axie Infinity y Loot Realms, todos causaron congestión en toda la red. ¿Cómo lo solucionaron? Crearon sus propias cadenas respectivamente, a saber, Flow, Ronin y Loot Chain. Los juegos en cadena requieren más recursos informáticos y todos los juegos competirán por el espacio del bloque. Por lo tanto, es natural que los equipos de comercialización con apoyo financiero opten por crear su propia capa de extensión L2 específica de la aplicación. Cooperan con proveedores de RaaS (Rollup as a Service) como Caldera, Conduit, Eclipse, Alt Layer, etc. El marco L2 popular actualmente parece ser OP Stack, y esperamos que esto cambie a medida que tecnologías como Arbitrum Orbit, Starkware L3 y ZkSync Hyperchains maduren y estén disponibles para uso en producción.
La cantidad de solicitudes que causaron congestión de la red cuando se lanzó CryptoKitties en diciembre
Argus también presentó su nuevo producto: EVM Layer 2 que se conecta a la capa de disponibilidad de datos. Este es el fragmento base. No conocemos más detalles al respecto, pero nos recuerda al Momoka de Len. La capa base EVM permitirá a otros desarrolladores de juegos crear fragmentos de juego de capa de ejecución altamente personalizables para sus juegos, y el fragmento base será la capa que brindará componibilidad a todo Argus L2.
La lenta velocidad de Blockchain
En blockchain, el estado del contrato no cambiará hasta que se confirme la transacción. Si desea que f (a) active f (b), este proceso solo puede esperar. Por lo tanto, el retraso en el juego parece inevitable. En Ethereum, esto serían 15 segundos hasta que se resuelva el bloqueo y otros 30 a 45 segundos para superar los riesgos de reorganización.
Al usar ticks, el estado del juego se puede cambiar automáticamente sin esperar a que se completen las transacciones. La frecuencia de ticks puede entenderse como la frecuencia de actualización. Los juegos MMO competitivos suelen tener velocidades de tick de 20 a 30 segundos, y los juegos de estrategia en tiempo real pueden tener velocidades de tick de hasta 60 segundos. Hoy en día, la mayoría de los desarrolladores de juegos crean juegos MMO, por lo que una frecuencia de ticks de 20 segundos es ideal. El tiempo promedio de bloqueo en Rollups es de 1 a 2 segundos (Momoka se conecta a Polygon PoS cada 2 segundos) y la nueva solución de Argus tiene una frecuencia de ticks de 20 ticks/segundo, que actualmente es la más rápida de la industria.
El equipo de 0xCurio es el primer equipo comercial que utiliza L2 personalizados (a través de Caldera) para optimizar tasas de ticks más rápidas. Han creado la primera aplicación de cadena de ticks en OP Stack y pueden lanzarla junto con sus juegos como tratado.earth.
Discusiones sobre la frecuencia promedio de ticks de juegos en Internet: la experiencia de los desarrolladores aún debe mejorarse
La historia detrás de MUD es que el equipo de Lattice había estado intentando crear un nuevo juego en cadena y se topó con los mismos problemas de backend. Entonces decidieron crear un marco de desarrollo de juegos en cadena que pudiera adoptarse universalmente. Además de la componibilidad, existen dos desafíos clave: una sincronización de estado más rápida entre los contratos y los clientes del jugador y actualizaciones sencillas (modificación/actualización de contenido) sin tener que reescribir el indexador en cada actualización (indexador automático).
En este artículo, asumiremos que todas las aplicaciones creadas en el mismo marco de motor de juego son componibles.
Introducción al motor de juego
Este artículo analizará cuatro proyectos que compiten por el estatus de estándar de motor de juegos blockchain más grande. Dos de ellos son bienes públicos y los otros dos fueron construidos por equipos comerciales que recaudaron fondos en el pasado. Profundicemos en algunos problemas más avanzados y cómo los resuelven los equipos.
BARRO v2:
MUD es el motor de juegos más popular y proporciona motores de juegos para más del 95% de los juegos en línea en EVM. El motor de juego de Lattice presenta Store, que puede representar datos en cadena de forma similar a una base de datos relacional. Los beneficios de utilizar una tienda en lugar de una tienda impulsada por un compilador son la capacidad de actualización de los datos del contrato y los costos del gas a gran escala.
Las actualizaciones de estado también emiten eventos automáticamente, por lo que el indexador automático puede indexar todo el estado sin necesidad de una configuración personalizada. En comparación con los datos estáticos de Solidity, se pueden agregar nuevos datos (tablas) en tiempo de ejecución, lo que permite la capacidad de actualización. Los costos de almacenamiento son comparables a la emisión manual de eventos para cada estado, pero MUD empaqueta datos de manera más eficiente que Solidity nativo, por lo que es más económico a largo plazo.
Tienda: es otra solución que utiliza almacenamiento sólido controlado por compilador. Almacenar datos en un contrato cuesta Gas y es estático/no inspeccionable en Solidity, lo que significa que las interfaces/aplicaciones deben asumir que las llamadas que realizan son correctas. A través de la base de datos en cadena de la Tienda, el almacén de contratos de una aplicación ahora puede ser indexado mediante un indexador fuera de la cadena, una interfaz u otro contrato. Los beneficios de utilizar Store son la capacidad de actualización de los datos del contrato y la consideración de los costos del gas a gran escala.
Modo: este es un indexador fuera de la cadena que utiliza PostgresDB. Puede indexar cualquier aplicación MUD en el EVM y se utiliza principalmente para una sincronización de estado más rápida con clientes MUD.
Mundo: es un marco, que incluye el uso de almacenamiento, sistema, creación no autorizada, control de acceso, módulos, etc. En resumen, el contrato mundial es un contrato único con estado centralizado y lógica contractual. Se puede ampliar con la ayuda de complementos en cadena y un conjunto mejorado de herramientas para desarrolladores. Cada nuevo complemento introducido en MUD aumenta el valor del marco y el motor para el próximo desarrollador que se una.
Algunos ejemplos:
Endless Quest: genere narrativa, metadatos y arte consistentes en AW
MUDVRF: módulo MUD que genera números aleatorios en cadena en el juego
DeFi Wonderland: use el módulo de administración de cuentas de la billetera a través del cliente grabador
MUD Scan: tablero de clasificación para juegos MUD
Motor Dojo:
Dojo Engine es un motor de juego público desarrollado por los desarrolladores de Starknet. Este es el único motor de juego que es verificable y su verificación es para la arquitectura y las herramientas del motor de juego.
En este caso, la demostrabilidad significa que el mismo bucle del juego se puede probar en el secuenciador del paquete acumulativo o en un cliente local, como un navegador. Con dojo, los usuarios pueden escribir lógica de prueba para ejecutarla en el lado del cliente y realizar solo la verificación en la cadena a un costo muy bajo. Esto también habilita funciones como anti-trampas y actualizaciones optimistas, donde la lógica se implementa en el navegador del jugador incluso si el secuenciador todavía está validando las transacciones del jugador.
Su esquema de almacenamiento de datos es similar al Store de MUD, pero personalizado para las características de demostrabilidad y validez. Utilizan Torii para proporcionar una indexación verificable automáticamente. La indexación se realiza utilizando diferencias de almacenamiento, proporcionando indexación O(1) y admite la verificabilidad del lado del cliente del estado mundial mediante pruebas de almacenamiento. Dojo admite la implementación en Starknet, así como secuenciadores de capa 3 de alto rendimiento como Katana y Madara. Dojo proporciona Katana (una red de desarrollo local), Sozo (una interfaz de línea de comandos para implementar, actualizar e interactuar con juegos) y Torii (un indexador verificable). Dojo proporciona un SDK de Rust que se puede compilar en WASM para el navegador, usarse en juegos basados en Rust (es decir, usar Bevy) y proporciona enlaces para Unity y Unreal (en desarrollo).
Se anima a los desarrolladores de juegos a escribir aplicaciones en El Cairo. Cairo es un lenguaje oxidado para crear programas demostrables para cálculos generales. Una ventaja de construir sobre Dojo es que puedes introducir mecánicas de niebla de guerra que son nativas de zkps sin tener que escribir código en Circom en Solidity.
Laboratorios Argus:
Argus Labs, fundado por Scott, uno de los cofundadores de Dark Forest, lanzó recientemente su última (y única) actualización. Este es un proyecto ambicioso que quiere ser la infraestructura para la creación de juegos (estudio), motores de juegos y para que otros desarrolladores escalen e implementen. Actualmente es un proyecto de código cerrado, pero su blog promete que será de código abierto cuando se publique.
Como se describió en lo que se compartió anteriormente, es un L2 personalizado con fragmentación básica y fragmentación de juegos personalizable individualmente. Con World Engine (motor de juego propietario), los desarrolladores de juegos pueden usar parámetros personalizados (como mayor tasa de ticks, AA local con personalización de gas, base de datos ECS y compatibilidad con clientes como Unity, Unreal, JS, etc.) Crear entornos de ejecución únicos . También proporcionan un indexador automático similar a otros motores de juegos. Optimizaron el motor mundial y L2, hicieron que el contenido escrito en Solidity fuera abstracto y fomentaron el desarrollo de juegos en Go. En el desarrollo de juegos tradicional, aunque Go es un lenguaje de programación perfecto, no es el lenguaje elegido porque la mayoría de los motores y bibliotecas admiten C, C++ y C++.
Scott insinuó una propuesta de valor única en su presentación reciente, a saber, la fragmentación basada en la ubicación (piense en "servidores de Asia", "servidores de Europa"), que podría mejorar aún más la latencia del juego. Por ejemplo, la mayoría de los secuenciadores tienen su sede en Estados Unidos y los jugadores asiáticos suelen enfrentarse a al menos 300 milisegundos de latencia, lo cual es mucho tiempo en los juegos. Toda la estructura está respaldada por un secuenciador compartido diseñado para optimizar la latencia en lugar de la componibilidad sincrónica y la agrupación atómica. No tiene bloqueos que bloqueen el tiempo de ejecución: se admiten múltiples fragmentos y no se bloquearán entre sí, ni impone un orden total.
Cardinal Shard es el primer fragmento de juego de la compañía, con 20 ticks por segundo, comparable a los juegos tradicionales.
Piedra clave:
El equipo de Curio fue el primer equipo comercial en experimentar con un L2 personalizado y finalmente trabajó con Caldera para implementar su OP Stack personalizado. Integrarán la estructura ECS en su cadena de ticks y proporcionarán funciones como indexación automática, soporte al cliente para Unity, etc. Este es un proyecto de I+D y es el resultado de sus esfuerzos por construir Tratado.Tierra. Es posible que se compartan más con el público cuando el equipo esté más preparado.
Otras cosas para probar:
Si bien estos cuatro son los más innovadores y conocidos en el ecosistema EVM/Ethereum, equipos como Playmint y Solana (Arc by Jump Crypto) están creando otros motores de juegos personalizados. Topology es otro explorador a la vanguardia de los juegos en línea y lanzó Isaac en Starknet basado en su motor de juego patentado, y pronto también se lanzará su último juego, Shoshin.
en conclusión:
Hoy en día, todos los motores intentan mejorar el tick. La velocidad y la expansión de la red tienen como objetivo permitir que blockchain realice interacciones de juegos más complejas; esto me recuerda el panorama competitivo de los equipos de juegos de realidad virtual en los primeros años. Surgieron nuevas tecnologías y cada empresa se centró en el ancho de banda de transmisión de los auriculares de realidad virtual. Después de una larga batalla, bajo el llamado de los fabricantes de hardware, los desarrolladores invadieron e intentaron hacer versiones VR/AR de juegos de varias categorías. Sin embargo, a medida que el mercado probó, la gente descubrió que solo ciertas categorías fijas eran adecuadas para la realidad virtual. El problema del ancho de banda del título no es crítico. De manera similar, el proceso de victoria decisiva entre los motores de cadena completa será el resultado de un juego de sistema complejo, pero es previsible que aquellos que encuentren pmf primero (aquellos con salidas de hot hits de cadena completa en el lado del contenido del motor) tendrá un mayor impacto.
Estamos emocionados de ver cómo se desarrolla cada capa, a medida que se lanzan nuevos juegos y surgen nuevos motores. A excepción de MUD v2 y Dojo, ninguno de ellos ha sido probado en combate real, y todavía nos queda un largo camino por recorrer antes de descubrir quién es el irreal y la unidad del mundo en cadena.