Intervenções: Andrea, Gabriele, Cofundadora da Magicblock
演讲标题:UMA ESTRUTURA PARA JOGOS ON-CHAIN
Prefácio do tradutor: "BOLT é um motor de jogo de cadeia completa desenvolvido pela equipe Magicblock para o ecossistema Solana. Este artigo é compilado a partir das apresentações dos dois fundadores da Magicblock no evento Breakpoint 2023. "
Olá a todos, este é o último discurso antes do Halloween, e espero que o conteúdo do discurso seja interessante para todos. Meu nome é Andrea e sou minha cofundadora, Gabriele. Hoje, vamos apresentar uma nova estrutura de jogos de cadeia completa (motor).
01.Por que você precisa de um jogo de cadeia completa
Vou começar com o básico, e é por isso que me preocupo em construir um jogo de cadeia completa com estado e lógica on-chain, e lidar com todas as complexidades que vêm com ele. A razão simples é obter recursos que a infraestrutura de jogos tradicional não tem.
O primeiro recurso são mods sem permissão. Isso significa que todos os jogadores e desenvolvedores podem personalizar qualquer componente do jogo, incluindo a introdução de plugins ou mods, a partir do cliente avançado. Até mesmo a lógica subjacente do jogo pode ser estendida através de contratos inteligentes. Essencialmente, é um novo modo onde cada jogo é uma nova plataforma por padrão, e você pode se tornar uma potência de conteúdo, não importa quão pequena seja sua equipe.
A segunda característica é a persistência. Mundos autônomos e o fato de que essas experiências virtuais podem existir para sempre causaram muitas repercussões. Como nenhum servidor pode ser censurado ou desligado, essas experiências realmente introduzem um novo significado. Os jogos tornaram-se uma plataforma para os jogadores jogarem, socializarem e realizarem comércio global, que é mais universal do que as plataformas de jogos tradicionais.
A última característica são as economias abertas. Os jogos podem tirar proveito do sistema de pagamento global aberto e sem atrito do blockchain, especialmente micropagamentos em nosso ecossistema, e reutilizar a infraestrutura on-chain existente, como DEXs ou mercados NFT.
02.Solução existente
O problema atual com jogos omnichain é que a experiência de desenvolvimento é muito ruim, e olhamos para as soluções no mercado e descobrimos que existem algumas estruturas de desenvolvimento que tentam simplificar a experiência do desenvolvedor.
Alguns deles são muito interessantes na medida em que tentam iterar em sessões prováveis, onde você pode fazer cálculos off-chain e provar a integridade dos cálculos on-chain. Ou introduza um tempo de execução controlado por eventos que seja mais adequado para mecanismos de jogos blockchain, em vez de um tempo de execução baseado em loop.
Mas todas essas estruturas exigem compensações entre desempenho e capacidade de composição para alcançar maior desempenho e maior TPS. Normalmente, você criará um isolamento ou introduzirá um tempo de execução diferente com fragmentos.
Mas não estamos satisfeitos com essa troca. Nós nos perguntamos, e se houvesse uma estrutura que pudesse suportar o TPS de que precisávamos? Quando o seu jogo é bem-sucedido, você não precisa sacrificar a experiência do usuário, mesmo com milhões de jogadores, porque guerras de gás não acontecerão. E a estrutura não requer fragmentação e fragmentação, então você pode usar sessões de jogo prováveis e até mesmo simular a passagem do tempo sem pagar taxas de gás. Não há necessidade de fragmentar o sistema ou usar a Camada 3.
03.Motor de desenvolvimento de jogos de cadeia completa em Solana: BOLT
É por isso que estamos entusiasmados em apresentar o BOLT, uma estrutura de desenvolvimento de jogos de alto desempenho, composta e de cadeia completa baseada em SVM.
BOLT é modular e composable, permitindo-lhe usar toda a infraestrutura existente em Solana. Ele trabalha com nossas instalações on-chain existentes, como identidade on-chain, API sem gás, chave de sessão, bem como a estrutura de desenvolvimento Anchor existente e todos os programas existentes no Solana. Ambos podem ser dimensionados em uma ordem de magnitude maior graças aos Ephemeral Rollups, que são sessões de jogos que são abertas e fechadas conforme a demanda do usuário e dimensionadas conforme necessário.
O BOLT é extremamente rápido, e podemos alcançar o mesmo nível de desempenho de um motor de jogo tradicional antes de usar esses tempos de execução dedicados para acelerar certas operações.
Esta é uma exibição panorâmica do quadro BOLT. Ele é obviamente construído para Solana, mas ele pode usá-lo em qualquer plataforma compatível com SVM, como a Camada 2 compatível com SVM. O BOLT tem dois objetivos principais, a capacidade de composição e a escalabilidade.
O sistema ECS (Entity Component) é uma das formas de simplificar a utilização de componentes on-chain. O outro é o Ephemeral Rollup, que foi brevemente mencionado anteriormente, e vou mergulhar em ambas as tecnologias em um momento.
BOLT foi integrado com os motores de jogos legados mais usados, como Unity, que muitas vezes servem como o front-end dos jogos. Claro, isso também inclui outros motores de jogo de código aberto e amados, como Godot e Phaser. Estamos até trabalhando com um cliente de jogo atualizado, Turbo, que se concentra em melhorar a experiência para desenvolvedores independentes e facilitar a criação rápida de jogos. Pode haver mais parceiros no futuro.
Vou começar aqui e continuar a explicar por que precisamos de um sistema de componentes de entidade ECS. A resposta é simples, porque permite a máxima composabilidade, o que significa que podemos criar e reutilizar componentes prontos.
Como o nome sugere, o ECS é construído em três elementos principais: entidades, que são essencialmente identificadores que são registrados em uma instância separada do mundo do jogo, componentes, que definem a estrutura de dados para que sejam basicamente os dados associados à entidade e, finalmente, o sistema, que é a lógica que manipula os componentes anexados à entidade.
A vantagem desta arquitetura é que todos os sistemas e componentes são reutilizáveis. Eles podem ser publicados em um registro público, e os desenvolvedores podem facilmente contribuir, criar, descobrir e integrar qualquer tipo de componente, para que você não precise mais escrever uma única linha de código do zero, mas possa reutilizar todos os componentes existentes e, eventualmente, contribuir para eles. Por exemplo, podemos ter uma estrutura de dados em grade (como um labirinto ou campo de batalha), um sistema em movimento ou um sistema de prova de conhecimento zero para a névoa da guerra.
04.BOLT Engine ECS Prática de Programação
(Nota do tradutor: Esta parte é recomendada para desenvolvedores assistirem ao vídeo original, não desenvolvedores podem pular esta parte)
AGORA, VOU MUDAR PARA O MEU IDE E MOSTRAR-LHE UM EXEMPLO DE JOGO SIMPLES USANDO O MOTOR BOLT ECS.
Vamos definir várias entidades, um componente de localização e dois sistemas que manipularão e alterarão os dados para esse componente de localização. Assim, o primeiro ponto de entrada é interagir com o Programa Mundial. O Programa Mundial faz parte da estrutura BOLT e expõe algumas extrações que permitem registrar novas Instâncias Mundiais.
Você pode adicionar entidades à sua Instância Mundial e pode registrar componentes com as entidades que você acabou de definir, que são essencialmente definidas pelo programa do componente. O programa componente contém duas diretivas, a primeira das quais é inicializar, criar e alocar espaço para armazenar linhas de dados que serão usados em seu componente. Neste exemplo simples, estamos definindo um componente de localização e, se olharmos para o contexto da diretiva de inicialização, podemos ver que temos dados de componentes, e os dados do componente apenas definem uma estrutura com coordenadas XYZ que pode armazenar, por exemplo, o local do player.
Agora, a segunda diretiva é provavelmente a mais interessante, é um ponto de entrada que nos permite executar qualquer lógica. Ele receberá nossos componentes e sistemas arbitrários como entradas e executará a lógica definida internamente no sistema, executando em todos os locais de programação. Agora, se você olhar para a linha 15, temos a nossa chamada CPI (Common Programming Interface), que executará a lógica definida internamente através da CPI. Ele irá realizar todos os cálculos definidos pelo sistema e, em seguida, retornar à nossa localização, onde o programa componente irá recuperá-lo e configurá-lo de volta em nossos dados.
Agora, vamos tentar olhar para o contexto da nossa função de aplicação, onde podemos ver que basicamente só temos duas contas. A primeira é a conta que contém os dados dos nossos componentes, e a segunda é o programa do sistema. Como resultado, um programa de sistema é agora uma interface em vez de um único programa. Portanto, qualquer programa que adere à nossa interface de sistema BOLT pode ser executado através deste aplicativo.
05.Importância do sistema ECS
Essencialmente, isso muda a maneira como você projeta a lógica do seu jogo e vira os processos tradicionais de cabeça para baixo. Anteriormente, se você quisesse criar ou encapsular alguma lógica em seu programa, normalmente adicionaria recursos primeiro, cada um dos quais era uma diretiva no programa, e então, eventualmente, em algum momento, você bloquearia o programa de jogo que estava desenvolvendo.
Com o modelo ECS, no entanto, podemos ter um programa imutável desde o início, e então com esse mecanismo de proxy, podemos adicionar um sistema construído internamente ou por qualquer pessoa, para que possamos ter um jogo que possa rodar para sempre, seja escalável e qualquer um possa realmente mudar a lógica do jogo.
Eles podem implantar novos sistemas que funcionarão nesses componentes. Agora, a interface também permite que você faça algumas verificações, para que possamos projetar uma mecânica de jogo que torna sem permissão para adicionar novos sistemas que podem modificar dados de componentes.
Ou podemos configurar uma interface para verificar se o sistema permite a execução no componente. Por exemplo, você pode projetar um sistema de governança onde se alguém está propondo uma nova lógica, e essa lógica é aprovada, então todos os jogadores podem usar essa lógica no jogo.
Isso pode até levar a uma bifurcação no mundo do jogo (o Contrato Mundial). Em um mundo, você possui o sistema de voo. E em outro mundo, se o sistema não for aprovado, é possível ter regras diferentes e cada um ainda poderá contribuir para sua própria versão do mundo.
Agora vamos ver como construir um sistema que pode modificar esse componente. O sistema é essencialmente apenas um programa no Solana que define uma instrução de execução, e a instrução de execução é a que chamamos do programa componente na CPI (Common Programming Interface). Aqui, ele apenas encapsula uma lógica muito simples na qual ele recebe a direção de entrada, calcula o delta e, em seguida, altera as posições X e Y do componente.
Então, vamos dar uma olhada em outro sistema que poderia ser implantado por outra pessoa, mesmo depois de lançarmos o jogo. Aqui está outro exemplo de um sistema que implementa ute. Aqui, a posição Z é aumentada em 1, então alguém está tentando adicionar um sistema de flanco, que pode ser uma interface com uma camada diferente em cima do seu jogo.
Então, a ideia agora é que todos esses sistemas, todos esses componentes sejam realmente compostáveis, os usuários do jogo não são mais usuários simples, o jogo se tornou uma plataforma aberta, escalável e persistente. Então vou tentar executar os testes de unidade que preparei neste exemplo, e vou usar a CLI BOLT, que é construída em cima do Anchor, uma estrutura de contrato inteligente para Solana, então se você já está familiarizado com Solana, não precisa aprender nada de novo.
Agora, você pode desenvolver programas no Solana, apenas desenvolver programas, programas de teste, então aqui eu estou executando o teste de parafuso e parafuso, e aqui eu estou implantando o nosso programa, e então eu estou fazendo o teste de tipo que eu preparei aqui.
Então, aqui o teste está enviando uma transação para inicializar um novo mundo. Estamos registrando algumas entidades, estamos anexando componentes de localização a algumas delas, e então talvez a parte interessante seja fazer alguns sistemas aqui. Então, aqui estamos chamando a função apply e, em seguida, estamos usando um desses sistemas. Então, aqui está apenas um sistema padrão.
Aqui estamos chamando um movimento simples, e então estamos voando um movimento aqui. Bem, agora, se olharmos para os logs do teste, na primeira negociação, aqui usamos um sistema em movimento com uma direção ascendente, aumentando a posição Y em 1. Na segunda transação, usamos o mesmo sistema para nos movermos para a direita e, finalmente, executamos o sistema de voo, que está fazendo o oposto, aumentando nossa posição Z em 1. É apenas um exemplo simples, mas ele oferece uma mecânica muito poderosa que permite que qualquer pessoa desenvolva, expanda e potencialmente torne seu jogo divertido.
06.Rollup efêmero
Agora que vamos voltar ao slide, vou descrever o segundo aspeto interessante da estrutura BOLT, que é a nossa solução de escalabilidade, que chamamos de Ephemeral Rollup.
É geralmente assumido que Solana já é muito rápido e barato, e que atualmente gera um bloco a cada 400 milissegundos e pode processar milhares de transações, então está realmente pronto para construir um jogo de cadeia completa. No entanto, se você tiver uma cadeia lógica antiga para multiplayer, as atualizações de localização serão muito lentas.
Assim, podemos construir uma camada de aceleração de curta duração que é totalmente compatível com o tempo de execução de Solana. O tempo usado é opcional, ele pode servir como uma aceleração real de uma determinada operação, enquanto a maior parte da lógica ainda é executada na cadeia principal, então ele confia no recurso de que todo o estado em Solana é armazenado na conta.
Normalmente, você terá um programa de jogo que define a lógica e, em seguida, todo o estado será armazenado nessa conta, para que possamos delegar algumas dessas contas a essa camada efêmera que usa o mecanismo BOLT.
Neste exemplo, há duas contas autorizadas que armazenam a localização do jogador e o provedor está escutando ativamente as solicitações de delegação e as solicitações de provisionamento. Ele vai começar um novo tempo de execução conforme necessário, que é rápido, personalizável, não pode ter transações de gás ou ticks, e nos permite realmente fazer transações abaixo de 50ms, e talvez escalar por ter vários tempos de execução dedicados.
Agora, a outra parte interessante é que toda essa complexidade pode ser abstraída do usuário. Temos um roteador RPC, que é essencialmente semelhante a um roteador RPC tradicional. O cliente RPC pode interagir diretamente com o RPC para enviar transações. Como no Solana, todas as transações são pré-declaradas para todas as contas mutáveis e legíveis, os roteadores RPC podem essencialmente rotear transações, consultas de dados e recuperação para a camada correta.
Então, em algum momento, a camada efêmera (como o próprio nome sugere) será fechada e todos os estados serão liquidados na camada base Solana, que é de responsabilidade do sequenciador, que acompanha todas as contas.
Outra maneira de olhar para este mecanismo é que temos duas camadas, e elas executam transações em paralelo. Temos contas delegadas que nos permitem atualizar com menor latência sem usar a taxa de transferência da cadeia principal. E depois temos outras contas, que não são delegadas, e são executadas na cadeia principal.
Agora, uma coisa muito interessante é que os programas, ferramentas, frameworks e infraestrutura estão todos na cadeia principal. Você não precisa implantar seu programa no Rollup, embora isso seja comum em muitas outras arquiteturas. Tudo está na mesma camada, tudo é compostável e, como mencionamos, esse tempo de execução especializado também é extensível e pode ser realmente personalizado.
Agora, isso desbloqueia uma nova categoria de jogos, que ele constrói no blockchain e é de baixa latência. Assim como você faria com um servidor multiplayer tradicional, mas ainda capaz de combinar com tudo o que está disponível no ecossistema da Camada 1.
Você tem acesso à liquidez existente, pode enviar mensagens através de protocolos, NFTs de cunhagem, usar abstrações de contas, chaves de sessão, tabelas de classificação e um ecossistema unificado, todos estão enriquecendo o mesmo ecossistema.
Muito obrigado por ouvir. Você pode se inscrever para acesso antecipado à nossa estrutura usando códigos QR e verificar o repositório. Você já pode encontrar documentação robusta e white papers que descrevem em detalhes a estrutura que acabamos de introduzir. Muito obrigado.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
BOLT: Motor de jogo de cadeia completa ECS baseado em Solana
Links de vídeo:
Intervenções: Andrea, Gabriele, Cofundadora da Magicblock
演讲标题:UMA ESTRUTURA PARA JOGOS ON-CHAIN
Prefácio do tradutor: "BOLT é um motor de jogo de cadeia completa desenvolvido pela equipe Magicblock para o ecossistema Solana. Este artigo é compilado a partir das apresentações dos dois fundadores da Magicblock no evento Breakpoint 2023. "
Olá a todos, este é o último discurso antes do Halloween, e espero que o conteúdo do discurso seja interessante para todos. Meu nome é Andrea e sou minha cofundadora, Gabriele. Hoje, vamos apresentar uma nova estrutura de jogos de cadeia completa (motor).
01.Por que você precisa de um jogo de cadeia completa
Vou começar com o básico, e é por isso que me preocupo em construir um jogo de cadeia completa com estado e lógica on-chain, e lidar com todas as complexidades que vêm com ele. A razão simples é obter recursos que a infraestrutura de jogos tradicional não tem.
O primeiro recurso são mods sem permissão. Isso significa que todos os jogadores e desenvolvedores podem personalizar qualquer componente do jogo, incluindo a introdução de plugins ou mods, a partir do cliente avançado. Até mesmo a lógica subjacente do jogo pode ser estendida através de contratos inteligentes. Essencialmente, é um novo modo onde cada jogo é uma nova plataforma por padrão, e você pode se tornar uma potência de conteúdo, não importa quão pequena seja sua equipe.
A segunda característica é a persistência. Mundos autônomos e o fato de que essas experiências virtuais podem existir para sempre causaram muitas repercussões. Como nenhum servidor pode ser censurado ou desligado, essas experiências realmente introduzem um novo significado. Os jogos tornaram-se uma plataforma para os jogadores jogarem, socializarem e realizarem comércio global, que é mais universal do que as plataformas de jogos tradicionais.
A última característica são as economias abertas. Os jogos podem tirar proveito do sistema de pagamento global aberto e sem atrito do blockchain, especialmente micropagamentos em nosso ecossistema, e reutilizar a infraestrutura on-chain existente, como DEXs ou mercados NFT.
02.Solução existente
O problema atual com jogos omnichain é que a experiência de desenvolvimento é muito ruim, e olhamos para as soluções no mercado e descobrimos que existem algumas estruturas de desenvolvimento que tentam simplificar a experiência do desenvolvedor.
Alguns deles são muito interessantes na medida em que tentam iterar em sessões prováveis, onde você pode fazer cálculos off-chain e provar a integridade dos cálculos on-chain. Ou introduza um tempo de execução controlado por eventos que seja mais adequado para mecanismos de jogos blockchain, em vez de um tempo de execução baseado em loop.
Mas todas essas estruturas exigem compensações entre desempenho e capacidade de composição para alcançar maior desempenho e maior TPS. Normalmente, você criará um isolamento ou introduzirá um tempo de execução diferente com fragmentos.
Mas não estamos satisfeitos com essa troca. Nós nos perguntamos, e se houvesse uma estrutura que pudesse suportar o TPS de que precisávamos? Quando o seu jogo é bem-sucedido, você não precisa sacrificar a experiência do usuário, mesmo com milhões de jogadores, porque guerras de gás não acontecerão. E a estrutura não requer fragmentação e fragmentação, então você pode usar sessões de jogo prováveis e até mesmo simular a passagem do tempo sem pagar taxas de gás. Não há necessidade de fragmentar o sistema ou usar a Camada 3.
03.Motor de desenvolvimento de jogos de cadeia completa em Solana: BOLT
É por isso que estamos entusiasmados em apresentar o BOLT, uma estrutura de desenvolvimento de jogos de alto desempenho, composta e de cadeia completa baseada em SVM.
BOLT é modular e composable, permitindo-lhe usar toda a infraestrutura existente em Solana. Ele trabalha com nossas instalações on-chain existentes, como identidade on-chain, API sem gás, chave de sessão, bem como a estrutura de desenvolvimento Anchor existente e todos os programas existentes no Solana. Ambos podem ser dimensionados em uma ordem de magnitude maior graças aos Ephemeral Rollups, que são sessões de jogos que são abertas e fechadas conforme a demanda do usuário e dimensionadas conforme necessário.
O BOLT é extremamente rápido, e podemos alcançar o mesmo nível de desempenho de um motor de jogo tradicional antes de usar esses tempos de execução dedicados para acelerar certas operações.
Esta é uma exibição panorâmica do quadro BOLT. Ele é obviamente construído para Solana, mas ele pode usá-lo em qualquer plataforma compatível com SVM, como a Camada 2 compatível com SVM. O BOLT tem dois objetivos principais, a capacidade de composição e a escalabilidade.
O sistema ECS (Entity Component) é uma das formas de simplificar a utilização de componentes on-chain. O outro é o Ephemeral Rollup, que foi brevemente mencionado anteriormente, e vou mergulhar em ambas as tecnologias em um momento.
BOLT foi integrado com os motores de jogos legados mais usados, como Unity, que muitas vezes servem como o front-end dos jogos. Claro, isso também inclui outros motores de jogo de código aberto e amados, como Godot e Phaser. Estamos até trabalhando com um cliente de jogo atualizado, Turbo, que se concentra em melhorar a experiência para desenvolvedores independentes e facilitar a criação rápida de jogos. Pode haver mais parceiros no futuro.
Vou começar aqui e continuar a explicar por que precisamos de um sistema de componentes de entidade ECS. A resposta é simples, porque permite a máxima composabilidade, o que significa que podemos criar e reutilizar componentes prontos.
Como o nome sugere, o ECS é construído em três elementos principais: entidades, que são essencialmente identificadores que são registrados em uma instância separada do mundo do jogo, componentes, que definem a estrutura de dados para que sejam basicamente os dados associados à entidade e, finalmente, o sistema, que é a lógica que manipula os componentes anexados à entidade.
A vantagem desta arquitetura é que todos os sistemas e componentes são reutilizáveis. Eles podem ser publicados em um registro público, e os desenvolvedores podem facilmente contribuir, criar, descobrir e integrar qualquer tipo de componente, para que você não precise mais escrever uma única linha de código do zero, mas possa reutilizar todos os componentes existentes e, eventualmente, contribuir para eles. Por exemplo, podemos ter uma estrutura de dados em grade (como um labirinto ou campo de batalha), um sistema em movimento ou um sistema de prova de conhecimento zero para a névoa da guerra.
04.BOLT Engine ECS Prática de Programação
(Nota do tradutor: Esta parte é recomendada para desenvolvedores assistirem ao vídeo original, não desenvolvedores podem pular esta parte)
AGORA, VOU MUDAR PARA O MEU IDE E MOSTRAR-LHE UM EXEMPLO DE JOGO SIMPLES USANDO O MOTOR BOLT ECS.
Vamos definir várias entidades, um componente de localização e dois sistemas que manipularão e alterarão os dados para esse componente de localização. Assim, o primeiro ponto de entrada é interagir com o Programa Mundial. O Programa Mundial faz parte da estrutura BOLT e expõe algumas extrações que permitem registrar novas Instâncias Mundiais.
Você pode adicionar entidades à sua Instância Mundial e pode registrar componentes com as entidades que você acabou de definir, que são essencialmente definidas pelo programa do componente. O programa componente contém duas diretivas, a primeira das quais é inicializar, criar e alocar espaço para armazenar linhas de dados que serão usados em seu componente. Neste exemplo simples, estamos definindo um componente de localização e, se olharmos para o contexto da diretiva de inicialização, podemos ver que temos dados de componentes, e os dados do componente apenas definem uma estrutura com coordenadas XYZ que pode armazenar, por exemplo, o local do player.
Agora, a segunda diretiva é provavelmente a mais interessante, é um ponto de entrada que nos permite executar qualquer lógica. Ele receberá nossos componentes e sistemas arbitrários como entradas e executará a lógica definida internamente no sistema, executando em todos os locais de programação. Agora, se você olhar para a linha 15, temos a nossa chamada CPI (Common Programming Interface), que executará a lógica definida internamente através da CPI. Ele irá realizar todos os cálculos definidos pelo sistema e, em seguida, retornar à nossa localização, onde o programa componente irá recuperá-lo e configurá-lo de volta em nossos dados.
Agora, vamos tentar olhar para o contexto da nossa função de aplicação, onde podemos ver que basicamente só temos duas contas. A primeira é a conta que contém os dados dos nossos componentes, e a segunda é o programa do sistema. Como resultado, um programa de sistema é agora uma interface em vez de um único programa. Portanto, qualquer programa que adere à nossa interface de sistema BOLT pode ser executado através deste aplicativo.
05.Importância do sistema ECS
Essencialmente, isso muda a maneira como você projeta a lógica do seu jogo e vira os processos tradicionais de cabeça para baixo. Anteriormente, se você quisesse criar ou encapsular alguma lógica em seu programa, normalmente adicionaria recursos primeiro, cada um dos quais era uma diretiva no programa, e então, eventualmente, em algum momento, você bloquearia o programa de jogo que estava desenvolvendo.
Com o modelo ECS, no entanto, podemos ter um programa imutável desde o início, e então com esse mecanismo de proxy, podemos adicionar um sistema construído internamente ou por qualquer pessoa, para que possamos ter um jogo que possa rodar para sempre, seja escalável e qualquer um possa realmente mudar a lógica do jogo.
Eles podem implantar novos sistemas que funcionarão nesses componentes. Agora, a interface também permite que você faça algumas verificações, para que possamos projetar uma mecânica de jogo que torna sem permissão para adicionar novos sistemas que podem modificar dados de componentes.
Ou podemos configurar uma interface para verificar se o sistema permite a execução no componente. Por exemplo, você pode projetar um sistema de governança onde se alguém está propondo uma nova lógica, e essa lógica é aprovada, então todos os jogadores podem usar essa lógica no jogo.
Isso pode até levar a uma bifurcação no mundo do jogo (o Contrato Mundial). Em um mundo, você possui o sistema de voo. E em outro mundo, se o sistema não for aprovado, é possível ter regras diferentes e cada um ainda poderá contribuir para sua própria versão do mundo.
Agora vamos ver como construir um sistema que pode modificar esse componente. O sistema é essencialmente apenas um programa no Solana que define uma instrução de execução, e a instrução de execução é a que chamamos do programa componente na CPI (Common Programming Interface). Aqui, ele apenas encapsula uma lógica muito simples na qual ele recebe a direção de entrada, calcula o delta e, em seguida, altera as posições X e Y do componente.
Então, vamos dar uma olhada em outro sistema que poderia ser implantado por outra pessoa, mesmo depois de lançarmos o jogo. Aqui está outro exemplo de um sistema que implementa ute. Aqui, a posição Z é aumentada em 1, então alguém está tentando adicionar um sistema de flanco, que pode ser uma interface com uma camada diferente em cima do seu jogo.
Então, a ideia agora é que todos esses sistemas, todos esses componentes sejam realmente compostáveis, os usuários do jogo não são mais usuários simples, o jogo se tornou uma plataforma aberta, escalável e persistente. Então vou tentar executar os testes de unidade que preparei neste exemplo, e vou usar a CLI BOLT, que é construída em cima do Anchor, uma estrutura de contrato inteligente para Solana, então se você já está familiarizado com Solana, não precisa aprender nada de novo.
Agora, você pode desenvolver programas no Solana, apenas desenvolver programas, programas de teste, então aqui eu estou executando o teste de parafuso e parafuso, e aqui eu estou implantando o nosso programa, e então eu estou fazendo o teste de tipo que eu preparei aqui.
Então, aqui o teste está enviando uma transação para inicializar um novo mundo. Estamos registrando algumas entidades, estamos anexando componentes de localização a algumas delas, e então talvez a parte interessante seja fazer alguns sistemas aqui. Então, aqui estamos chamando a função apply e, em seguida, estamos usando um desses sistemas. Então, aqui está apenas um sistema padrão.
Aqui estamos chamando um movimento simples, e então estamos voando um movimento aqui. Bem, agora, se olharmos para os logs do teste, na primeira negociação, aqui usamos um sistema em movimento com uma direção ascendente, aumentando a posição Y em 1. Na segunda transação, usamos o mesmo sistema para nos movermos para a direita e, finalmente, executamos o sistema de voo, que está fazendo o oposto, aumentando nossa posição Z em 1. É apenas um exemplo simples, mas ele oferece uma mecânica muito poderosa que permite que qualquer pessoa desenvolva, expanda e potencialmente torne seu jogo divertido.
06.Rollup efêmero
Agora que vamos voltar ao slide, vou descrever o segundo aspeto interessante da estrutura BOLT, que é a nossa solução de escalabilidade, que chamamos de Ephemeral Rollup.
É geralmente assumido que Solana já é muito rápido e barato, e que atualmente gera um bloco a cada 400 milissegundos e pode processar milhares de transações, então está realmente pronto para construir um jogo de cadeia completa. No entanto, se você tiver uma cadeia lógica antiga para multiplayer, as atualizações de localização serão muito lentas.
Assim, podemos construir uma camada de aceleração de curta duração que é totalmente compatível com o tempo de execução de Solana. O tempo usado é opcional, ele pode servir como uma aceleração real de uma determinada operação, enquanto a maior parte da lógica ainda é executada na cadeia principal, então ele confia no recurso de que todo o estado em Solana é armazenado na conta.
Normalmente, você terá um programa de jogo que define a lógica e, em seguida, todo o estado será armazenado nessa conta, para que possamos delegar algumas dessas contas a essa camada efêmera que usa o mecanismo BOLT.
Neste exemplo, há duas contas autorizadas que armazenam a localização do jogador e o provedor está escutando ativamente as solicitações de delegação e as solicitações de provisionamento. Ele vai começar um novo tempo de execução conforme necessário, que é rápido, personalizável, não pode ter transações de gás ou ticks, e nos permite realmente fazer transações abaixo de 50ms, e talvez escalar por ter vários tempos de execução dedicados.
Agora, a outra parte interessante é que toda essa complexidade pode ser abstraída do usuário. Temos um roteador RPC, que é essencialmente semelhante a um roteador RPC tradicional. O cliente RPC pode interagir diretamente com o RPC para enviar transações. Como no Solana, todas as transações são pré-declaradas para todas as contas mutáveis e legíveis, os roteadores RPC podem essencialmente rotear transações, consultas de dados e recuperação para a camada correta.
Então, em algum momento, a camada efêmera (como o próprio nome sugere) será fechada e todos os estados serão liquidados na camada base Solana, que é de responsabilidade do sequenciador, que acompanha todas as contas.
Outra maneira de olhar para este mecanismo é que temos duas camadas, e elas executam transações em paralelo. Temos contas delegadas que nos permitem atualizar com menor latência sem usar a taxa de transferência da cadeia principal. E depois temos outras contas, que não são delegadas, e são executadas na cadeia principal.
Agora, uma coisa muito interessante é que os programas, ferramentas, frameworks e infraestrutura estão todos na cadeia principal. Você não precisa implantar seu programa no Rollup, embora isso seja comum em muitas outras arquiteturas. Tudo está na mesma camada, tudo é compostável e, como mencionamos, esse tempo de execução especializado também é extensível e pode ser realmente personalizado.
Agora, isso desbloqueia uma nova categoria de jogos, que ele constrói no blockchain e é de baixa latência. Assim como você faria com um servidor multiplayer tradicional, mas ainda capaz de combinar com tudo o que está disponível no ecossistema da Camada 1.
Você tem acesso à liquidez existente, pode enviar mensagens através de protocolos, NFTs de cunhagem, usar abstrações de contas, chaves de sessão, tabelas de classificação e um ecossistema unificado, todos estão enriquecendo o mesmo ecossistema.
Muito obrigado por ouvir. Você pode se inscrever para acesso antecipado à nossa estrutura usando códigos QR e verificar o repositório. Você já pode encontrar documentação robusta e white papers que descrevem em detalhes a estrutura que acabamos de introduzir. Muito obrigado.