Os ideais da web3 parecem se encaixar perfeitamente no setor de jogos e na tendência de gamificação dos últimos anos. Já faz algum tempo que nos foi prometida uma nova ruptura na forma de uma experiência única: jogos em cadeia. Com propriedades como a descentralização, que desloca o equilíbrio de poder dos operadores históricos do setor de jogos muito mais para as entidades criativas, a capacidade de composição que rompe as paredes dos jardins há muito fechados e a verdadeira propriedade para os jogadores.

Mas esses ideais poderosos permanecem em segundo plano, pois ainda não os vimos na prática. O MUD é a primeira tentativa corajosa de criar uma estrutura completa para jogos on-chain, uma faísca que pode acender a próxima geração de jogos. Isso não é um sonho impossível. Em seu curto período de vida, a equipe do MUD é responsável pelo OPcraft, um jogo 3D real com o tema Minecraft totalmente on-chain.

Lições do setor de jogos tradicionais

Muito pode ser dito sobre a obsessão de inovar, construir tudo do zero e criar uma criatura totalmente nova. Mas, com relação aos jogos, há dezenas de anos de lições sobre padrões de design e a criação de um novo nicho de engenharia que deve ser levado a sério. Ignorar isso é o equivalente a tentar criar um jogo AAA com tecnologia Atari.

Quando olhamos para os primeiros anos do desenvolvimento de jogos, podemos ver uma semelhança inconfundível com os jogos na cadeia - grandes quantidades de talentos e projetos altamente inspiradores, mas também uma falta de coordenação e estruturas claras.

Nos primórdios dos videogames, antes do surgimento dos mecanismos de jogos, foram estabelecidas convicções e padrões de design. Videogames diferentes tinham pouco em comum, até certo ponto, jogos semelhantes podiam ter uma base de código completamente diferente. Mas com a introdução dos mecanismos de jogos, tudo mudou.

É difícil estabelecer exatamente uma distinção clara entre os mecanismos de jogos e os próprios jogos. Em geral, os mecanismos de jogos são estruturas com um conjunto de regras e padrões de design que podem ser ligeiramente modificados e ampliados para criar diferentes implementações de jogos. Nos anos 90, após anos de desenvolvimento fragmentado de jogos, algo mudou, e os mecanismos de jogos "baseados em gênero" e alguns esforços para desenvolver mecanismos de uso geral assumiram a liderança. Jogos como Doom e Unreal tinham componentes centrais que podiam ser reutilizados para criar muitos jogos diferentes. Jogos com gêneros semelhantes começaram a compartilhar muitas de suas implantações lógicas principais. O custo e a complexidade do desenvolvimento de jogos de corrida, luta e tiro em primeira pessoa diminuíram em ordens de magnitude. O impossível se tornou possível, e gerações de jogos e códigos atualizados se acumularam uns sobre os outros. Do ponto de vista do software, esse é um dos principais motivos pelos quais o desenvolvimento de jogos se tornou um grande setor.

Existem alguns problemas centrais associados aos jogos na cadeia:

1. Falta de estruturas: Cada equipe está tentando construir tudo do zero, o que resulta em baixa eficiência e falta de conhecimento sistêmico após a experiência agregada de construtores que lidam com os mesmos problemas e otimizam as melhores soluções.
2. Falta de reutilização do código: Veja muitos dos jogos on-chain que estão sendo desenvolvidos atualmente. Quantos deles podem ser copiados com sucesso para criar jogos ligeiramente diferentes? Quantos deles têm uma distinção clara entre diferentes camadas e componentes do jogo que permite criar uma nova geração com uma base de código semelhante? A promessa de criar o projeto de código aberto mais significativo e interconectado para jogos parece distante.
3. Falta de capacidade de composição de dados: Isso não termina com a reutilização do código. Trata-se também da capacidade dos jogos on-chain de aproveitar o estado compartilhado da blockchain para construir um sobre o outro usando os dados do jogo A no jogo B. Na prática, é preciso muito trabalho e recursos para incorporar os dados e a lógica de um jogo no outro.

A solução do MUD:

O Mud é a primeira tentativa corajosa de criar um mecanismo e uma estrutura para jogos na cadeia, fornecendo a estrutura para manutenção, atualização e moldabilidade. O padrão ECS (Entity Component System, sistema de componentes de entidade) defendido por mud faz sentido não apenas no sentido do desenvolvimento geral de jogos, mas ainda mais para o desenvolvimento de jogos na cadeia.

ECS em contratos inteligentes:

Os blocos de construção mais básicos do MUD são os componentes. Eles são contratos implantados que funcionam como bancos de dados que armazenam dados sobre entidades. Por exemplo, vamos considerar uma entidade (um endereço) como a carteira do jogador. Essa entidade representada por um endereço pode ter propriedades diferentes, como valor de posição (x,y) no componente de posição, nível 10 no componente de nível e 50 no componente de moedas. Os componentes consistem apenas em um mapeamento e em uma configuração básica. Os sistemas são mais complicados e implementam a lógica de alterar o valor nos componentes. O senhor pode pensar nisso como sistemas que especificam a API para solicitações POST nos bancos de dados (componentes). Eles só poderiam fazer isso se tivessem acesso de gravação a componentes específicos. Aqui a coisa fica interessante. Os sistemas podem interagir com diferentes componentes para criar uma lógica detalhada. O senhor pode ter um sistema de movimento que especifica o movimento válido que o jogador pode fazer (por exemplo, dois passos de cada vez) e pode ter um sistema de recompensa que dá moedas aos jogadores sempre que eles sobem de nível. Todos eles são registrados no "contato mundial", de modo que cada alteração nos dados do componente é seguida por um evento emitido. Os contratos mundiais não têm permissão. Qualquer pessoa pode adicionar novos sistemas e componentes. Em teoria, mundos diferentes podem interagir uns com os outros.

Trazer o ECS para jogos on-chain resulta em uma estrutura muito elegante, de modo que o OPcraft consiste em apenas 10 componentes e cerca de 15 sistemas. O senhor pode conferir esta excelente postagem no blog do MUD.dev

Verdadeira capacidade de composição

O sistema ECS não só faz todo o sentido no desenvolvimento de jogos tradicionais, mas ainda mais nos jogos on-chain, pois oferece dois recursos importantes

1. Possibilidade de atualização do jogo implantado
2. O mais alto grau de capacidade de composição

Imagine dois caminhos. Uma delas é preservar o design básico. E a outra é mudar a lógica central do jogo.

Pense em um jogo de estratégia PVP padrão no qual os jogadores podem construir exércitos para lutar entre si. A versão básica era 2D, mas agora a equipe decidiu que deseja criar uma renderização 3D detalhada do jogo. Tudo o que eles precisam fazer é pegar todos os sistemas relacionados à posição e criar versões atualizadas com coordenadas (x,y,z) em vez de (x,y). Todos os outros sistemas e componentes (como sistema de ataque, HP e formação de exército) podem permanecer os mesmos. As comunidades podem criar diferentes mods do jogo reimplantando sistemas e componentes ou até mesmo interagir com os mesmos componentes concedendo acesso de escrita a novos sistemas (se for um jogo de propriedade da comunidade, vários modelos de governança podem ser aplicados a esses tipos de decisões).

A outra abordagem manterá os mesmos componentes e sistemas sem dar acesso de gravação aos novos sistemas. Mas, com componentes e sistemas adicionais para ampliar as funcionalidades do jogo, como ele poderia ser? Considere um jogo de xadrez básico na cadeia. Os sistemas de movimentos e regras já estão implantados. As pessoas podem jogar o jogo como se estivessem jogando xadrez na vida real, mas talvez a sua equipe decida que é necessário criar uma camada adicional, uma camada social que consista em um sistema de classificação para a formação de partidas ou qualquer outro caso de uso. Tudo o que o senhor precisa fazer é adicionar um componente de classificação e um sistema com regras de classificação. Isso resulta não apenas em uma mudança perfeita para novas versões do jogo (UX aprimorada), mas também cria os meios técnicos para que diferentes versões coexistam lado a lado ou umas sobre as outras no nível do contrato inteligente. Os jogadores podem permanecer em várias versões do jogo enquanto interagem com os mesmos dados dos componentes principais, o que é muito inovador, além dos aplicativos de composição. Ele cria um recurso de imutabilidade opt-in, criando outra dimensão de propriedade que os jogos on-chain proporcionariam. A verdadeira propriedade de diferentes ativos do jogo (como pontuação, NFTs, conquistas) é garantida por uma lógica imutável que pode ser estendida com atualizações adicionais, mas que não muda em seu núcleo. Ele resolve um dos principais problemas dos jogos da Web3, que é a capacidade dos criadores de enfraquecer os recursos sem consentimento.

Do lado do cliente, uma perspectiva geral:

Observe que o MUD é um projeto em andamento. A próxima parte pode não estar atualizada e conter algumas imprecisões e distinções grosseiras, mas não se espera que a arquitetura geral seja alterada drasticamente.

Até agora, analisamos o MUD no nível do contrato inteligente. Mas há muito mais. O MUD oferece um conjunto completo de bibliotecas e camadas de clientes. Existem alguns recursos exclusivos para os quais o MUD foi projetado.

1. Capacidade de composição do cliente
2. O cliente está totalmente sincronizado com a mudança de estado do blockchain (dados do jogo)
3. PhaserX como camada de renderização

Vamos nos aprofundar nos detalhes técnicos para tornar isso mais concreto.

Camada de rede:

A camada de rede é a camada de base do cliente. Ele contém a configuração básica (contrato mundial, jogo e configuração de rede) e a API para interações do jogo. Quando a camada de rede é criada, ela tem uma especificação de todos os diferentes componentes e sistemas com os quais o cliente poderá interagir, e o senhor pode optar por interagir apenas com componentes/sistemas específicos. Por exemplo, se quiser criar movimento no jogo e representá-lo no front-end, o senhor precisará criar uma camada de rede que sincronize com o contrato inteligente implantado do componente de posição e também com o sistema de movimento. Agora o senhor pode criar uma API Move que recebe uma posição e algum objeto (entidade) no jogo e define sua posição ou o move de um lugar para outro. Sempre que os jogadores usarem a API Move. Eles vão enviar uma transação para o blockchain. No caso do sistema de movimentação, eles executarão uma função dentro do contrato inteligente do sistema de movimentação.

Essa estrutura permite jogos baseados em vários clientes. Todos poderiam criar clientes exclusivos, e todos eles são igualmente válidos, desde que estejam sincronizados com o blockchain e sigam a estrutura básica da camada de rede. Vimos casos de uso muito interessantes para jogos com vários clientes, como no caso de uma floresta escura, em que os jogadores competem entre si, mas usam clientes e plug-ins diferentes. A estrutura do cliente nos permite implantar a camada de rede e modificar a API para obter diferentes versões do cliente com muita rapidez, atingindo um alto nível de moldabilidade e capacidade de composição do cliente.

O senhor pode se perguntar como exatamente os componentes do cliente se sincronizam com os componentes da cadeia. Esse é um dos grandes desafios que os criadores enfrentam ao lidar com o lado do cliente dos jogos na cadeia. O MUD tem algumas soluções para isso.

Primeiro, o MUD implementou um recurso de instantâneo que permite que o cliente sincronize com o estado do mundo (ou seja, valores de entidades por componentes) sem processar todos os eventos passados para reconstruir o estado, o que resulta em baixa latência e menor complexidade.

Além disso, o sistema de ID do MUD, no qual cada sistema e componente recebe um ID com base em seu nome e, após a implantação, eles são registrados no contrato mundial, o que torna muito mais acessível acompanhar as alterações, interagir com o jogo e buscar eventos facilmente.

Camada de renderização - quando e como os eventos são renderizados

O MUD é fornecido com o PhaserX, "um mecanismo altamente escalonável desenvolvido com base no phaser", mas o PhaserX não é obrigatório. No OPcraft, há um mecanismo de voxel Noa em vez do PhaserX. Em teoria, o senhor pode usar qualquer mecanismo que desejar, desde que ele siga a estrutura.

Conforme mencionado anteriormente, cada componente e sistema é registrado no contrato mundial e, quando ocorre uma alteração, um evento é emitido (com dados identificados, como ID do componente e ID da entidade). Aqui, o serviço de fluxo do ECS pode oferecer ao cliente a opção de escolher quais eventos deseja assinar.

A representação gráfica das entidades pode ser a que o senhor quiser. Um jogo de luta pode ter personagens de anime, cavaleiros ou até mesmo seus influenciadores de criptografia favoritos. Todas elas são versões válidas, desde que representem e reajam a eventos na cadeia.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[mirror], Todos os direitos autorais pertencem ao autor original[Matchbox DAO]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn (Gate Learn "Gate Learn"), que tratará do assunto prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.