Isso está claramente em desacordo com o modelo de desenvolvimento dos jogos tradicionais. Os jogos tradicionais bem-sucedidos atraem muitos usuários através de mecânicas de jogo envolventes, permitindo aos desenvolvedores construir caminhos lucrativos e potencialmente expandir para produtos relacionados e IPs. Esses jogos operam em um ciclo positivo onde os jogadores desfrutam do jogo e frequentemente obtêm benefícios econômicos tanto dentro como fora do jogo.

Pelo contrário, os jogos de blockchain atuais atraem principalmente os jogadores através de retornos financeiros. Além da sua baixa jogabilidade, os jogos Web3 também enfrentam problemas de longa data como altas barreiras de entrada e processos de interação complicados.

Qual é a causa raiz desses problemas? As opiniões variam. A equipe TabiChain acredita que um fator significativo é que talentosos desenvolvedores tradicionais de jogos lutam para entrar no ecossistema Web3 devido a barreiras técnicas e de aprendizado. Para aqueles não familiarizados com o desenvolvimento de jogos ou software, a transição do Web2 para o Web3 pode parecer apenas uma mudança de narrativa e ambiente, mas a realidade é muito mais dura.

Então, como podemos criar um ambiente mais acolhedor para os desenvolvedores tradicionais de jogos ou empresas relacionadas por meio da tecnologia? Nas seções seguintes, analisaremos minuciosamente os desafios enfrentados pelos jogos Web3 e suas soluções, explicando como a futura indústria de jogos Web3 pode ser tecnicamente adaptada para melhor atender aos desenvolvedores de jogos tradicionais.

Razões Técnicas Impedindo os Desenvolvedores de Jogos Tradicionais de Entrar no Ecossistema Web3

No artigo anterior, mencionamos brevemente que a tecnologia hostil e os altos custos de aprendizado são os principais fatores que impedem os praticantes de jogos tradicionais de entrarem no ecossistema web3. A chamada tecnologia hostil e os altos custos de aprendizado podem ser expandidos para os seguintes pontos:

1. A diferença entre aplicações web3 e estruturas de software tradicionais

Blockchain e as aplicações nele (dApps) são fundamentalmente diferentes da arquitetura de software tradicional e requerem que os desenvolvedores tenham um novo sistema de conhecimento, como o princípio de funcionamento da blockchain, protocolos de consenso, modelos de programação de contratos inteligentes, etc. Os desenvolvedores de jogos tradicionais precisam passar muito tempo aprendendo Solidity ou outras linguagens de contratos inteligentes e precisam entender como a EVM funciona.

Além disso, a lógica de jogo tradicional geralmente é executada em um servidor centralizado, que pode lidar de forma flexível com estados de jogo complexos e interações de alta frequência. Executar a lógica do jogo na blockchain requer um alto grau de simplificação ou refatoração, pois cada operação deve ser publicada na rede distribuída para execução e depois enviada para a cadeia, o que é severamente limitado pelo desempenho e custo da blockchain.

1. Limitações de design dos contratos inteligentes

Embora o EVM seja Turing completo e teoricamente possa expressar lógica arbitrária, as suas características são muito desfavoráveis para o desenvolvimento de jogos, tais como:

• Falta de temporizador. Todas as operações na cadeia Ethereum devem ser acionadas manualmente pela conta EOA. Para obter um efeito semelhante a um temporizador, os desenvolvedores precisam implantar um serviço adicional e manter uma conta EOA e uma lista de eventos para acionar manualmente tarefas agendadas. Devido ao problema de atraso na cadeia, não é garantido que essas tarefas agendadas sejam concluídas a tempo.

• Não há callback nem outros mecanismos, e não suporta multithreading e assíncrono. Como o Solidity é projetado para o desenvolvimento de contratos inteligentes do Ethereum, o seu ambiente de execução é significativamente diferente dos ambientes de tempo de execução tradicionais. A operação do EVM é transacional e cada chamada de função precisa ser completamente executada numa transação. Não existe o conceito de "assíncrono" no sentido tradicional. Isto significa que uma chamada de função em Solidity é atômica do início ao fim e não pode ser interrompida por outras transações.
• Não há capacidade de referenciar dados externos. Embora existam oráculos como Chainlink, quer do ponto de vista da integração quer da chamada de dados, a facilidade de uso é muito diferente da obtenção direta de chamadas de dados através de pedidos https, o que permite aos desenvolvedores adicionar integrações adicionais. Fardo e dependência.
• Limitações de escalabilidade e desempenho. A lógica do jogo deve ser simplificada ou dividida em várias transações simples para evitar que a taxa de gás de uma única transação se torne muito alta ou exceda o limite máximo, o que limita a implementação de interações e funções complexas.

1. Limitações no armazenamento e recuperação de dados

• Os contratos inteligentes têm um espaço de armazenamento caro e um design limitado, o que os torna inadequados para armazenar grandes quantidades de dados de jogos.
• Os registos de eventos podem ser necessários para rastrear indiretamente o estado do jogo, e a captura de eventos pode não ser estável. Questões como quando atualizar frequentemente o estado do jogo exigem que os jogadores ou operadores do jogo o acionem manualmente.
• A estrutura de dados da conta adotada pelo EVM resulta em capacidades de indexação de dados pobres. Quando você consulta os dados de uma conta, só pode saber o saldo do seu ETH ou token nativo da cadeia, mas quais ativos ERC-20 ela possui e o saldo de cada ativo não podem ser diretamente conhecidos. O mesmo acontece com os NFT. Esta informação está encapsulada no contrato exclusivo de cada ativo, em vez de ser armazenada sob a conta do usuário.

Podemos ver que tipo de token e informações de saldo um determinado endereço possui a partir de ferramentas como Etherscan. Estes são indexados por ferramentas periféricas, como navegadores de blockchain, e estes últimos precisam construir um enorme banco de dados dedicado e rastreá-lo completamente. Apenas coletando todos os dados do bloco ou monitorando eventos na cadeia, todos os dados na cadeia podem ser resumidos.

Os desenvolvedores Web3 geralmente têm que integrar fornecedores de dados de terceiros, como Etherscan, NFTscan, The Graph, etc., e até mesmo pagar pela sua CHAVE API. Além disso, esses serviços de terceiros são essencialmente bases de dados off-chain, o que pode causar atrasos, erros, exceder limites de chamada, indisponibilidade de serviço e outras falhas.

Vamos comparar as diferenças entre a forma de base de dados da maioria dos jogos e os métodos de armazenamento de dados na blockchain. A diferença entre os dois é óbvia. A estrutura de dados da maioria dos jogos é completamente personalizada por si mesma, tem boas capacidades de expressão e indexação, e não precisa de depender de quaisquer serviços de terceiros.

1. Desafios na integração de ativos de jogos existentes com blockchain

Os ativos de jogo existentes (como acessórios e personagens) geralmente não são criados e geridos na blockchain. Migrar esses ativos para a blockchain geralmente envolve a conversão de tipos de dados comuns, mas de cauda longa, em NFTs ou Tokens padrão, o que implica um trabalho de migração e integração complexo e afetará o sistema econômico de jogo existente.

1. Atualizações, patches e prevenção de desastres

Na Ethereum, uma vez que um contrato inteligente é implementado, o código é imutável, tornando as atualizações e correções mais complexas do que o software tradicional. Os desenvolvedores frequentemente usam contratos de proxy ou padrões de versionamento para contornar esta limitação, mas isso aumenta a complexidade da estrutura geral. Os contratos de proxy precisam ser usados com cuidado especial para evitar a corrupção de dados causada por conflitos de slot de armazenamento. Além disso, o risco de vazamento de direitos administrativos também é sério.

A atualização de código de jogos tradicionais não é tão complicada em termos de estrutura técnica. A única coisa que pode precisar de ser restrita é a autoridade centralizada de atualização. Isso pode ser alcançado através de métodos como DAO em vez de depender de contratos inteligentes.

Além disso, os jogos tradicionais frequentemente tiram instantâneos ou backups do banco de dados. Isso pode não ser muito importante normalmente, mas se você encontrar um grande bug na atualização, pode reverter rapidamente os dados, o que é basicamente um sonho na blockchain. Mesmo que alguns dados do jogo sejam revertidos reconstruindo o contrato, como migrar os dados e o status do contrato antigo para o novo contrato ainda é complicado.

1. Fragmentação e questões de experiência do utilizador

Diferentes cadeias públicas e VMs têm linguagens de contrato inteligente, arquiteturas, estruturas de dados, etc., completamente diferentes. No Web2, os desenvolvedores de jogos escolherão motores de front-end multiplataforma como a Unity, que podem fazer com que um conjunto de códigos seja ligeiramente adaptado para ser executado em diferentes ambientes, como iPhone, Android e desktop. Como o back-end não é executado no terminal do usuário, não há problemas de multiplataforma.

Em Web3, isso é basicamente um luxo. Migrar para uma cadeia ou VM diferente significa reconstruir todo o projeto e incorrer em custos enormes. Além disso, os desenvolvedores que são novos no Web3 não têm experiência alguma para escolher um ecossistema que lhes convém. Isso é visto a partir de uma perspetiva técnica ou ecológica?

Ao nível da experiência do utilizador, as interações em blockchain são extremamente complexas. O conceito de abstração de conta, que era tão popular anteriormente, surgiu precisamente para resolver os problemas de experiência do utilizador web3, por isso não entrarei em detalhes aqui.

Após listar os 6 principais argumentos acima, vamos resumir: os desenvolvedores da web2 para a web3 enfrentam um grande limiar de adaptação. Se eles são os melhores desenvolvedores na web2, não há necessidade de abandonar suas carreiras na web2 e ir para um desconhecido como a web3. Neste ambiente, estamos desenvolvendo alguns negócios dos quais não sabemos se serão bem-sucedidos ou não.

Pode dizer-se que a maioria dos principais desenvolvedores de jogos ainda não entraram na Web3. Até certo ponto, isso faz com que a maioria dos jogos Web3 sejam tendenciosos para a especulação financeira em vez de terem uma jogabilidade e diversão particularmente elevadas.

Os obstáculos da mesma natureza também existem no lado do utilizador. Os jogos Web3 têm uma série de passos de operação que impedem as taxas de conversão do utilizador, resultando num enorme grupo de utilizadores da Web2 que não estão dispostos a experimentar ou até mesmo completamente inconscientes da existência de jogos Web3.

Existe um projeto de nível infraestrutural que pode resolver os problemas acima? A Tabi Chain pode ser um projeto muito próximo de uma das soluções finais para os jogos Web3. O seu conceito central é a “Camada de Execução Omni”: Os desenvolvedores já não precisam de se preocupar com as diferenças entre vários VMs ou ambientes de operação. Eles podem usar diretamente os seus ambientes operacionais familiares ou até personalizáveis para desenvolver ou portar jogos diretamente.

Além disso, a Tabi Chain também possui consenso modular, camada de segurança e outras funcionalidades. Tudo é modular e personalizável para atender às necessidades de diferentes jogos e aplicações.

Camada de Execução Omni: Selecionando o Ambiente de Execução com Base nas Necessidades do Desenvolvedor

Vamos revisitar o conceito fundamental da blockchain. Enquanto alguns podem descrevê-la como um livro-razão descentralizado e imutável, é mais precisamente definido como a sincronização verificável do estado permanente de uma máquina de estado dentro de uma rede distribuída.

Em essência, o blockchain mantém uma máquina de estado universalmente aceita e seu status operacional:

• Cada input é determinístico, registado em cada bloco;
• A função de transição de estado é determinística, representada pela VM ou tempo de execução dentro do cliente blockchain;
• O estado de saída também é determinístico, registado em cada bloco;

Assim, o sistema de consenso de uma blockchain não precisa de estar limitado a uma única camada de execução (como apenas o EVM). Independentemente do número de camadas de execução, desde que a cadeia consiga verificar os estados através de múltiplas camadas, permitindo que cada jogo opere no seu próprio ambiente, podemos abordar as várias questões anteriormente discutidas.

Em Tabi, cada jogo ou dApp pode construir o seu próprio Serviço independente. Todos os Serviços submetem os seus próprios blocos gerados ao sistema de consenso da cadeia; Os Nós Supervisores incluem o tempo de execução/VM em todos os Serviços para verificar o estado dos blocos de serviço. O núcleo da camada de execução abrangente de Tabi pode ser considerado como uma VM com capacidades polimórficas, por isso é chamado de VM de Polimorfismo.

Para as VMs blockchain existentes, uma VM de Polimorfismo precisa integrar essas VMs dentro do seu ambiente de tempo de execução e fornecer os métodos de chamada de interface necessários. O conceito de "integração" aqui pode ser implementado de duas maneiras:

Estado Mundial Compartilhado: Semelhante ao Ethermint, que suporta EVM no Cosmos. O EVM atua como uma camada superficial, focando nas interações do usuário e operações de contrato, fazendo com que todas as atividades do lado do usuário pareçam ser executadas no EVM. No entanto, os resultados finais e os dados dessas operações são armazenados em outros módulos do Cosmos. Assim, essa compatibilidade com o EVM é essencialmente um mapeamento dos dados subjacentes.

Esta relação de mapeamento pode ser estendida a outras VMs também. Por exemplo, o Ethermint pode incorporar uma camada de módulo SVM adicional, onde tanto o SVM quanto o EVM correspondem aos mesmos dados subjacentes.

Isto é semelhante a usar o VMWare num PC para executar uma máquina virtual do Windows. O VMWare pode aceder tanto ao disco rígido virtual da máquina virtual como ao disco rígido do computador físico. Se depois iniciar uma máquina virtual Mac, esta pode montar os dados do disco físico da mesma maneira. Esta configuração permite efetivamente que várias máquinas virtuais partilhem os recursos e o estado do mesmo ambiente.

O serviço principal da Tabi Chain usará uma abordagem de estado mundial compartilhado. Isso significa que, desde que a VM correspondente seja adaptada, os dApps desenvolvidos para essa VM podem ser implantados diretamente no Serviço Principal sem a necessidade de criar um serviço separado.

Estado Mundial Independente: Aplicações e jogos diferentes têm requisitos únicos, e alguns jogos usam runtimes personalizados. Portanto, uma abordagem universal de integração de todas as VMs através de um "estado mundial compartilhado" na VM de Polimorfismo não é adequada para todos os casos. Um estado mundial independente também é necessário, pois é mais simples de implementar e ideal para serviços com dados totalmente separados.

Independentemente da abordagem utilizada, esta deve ser verificável pelos Nós Supervisores. Isto significa que o Polymorphism VM deve incluir todas as VMs ou runtimes utilizados pelos vários métodos de implementação.

Exemplo de Portabilidade de Jogo Web2

O VM de Polimorfismo é altamente personalizável, tornando-o particularmente benéfico para os desenvolvedores Web2. Eles podem usar linguagens e estruturas familiares para portar qualquer lógica de negócios para o VM de Polimorfismo.

Suponhamos que o Minecraft queira fazer portabilidade para o Tabi. O processo geral seria o seguinte:

1. Modificar o Código do Servidor: Modificar ligeiramente o código do servidor Minecraft (Java ou qualquer outro idioma), movendo os dados que precisam estar na cadeia para um banco de dados (ou um conjunto de bancos de dados). Identificar e selecionar todas as funções que possam alterar este banco de dados (ou seja, funções de transição de estado).
2. Agrupe os Componentes: Agrupe este banco de dados e estas funções num ficheiro JAR, que é um programa executável em Java. Inclua o JRE (Java Runtime Environment) neste pacote. Este pacote completo é então carregado na VM de Polimorfismo, garantindo que todos os dados estão na cadeia.
3. Executar Lógica Fora da Cadeia: Executar outra lógica de backend que não precisa estar na cadeia (como formação de equipe, chat, etc.) em servidores fora da cadeia.
4. Iniciar um Serviço: Iniciar um Serviço na Cadeia Tabi e notificar o Polimorfismo VM dos Nós Supervisores para carregar o mesmo JRE.
   

Com isto, todo o processo está completo.

Para os desenvolvedores, estas modificações são feitas dentro da linguagem e estrutura Java existente. O mesmo conceito aplica-se a jogos desenvolvidos usando qualquer outro método. Para os utilizadores, a interação do jogo permanece em grande parte inalterada. Claramente, este método de portar jogos Web2 é muito rápido e eficiente, podendo tornar-se o modelo fundamental para a adoção em massa de jogos Web3.

Detalhes das Funções do Jogo STR (State Transition Runtime)

O exemplo anterior forneceu uma visão geral geral sobre a portabilidade de um jogo Web2. Para obter uma compreensão mais profunda, precisamos nos aprofundar em mais detalhes. Desta vez, usaremos um exemplo geral em vez de um jogo específico para ilustrar os detalhes envolvidos na execução da Camada de Execução Omni.

Essencialmente, personalizar o ambiente de tempo de execução de um jogo pode ser visto como criar a máquina de estados do jogo na blockchain, referida como o Tempo de Execução de Transição de Estado (STR) em Tabi.

O exemplo acima é o processo geral de portar jogos Web2. Ainda precisamos saber mais sobre os detalhes. Desta vez, usamos um exemplo geral em vez de um exemplo de jogo específico para mostrar os detalhes envolvidos na execução em tempo de execução na camada de execução onipotente.

Basicamente, personalizar o ambiente de execução de um jogo pode ser considerado como a criação de uma máquina de estado para um determinado jogo no blockchain, que é chamado de State Transition Runtime em Tabi.

STR pode ser integrado em Polymorphism VM na forma de binário ou módulo.

Num sistema semelhante a uma blockchain, precisamos garantir a transparência das entradas, a visibilidade pública das transições de estado e a expressividade do estado global. Para atender a esses requisitos, precisamos construir um tempo de execução com as seguintes características:

1. World DBContains all user data within the application that needs to be recorded on the blockchain. This data should be valuable and important, so a blockchain-like structure is needed to ensure its availability. Therefore, not all data needs to be recorded on the blockchain. For example, in games, the user’s chat content is generally not important and is disposable, so there is no need to put it on the blockchain.
2. Ele pode expressar o estado completo do mundo. Em muitos cenários, como em jogos, essa expressão não implica necessariamente um alto grau de rastreabilidade - um simples acumulador será suficiente, o que significa que uma estrutura de dados como uma árvore de Merkle nem sempre é necessária. No entanto, independentemente da estrutura de dados utilizada para representar o estado do mundo, é crucial que o estado do mundo do banco de dados possa ser expresso de forma resumida.
3. Qualquer função que possa causar alterações na base de dados mundial é chamada de função de transição de estado e deve ser encapsulada no tempo de execução da transição de estado. Qualquer modificação na base de dados mundial fora do tempo de execução deve ser considerada ilegal e rejeitada.
4. As interfaces de entrada e saída devem estar de acordo com o design do Intérprete de Entrada e do Propositor de Bloco. Isto é relativamente simples e não será explicado em detalhe aqui.

As seguintes estruturas organizacionais são elementos essenciais desta STR. Tabi fornecerá um SDK por padrão para facilitar os desenvolvedores a criar o tempo de execução.

Base de Dados Mundial

Na prática, um jogo ou aplicação provavelmente usará mais do que uma base de dados e estas bases de dados podem ser de tipos diferentes. Vamos supor que um determinado jogo utilize tanto uma base de dados relacional como uma base de dados chave-valor.

O seguinte é um exemplo simples de base de dados relacional:

1. UID: Representa um utilizador único, que pode ser uma chave pública ou outro identificador.
2. Nonce: usado para prevenir ataques de repetição.
3. Campos de dados extra: qualquer tipo de dados.

Esta é uma base de dados simples de chave-valor:

Função de Transição de Estado

Esta é uma função simples de transição de estado. Quando esta função recebe entrada do utilizador, simplesmente multiplica-a por 5 e modifica os dados na base de dados relacional.

Acumulador de Estado Mundial

Podemos construir um acumulador de hash simples para representar o estado do mundo:

A_s+1 = hash(A_s + hash(query))

Este método garante que após qualquer modificação no banco de dados mundial, haverá sempre um estado único e definitivo correspondente a essa modificação.

É importante notar que cada função de transição de estado deve implementar este método. Este requisito pode ser aplicado usando modificadores, interfaces, ganchos ou outros mecanismos específicos da linguagem. Devido às diferentes características de várias linguagens de programação, não entraremos em detalhes específicos aqui.

O processo de atualização de um banco de dados chave-valor (KVDB) segue o mesmo princípio.

Números Aleatórios

As funções de transição de estado não devem incluir números aleatórios, pois isso causaria resultados diferentes quando validados por verificadores diferentes, quebrando a consistência. Os números aleatórios devem ser incluídos como parte dos parâmetros de entrada do sistema.

Resumo

A partir dos exemplos acima, podemos ver que a Camada de Execução Omni da Tabi Chain fornece aos desenvolvedores de jogos uma flexibilidade significativa através de uma abordagem modular. Devido a restrições de espaço, não podemos discutir todos os detalhes aqui, mas os pontos principais mencionados são suficientes para demonstrar que a solução da Tabi Chain é tanto prática quanto inovadora.

No ecossistema Web3 atual, as obras desenvolvidas em diferentes chains e VMs geralmente carecem de portabilidade. Para os jogos Web2 fazerem a transição para o Web3, muitas vezes significa reescrever o jogo em idiomas e ambientes desconhecidos, enfrentando várias restrições incompreensíveis.

Com o Tabi, os desenvolvedores podem usar sua linguagem original, plataforma de desenvolvimento e mecanismo. Eles só precisam fazer adaptações e modificações simples, semelhantes à chamada de um SDK, para trazer seus projetos para o mundo da blockchain. Isso resulta em melhorias exponenciais na eficiência e reduções na complexidade.

Esperamos que a Tabi Chain possa tornar-se um catalisador para a adoção em massa de jogos Web3, atraindo talentosos desenvolvedores de jogos Web2 e trazendo jogos verdadeiramente divertidos e jogáveis para o espaço Web3.

Aviso legal：

1. Este artigo é reimpresso de [Gate极客 Web3]. Todos os direitos autorais pertencem ao autor original [罗奔奔]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa, e eles tratarão disso prontamente.
2. Responsabilidade de Isenção: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.