mud2048.fun é a nossa exploração para obter um senso microscópico do desenvolvimento completo do jogo em cadeia. O objetivo é experimentar a versão completa em cadeia do jogo original 2048 (play2048.co) replicando-o para vivenciar a experiência completa do desenvolvimento do jogo em cadeia. Temperatura da água, obtenha uma sensação corporal de primeira linha.
Este artigo é um resumo das experiências e pensamentos obtidos durante este processo de desenvolvimento, e tem como objetivo inspirar os leitores.
Esta é provavelmente a tentativa mais simples de desenvolver Jogos Totalmente On-chain. Antes disso, tentamos implementar uma versão completa de cadeia do Jogo Offline do Dinossauro do Chrome (Chrome Dino Game), mas depois descobrimos que não era nativo da blockchain. Com o suporte do mecanismo Tick do jogo, é difícil reproduzir uma versão completa da cadeia que se aproxime da experiência do jogo original.
Versão online do Jogo do Dinossauro do Chrome em:https://dinorunner.com/
Isso pode envolver um mal-entendido comum: é mais fácil implementar uma versão completa em cadeia de jogos simples. Na verdade, esse não é o caso, porque o tempo de confirmação da transação do blockchain (mesmo Layer 2 mainstream) ainda não atingiu o nível de tempo de resposta da interface do servidor centralizado; além disso, depois que a lógica do jogo é enviada para a cadeia, ela traz complexidade de engenharia que não apareceu no cenário centralizado, levando ao fato de que nem todos os jogos casuais simples podem implementar facilmente versões completas em cadeia. Isso também explica em certa medida as divisões atuais da ecologia de jogos completos em cadeia:
Principalmente RTS (jogos de estratégia em tempo real), como: Loot Survivor, Primodium, Sky Strife, Cellula, etc., complementados por Meta Rules (jogos de metarregras/jogos de sandbox), como: PixeLAW, Briq, OpCraft, etc. Ambos os tipos de jogos evitam as desvantagens causadas pelo longo tempo de confirmação de transações em blockchain em termos de forma de jogo.
A imagem mostra a interface de inicialização do Sky Strife, URL:https://playtest.skystrife.xyz/
MUD é o primeiro mecanismo de jogo de cadeia completa no ecossistema EVM (e o primeiro framework de desenvolvimento de aplicativos no ecossistema EVM). A carteira de Sessão integrada ao mecanismo e a Torneira da cadeia de teste que pode ser chamada por meio da API podem reduzir a barreira de entrada para os jogadores.
Outra razão é que o MUD é de código aberto, tem muitos documentos e materiais comunitários, e é fácil de começar. Se o mecanismo do jogo é de código aberto envolve questões de modelo de negócios que serão discutidas especificamente abaixo.
Introdução aos MUDs. source:https://github.com/latticexyz/mud
Agora vamos direto ao ponto. Vamos falar sobre algumas de nossas experiências ao usar o mecanismo MUD. Existem níveis da indústria macro-perceptual e níveis práticos de engenharia micro-racional. Eles são direcionados a diferentes grupos de público. Você pode usá-los você mesmo (pule diretamente) parte que não for interessante.
O que é um mecanismo de MUD em geral?
MUD engine = banco de dados relacional on-chain + estrutura de desenvolvimento de aplicativos on-chain.
Recursos do MUD. source:https://github.com/latticexyz/mud
Esta é uma perspectiva de olhar para o campo da blockchain a partir do campo da Internet (um pouco semelhante a olhar para o poder marítimo a partir da perspectiva do poder terrestre). Definitivamente não é a perspectiva mais apropriada, mas considerando que a blockchain ainda não alcançou a Adoção em Massa, os produtos de blockchain precisam ser lançados. círculo, ainda precisamos atrair mais usuários no campo da Internet, então talvez seja melhor analisar a partir da perspectiva da Internet primeiro.
Seja um “banco de dados relacional on-chain” ou um “framework de desenvolvimento de aplicativos on-chain”, eles são cruciais para o desenvolvimento do Ethereum, o “computador mundial”.
Aprendemos com o desenvolvimento de aplicativos da Internet: a facilidade de uso do software de banco de dados/a razoabilidade do design da estrutura da tabela de banco de dados determina em grande parte a complexidade do desenvolvimento do projeto inteiro. Em outras palavras, o desenvolvimento de aplicativos da Internet é realizado com o banco de dados como núcleo, vamos chamá-lo de "baseado em banco de dados".
Então, vamos ver se o design do motor MUD também segue a ideia "baseada em banco de dados". Do ponto de vista do design do motor MUD, ele resolve três problemas principais:
Como tornar os dados na cadeia fáceis de ler e escrever e armazenar de forma econômica,
Sincronização automática de dados entre on-chain/clientes,
Gerenciamento geral da complexidade do desenvolvimento de aplicativos.
Vamos olhar para a primeira pergunta primeiro: “Como os dados na cadeia podem ser facilmente lidos, escritos e armazenados de forma econômica”.
Este problema pode ser dividido em dois elementos:
1> Fácil de ler e escrever
2> Armazenamento econômico
Após décadas de prática no campo da Internet, a “facilidade de leitura e escrita”, o “banco de dados relacional” é considerado a solução ideal. Embora o blockchain seja um modelo de armazenamento em cadeia muito diferente do modelo de armazenamento de banco de dados tradicional (veja a figura abaixo), esse modelo não é amigável mesmo para operações simples em um único cenário (como somar/tirar a média do valor da transação de uma determinada Coleção NFT) / encontrar os valores máximo e mínimo, etc.), sem mencionar cenários mais complexos.
Fonte da imagem:https://mempool.space/mining
Portanto, a solução para MUD é implementar um “banco de dados relacional” em cima do armazenamento encadeado (correspondente à Tabela sob Store no mecanismo MUD). Para os desenvolvedores, a experiência de uso é a mesma que operar bancos de dados relacionais comuns (como MySQL, SQL Server, PostgreSQL, SQLite, etc.). Isso é realmente mais amigável para a maioria dos desenvolvedores da Internet. A figura abaixo mostra a estrutura da tabela correspondente quando desenvolvemos a versão 2048 baseada no mecanismo MUD completo.
Origem:https://github.com/themetacat/MUD2048/blob/main/packages/contracts/mud.config.ts
Podemos analisar o ponto de “armazenamento econômico” a partir da perspectiva do Ethereum, o computador mundial.
Os computadores modernos todos seguem a estrutura de “Von Neumann”, que é dividida em cinco partes: entrada, saída, operação, controle e armazenamento (veja a figura abaixo).
As imagens vêm da Internet
Do ponto de vista do próprio motor de jogo de blockchain completo, só pode otimizar o “armazenamento”, porque “entrada” e “saída” estão em sua camada superior e não podem ser controlados; “operação” e “controle” são feitos na blockchain do Ethereum. Como um “software de aplicação básico” em execução neste “computador mundial”, o motor de jogo de blockchain completo só pode otimizar a entrada de “armazenamento” por meio dele.
A solução específica para a otimização de armazenamento é implementar um “bitpacking” muito eficiente e compacto para os dados de entrada. Como o armazenamento de dados na blockchain é cobrado com base no volume de dados, um volume de dados menor significa custos de armazenamento mais baixos. Os custos de armazenamento completamente otimizados são o requisito para o surgimento de aplicativos on-chain complexos em grande escala. A figura abaixo mostra um caso específico de otimização de armazenamento pela MUD. Para mais detalhes, consulte“Motor de jogo de cadeia completa MUD de 0 a V2”。
Fonte da imagem:https://lattice.xyz/blog/mud-zero-to-v2
Em resumo, para a pergunta um, MUD resolve principalmente o problema do ponto de vista "baseado em banco de dados".
Agora chegamos à segunda pergunta: “Sincronização automática de dados entre on-chain/clientes”.
Esta também é uma função essencial fornecida pelo motor MUD, que ajuda os desenvolvedores a pouparem-se do pesado trabalho de gerenciar a sincronização de estados complexos. O plano de implementação específico é: sincronização em tempo real do banco de dados on-chain no cliente. Em outras palavras, cada cliente possui uma cópia local integrada que é sincronizada com o banco de dados on-chain em tempo real.
Isso é principalmente alcançado através do Indexador no motor MUD. A imagem abaixo é a introdução oficial da MUD ao Indexador, que é principalmente para cenários onde você deseja construí-lo e executá-lo no servidor do projeto (é claro, essa descrição também se aplica ao Indexador que é executado automaticamente no cliente de jogo de cadeia completa).
Fonte da imagem:https://mud.dev/services/indexer
Para os desenvolvedores, inicialmente eles têm um banco de dados on-chain com uma experiência de usuário próxima à de um banco de dados local. No entanto, em relação à implementação atual do MUD, é difícil para o cliente implementar funções como gerar uma lista global; além disso, não é uma abordagem econômica para cada cliente gerar uma lista global.
Falando nisso, todos certamente vão perguntar: Por que não gerar uma lista global na cadeia? A razão é que, embora o motor MUD tenha implementado um banco de dados relacional preliminar, o MUD ainda não suportou funções comuns como soma/média/máximo e mínimo em bancos de dados relacionais.
Portanto, em mud2048.fun, construímos um nó de Indexador MUD em um servidor centralizado para gerar um ranking global de jogadores de forma relativamente custo-benefício (veja a figura abaixo).
No entanto, permitir que cada cliente tenha uma cópia em tempo real do banco de dados on-chain também tem desvantagens. Por exemplo, antes que o aplicativo seja iniciado, os dados precisam ser sincronizados da cadeia para estabelecer a cópia mais recente do banco de dados da cadeia localmente, o que aumentará o tempo de espera para os jogadores entrarem no jogo. Os funcionários do MUD também estão cientes desse problema e mencionaram soluções de otimização relacionadas (sincronização de dados segmentados e armazenamento em cache do cliente) na versão MUD V2. No entanto, na minha opinião, são soluções temporárias e não podem resolver completamente o problema da cadeia a ser sincronizada ao longo do tempo. Há cada vez mais problemas com dados.
Este problema parece insolúvel por enquanto (será difícil alcançar avanços significativos na eficiência de transmissão de dados em rede pública e na recuperação de dados encadeados a curto prazo). Esperamos que com a iteração do MUD, uma solução mais apropriada possa ser encontrada. Se este problema for resolvido adequadamente, também abrirá caminho para o surgimento de aplicações complexas em outras cadeias.
Agora chegamos à pergunta três: “Gerenciamento de complexidade comum para o desenvolvimento de aplicativos”。
Antes disso, a maioria das aplicações on-chain no ecossistema Ethereum eram relativamente simples (um indicador objetivo é que o número de contratos envolvidos em um único produto DeFi/NFT/DAO é limitado e, na maioria dos casos, a possibilidade de atualização após o deployment é muito pequena). Mas para o desenvolvimento de aplicações complexas, as atualizações lógicas, o controle de acesso e a gestão de permissões são todas tarefas repetitivas que precisam ser feitas do zero. Portanto, há uma grande necessidade de um framework/motor universal que possa ajudar os desenvolvedores a lidar com esses problemas de forma unificada, para que os desenvolvedores possam se dedicar ao desenvolvimento de aplicações.
Outra função principal fornecida pelo motor MUD é ajudar os desenvolvedores a economizar tempo lidando com os problemas acima por meio do módulo World. Especificamente, o World fornece lógica e controle de acesso sobre o Store. A figura a seguir mostra o site oficial do MUD para o World. Descrição, esta é uma função fornecida por estruturas gerais de desenvolvimento de aplicativos, então não entrarei em detalhes aqui.
Fonte da imagem:https://mud.dev/mundo/introdução
Para o desenvolvimento de aplicativos complexos, o controle de acesso (ou roteamento) é um elo importante para determinar o volume total do projeto. A qualidade do design de controle de acesso determina diretamente a complexidade e facilidade de manutenção do desenvolvimento de aplicativos. MUD obviamente dá grande importância a isso. A figura abaixo mostra a otimização do módulo de controle de acesso em suas versões MUD v1 e v2.
Fonte da imagem:https://lattice.xyz/blog/mud-zero-to-v2
Os acima são alguns dos nossos pensamentos e experiências de engenharia no processo de desenvolvimento do mud2048.fun usando o motor MUD. Em termos gerais, os motores MUD também seguem a ideia "baseada em banco de dados", que é altamente consistente com a metodologia de desenvolvimento de aplicações na Internet. Portanto, os motores MUD não serão estranhos para os desenvolvedores de aplicações na Internet. Em seguida, discutiremos nossos pensamentos sobre a indústria de jogos full-chain.
Quando entramos no campo dos jogos de cadeia completa, as três perguntas que constantemente nos fazemos são:
Por que é necessário um jogo completo de cadeia?
Que tipo de jogos são adequados para toda a cadeia?
Qual é a relação entre Totalmente na Cadeia e Nativo de Cripto?
Em seguida, discutimos um por um:
Para a primeira pergunta: Por que precisamos de jogos de cadeia completa?
Este problema pode ser ainda decomposto em dois sub-problemas:
1> Por que a indústria blockchain precisa de jogos completos de cadeia?
2> Por que o mercado de criptomoedas precisa de jogos de cadeia completa?
Do ponto de vista da indústria blockchain:
O ecossistema Ethereum evoluiu para um estágio que requer o surgimento de aplicações complexas on-chain (no passado, as aplicações on-chain DeFi/DAO/NFT eram relativamente simples, como pode ser visto pelo número de contratos que suportam uma aplicação). Outro exemplo inverso é o par de Suporte da Camada 2 do Ethereum para toda a cadeia de jogos. Do ponto de vista da lógica interna, sem trabalho em porcelana, diamantes não podem ser feitos. A Camada 2 precisa de todo o trabalho em porcelana em toda a cadeia de jogos para se realizar.
O campo NFT não teve um novo paradigma para promover seu desenvolvimento após a bolha PFP. O ponto que distingue NFT de ERC-20 é a composabilidade, e a cena de jogos é o lugar natural para a composabilidade de NFT.
O objetivo final do jogo de toda a cadeiamundo autônomo"Gate" é outra elaboração da forma final do mundo digital (a última elaboração foi o "Metaverso" que se tornou uma bagunça depois de ser super promovido). Como uma imaginação comum da humanidade para um futuro melhor, o mundo autônomo tem grande apelo, e o mundo inteiro. Como uma maneira importante de alcançar esse objetivo, os jogos de corrente também têm grandes esperanças.
Site oficial da Autonomous Worlds:https://aw.network/
Olhando para o mercado de criptomoedas:
Olhando para trás na história do desenvolvimento da Internet, os jogos são sempre os primeiros a adotar novos campos de tecnologia. Os jogos são aplicativos de consumo e são mais fáceis de alcançar os usuários finais.
O modelo de jogo blockchain/GameFi foi temporariamente falsificado, e a exploração de jogos blockchain retornou à origem dos jogos: jogabilidade. A jogabilidade baseada em blockchain (que herda totalmente as vantagens e desvantagens do blockchain) promete fornecer novas experiências e paradigmas não disponíveis no passado, atraindo assim os usuários.
Chegamos à segunda pergunta: Que tipo de jogos são adequados para toda a cadeia??
Atualmente, a indústria/mercado ainda não chegou a um consenso sobre este ponto. De uma perspectiva indutiva, as duas categorias mencionadas acima são a estratégia em tempo real (RTS) e as regras meta (Meta Rules). No entanto, problemas como inovação insuficiente, modelos de negócios pouco claros e a falta de combinação adequada com os usuários ainda são problemas inevitáveis neste campo.
Pessoalmente, acho que a classe Meta Rules tem relativamente mais potencial, porque pelo menos tem mais possibilidades nativas no nível das regras e no nível de interoperabilidade. No entanto, ainda é muito cedo e é difícil avaliar sua certeza. A imagem abaixo é a interface do jogo completo de corrente meta-regras PixeLAW.
Fonte da imagem:https://twitter.com/0xPixeLAW/status/1704375844674912515
A interoperabilidade entre os jogos pode ser uma proposição falsa por muito tempo. Embora os jogos de cadeia completa herdem a interoperabilidade da blockchain, do ponto de vista empresarial/produtos/ecológico, é difícil imaginar dois produtos independentes sendo desenvolvidos para interoperabilidade a curto prazo, e este ponto também foi falsificado no ciclo anterior do 'Metaverso' em certa medida.
Agora vamos falar sobre a terceira pergunta: Qual é a relação entre Fully on-Chain e Crypto native??
Em primeiro lugar, super enfatizar “em toda a cadeia” fará as pessoas caírem no círculo vicioso do fundamentalismo. A infraestrutura atual da blockchain não pode suportar uma ampla gama de jogos para colocar todos os dados/lógica na cadeia. Além disso, GubSheep, o fundador de “Dark Forest”,formulação inicialé "Jogos Nativos de Cripto", a fim de pensar sobre como os jogos podem promover o desenvolvimento da indústria de blockchain ao máximo do ponto de vista de Cripto-Nativos. A imagem abaixo mostra parte do texto original de GubSheep.
origem:https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis
Crypto nativo é um conceito com conotações em constante mudança e fronteiras relativamente borradas. Existem diferentes interpretações em diferentes estágios do desenvolvimento de blockchain.
Em 2017, CryptoKitties foi considerado o epítome do nativo da cripto;
Em 2018, Uniswap foi o epítome do nativo de cripto;
Em 2020, CryptoArt é o epítome do nativo de cripto;
Em 2021, O DAO é o epítome do nativo da criptografia;
Até 2023, os jogos de cadeia completa, onde os dados e a lógica estão na cadeia, são vistos como um modelo nativo de criptografia.
Mas essencialmente a criptografia é uma ideia, não um dogma。
Totalmente na cadeia é uma metodologia que implementa nativo de cripto, mas não podemos ser limitados por ele., assim como centralização/descentralização, revolução/contrarrevolução, são todos conceitos relativos, e é fácil levar a um beco sem saída se você ficar muito enredado com o significado literal.
Então, quer se trate de jogos de blockchain completos ou de jogos nativos de criptomoeda, que novas possibilidades eles trazem?
Eu acredito que, após a lógica/regras do jogo serem tornadas transparentes através da cadeia, todas as estratégias de jogo podem competir verdadeiramente de forma justa. Claro, precisamos encontrar um cenário que possa refletir essa vantagem. Por exemplo, porque a lógica do jogo está na cadeia, você pode escrever diretamente o código do contrato para jogar o jogo, juntamente com estratégias de jogo geradas por IA, isso pode nos permitir ter um agente de jogador virtual acima da média/sem sono (essa ideia é inspirada por Shoshin inspirado).
Além disso, um mecanismo de jogo de cadeia completa como MUD (na verdade, é mais apropriado chamá-lo de estrutura de desenvolvimento de aplicativos de cadeia completa), como uma combinação de banco de dados + estrutura de desenvolvimento de aplicativos, é de importância autoevidente no ecossistema dos EVMs. No entanto, bancos de dados/estruturas de desenvolvimento de aplicativos são bens públicos e não têm modelo de negócios algum. Felizmente, existe um mecanismo nativo de Token da blockchain, bem comoEIP-6969Um esquema de royalties para desenvolvedores pode ajudar os desenvolvedores desses itens justos a capturar valor de uma maneira externa. Este é o ponto em que a blockchain é superior ao Web2.
"Consensus" não é apenas 51% do poder computacional, mas também os valores compartilhados que existem entre sociedades/grupos. Nesse sentido, a criptografia é uma espécie de valor.
Site oficial do MUD 2048:https://www.mud2048.fun/
Código do projeto MUD 2048:https://github.com/themetacat/MUD2048
Site oficial do motor MUD: https://mud.dev/
Site oficial da Bíblia dos Mundos Autônomos:https://aw.network/
Teoria de jogo nativa criptografada GubSheep:https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis
mud2048.fun é a nossa exploração para obter um senso microscópico do desenvolvimento completo do jogo em cadeia. O objetivo é experimentar a versão completa em cadeia do jogo original 2048 (play2048.co) replicando-o para vivenciar a experiência completa do desenvolvimento do jogo em cadeia. Temperatura da água, obtenha uma sensação corporal de primeira linha.
Este artigo é um resumo das experiências e pensamentos obtidos durante este processo de desenvolvimento, e tem como objetivo inspirar os leitores.
Esta é provavelmente a tentativa mais simples de desenvolver Jogos Totalmente On-chain. Antes disso, tentamos implementar uma versão completa de cadeia do Jogo Offline do Dinossauro do Chrome (Chrome Dino Game), mas depois descobrimos que não era nativo da blockchain. Com o suporte do mecanismo Tick do jogo, é difícil reproduzir uma versão completa da cadeia que se aproxime da experiência do jogo original.
Versão online do Jogo do Dinossauro do Chrome em:https://dinorunner.com/
Isso pode envolver um mal-entendido comum: é mais fácil implementar uma versão completa em cadeia de jogos simples. Na verdade, esse não é o caso, porque o tempo de confirmação da transação do blockchain (mesmo Layer 2 mainstream) ainda não atingiu o nível de tempo de resposta da interface do servidor centralizado; além disso, depois que a lógica do jogo é enviada para a cadeia, ela traz complexidade de engenharia que não apareceu no cenário centralizado, levando ao fato de que nem todos os jogos casuais simples podem implementar facilmente versões completas em cadeia. Isso também explica em certa medida as divisões atuais da ecologia de jogos completos em cadeia:
Principalmente RTS (jogos de estratégia em tempo real), como: Loot Survivor, Primodium, Sky Strife, Cellula, etc., complementados por Meta Rules (jogos de metarregras/jogos de sandbox), como: PixeLAW, Briq, OpCraft, etc. Ambos os tipos de jogos evitam as desvantagens causadas pelo longo tempo de confirmação de transações em blockchain em termos de forma de jogo.
A imagem mostra a interface de inicialização do Sky Strife, URL:https://playtest.skystrife.xyz/
MUD é o primeiro mecanismo de jogo de cadeia completa no ecossistema EVM (e o primeiro framework de desenvolvimento de aplicativos no ecossistema EVM). A carteira de Sessão integrada ao mecanismo e a Torneira da cadeia de teste que pode ser chamada por meio da API podem reduzir a barreira de entrada para os jogadores.
Outra razão é que o MUD é de código aberto, tem muitos documentos e materiais comunitários, e é fácil de começar. Se o mecanismo do jogo é de código aberto envolve questões de modelo de negócios que serão discutidas especificamente abaixo.
Introdução aos MUDs. source:https://github.com/latticexyz/mud
Agora vamos direto ao ponto. Vamos falar sobre algumas de nossas experiências ao usar o mecanismo MUD. Existem níveis da indústria macro-perceptual e níveis práticos de engenharia micro-racional. Eles são direcionados a diferentes grupos de público. Você pode usá-los você mesmo (pule diretamente) parte que não for interessante.
O que é um mecanismo de MUD em geral?
MUD engine = banco de dados relacional on-chain + estrutura de desenvolvimento de aplicativos on-chain.
Recursos do MUD. source:https://github.com/latticexyz/mud
Esta é uma perspectiva de olhar para o campo da blockchain a partir do campo da Internet (um pouco semelhante a olhar para o poder marítimo a partir da perspectiva do poder terrestre). Definitivamente não é a perspectiva mais apropriada, mas considerando que a blockchain ainda não alcançou a Adoção em Massa, os produtos de blockchain precisam ser lançados. círculo, ainda precisamos atrair mais usuários no campo da Internet, então talvez seja melhor analisar a partir da perspectiva da Internet primeiro.
Seja um “banco de dados relacional on-chain” ou um “framework de desenvolvimento de aplicativos on-chain”, eles são cruciais para o desenvolvimento do Ethereum, o “computador mundial”.
Aprendemos com o desenvolvimento de aplicativos da Internet: a facilidade de uso do software de banco de dados/a razoabilidade do design da estrutura da tabela de banco de dados determina em grande parte a complexidade do desenvolvimento do projeto inteiro. Em outras palavras, o desenvolvimento de aplicativos da Internet é realizado com o banco de dados como núcleo, vamos chamá-lo de "baseado em banco de dados".
Então, vamos ver se o design do motor MUD também segue a ideia "baseada em banco de dados". Do ponto de vista do design do motor MUD, ele resolve três problemas principais:
Como tornar os dados na cadeia fáceis de ler e escrever e armazenar de forma econômica,
Sincronização automática de dados entre on-chain/clientes,
Gerenciamento geral da complexidade do desenvolvimento de aplicativos.
Vamos olhar para a primeira pergunta primeiro: “Como os dados na cadeia podem ser facilmente lidos, escritos e armazenados de forma econômica”.
Este problema pode ser dividido em dois elementos:
1> Fácil de ler e escrever
2> Armazenamento econômico
Após décadas de prática no campo da Internet, a “facilidade de leitura e escrita”, o “banco de dados relacional” é considerado a solução ideal. Embora o blockchain seja um modelo de armazenamento em cadeia muito diferente do modelo de armazenamento de banco de dados tradicional (veja a figura abaixo), esse modelo não é amigável mesmo para operações simples em um único cenário (como somar/tirar a média do valor da transação de uma determinada Coleção NFT) / encontrar os valores máximo e mínimo, etc.), sem mencionar cenários mais complexos.
Fonte da imagem:https://mempool.space/mining
Portanto, a solução para MUD é implementar um “banco de dados relacional” em cima do armazenamento encadeado (correspondente à Tabela sob Store no mecanismo MUD). Para os desenvolvedores, a experiência de uso é a mesma que operar bancos de dados relacionais comuns (como MySQL, SQL Server, PostgreSQL, SQLite, etc.). Isso é realmente mais amigável para a maioria dos desenvolvedores da Internet. A figura abaixo mostra a estrutura da tabela correspondente quando desenvolvemos a versão 2048 baseada no mecanismo MUD completo.
Origem:https://github.com/themetacat/MUD2048/blob/main/packages/contracts/mud.config.ts
Podemos analisar o ponto de “armazenamento econômico” a partir da perspectiva do Ethereum, o computador mundial.
Os computadores modernos todos seguem a estrutura de “Von Neumann”, que é dividida em cinco partes: entrada, saída, operação, controle e armazenamento (veja a figura abaixo).
As imagens vêm da Internet
Do ponto de vista do próprio motor de jogo de blockchain completo, só pode otimizar o “armazenamento”, porque “entrada” e “saída” estão em sua camada superior e não podem ser controlados; “operação” e “controle” são feitos na blockchain do Ethereum. Como um “software de aplicação básico” em execução neste “computador mundial”, o motor de jogo de blockchain completo só pode otimizar a entrada de “armazenamento” por meio dele.
A solução específica para a otimização de armazenamento é implementar um “bitpacking” muito eficiente e compacto para os dados de entrada. Como o armazenamento de dados na blockchain é cobrado com base no volume de dados, um volume de dados menor significa custos de armazenamento mais baixos. Os custos de armazenamento completamente otimizados são o requisito para o surgimento de aplicativos on-chain complexos em grande escala. A figura abaixo mostra um caso específico de otimização de armazenamento pela MUD. Para mais detalhes, consulte“Motor de jogo de cadeia completa MUD de 0 a V2”。
Fonte da imagem:https://lattice.xyz/blog/mud-zero-to-v2
Em resumo, para a pergunta um, MUD resolve principalmente o problema do ponto de vista "baseado em banco de dados".
Agora chegamos à segunda pergunta: “Sincronização automática de dados entre on-chain/clientes”.
Esta também é uma função essencial fornecida pelo motor MUD, que ajuda os desenvolvedores a pouparem-se do pesado trabalho de gerenciar a sincronização de estados complexos. O plano de implementação específico é: sincronização em tempo real do banco de dados on-chain no cliente. Em outras palavras, cada cliente possui uma cópia local integrada que é sincronizada com o banco de dados on-chain em tempo real.
Isso é principalmente alcançado através do Indexador no motor MUD. A imagem abaixo é a introdução oficial da MUD ao Indexador, que é principalmente para cenários onde você deseja construí-lo e executá-lo no servidor do projeto (é claro, essa descrição também se aplica ao Indexador que é executado automaticamente no cliente de jogo de cadeia completa).
Fonte da imagem:https://mud.dev/services/indexer
Para os desenvolvedores, inicialmente eles têm um banco de dados on-chain com uma experiência de usuário próxima à de um banco de dados local. No entanto, em relação à implementação atual do MUD, é difícil para o cliente implementar funções como gerar uma lista global; além disso, não é uma abordagem econômica para cada cliente gerar uma lista global.
Falando nisso, todos certamente vão perguntar: Por que não gerar uma lista global na cadeia? A razão é que, embora o motor MUD tenha implementado um banco de dados relacional preliminar, o MUD ainda não suportou funções comuns como soma/média/máximo e mínimo em bancos de dados relacionais.
Portanto, em mud2048.fun, construímos um nó de Indexador MUD em um servidor centralizado para gerar um ranking global de jogadores de forma relativamente custo-benefício (veja a figura abaixo).
No entanto, permitir que cada cliente tenha uma cópia em tempo real do banco de dados on-chain também tem desvantagens. Por exemplo, antes que o aplicativo seja iniciado, os dados precisam ser sincronizados da cadeia para estabelecer a cópia mais recente do banco de dados da cadeia localmente, o que aumentará o tempo de espera para os jogadores entrarem no jogo. Os funcionários do MUD também estão cientes desse problema e mencionaram soluções de otimização relacionadas (sincronização de dados segmentados e armazenamento em cache do cliente) na versão MUD V2. No entanto, na minha opinião, são soluções temporárias e não podem resolver completamente o problema da cadeia a ser sincronizada ao longo do tempo. Há cada vez mais problemas com dados.
Este problema parece insolúvel por enquanto (será difícil alcançar avanços significativos na eficiência de transmissão de dados em rede pública e na recuperação de dados encadeados a curto prazo). Esperamos que com a iteração do MUD, uma solução mais apropriada possa ser encontrada. Se este problema for resolvido adequadamente, também abrirá caminho para o surgimento de aplicações complexas em outras cadeias.
Agora chegamos à pergunta três: “Gerenciamento de complexidade comum para o desenvolvimento de aplicativos”。
Antes disso, a maioria das aplicações on-chain no ecossistema Ethereum eram relativamente simples (um indicador objetivo é que o número de contratos envolvidos em um único produto DeFi/NFT/DAO é limitado e, na maioria dos casos, a possibilidade de atualização após o deployment é muito pequena). Mas para o desenvolvimento de aplicações complexas, as atualizações lógicas, o controle de acesso e a gestão de permissões são todas tarefas repetitivas que precisam ser feitas do zero. Portanto, há uma grande necessidade de um framework/motor universal que possa ajudar os desenvolvedores a lidar com esses problemas de forma unificada, para que os desenvolvedores possam se dedicar ao desenvolvimento de aplicações.
Outra função principal fornecida pelo motor MUD é ajudar os desenvolvedores a economizar tempo lidando com os problemas acima por meio do módulo World. Especificamente, o World fornece lógica e controle de acesso sobre o Store. A figura a seguir mostra o site oficial do MUD para o World. Descrição, esta é uma função fornecida por estruturas gerais de desenvolvimento de aplicativos, então não entrarei em detalhes aqui.
Fonte da imagem:https://mud.dev/mundo/introdução
Para o desenvolvimento de aplicativos complexos, o controle de acesso (ou roteamento) é um elo importante para determinar o volume total do projeto. A qualidade do design de controle de acesso determina diretamente a complexidade e facilidade de manutenção do desenvolvimento de aplicativos. MUD obviamente dá grande importância a isso. A figura abaixo mostra a otimização do módulo de controle de acesso em suas versões MUD v1 e v2.
Fonte da imagem:https://lattice.xyz/blog/mud-zero-to-v2
Os acima são alguns dos nossos pensamentos e experiências de engenharia no processo de desenvolvimento do mud2048.fun usando o motor MUD. Em termos gerais, os motores MUD também seguem a ideia "baseada em banco de dados", que é altamente consistente com a metodologia de desenvolvimento de aplicações na Internet. Portanto, os motores MUD não serão estranhos para os desenvolvedores de aplicações na Internet. Em seguida, discutiremos nossos pensamentos sobre a indústria de jogos full-chain.
Quando entramos no campo dos jogos de cadeia completa, as três perguntas que constantemente nos fazemos são:
Por que é necessário um jogo completo de cadeia?
Que tipo de jogos são adequados para toda a cadeia?
Qual é a relação entre Totalmente na Cadeia e Nativo de Cripto?
Em seguida, discutimos um por um:
Para a primeira pergunta: Por que precisamos de jogos de cadeia completa?
Este problema pode ser ainda decomposto em dois sub-problemas:
1> Por que a indústria blockchain precisa de jogos completos de cadeia?
2> Por que o mercado de criptomoedas precisa de jogos de cadeia completa?
Do ponto de vista da indústria blockchain:
O ecossistema Ethereum evoluiu para um estágio que requer o surgimento de aplicações complexas on-chain (no passado, as aplicações on-chain DeFi/DAO/NFT eram relativamente simples, como pode ser visto pelo número de contratos que suportam uma aplicação). Outro exemplo inverso é o par de Suporte da Camada 2 do Ethereum para toda a cadeia de jogos. Do ponto de vista da lógica interna, sem trabalho em porcelana, diamantes não podem ser feitos. A Camada 2 precisa de todo o trabalho em porcelana em toda a cadeia de jogos para se realizar.
O campo NFT não teve um novo paradigma para promover seu desenvolvimento após a bolha PFP. O ponto que distingue NFT de ERC-20 é a composabilidade, e a cena de jogos é o lugar natural para a composabilidade de NFT.
O objetivo final do jogo de toda a cadeiamundo autônomo"Gate" é outra elaboração da forma final do mundo digital (a última elaboração foi o "Metaverso" que se tornou uma bagunça depois de ser super promovido). Como uma imaginação comum da humanidade para um futuro melhor, o mundo autônomo tem grande apelo, e o mundo inteiro. Como uma maneira importante de alcançar esse objetivo, os jogos de corrente também têm grandes esperanças.
Site oficial da Autonomous Worlds:https://aw.network/
Olhando para o mercado de criptomoedas:
Olhando para trás na história do desenvolvimento da Internet, os jogos são sempre os primeiros a adotar novos campos de tecnologia. Os jogos são aplicativos de consumo e são mais fáceis de alcançar os usuários finais.
O modelo de jogo blockchain/GameFi foi temporariamente falsificado, e a exploração de jogos blockchain retornou à origem dos jogos: jogabilidade. A jogabilidade baseada em blockchain (que herda totalmente as vantagens e desvantagens do blockchain) promete fornecer novas experiências e paradigmas não disponíveis no passado, atraindo assim os usuários.
Chegamos à segunda pergunta: Que tipo de jogos são adequados para toda a cadeia??
Atualmente, a indústria/mercado ainda não chegou a um consenso sobre este ponto. De uma perspectiva indutiva, as duas categorias mencionadas acima são a estratégia em tempo real (RTS) e as regras meta (Meta Rules). No entanto, problemas como inovação insuficiente, modelos de negócios pouco claros e a falta de combinação adequada com os usuários ainda são problemas inevitáveis neste campo.
Pessoalmente, acho que a classe Meta Rules tem relativamente mais potencial, porque pelo menos tem mais possibilidades nativas no nível das regras e no nível de interoperabilidade. No entanto, ainda é muito cedo e é difícil avaliar sua certeza. A imagem abaixo é a interface do jogo completo de corrente meta-regras PixeLAW.
Fonte da imagem:https://twitter.com/0xPixeLAW/status/1704375844674912515
A interoperabilidade entre os jogos pode ser uma proposição falsa por muito tempo. Embora os jogos de cadeia completa herdem a interoperabilidade da blockchain, do ponto de vista empresarial/produtos/ecológico, é difícil imaginar dois produtos independentes sendo desenvolvidos para interoperabilidade a curto prazo, e este ponto também foi falsificado no ciclo anterior do 'Metaverso' em certa medida.
Agora vamos falar sobre a terceira pergunta: Qual é a relação entre Fully on-Chain e Crypto native??
Em primeiro lugar, super enfatizar “em toda a cadeia” fará as pessoas caírem no círculo vicioso do fundamentalismo. A infraestrutura atual da blockchain não pode suportar uma ampla gama de jogos para colocar todos os dados/lógica na cadeia. Além disso, GubSheep, o fundador de “Dark Forest”,formulação inicialé "Jogos Nativos de Cripto", a fim de pensar sobre como os jogos podem promover o desenvolvimento da indústria de blockchain ao máximo do ponto de vista de Cripto-Nativos. A imagem abaixo mostra parte do texto original de GubSheep.
origem:https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis
Crypto nativo é um conceito com conotações em constante mudança e fronteiras relativamente borradas. Existem diferentes interpretações em diferentes estágios do desenvolvimento de blockchain.
Em 2017, CryptoKitties foi considerado o epítome do nativo da cripto;
Em 2018, Uniswap foi o epítome do nativo de cripto;
Em 2020, CryptoArt é o epítome do nativo de cripto;
Em 2021, O DAO é o epítome do nativo da criptografia;
Até 2023, os jogos de cadeia completa, onde os dados e a lógica estão na cadeia, são vistos como um modelo nativo de criptografia.
Mas essencialmente a criptografia é uma ideia, não um dogma。
Totalmente na cadeia é uma metodologia que implementa nativo de cripto, mas não podemos ser limitados por ele., assim como centralização/descentralização, revolução/contrarrevolução, são todos conceitos relativos, e é fácil levar a um beco sem saída se você ficar muito enredado com o significado literal.
Então, quer se trate de jogos de blockchain completos ou de jogos nativos de criptomoeda, que novas possibilidades eles trazem?
Eu acredito que, após a lógica/regras do jogo serem tornadas transparentes através da cadeia, todas as estratégias de jogo podem competir verdadeiramente de forma justa. Claro, precisamos encontrar um cenário que possa refletir essa vantagem. Por exemplo, porque a lógica do jogo está na cadeia, você pode escrever diretamente o código do contrato para jogar o jogo, juntamente com estratégias de jogo geradas por IA, isso pode nos permitir ter um agente de jogador virtual acima da média/sem sono (essa ideia é inspirada por Shoshin inspirado).
Além disso, um mecanismo de jogo de cadeia completa como MUD (na verdade, é mais apropriado chamá-lo de estrutura de desenvolvimento de aplicativos de cadeia completa), como uma combinação de banco de dados + estrutura de desenvolvimento de aplicativos, é de importância autoevidente no ecossistema dos EVMs. No entanto, bancos de dados/estruturas de desenvolvimento de aplicativos são bens públicos e não têm modelo de negócios algum. Felizmente, existe um mecanismo nativo de Token da blockchain, bem comoEIP-6969Um esquema de royalties para desenvolvedores pode ajudar os desenvolvedores desses itens justos a capturar valor de uma maneira externa. Este é o ponto em que a blockchain é superior ao Web2.
"Consensus" não é apenas 51% do poder computacional, mas também os valores compartilhados que existem entre sociedades/grupos. Nesse sentido, a criptografia é uma espécie de valor.
Site oficial do MUD 2048:https://www.mud2048.fun/
Código do projeto MUD 2048:https://github.com/themetacat/MUD2048
Site oficial do motor MUD: https://mud.dev/
Site oficial da Bíblia dos Mundos Autônomos:https://aw.network/
Teoria de jogo nativa criptografada GubSheep:https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis