Backend de economia de jogo Web3: inventário, ações on-chain e preços em uma key
A economia de um jogo Web3 depende de três coisas que precisam ser rápidas e baratas: mostrar o inventário do jogador, executar ações on-chain como mint, trade e recompensas, e precificar itens em fiat para as lojas do jogo. Como o game loop consulta esses dados o tempo todo, o custo por chamada importa. Esta arquitetura de referência descreve como concentrar leitura de inventário, execução de ações e preços sobre uma key e um saldo em credits, sem custódia de keys dos jogadores.
O desafio
O game backend não pode virar um indexador de blockchain. Para reconstruir o inventário a partir dos eventos on-chain seria preciso manter e versionar ABIs de cada contrato, algo frágil quando os contratos do jogo evoluem. As ações do jogador precisam ir para a rede, mas o estúdio não quer custodiar as keys dos jogadores. E como o game loop faz polling constante de saldos e preços para renderizar telas, uma solução cara por chamada estoura o orçamento rapidamente. É preciso resolver inventário, ação e preço sem ABIs próprias, sem custódia e com consumo de credits sob controle.
- Balances / portfolio / net-worthC2
- Decoded transactions / logsC2
- Build / sign / broadcastC2
- Spot / OHLCVC1
Inventário por balances e decoded logs, sem manter ABIs
O inventário sai de balances e de decoded logs já decodificados pela plataforma, sem o estúdio precisar guardar e versionar as ABIs dos contratos do jogo. Quando um item é cunhado ou transferido, o evento decodificado alimenta o inventário do jogador, então a tela de itens reflete o estado on-chain sem que o backend do jogo mantenha um decodificador próprio.
Ações do jogo com build/sign/broadcast e assinatura do cliente
Mint, trade e recompensas usam o fluxo build/sign/broadcast: a plataforma monta a transação e faz o broadcast, mas a assinatura fica do lado do cliente. O estúdio não custodia as keys dos jogadores, o que mantém o modelo de posse dos ativos com quem joga e tira do backend a responsabilidade de guardar private keys.
Preço spot cacheado por intervalo de render para segurar credits
Para precificar itens em fiat, o backend usa preço spot, que é o tier mais barato. Como o game loop faz polling, o valor spot é cacheado por intervalo de render: em vez de uma chamada por frame, uma leitura serve todos os frames daquele intervalo. Isso mantém o consumo de credits baixo mesmo com muitos jogadores consultando preços ao mesmo tempo.
O que a arquitetura entrega
- O inventário reflete o estado on-chain a partir de decoded logs, sem o estúdio manter e versionar ABIs dos contratos do jogo.
- Mint, trade e recompensas são executados com assinatura do lado do cliente, então o jogo não custodia keys dos jogadores.
- Cache de preço spot por intervalo de render mantém o consumo de credits baixo mesmo com o polling constante do game loop.
Perguntas frequentes
Preciso subir e manter as ABIs dos contratos do jogo para montar o inventário?
Não. A leitura de inventário se apoia em balances e em decoded logs já decodificados pela plataforma, então você não precisa guardar nem versionar ABIs no seu backend. Quando um contrato do jogo muda, você não fica com um decodificador próprio para atualizar só para continuar lendo os eventos de item.
Com o polling do game loop, como evito que o custo de preços exploda em credits?
O preço spot é o tier mais barato e é cacheado por intervalo de render: uma leitura atende todos os frames daquele intervalo em vez de uma chamada por frame. Assim o consumo de credits acompanha o número de intervalos e não o número de quadros renderizados, mesmo com muitos jogadores ativos.
Recarregue, pegue a chave e publique.
Autoatendimento. Pague em cripto ou cartão. Medido por créditos: primitivas pesadas custam mais, as simples são baratas.
Obter chave de API