Os ideais da web3 parecem encaixar-se perfeitamente na indústria dos jogos e na tendência de gamificação dos últimos anos. Há já algum tempo que nos é prometida uma nova disrupção sob a forma de uma experiência única - os jogos em cadeia. Com propriedades como a descentralização, que desloca o equilíbrio de poder dos operadores históricos da indústria dos jogos muito mais para as entidades criativas, a capacidade de composição que quebra as paredes dos jardins há muito fechados e a verdadeira propriedade para os jogadores.

Mas estes ideais poderosos permanecem à margem, pois ainda não os vimos na prática. 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. Não se trata de um sonho impossível. Durante o seu curto período de vida, a equipa do MUD é responsável pelo OPcraft, um jogo 3D com o tema Minecraft, totalmente em cadeia.

Lições do sector dos jogos tradicionais

Muito pode ser dito sobre a obsessão de inovar, construir tudo a partir do zero e criar uma criatura inteiramente nova. Mas no que diz respeito 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. Ignorá-los é 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 em cadeia - grandes quantidades de talentos e projectos altamente inspiradores, mas também uma falta de coordenação e de estruturas claras.

Nos primórdios dos videojogos, antes do aparecimento dos motores de jogo, foram estabelecidas convicções e padrões de conceção. Os diferentes jogos de vídeo tinham pouco em comum, até certo ponto, jogos semelhantes podiam ter uma base de código completamente diferente. Mas com a introdução dos motores de jogo, tudo mudou.

É difícil estabelecer exatamente uma distinção clara entre os motores de jogo e os jogos propriamente ditos. Geralmente, os motores de jogos são estruturas com um conjunto de regras e padrões de conceção que podem ser ligeiramente modificados e alargados para criar diferentes implementações de jogos. Nos anos 90, após anos de desenvolvimento fragmentado de jogos, algo mudou e os motores de jogos "baseados em géneros" e alguns esforços para desenvolver motores de uso geral assumiram a liderança. Jogos como o Doom e o Unreal tinham componentes essenciais que podiam ser reutilizados para criar muitos jogos diferentes. Os jogos com géneros semelhantes começaram a partilhar muitas das suas implantações lógicas fundamentais. O custo e a complexidade do desenvolvimento de jogos de corrida, de luta e de tiro na primeira pessoa diminuíram em ordens de grandeza. O impossível tornou-se possível e as gerações de jogos e de código atualizado acumularam-se umas em cima das outras. Do ponto de vista do software, esta é uma das principais razões pelas quais o desenvolvimento de jogos se tornou uma indústria enorme.

Existem alguns problemas fundamentais associados aos jogos na cadeia:

1. Falta de estruturas: Todas as equipas estão a tentar construir tudo a partir do zero, o que resulta numa baixa eficiência e na falta de conhecimento sistémico após a experiência agregada de construtores que abordam os mesmos problemas e optimizam as melhores soluções.
2. Falta de reutilização do código: Veja muitos dos jogos on-chain que estão a ser 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 construir uma nova geração com uma base de código semelhante? A promessa de criar o projeto de código aberto mais significativo e interligado para jogos parece distante.
3. Falta de capacidade de composição dos dados: Não termina com a reutilização do código. Trata-se também da capacidade de os jogos on-chain aproveitarem o estado partilhado da blockchain para se construírem uns sobre os outros, utilizando 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 motor e uma estrutura para jogos na cadeia, fornecendo a estrutura para manutenção, atualização e moldabilidade. O padrão Entity Component System (ECS) defendido por mud faz sentido não apenas no sentido do desenvolvimento de jogos em geral, mas ainda mais para o desenvolvimento de jogos on-chain.

ECS em contratos inteligentes:

Os blocos de construção mais básicos do MUD são os componentes. São contratos implementados que funcionam como bases de dados que armazenam dados sobre entidades. Por exemplo, pegue numa entidade (um endereço) como a carteira do jogador. Esta entidade representada por um endereço pode ter propriedades diferentes, como o valor da posição (x,y) na componente posição, o nível 10 na componente nível e 50 na componente moedas. Os componentes consistem apenas num mapeamento e numa configuração básica. Os sistemas são mais complicados e implementam a lógica de alteração do valor nos componentes. Pode pensar nisto como se os sistemas especificassem a API para pedidos POST nas bases de dados (componentes). Só o podem fazer se lhes for concedido acesso de escrita a componentes específicos. Aqui torna-se interessante. Os sistemas podem interagir com diferentes componentes para criar uma lógica detalhada. Pode ter um sistema de movimento que especifique 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 de cada vez que sobem de nível. Todos eles são registados no "Contacto mundial", de modo que cada alteração nos dados do componente é seguida de um evento emitido. Os contratos mundiais não têm autorização. Qualquer pessoa pode acrescentar novos sistemas e componentes. Em teoria, os diferentes mundos podem interagir uns com os outros.

Trazer o ECS para os jogos on-chain resulta numa estrutura muito elegante, de tal forma que o OPcraft é constituído apenas por 10 componentes e cerca de 15 sistemas. Pode consultar esta excelente publicação no blogue MUD.dev

Verdadeira capacidade de composição

O sistema ECS não só faz todo o sentido no desenvolvimento de jogos tradicionais, como ainda faz mais sentido nos jogos on-chain, fornecendo duas características importantes

1. Possibilidade de atualização do jogo implementado
2. O mais alto grau de composibilidade

Imagine dois caminhos. Uma delas é preservar a conceção de base. E a outra é a alteração da lógica do jogo.

Pense num jogo de estratégia PVP normal em que os jogadores podem construir exércitos para combaterem entre si. A versão de base era 2D, mas agora a equipa decidiu que quer criar uma renderização 3D detalhada do jogo. Tudo o que precisam de fazer é pegar em todos os sistemas relacionados com a posição e criar versões actualizadas com coordenadas (x,y,z) em vez de (x,y). Todos os outros sistemas e componentes (como o sistema de ataque, os PV e a construção do exército) podem permanecer os mesmos. As comunidades podem criar diferentes mods do jogo, reimplantando sistemas e componentes, ou mesmo interagir com os mesmos componentes, concedendo acesso de escrita a novos sistemas (se o jogo for propriedade da comunidade, podem ser aplicados vários modelos de governação para este tipo de decisões).

A outra abordagem manterá os mesmos componentes e sistemas sem dar acesso de escrita aos novos sistemas. Mas, com componentes e sistemas adicionais para alargar as funcionalidades do jogo, como é que ele poderia ser? Considere um jogo de xadrez básico na cadeia. Os sistemas de movimentos e regras já estão a ser implementados. As pessoas podem jogar o jogo como se estivessem a jogar xadrez na vida real, mas talvez a sua equipa decida que é necessário criar uma camada adicional, uma camada social que consista num sistema de classificação para a formação de partidas ou qualquer outro caso de utilização. Tudo o que precisa de fazer é adicionar um componente de classificação e um sistema com regras de classificação. Isto resulta não só numa mudança muito fácil para novas versões do jogo (UX melhorada), mas também cria os meios técnicos para que diferentes versões coexistam lado a lado ou umas sobre as outras ao nível do contrato inteligente. Os jogadores podem permanecer em várias versões do jogo enquanto interagem com os dados dos mesmos componentes principais, o que é muito inovador, para além das aplicações de composibilidade. Cria uma caraterística de imutabilidade opt-in, criando outra dimensão de propriedade que os jogos na cadeia proporcionariam. Verdadeira propriedade de diferentes activos do jogo (como pontuação, NFTs, conquistas) que é assegurada por uma lógica imutável que pode ser alargada com actualizações adicionais, mas que não muda no seu núcleo. Resolve um dos principais problemas dos jogos da web3, que é a possibilidade de os criadores enfraquecerem os activos sem consentimento.

Do lado do cliente, uma perspetiva global:

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

Até agora, analisámos o MUD ao nível dos contratos inteligentes. Mas há muito mais. O MUD fornece um conjunto completo de bibliotecas e camadas de clientes. Existem algumas características únicas para as quais o MUD foi concebido.

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

Vamos mergulhar nos pormenores técnicos para o tornar mais concreto.

Camada de rede:

A camada de rede é a camada de base do cliente. Contém a configuração básica (contrato mundial, jogo e configuração de rede) e a API para as interacções do jogo. Quando a camada de rede é criada, tem uma especificação de todos os diferentes componentes e sistemas com que o seu cliente poderá interagir, e pode optar por interagir apenas com componentes/sistemas específicos. Por exemplo, se quiser criar movimento no seu jogo e dar-lhe representação no frontend, terá de criar uma camada de rede que sincronize com o contrato inteligente implementado do componente de posição e também com o sistema de movimento. Agora pode criar uma API Move que recebe uma posição e um objeto no jogo (entidade) e define a sua posição ou move-o de um lugar para outro. Sempre que os jogadores utilizarem a API Move. Vão submeter uma transação à cadeia de blocos. No caso do sistema de movimento, eles vão executar uma função dentro do contrato inteligente do sistema de movimento.

Esta estrutura permite jogos com vários clientes. Todos poderiam criar clientes únicos, e todos eles são igualmente válidos desde que estejam sincronizados com a blockchain e sigam a estrutura base da camada de rede. Vimos casos de utilização muito interessantes para jogos com vários clientes, como no caso de uma floresta negra, em que os jogadores competem entre si mas utilizam clientes e plug-ins diferentes. A estrutura do cliente permite-nos implantar a camada de rede e modificar a API para obter diferentes versões do cliente muito rapidamente, alcançando um elevado nível de moldabilidade e composibilidade do cliente.

Poderá perguntar como é que os componentes do cliente se sincronizam exatamente com os componentes da cadeia. Este é um dos grandes desafios que os construtores enfrentam quando lidam com o lado cliente dos jogos na cadeia. O MUD tem algumas soluções para o efeito.

Em primeiro lugar, o MUD implementou uma funcionalidade de instantâneo que permite ao cliente sincronizar-se 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 numa baixa latência e numa menor complexidade.

Além disso, o sistema de ID do MUD, em que cada sistema e componente recebe um ID baseado no seu nome e, após a implementação, são registados no contrato mundial, tornando muito mais acessível acompanhar as alterações, interagir com o jogo e obter eventos facilmente.

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

O MUD vem com o PhaserX, "Um motor altamente escalável construído em cima do phaser", o PhaserX não é obrigatório. No OPcraft, existe um motor de voxel Noa em vez do PhaserX. Em teoria, pode utilizar qualquer motor que deseje, desde que siga a estrutura.

Como referido anteriormente, todos os componentes e sistemas são registados no contrato mundial e, quando ocorre uma alteração, é emitido um evento (com dados identificados, como o ID do componente e o ID da entidade). Neste caso, o serviço de fluxo contínuo ECS pode dar ao cliente a opção de escolher os eventos a subscrever.

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

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[mirror], Todos os direitos de autor pertencem ao autor original[Matchbox DAO]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn (Gate Learn "Gate Learn"), que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.