Utilizando Polkadot Para Impulsionar o Futuro dos Jogos Multijogador Online

tl;dr : nesta matéria, proponho um jogo simples de RPG multijogador que existe inteiramente on-chain.

Agradeço ao meu colega Iggy ( Web3 Foundation ) por criar esta visualização incrível.

Este artigo é a continuação do meu artigo intitulado “Blockchain gaming: putting the state on-chain” (Jogos Blockchain: colocando o estado on-chain). Na primeira parte, descrevi alguns dos problemas da arquitetura centralizada de jogos online e sugeri como futuros jogos online poderiam se beneficiar do uso da tecnologia blockchain.

Neste blog de acompanhamento, proporei um jogo simples que se encaixa nessa arquitetura. Também me aprofundo em algumas possibilidades que são possibilitadas por uma rede blockchain interoperacional, como a Polkadot.

Estou imaginando um futuro em que os dados do jogo sejam armazenados em uma cadeia blockchain, um futuro em que os itens do jogo sejam comprados em Bitcoin, ether ou qualquer outro token, e os ativos do jogo podem aparecer em vários jogos da blockchain porque os jogadores têm a verdadeira propriedade.

Nesta matéria, considero apenas parte dos requisitos para dar vida a um jogo como esse. Eu me concentro principalmente como os personagens de tal jogo. Considerações sobre como o mundo deve funcionar virão em um post de acompanhamento.

Recapitulação dos problemas identificados

Em meu blog anterior, descrevi por que poderíamos querer colocar todo o estado do jogo on-chain. Eu fiz alusão à capacidade de verificar ações e também melhorar a propriedade do item. Os dados que estão on-chain devem ser fáceis de verificar, o que significa que as ações do jogador serão fáceis de verificar.

Os principais problemas são:

• A propriedade de itens é ruim no modelo atual de jogos online.
• A verificação de ação é fraca e altamente assíncrona.

Com blockchains, você obtém um acordo consensual e uma história iterada criptograficamente protegida.

Interação entre cadeias com Polkadot (Fonte)

Além de resolver esses problemas, gostaria de ver interações entre cadeias em que os jogadores de um jogo pudessem aparecer em outro (itens, estatísticas e tudo!). Naturalmente, isso significaria que o estado poderia ser bastante grande e, se tais dados fossem despejados em uma blockchain atual, eles iriam inflá-la. Isso requer sidechains (comparar com Rede POA) ou parachains (comparar com Rede Polkadot).

O primeiro jogo a fazê-lo provavelmente será bastante simples e é exatamente isso que pretendo descrever no restante deste artigo. No entanto, uma ideia bastante radical seria construir o jogo para ter sua própria instância de Polkadot e que os jogadores sejam suas próprias parachains.

Rogue: olhar para trás para seguir em frente

Dados os problemas de escalabilidade que vimos quando o CryptoKitties atingiu o pico de popularidade, provavelmente parece uma sugestão maluca colocar todo o estado de um jogo on-chain. No entanto, acredito que seja possível se empregarmos as técnicas mais recentes de escalonamento de blockchain.

Estamos muito longe de colocar a totalidade de um jogo complexo como EVE ou World of Warcraft em uma blockchain, e não tenho como adivinhar um prazo para quando isso pode ser possível, mas, em vez disso, delinearei um jogo simples que poderia ser viável "encaixar on-chain".

Pessoas de uma certa época se lembrarão com carinho de jogar Rogue. Um clássico jogo de RPG de 1980 que inspirou uma miríade de clones desde a sua criação. É um RPG tão simples quanto você encontrará e é exatamente o que eu acho que a próxima geração de jogos blockchain poderia ser. A mecânica, pelo menos, mas com gráficos melhores!

Existe até uma indústria artesanal de amadores criando novos jogos Roguelike e, melhor ainda, uma infinidade de tutoriais para aprender como criar um. Descobrir o básico é fácil!

Rogue. Um jogo clássico de 1980 (Fonte: Wikipedia)

A simplicidade do Rogue significa que os requisitos de dados devem ser pequenos o suficiente para que o estado possa caber confortavelmente em uma blockchain dedicada. Dado o poder dos computadores modernos e a quantidade de dados que podemos potencialmente obter, provavelmente podemos levar os jogos blockchain além de um Rogue multijogador e ser mais comparável ao Ultima Online.

Nota sobre os gráficos

Os gráficos não precisam necessariamente ser armazenados on-chain. Um simples conjunto de sprites (é um objeto gráfico bi ou tridimensional que se move numa tela sem deixar traços de sua passagem) certamente pode ser armazenado dentro do cliente do jogo. Obviamente, eles não devem ser enviados por meio de extrínsecos (transações). Se os jogadores usarem essencialmente o mesmo cliente, eles verão o que os outros jogadores veem. Pequenas modificações nos gráficos não devem realmente afetar a jogabilidade. O que importa é que os jogadores possam verificar os movimentos e ações uns dos outros.

Estado do jogo: com o que se parece?

Espero que o estado do jogo seja uma combinação do estado do mundo (o mundo do jogo em que jogamos) e a agregação de todos os estados do personagem. Potencialmente, só precisamos salvar as provas de estado on-chain: ou seja, em um encontro entre dois jogadores, eles devem ser capazes de verificar se seus respectivos personagens são válidos.

Se os personagens do jogo não estiverem armazenados on-chain, pode ser aceitável, então realmente precisamos de uma prova de que o estado do jogador (ou seja, estatísticas do personagem, como posições, força, etc.) é válido. Isso ajudaria a reduzir a quantidade de armazenamento on-chain, mas pode aumentar os tempos de computação.

Um estado de personagem individual:

• Identificação do personagem (por exemplo, GUIDs, nome)
• Estatísticas do personagem (por exemplo, posição, velocidade, força, etc.)
• Itens (por exemplo, armas, armaduras/roupas, moeda do jogo)
• Opcional: feitiços mágicos e habilidades semelhantes.
• Hash do estado atual do personagem

Nesse modelo de jogo, personagens e itens são NFTs. Todos os personagens e cada item individual serão identificados por Identificadores Únicos Globais (GUIDs). Acho que tanto um número de sequência quanto um hash do público seriam o ideal: o último como endereço de pagamento e o primeiro como uma forma simples de identificar cada personagem.

Um exemplo de estatísticas de personagem no Ultima Online ( Fonte )

Se formos criativos, há muito mais estatísticas que podem ser adicionadas, mas o ponto principal deste artigo é apenas obter um estado razoavelmente mínimo de características para um jogo multijogador simples, mas funcional.

Como os estados do personagem serão compostos de vários tipos de token, parece provável que algo como ERC 1155 seja de grande utilidade para este modelo que estou propondo. Eu estava lendo sobre esse novo padrão de token e queria incluí-lo aqui. Blockgeeks também escreveu um bom ERC-1155.

Não sugeri adicionar estatísticas vazias ao estado do personagem em antecipação a futuras atualizações do jogo, mas acho que novas estatísticas podem ser adicionadas por meio da governança (um tópico para uma postagem posterior no blog).

Um pensamento subdesenvolvido é que poderia haver uma estatística de “penalização de tempo”. A ideia é que os jogadores mal comportados possam receber um tempo limite, em vez de cortar seus fundos. Eles não seriam capazes de se mover ou executar qualquer ação até que um número de bloco declarado no futuro fosse descongelado novamente.

Ações são transições de estado

Quando o mundo do jogo é atualizado ou o estado de um jogador é alterado, essas atualizações são armazenadas on-chain. Qualquer atualização no estado de uma blockchain é feita por meio de uma função de transição de estado. Esta é a parte cara de ter um jogo que armazena o estado on-chain.

Não precisa de gás!

Não precisa de gás! ( Fonte da imagem )

Colocar tal jogo em uma blockchain de uso geral, como Edgeware ou Ethereum, incorrerá em custos de gás. Dada a incrível generalidade de ambas as cadeias, é absolutamente necessário ter ações medidas (combustível) para evitar loops infinitos.

Se os desenvolvedores criarem uma blockchain com Substrate, eles terão a liberdade de criar uma blockchain personalizada para seu caso de uso. Não é necessário construir um jogo no topo da blockchain Turing-complete (refere-se à ideia de que, dado um tempo infinito, qualquer programa em uma linguagem pode ser escrito em outra) os jogadores não estarão implantando contratos inteligentes genéricos.

As ações do jogador (transições de estado) serão bem definidas e altamente limitadas. Eles não terão permissão para realizar um número ilimitado de ações. Existem limites razoáveis ​​para o que se espera que um jogador faça em uma determinada janela de tempo. Portanto, podemos considerar a remoção total dos custos de gás.

Movimento do jogador

Acho que lidar com o movimento do jogador será um dos desafios mais difíceis de acertar. Potencialmente, o movimento será baseado em turnos na primeira iteração de tal jogo, mas, em última análise, não acho que seja estritamente necessário. Idealmente, os movimentos de um jogador aparecem suaves e fluidos nos gráficos do jogo.

O cliente front-end capturará um fluxo contínuo de entrada do teclado e do mouse, mas os dados armazenados em um bloco obviamente são discretos. É importante que jogadores próximos vejam seus movimentos em tempo real (assim como você); no entanto, o fluxo exato de movimentos não precisará ser replicado on-chain.

Alguma quantidade de compartilhamento de dados entre jogadores na mesma área pode ser feita ponto a ponto, off-chain, para garantir que os elementos gráficos sejam integrados. Isso será particularmente necessário para o combate. Os dados de movimento que estão comprometidos com a cadeia precisam ter verificações de consistência para evitar que os jogadores trapaceiem, mas não será necessário verificar todos os pequenos movimentos.

Uma verificação simples de consistência é se a mudança de posição, do final do bloco anterior para o final do novo bloco, foi maior que a velocidade máxima permitida do jogador.

Ilustração da divisão de um caminho em partes distintas.

Se os dados de movimento forem amostrados de forma que haja N número de “passos” por bloco, então cada passo pode ser verificado se a mudança na distância ao longo do tempo não foi maior que a velocidade máxima do jogador (por exemplo, dx/dt =< max_speed). Um problema aqui é que o tempo entre os blocos (blocktime) não é fixo, mas acho que haverá uma solução prática aqui para que não seja um grande problema.

Claramente, isso pode produzir muitos dados e talvez muitos desses dados sejam essencialmente ruído. Minha proposta não está totalmente otimizada, então será interessante ver o que os desenvolvedores podem criar ao lidar com esse problema.

Determinismo: fixo x ponto flutuante: como a sandbox Wasm fornecida pelo Substrate é completamente determinística por design, não há números de ponto flutuante. Floats são uma maneira natural de representar decimais, mas eu suspeito que não há problema em usar pontos fixos para resolver esse problema. Também não acho que precisamos de grande precisão para os dados armazenados on-chain.

Implementação de exemplo: se o jogo for executado no navegador, a parte front-end do cliente poderá ser escrita em javascript (+HTML). Enquanto o front-end captura o teclado e o mouse, os dados devem ser 'enviados' para o cliente Substrate que fornece o back-end. Um módulo Substrate colocará os dados em um extrínseco (uma “transação”) e os enviará para os outros nós da rede.

A lógica do jogo será executada no front-end, enquanto o back-end será responsável por verificar os dados e colocá-los on-chain. O back-end do Substrate também verificará os novos blocos que vêm do resto da rede.

Semelhante a Polkadot, os blocos podem ser produzidos rapidamente com finalidade probabilística, mas a finalidade absoluta pode vir depois (comparar com GRANDPA). Para negociação entre cadeias de ativos de jogo, será necessário ter finalidade absoluta eventualmente.

Privacidade da posição: Qualquer um que jogue jogos online saberá que sua posição não é transmitida para todos os jogadores. É conhecido apenas por amigos ou jogadores em sua vizinhança imediata. Se a posição for armazenada on-chain, ela será pública por padrão. Isso requer mais reflexão.

Combate, níveis e experiência

Conforme mencionado, as estatísticas do jogo serão armazenadas on-chain. Os pontos de experiência e a progressão das estatísticas também serão armazenados on-chain. A atualização das estatísticas do jogador envolve a atualização do estado do jogo e é realizada pela função de transição. O combate depende dos movimentos do jogador serem precisos e válidos, por isso é necessário resolver os problemas com o movimento antes de trabalhar no combate.

Embora o combate seja calculado no cliente do jogo, o resultado deve ser verificado pelos outros nós da rede. Consequentemente, os pontos de experiência (e novos níveis de combate) não podem ser concedidos até que os blocos correspondentes sejam finalizados.

Isso também deve valer para o saque: as recompensas ganhas dentro do jogo não podem ser usadas/gastas até que os blocos relevantes sejam finalizados. Se um jogador mata um monstro e pega moedas de ouro, o jogo deve bloquear a recompensa sendo gasta até que seja finalizada. Essa seria pelo menos a maneira mais segura, mas temo que possa prejudicar a experiência do usuário.

Se os blocos forem revertidos, será problemático para o jogo. Nos jogos online atuais, as transações são sempre definitivas. Finalidade probabilística pode ser boa para jogabilidade de mundo aberto, mas em jogabilidade instanciada (por exemplo, masmorras), onde as recompensas podem ser maiores, podemos confiar na finalidade absoluta antes de atribuir recompensas totalmente.

Negociação de saques em cadeia cruzada

Depois que o saque for coletado após o combate e os blocos finalizados, será possível trocar esses itens do jogo com outros jogadores. Além disso, com as transações entre cadeias, seria possível negociar ativos entre as cadeias e, portanto, entre os jogos.

Visualizando a interoperabilidade entre cadeias ( Fonte )

Uma espada em um jogo hospedado na Polkadot pode ser trocada para outro jogo e usada lá. Naturalmente, há um nível de confiança necessário entre os dois. Os jogos devem idealmente confiar mutuamente nas transições de estado um do outro.

O comércio entre cadeias é auxiliado pelo fato de que cada item, e até mesmo cada personagem, é um NFT. O mesmo pode ser verdade para as terras do jogo e talvez qualquer outro ativo de valor concebível. A 'mágica' é que todos eles são ativos únicos. Isso não quer dizer que eu tenha uma solução exata para isso funcionar, mas, curiosamente, uma das equipes construídas no topo de Polkadot indicou que construiria uma troca NFT (no momento em que escrevo, o site está inativo).

A seguir…

Na próxima parte, discutirei mais sobre o estado do jogo, em particular o mundo do jogo, que faz parte do estado on-chain do jogo. Também haverá consideração para incentivos: tanto para hospedar os dados do jogo quanto para pagar pelo trabalho de desenvolvimento futuro.

Próximo post: Os mundos da Web 3 Games

---

Sobre mim

Atualmente, trabalho na Web3 Foundation, cobrindo inúmeras responsabilidades (como segurança e comunicações). Este blog é de natureza pessoal. Acontece que meu hobby se alinha com o trabalho.

Um dos principais projetos da fundação é a rede Polkadot. Uma plataforma blockchain de próxima geração. Para ler mais sobre a inovação que a Polkadot está trazendo para a indústria de blockchain, convido você a ler a seguinte postagem no blog: link.

Perguntas / Comentários?

Você pode entrar em contato comigo no Twitter: @EAThomson.