Os Mundos dos Jogos da Web3

tl;dr: uma continuação dos meus pensamentos sobre um jogo multijogador online que existe inteiramente na cadeia (on-chain). Esta parte contém meus pensamentos sobre o mundo do jogo.

Estou imaginando o futuro dos jogos online de olho em algo que seja da escala MMO, mas que substitua a antiga arquitetura de jogador para servidor por algo que é peer-to-peer. Para alcançar este futuro, acho que podemos empregar uma blockchain que armazene o estado do jogo na cadeia.

A razão para fazer isso é aproveitar as possibilidades oferecidas pela próxima geração de tecnologias da web (o que muitas pessoas chamam de “web3"). Posso prever que tais “jogos da web3” sejam auto-hospedados na internet “sem servidor“. Também quero ilustrar o fato de que jogos descentralizados que fazem uso da tecnologia blockchain também podem usar outra tecnologia descentralizada (não-blockchain).

Postagens Anteriores

Este artigo é o terceiro post de uma série de artigos relacionados.

No primeiro post, descrevi por que devemos colocar o estado do jogo na cadeia. Na segunda parte, sugeri que pudéssemos testar essa ideia criando um jogo simples inspirado em um jogo dos anos 80.

Neste artigo, também discrevi os desafios de armazenar e provar a validade do movimento do personagem e como isso afeta o combate, os níveis de experiência e a pilhagem.

No final do artigo, lancei algumas reflexões sobre o trading de pilhagem cross-chain. No entanto, o auge da interação cross-chain merece um pouco mais de atenção. Vou apresentar mais algumas ideias antes de entrar nas considerações sobre o estado do mundo do jogo.

Pensamento adicional sobre a interação cross-chain

Um ponto crucial a ser mencionado é que, embora eu ache que colocar o estado do jogo na cadeia trará novas possibilidades interessantes, o sucesso de tal jogo será limitado, a menos que haja uma incapacidade de permitir a interação cross-chain (e, portanto, entre jogos).

Visualizando a interoperabilidade cross-chain ( Fonte )

O que a interação cross-chain permitirá?

Os itens do jogo podem ser comprados em bitcoin, ether, dai, zkDai e qualquer outro token.
Os jogadores terão uma forte noção de propriedade de seus ativos do jogo. Essa propriedade será fácil de provar.
Os ativos do jogo (personagens/itens) podem ser reutilizados em qualquer outro jogo compatível.
Usando ativos do jogo na próxima onda de finanças descentralizadas (por exemplo, como garantia ou outra coisa). Não estou dizendo que você deve fazer isto, apenas que é possível.
Os jogos podem fazer uso de dados 'oráculo' armazenados em outra cadeia. Posso ver que isso é útil para jogos de azar: por exemplo, apostas que dependem de dados do mundo real.

Naturalmente, esses aspectos dependerão de um protocolo blockchain que forneça interatividade cross-chain, como Polkadot.

O Estado Mundial

Em um jogo blockchain, ou um jogo web3, onde o estado do jogo é registrado na cadeia, sugeri em meu post anterior que o estado é:

uma combinação do estado mundial (o mundo do jogo em que jogamos) e a agregação de todos os estados do personagem.

Caso contrário: concentre todos os estados de personagens individuais juntos para obter o estado de personagem agregado e, em seguida, adicione o estado do ambiente no qual o jogo acontece (“o mundo”).

Eu descrevi os estados dos personagens no post anterior, então neste post vou delinear o que eu acho que compõe o estado mundial.

O mundo é o ambiente com o qual os jogadores interagem: por exemplo, terreno, monstros, pilhagem, NPCs e outros objetos, como edifícios (incluindo casas de jogadores). Claramente, quanto mais conteúdo e recursos forem adicionados ao jogo, mais espaço de armazenamento será necessário.

Também é possível que os jogadores possam baixar uma grande quantidade de dados para começar (baixar um estado enorme, como faria para qualquer jogo moderno) e mantê-los sincronizados ao longo do tempo. Vale a pena notar que muitos MMOs modernos têm tamanhos de instalação de 10 GBs de dados, e isso representa um grande desafio para replicar em tal modelo, embora eu suspeite que muito disso seja gráfico e não precise ser armazenado na cadeia.

O primeiro jogo a adotar tal modelo provavelmente terá um jogo simples, com gráficos simples. No entanto, os dados mantidos na cadeia (pós-gênese) são as mudanças no mundo (ou pelo menos as provas das mudanças).

Estado Mundial (Localização Agregada)

O mundo provavelmente é composto de vários locais diferentes e é provável que o mundo não seja um único mapa contíguo. O estado mundial 'global' seria, obviamente, uma agregação das áreas individuais.

O estado mundial também precisará acompanhar os fatores do ambiente
Uma lista de jogadores presentes com sua localização (GUIDs do jogador + localização). Uma lista de itens presentes com sua localização (GUIDs de item + localização).
Outros fatores de ambiente.

Os jogadores provavelmente terão sua localização listada em seu próprio estado e eu debati se faria sentido também armazenar GUIDs do jogador no estado mundial. Por fim, acho que o estado mundial deve ser o mais simples possível e é redundante listar os locais dos personagens no mundo e no estado do personagem, mas acho que isso reduzirá o tempo de computação.

Talvez isso seja algo que não precise estar no estado mundial, pois está no estado do personagem e os clientes do jogo podem ter um meta-estado localmente e mantê-lo atualizado conforme o estado do jogo é atualizado. Há um debate semelhante para os estados dos itens também.

Tangente relacionada: Manter a privacidade das localizações dos jogadores será um desafio (como sugerido anteriormente).

Estado do item genérico

Aqui está uma proposição para as propriedades (estado) de um item genérico:

Posição
Proprietário
Stackable (Empilhável) (sim/não)
Quantidade de stack (sim/não)
Equipável (sim/não) [se um item pode ser usado]

O sistema de inventário do Ultima Online ( Fonte )

Os itens podem ser praticamente qualquer coisa, desde peças de ouro (que são Stackable) até espadas e casas (provavelmente nenhum dos dois é Stackable depois de implantado, se você permitir que sejam Stackable no inventário é uma escolha do desenvolvedor).

Potencialmente, há um item genérico ou modelo de ativo que permitirá que itens mais complexos sejam criados estendendo a classe do item ou talvez até mesmo permitindo que os itens sejam combinados (pensando na capacidade de composibilidade).

Os estados do NPC provavelmente são semelhantes aos dos personagens (que foi explorado no blog anterior), mas com algumas diferenças para explicar o fato de serem controlados pelo jogo e não pelo jogador. Eles manterão ativos em seu inventário que talvez possam ser pilhados após a morte.

Alguns NPCs farão parte do arco da história. Isso certamente implicará em outras propriedades a serem adicionadas ao estado de tais NPCs.

Desafios técnicos de um estado mundial on-chain

Há uma série de desafios técnicos a serem resolvidos para criar um jogo online que atenda às expectativas dos jogadores. São desafios que dizem respeito ao estado mundial.

Embora seja óbvio que a experiência gráfica diminuirá na primeira geração desses jogos, ainda há um nível básico de recursos necessários. Os desafios, em última análise, relacionam-se com os temas abaixo:

Escalonamento,
Privacidade,
Aleatoriedade,
Finalidade,
Incentivos.

Nas seções a seguir, descrevo alguns dos principais desafios e como eles se relacionam com os problemas de design de jogos blockchain.

Escalonamento via geração processual

No Rogue original, os níveis do jogo foram gerados processualmente. Acho que seria útil para o tipo de jogo que estou descrevendo aqui, pois acho que deveria reduzir a quantidade de dados armazenados na cadeia.

Um dos jogos gerados processualmente: Rescue On Fractalus ( Fonte )

Isso não exige que o mundo seja “aleatório” ou que seja diferente toda vez que você joga, mas sim que o mundo é gerado de forma determinística como um conjunto de sementes, em vez de ser armazenado na memória. Acredito que isso também alimentará a geração de monstros e pilhagens.

Escalonamento com zkSTARKs

Uma possibilidade interessante que surgiu no ano passado é o uso de zkSTARKs em blockchain. Eles devem ser capazes de fornecer privacidade, bem como fortes propriedades de escalonamento.

Embora o tamanho da prova dos STARKs seja grande em relação a métodos comparáveis, os tamanhos das provas não crescem muito, nem o tempo de verificação, com a complexidade da computação. Isso é ideal para jogos em que a privacidade é necessária e essa complexidade cresce rapidamente à medida que novos recursos são adicionados.

Visão geral dos esquemas ZK da palestra de Zooko Wilcox (de Zcash) na Devcon4.

Privacidade para itens, habitação e pilhagem

Dada a transparência das blockchains atuais, é difícil ocultar os dados que os jogadores esperariam manter privados. Nenhum outro jogador deve ser capaz de ver o que você tem em seu inventário, nem sua localização, nem a localização de algo como a casa de um jogador no jogo. Além disso, os jogadores não devem ser capazes de ver qual pilhagem é descartada por um monstro NPC antes de ser morto.

Embora os jogadores possam compartilhar o que está em seu inventário e ver outras pessoas e objetos nas proximidades, eles não devem poder consultar o estado da cadeia e saber onde as pessoas estão. Estar perto de outro jogador sempre foi um aspecto fundamental para saber algo sobre ele em jogos online anteriores. Potencialmente, você também pode compartilhar sua localização com amigos. Em uma arquitetura centralizada, isso é fácil de resolver. Em um jogo descentralizado, isso se mostra complicado.

A solução pode ser possível em algo como zkSTARKs, mas suspeito que algumas das questões de privacidade também podem ser resolvidas com uma tecnologia mais simples.

Aleatoriedade para recursos, pilhagem e monstros

A aleatoriedade na cadeia ainda é um desafio para a blockchain, mas é necessária para coisas como pilhagem e geração de monstros. Deve haver uma maneira de fazer com que os objetos apareçam aleatoriamente no jogo, mas o valor não pode ser conhecido com muita antecedência.

Os recursos serão gerados aleatoriamente em intervalos de tempo aproximados conhecidos, no entanto, não deve ser possível para jogadores experientes em código obter uma vantagem injusta sabendo quando os recursos serão gerados muito antes do evento acontecer.

Eu sei que os pesquisadores da Eth 2.0 e da Polkadot estão analisando a aleatoriedade na cadeia. Com Polkadot, existe o potencial de existir um farol de aleatoriedade em uma cadeia e, em seguida, enviar esses valores para outra cadeia (uma cadeia de jogo) para reutilização.

Pilhagem e finalização

Mencionei esse problema no post anterior, pois está relacionado aos estados dos personagens. A pilhagem é obtida de inimigos NPC mortos e, em seguida, armazenada nos inventários dos jogadores (caso os jogadores tenham pego os itens). Naturalmente, esses itens podem ser negociados de jogador para jogador, mas não queremos que jogadores que trapacearam possam trocar seus itens ilícitos.

Eu ri. ( Fonte )

Isso significa que provavelmente deve haver um atraso entre a coleta de um item e a troca desse item. Se um item coletado melhora as estatísticas de um jogador e, subsequentemente, afeta o resultado do combate (por exemplo, mortes mais rápidas), deve haver um atraso entre a coleta e a utilização. O atraso fornece tempo para a rede verificar se as ações foram válidas.

As ações válidas se tornarão finais, o que significa que não podem ser revertidas. Isso exige que tenhamos certeza de que não houve trapaça. Minha intenção para o design de jogos blockchain é que as ações sejam simples / fáceis de verificar, caso contrário, possivelmente não deveriam estar no jogo. Se ainda houver casos extremos em que a verificação falha, um mecanismo de governança on-chain seria útil para reverter ações maliciosas.

A introdução de algum elemento de atraso seria pelo menos a maneira mais segura, mas temo que isso possa prejudicar a experiência do usuário.

Incentivos para hospedagem e validação de dados

Idealmente, muitos dos jogadores hospedarão dados e participarão do compartilhamento com o restante da comunidade. Dito isto, provavelmente deveria haver um incentivo para fazer isso.

Semelhante ao mecanismo de incentivo de Polkadot, acho que se os jogadores fizerem stake em nós que eles nomearem como confiáveis para hospedar e validar dados, eles ganharão alguma recompensa da inflação por terem feito stake. Os nós que realizam a hospedagem e validação de dados (podem ser nós separados) podem receber uma quantidade adicional de inflação por seus problemas.

Este seria um jogo web3 auto-hospedado e autossuficiente. Acho que isso é atraente para os desenvolvedores de jogos, pois deve reduzir bastante o custo de ser o único provedor de hospedagem do jogo. Além disso, elimina o tempo de inatividade e existe a possibilidade de ter blockchains atualizáveis, conforme descrito em um blog da Polkadot (“Never Fork Again”).

Essas preocupações de disponibilidade e validação de dados são realmente comuns a todas as parachains dentro de Polkadot. Os desenvolvedores são um pouco livres para decidir como desejam impor isso, mas se não tiverem um plano sólido, há uma chance de que sua parachain seja rejeitada.

A seguir… governança e incentivos!

Na próxima parte, ofereço sugestões sobre como pagar pelo desenvolvimento de um jogo de código aberto auto-hospedado, além de algumas reflexões sobre a governança do jogo.

Próxima parte aqui: Governança e incentivos para um jogo Web3

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.