Como sincronizar o "estado" de todo o jogo em cadeia?

Por Fiona, IOSG Ventures

TL;DR

*Cadeia completa de jogos/mundos autônomos (“FOG/AW”) é uma das poucas narrativas importantes em torno da Web 3. Comparado com aplicativos Web2.5 que se conectam apenas ao Web3 por meio de NFT, o FOG/AW coloca a lógica do jogo na cadeia. Ele utiliza o blockchain como um servidor de jogos, tornando-se uma fonte descentralizada de confiança para o estado do jogo. Isso traz vantagens como persistência, resistência à censura, capacidade de composição, etc., mas também limita a variedade e a complexidade dos jogos construídos sobre ele.

• Com o aumento da complexidade e dos requisitos de jogabilidade do jogo, mais desafios são apresentados para a arquitetura do motor: como atraso de quadro, número aleatório, recuperação de saúde, efeito passivo contínuo, temporizador, etc. O conceito de unidades de tempo e Ticks são diferentes no blockchain. A lama fornece muitas ideias para simular a passagem do tempo e habilidades de recuperação passiva. Por exemplo, quando o jogador se move na sala, a transação consiste em mover todos os itens da sala de acordo com algum design predefinido. Use isso para perceber mudanças no tempo e no estado.
• A pilha de tecnologia FOG/AW pode ser abstraída como: os desenvolvedores escrevem códigos front-end e back-end para ui/ux e a lógica central do jogo, depois sincronizam todas as alterações por meio do loop de estado do jogo e, finalmente, refletem o novo estado no dispositivo local front-end pelo indexador.
• Uma vez que muitos tipos de jogos, como RTS, exigem altos tickrates, e blockchains produzidos por consenso só podem lidar com mudanças nos tempos de bloco, tickrate é um grande problema a ser resolvido aqui. Curio e Argus são líderes nesse aspecto e estão aumentando a taxa de marcação do jogo no nível da cadeia de fumble. A lama está tentando maximizar a cadeia completa e todo o estado do aplicativo é armazenado no EVM. Não há planos para introduzir a integração off-chain para obter uma taxa de ticks mais alta para o jogo.
• Para a seleção de diferentes cadeias, Dojo está liderando toda a ecologia da cadeia da Starknet. De acordo com a descrição de @tarrenceva, Starknet tem diferenças de estado de estado, que são diferentes de rollups otimistas e se concentram na saída da execução em vez da entrada. O impacto nos jogos provavelmente otimizará o custo, por exemplo, um jogo de xadrez: em um jogo de três minutos, podem ocorrer 50 jogadas. Através de diferenças de estado, uma única prova e estado final podem provar a “saída”. Por outro lado, rollups otimistas requerem “entradas” de todos os estados intermediários.

Defina FOG/AW: como o estado do jogo é sincronizado

Acho que para julgar se é FOG, o benchmark é como o estado do jogo é sincronizado (fonte da verdade).

Para jogos Web 2.5 ou jogos multijogador tradicionais, existe um servidor centralizado que define o estado atual do jogo e, quando os jogadores enviam ações, o servidor compila essas entradas e retorna os resultados atualizados para o dispositivo de cada jogador conectado. O servidor lida com todas as entradas (ticks), resolve inconsistências e envia periodicamente atualizações para o jogador, fornecendo um instantâneo de todos os elementos do jogo, atualizando o estado do jogo a cada tick. O **estado do jogo (“estado do jogo ou marca”) é um instantâneo no tempo das propriedades de cada objeto no mundo do jogo. Tickrate é o número de vezes por segundo que o servidor do jogo calcula e transmite o estado atualizado do jogo para os jogadores. Quanto maior o Tickrate, mais precisa e de alta fidelidade será a experiência de jogo. Em geral, jogos de estratégia ou ação em tempo real exigem alta. tickrate, enquanto jogos baseados em turnos, como jogos de cartas, não.

Fonte:

Para jogos executados inteiramente na cadeia, o blockchain é o servidor do jogo e atua como uma fonte descentralizada de confiança para o estado do jogo. Nesse caso, não apenas NFTs ou tokens têm propriedade real, mas até mesmo os tiques do jogador e a lógica do jogo estão na cadeia. É por isso que propriedade verdadeira, persistência, resistência à censura, capacidade de composição e muito mais são possíveis. Idealmente, todas as ações de um jogador devem ser submetidas ao blockchain e, após um consenso, o estado do jogo é atualizado e retornado ao dispositivo local. Portanto, naturalmente, os tipos de jogos que exigem menos tickrate são mais adequados para serem jogados inteiramente na cadeia.

** Resolva os desafios de atraso do jogo, tempo, etc.**

Com o aumento da complexidade do jogo e dos requisitos de jogabilidade, mais desafios são colocados para a arquitetura do motor: como atraso de quadros, números aleatórios, recuperação de vida, efeitos passivos contínuos, temporizadores, etc.

Atraso no número do quadro Na verdade, também é muito comum no mundo Web2, incluindo atrasos na renderização do cliente e nas operações do usuário. Especialmente para jogos de alta taxa de ticks como FPS, uma vez que há um atraso, a experiência do jogador será muito ruim. Uma das soluções no Web2 é a atualização de estado lockstep, que permite que todos os jogadores sejam sincronizados de acordo com o mais alto padrão de atraso entre os jogadores, de modo a resolver a experiência justa do jogador. Esse atraso pode ser ainda pior quando o blockchain é introduzido e as transações precisam ser confirmadas. Para isso, o Mud também adiciona o mecanismo de renderização otimista comumente usado em jogos, assumindo que a operação do usuário seja bem-sucedida e renderize-a no cliente antes que o servidor concorde (ou neste caso, antes que a transação seja confirmada).

Gerar números aleatórios na cadeia é um tópico frequentemente discutido. Mud acredita que o comportamento do usuário pode ser usado como entrada de resultados aleatórios e gerados após a ocorrência da interação.

O conceito de unidades de tempo e Ticks são diferentes no blockchain. @SebastienGllmt acha que é difícil usar timers em chains que usam conceitos à prova de fraude (como Op), porque uma vez que algo der errado, precisará ser revertido. Se timers forem usados no jogo, a experiência será ruim. A lama fornece muitas ideias para simular a passagem do tempo e habilidades de recuperação passiva. Por exemplo, aumentando as moedas de ouro ao longo do tempo, cada vez que o jogador executa uma operação que requer moedas de ouro, calcule a quantidade de moedas de ouro do jogador com base na contagem anterior de moedas de ouro do jogador, na contagem de atualização mais recente e na taxa de atualização. Por outro exemplo, quando o jogador se move na sala, a transação vem com a movimentação de todos os itens na sala de acordo com algum design predefinido. Use isso para perceber mudanças no tempo e no estado.

** Escrever scripts para “cheat” pode não ser um problema. **@BriefKandle não acha que o MEV do sistema do jogo está trapaceando. Prevenir o MEV com scripts simples é algo que a equipe do jogo precisa considerar. O desenvolvimento de jogos Web2 precisa mudar a maneira de pensar. Um bom bot MEV é um NPC no jogo.

Algumas dessas funcionalidades foram implementadas em alguns jogos on-chain lançados recentemente, como Rhascau, onde eles usam temporizadores e efeitos passivos contínuos. Basicamente, usando o tempo do bloco como um tick. (Na corrente L2, tempo de bloqueio = tickrate).

Pilha de tecnologia FOG/AW

A estrutura do mecanismo FOG/AW é uma pilha de ferramentas de desenvolvedor que permite aos desenvolvedores criar jogos usando o blockchain como servidor e fonte de confiança. Além disso, pode resolver alguns problemas atuais:

• Ineficiência na construção de FOG/AW on-chain devido à falta de estrutura padrão/pronta;
• Falta de modularidade e reutilização de código;
• Falta de capacidade de composição. Com o desenvolvimento do mecanismo FOG/AW, os jogos on-chain podem ser mais interessantes e imaginativos.

Para facilitar o entendimento, o processo técnico geralmente simplificado desse tipo de mecanismo é: os desenvolvedores escrevem códigos front-end e back-end para ui/ux e a lógica principal do jogo e, em seguida, sincronizam todas as alterações por meio do loop do estado do jogo e, finalmente, refletem o novo estado no dispositivo local front-end pelo indexador.

Para fazer com que os jogos rodando no blockchain funcionem sem problemas, Mud, Dojo, Curio, Argus, motor Paima e Lootchain estão desenvolvendo suas próprias pilhas de tecnologia para esse fim. A pilha de tecnologia consiste em 3 partes principais: cadeia, pilha de desenvolvimento principal e front-end do jogo. Todos eles têm suas próprias inovações, fazendo concessões entre descentralização e complexidade do jogo.

• Front-end do jogo: contém mecanismos tradicionais, como Unity, Unreal, etc., bem como react/Threejs e outras linguagens, além de ferramentas poderosas para fornecer renderização e outras funções, o que é uma parte indispensável para aprimorar a jogabilidade e a experiência do jogo. Os projetos acima podem basicamente fornecer SDKs relevantes para os desenvolvedores usarem.
• Pilha de desenvolvimento principal: Projete um conjunto de soluções para permitir que a lógica do jogo seja executada no blockchain e sincronize com o front-end no prazo. Os principais componentes incluem uma estrutura de banco de dados apropriada (definindo o comportamento e a lógica do jogo) e sincronização e retorno do estado do jogo.
• Chain: A maioria deles escolhe construir em Ethereum, Optimism e Starknet.

A figura abaixo descreve como diferentes protocolos projetam suas respectivas pilhas de tecnologia. Tome o Mud V2 como exemplo para ver seu fluxo de operação:

1. Um desenvolvedor chamará algumas ferramentas de front-end Web2 no Mud para escrever código e usará essas funções poderosas, como renderização, para tornar o jogo mais visual e divertido;
2. Ao mesmo tempo, os desenvolvedores escreverão os personagens, itens e a lógica de operação específica do jogo de acordo com a estrutura de contrato inteligente de Mud (Mud World), como quando o herói A se move de X para Y e inicia uma cruzada contra a terra Y, qual probabilidade ou sob quais circunstâncias a terra pode ser ocupada com sucesso;
3. As ações acima e o estado do jogo serão registrados no Mud Store, que é um banco de dados on-chain responsável pelo estado global do jogo e uma fonte de confiança para sincronização do estado do jogo;
4. Quando o herói A ataca Y, o jogador realmente clica com o mouse na máquina local front-end e envia o comando para ser carregado na cadeia. O comando é baseado na lógica de design do jogo do desenvolvedor e no estado atual do jogo na Loja, resultando em um resultado. O resultado é atualizado para o novo estado global do jogo e sincronizado com a cadeia;
5. O Games on Mud oferece suporte a vários front-ends, como Web e Mobile, mas pode enfrentar requisitos de indexação complexos. O Mode é um indexador off-chain desenvolvido para essa finalidade.

Agora, vamos falar sobre os designs comuns e diferentes dessas estruturas principais.

• A maioria deles segue o design Mud v1 e utiliza ECS como estrutura de dados para desenvolvimento de jogos. É assim que a lógica do jogo é escrita e apresentada. O Mud V2 o aprimorou e os dados são definidos em Tabelas e s, o que permite outros padrões de dados (não precisa estar em conformidade com o padrão de modelagem de dados ECS como V1), o que oferece aos desenvolvedores mais opções e o torna mais inclusivo.
• A maioria usa bancos de dados descentralizados, pois o blockchain é naturalmente a fonte de confiança para o estado do jogo e banco de dados. A lama está tentando maximizar a cadeia completa e todo o estado do aplicativo é armazenado no EVM. Não há sacrifício de descentralização ou introdução de esquemas de integração off-chain para alcançar um tickrate mais alto para o jogo.
• Como muitos tipos de jogos, como FPS, exigem altos tickrates, e blockchains produzidos por consenso só podem lidar com mudanças nos tempos de bloco, o tickrate é um grande problema a ser resolvido aqui. Em seus designs inovadores, Curio e Argus são os primeiros a esperar aumentar as taxas de ticks no nível da cadeia.
• Para a seleção de cadeias diferentes, Curio e Loot usam Caldera para construir cadeias de pilha Op. Além disso, Dojo está liderando toda a ecologia de cadeia de Starknet. De acordo com a descrição de @tarrenceva, Starknet tem diferenças de estado de estado, que são diferentes de rollups otimistas e se concentram na saída da execução em vez da entrada. O impacto nos jogos provavelmente otimizará o custo, por exemplo, um jogo de xadrez: em um jogo de três minutos, podem ocorrer 50 jogadas. Através de diferenças de estado, uma única prova e estado final podem provar a “saída”. Por outro lado, rollups otimistas requerem “entradas” de todos os estados intermediários.

Já existem alguns jogos construídos nesses motores. Tanto Mud quanto Dojo estão realizando hackathons para atrair desenvolvedores para construir aplicativos. Curio acaba de lançar a demo do minijogo de Warcraft no ETHCC.

Obviamente, FOG/AW está se tornando um ecossistema chave para competição de cadeia pública.O AW (Mundo Autônomo) proposto por Lattice é um grande conceito, não limitado a jogos, mas também inclui muitos atributos como social e financeiro. Então, construído em cima disso está um mundo virtual imaginativo, o Metaverso. Podemos esperar algumas novas formas de aplicativos integrados, como jogos, redes sociais e finanças.

Referência: