Antevisão dos jogos de cadeia completa: A evolução do motor de jogo Web2

01 A tecnologia subjacente impulsiona o desenvolvimento Leapfrog em jogos

O progresso na indústria do jogo está sempre a evoluir juntamente com os avanços na tecnologia. Desde mudanças nos gráficos e no som até mudanças no design de jogos e métodos de interação, todos contribuem para o desenvolvimento do jogo. O primeiro jogo desenvolvido pela Atari, Pong, é amplamente considerado como o primeiro jogo eletrónico de sucesso comercial, o que está a dar início a uma tendência nos jogos eletrónicos. Os anos 70 foram um período de rápido desenvolvimento para circuitos integrados. Em 1975, a Motorola introduziu o processador 6502, lançando as bases para o sucesso subsequente das consolas domésticas. O mais famoso pioneiro da consola doméstica, o Atari 2600, nasceu disso, fazendo do Pac-Man um nome familiar.

O jogo moderno é uma arte integrada e também uma tecnologia complexa. Os primeiros jogos eram relativamente simples em lógica de código e interação de interface. Os desenvolvedores estavam mais acostumados a trabalhar de 0 a 1, mas à medida que as capacidades melhoravam, a jogabilidade tornou-se mais diversificada e a tecnologia tornou-se mais complicada. Começar o desenvolvimento do zero tornou-se cada vez mais ineficiente. Na década de 1990, o advento dos CD-ROMs e das placas de aceleração gráfica 3D levou os jogos a novos patamares no conteúdo e no desempenho visual, levando a um aumento dramático na quantidade de código necessário para desenvolver um jogo. Contra este pano de fundo, surgiu o conceito de motores de jogo. Os desenvolvedores de jogos padronizaram algumas das tecnologias subjacentes e as integraram num conjunto de ferramentas eficiente para encurtar os ciclos de desenvolvimento, reduzir a complexidade e suportar lançamentos de jogos multiplataforma. O surgimento dos motores de jogo trouxe grande comodidade aos programadores. Estas funcionalidades modulares, generalizadas e normalizadas permitem que os programadores se concentrem mais no conteúdo do jogo e no design da jogabilidade. Hoje em dia, um motor de jogo maduro pode incluir sistemas para gráficos, física e cenas.

Em 1993, a Id Software usou o motor DOOM (Id Tech 1) para criar o jogo “Doom”, alcançando um tremendo sucesso com as vendas que atingiram 3,5 milhões de cópias no primeiro ano. O sucesso de “Doom” foi em grande parte atribuído ao seu design de arquitetura de software. A arquitetura do software do jogo foi dividida em componentes de software principais, ativos de arte, mundo do jogo e regras do jogo, entre outros. Esta divisão arquitetónica clara permite que diferentes programadores utilizem o mesmo motor e criem jogos inteiramente novos, produzindo novas artes, níveis, personagens, mundos de jogo e regras. O sucesso do motor DOOM despertou interesse na produção de MOD dentro da comunidade e tornou-se o primeiro motor de jogo comercial. Na década seguinte, os motores de jogo tornaram-se muito procurados, desde o Unreal Engine da Epic Games, ao CryEngine da CryTech, à Unity, que brilha na plataforma iOS. Para além dos motores comerciais, muitos fabricantes também construíram motores proprietários para uso interno, como o motor Source da Valve, o motor IW da Infinity Ward e o motor Anvil da Ubisoft.

02 Arquitetura ECS do Web3 Game Engine

Os dois motores de jogo blockchain mais conhecidos, MUD e DOJO, ambos utilizam a arquitetura ECS. ECS significa Entity-Component-System. É um padrão arquitectónico comum no desenvolvimento de jogos Web2 para gerir objetos de jogo (entidades), as suas propriedades (componentes) e comportamentos (sistemas). Os benefícios desta arquitetura incluem:

• Optimização de desempenho: A arquitectura ECS permite aos programadores de jogos gerir melhor o layout da memória e os padrões de acesso a dados, melhorando assim o desempenho do jogo. O arranjo próximo de entidades e componentes ajuda a reduzir as falhas de cache, melhorando a eficiência do acesso aos dados.
• Escalabilidade: Devido à dissociação de entidades e componentes, adicionar novas funcionalidades requer apenas a adição de componentes e sistemas correspondentes, sem alterar o código existente. Isto torna mais fácil expandir as funções e o conteúdo do jogo.
• Reutilização: Ao dividir os atributos em componentes independentes, estes componentes podem ser mais facilmente reutilizados para criar diferentes tipos de entidades, reduzindo assim o código redundante.

O MUD V1 é um exemplo típico da arquitectura ECS. No âmbito da V1, as Entidades são também as unidades básicas do jogo, que podem ser vários objetos, adereços ou endereços de carteira, identificados por um ID único. Os componentes são a parte de dados das entidades utilizadas para descrever diferentes atributos da entidade, tais como a localização dos objetos, atributos de caracteres, etc. Ao anexar diferentes componentes a entidades, podem ser criados diversos e variados objetos de jogo. Os sistemas lidam com a lógica dos Componentes, implementando várias regras e comportamentos do jogo. Existem na cadeia sob a forma de contratos inteligentes. Entidades, componentes, sistemas existem todos num contrato inteligente do Mundo, cada Mundos é equivalente a um ambiente de jogo independente.

Como é que esta arquitetura reflete a escalabilidade? Suponha que precisamos de atualizar uma funcionalidade no jogo ou a comunidade quer adicionar novos conteúdos. Primeiro, precisa dar à nova função do jogo/lógica (sistema) acesso de gravação a componentes relevantes. Em seguida, crie uma versão actualizada; outros conteúdos do jogo permanecem inalterados. Se não for concedido acesso de escrita, pode considerar a criação de novos componentes e sistemas com novas funcionalidades. Os jogadores podem escolher versões diferentes para jogar enquanto interagem com os mesmos dados dos componentes principais. Do ponto de vista dos Mundos, qualquer pessoa pode criar componentes e sistemas, tal como qualquer pessoa pode criar novos tokens ERC-20 e “anexá-los” a endereços.

03 Importância dos motores de jogos Web3 para o desenvolvimento de jogos Blockchain

Embora a tecnologia blockchain ainda não tenha chegado totalmente às aplicações diárias, as suas características únicas, tais como direitos de autenticação e transparência, trarão inevitavelmente mudanças importantes no campo dos jogos. Especialmente que as pessoas já testemunharam a enorme oportunidade trazida pelo DeFi. O que acontecerá se o jogo estiver totalmente em cadeia? Do DeFi, não é difícil inferir as mudanças que a blockchain vai trazer para o jogo:

• Sistema económico aberto: A Blockchain pode fazer com que os ativos virtuais no jogo tenham propriedade real e escassez. Isto significa que os jogadores podem verificar a raridade e a taxa de produção dos itens, evitando o controlo centralizado das empresas de jogos e a gestão dos ativos.
• Composição: Colocar o jogo no ambiente aberto da blockchain permite que diferentes jogos e projetos se complementem. O progresso dos jogadores num jogo pode refletir-se noutros jogos, mesmo na partilha de ativos, criando um ecossistema de jogos mais aberto e interligado.
• Conteúdo gerado pelo utilizador: Os utilizadores podem construir conteúdos ou ativos de jogos de forma totalmente autónoma e possuir os ativos num ambiente de código aberto. Isto promove um ciclo de jogo gerado pelo utilizador, aumentando a jogabilidade e a distribuição do jogo. Por exemplo, os utilizadores podem carregar conteúdo de mod verificado no contrato do jogo, enriquecendo a jogabilidade e talvez até ganhando alguma receita.

Os jogos Blockchain foram muito esperados, especialmente depois do DeFie e NFT, estas duas áreas de aplicação blockchain explodiram sucessivamente. No entanto, ainda existem muitos obstáculos à implementação:

• Em primeiro lugar é a limitação da infra-estrutura técnica. A velocidade do EVM é lenta, as taxas de gás são altas, a linguagem Solidity é quase incapaz de lidar com a lógica de jogo complexa, o que limita severamente a complexidade e a interatividade do jogo.
• Design de modelo económico, como é bem sabido, o sistema económico de jogos em cadeia é crucial. Incentivos eficazes e financeirização precisam encontrar um equilíbrio.
• Liberdade e governança, os jogos on-chain têm um grau bastante elevado de liberdade ou abertura. Deverá permitir a qualquer jogador criar e implementar diferentes conteúdos de jogos, no entanto, este conteúdo irá inevitavelmente tornar o mundo do jogo mais complexo e até produzir impactos económicos imprevistos, o que requer mecanismos de governação eficazes para coordenar a gestão.

Estas são apenas algumas das dificuldades previsíveis e também são a razão pela qual quase todos os jogos de cadeia completa atualmente se concentram no SLG — o mecanismo do jogo é simples, não requer TPS alto e a incompletude da informação pode ser perfeitamente aplicada pela tecnologia existente. Se esperamos um MMORPG, é sem dúvida bastante desafiador. Tomando referência às mudanças que os motores de jogo trouxeram aos jogos Web2, se os jogos em cadeia também adotarem a arquitetura ECS, pode resolver:

• Organização e gestão de dados: Os jogos em cadeia também têm muitos dados do jogo para processar, incluindo atributos de personagens, itens, informações de mapa, etc. A arquitetura ECS pode ajudar a organizar os dados em componentes reutilizáveis e gerir eficazmente a modificação e o acesso aos dados.
• Flexibilidade e escalabilidade: Ao separar entidades e componentes do jogo, os desenvolvedores podem facilmente criar novos objetos e funções do jogo sem afetar a lógica existente. Esta flexibilidade e escalabilidade é particularmente importante nos jogos on-chain, uma vez que mecanismos de jogo complexos podem exigir upgrades e expansões frequentes.
• Contratos inteligentes e atualizações de dados: A arquitetura ECS pode gerir de forma mais eficaz as atualizações de dados em contratos inteligentes. Cada componente pode ser atualizado independentemente sem atualizar toda a entidade. Isto pode reduzir o custo de execução de contratos inteligentes e melhorar a eficiência da interação.
• Composibilidade: Uma vantagem do ECS é a capacidade de composição dos seus componentes e sistemas, que se encaixa bem com o conceito de composabilidade em jogos on-chain. Talvez os jogadores possam criar novos conteúdos, trazendo experiências mais ricas.

04 Web3 Jogo de Cadeia Completeira Outlook

Os desafios dos jogos de cadeia completa ainda são numerosos e o motor de jogo resolve apenas uma pequena parte do problema. No entanto, desafios e oportunidades coexistem, e os jogos de cadeia completa como uma aplicação complexa podem tornar-se o trampolim para a implementação real da tecnologia blockchain.

Atualmente, os motores de jogo de cadeia completa ainda estão numa fase muito inicial. Como mencionado anteriormente, vimos a forma embrionária de aplicações complexas, mas falta-lhes as ferramentas para implementação. O progresso de desenvolvimento mais rápido é atualmente o MUD V2 e o Dojo. O MUD V2, em comparação com o V1, melhorou a arquitectura ECS mas a V2 ainda está em desenvolvimento. O Dojo é atualmente o único motor de jogo verificável construído pela comunidade Starknet, beneficiando-se da linguagem do Cairo, pode implementar nativamente o nevoeiro da guerra. O Dojo também adota a arquitetura ECS e planeia desenvolver jogos L3 exclusivos na Starknet para melhorar ainda mais a escalabilidade.

Além disso, a infraestrutura da qual os jogos em cadeia dependem também está a evoluir. O L2 foi tão desenvolvido que pode lançar uma cadeia com um clique. Talvez um jogo de grande sucesso possa sustentar a sua estrutura dissipativa ganhando a propagação através do Rollup auto-construído, evitando assim uma espiral de morte. Utilizando a tecnologia de abstração de contas ERC-4337, os jogos de cadeia completa podem permitir aos jogadores conduzir transações de jogos e criar personagens numa única conta, o que ajuda a simplificar a experiência do utilizador. Diferentes mecanismos de jogo também podem ser encapsulados em uma conta de contrato atualizável, tornando mais fácil para os desenvolvedores atualizar ou otimizar as regras do jogo, conteúdo, etc.

Isenção de responsabilidade:

1. Este artigo é reproduzido de [], e os direitos de autorpertencem ao autor original [SnapFingers DAO]. Se houver objeções à reprodução, contacte a equipa do Gate Learn, e a equipa irá processá-la prontamente de acordo com os procedimentos relevantes.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem nenhum conselho de investimento.
3. Outras versões linguísticas do artigo são traduzidas pela equipa do Gate Learn. Sem mencionar o Gate.io, não é permitido copiar, divulgar ou plagiar os artigos traduzidos.