Voltar para o Blog
Quest Log

Economia de Jogo: Como Projetar Fontes, Sumidouros e Balanceamento

Ilustração de uma economia de jogo com moedas fluindo de uma fonte para um sumidouro, com uma balança ao centro

Aprenda a projetar a economia de jogo do zero: fontes e sumidouros de moeda, como evitar inflação e um método prático de balanceamento com exemplos em Godot.

Economia de Jogo: Como Projetar Fontes, Sumidouros e Balanceamento

Economia de jogo é o sistema que decide quanto recurso entra, quanto sai e o que o jogador faz com a diferença. Ouro, XP, madeira, munição, energia, gemas: se o jogador acumula e gasta, é economia. E é um dos sistemas mais negligenciados por quem está começando, porque ele não quebra com erro de compilação. Ele quebra três semanas depois, quando o playtester chega no chefe final com 50 mil moedas, compra tudo da loja e o jogo perde a graça.

A boa notícia: o modelo mental pra projetar isso é simples. Toda economia se resume a fontes (de onde o recurso nasce), sumidouros (onde ele morre) e o fluxo entre os dois. Se você controla essas três coisas, controla a economia. Esse artigo cobre o modelo, os erros clássicos de inflação e um método de balanceamento que funciona na prática, com código real de Godot pra instrumentar tudo.

Como funciona uma economia de jogo

Pensa na economia como uma banheira. A torneira é a fonte: inimigo derrotado, quest completada, baú aberto, venda de item. O ralo é o sumidouro: loja, reparo de equipamento, taxa de viagem rápida, upgrade, consumível. O nível da água é o saldo do jogador.

O design da economia é o design dessa banheira:

  • Se a torneira corre mais que o ralo, a água sobe sem parar. O jogador fica rico, tudo vira "comprável" e as decisões econômicas deixam de existir.
  • Se o ralo engole mais que a torneira, o jogador vive sem recurso, não consegue progredir e a frustração toma conta.
  • O ponto certo não é equilíbrio perfeito. É um leve excedente que dá sensação de progresso, com sumidouros desejáveis o bastante pra drenar esse excedente de tempos em tempos.

Esse último ponto merece destaque: o objetivo não é zerar o saldo do jogador. É fazer ele querer gastar. Sumidouro bom não parece imposto, parece oportunidade.

Os três tipos de recurso

Antes de desenhar fluxos, classifique seus recursos, porque cada tipo pede um tratamento diferente:

Moeda primária: o recurso central de troca. Ouro, créditos, dinheiro. Flui em volume alto, tem dezenas de fontes e sumidouros. É onde a inflação aparece primeiro.

Recursos de progressão: XP, pontos de habilidade, materiais de upgrade. Geralmente só entram, nunca saem (ninguém "gasta" XP de volta). Aqui o controle é na taxa de entrada, não no sumidouro.

Recursos premium ou escassos: gemas em mobile, itens lendários, moeda de evento. Volume baixo, fontes raríssimas, valor percebido alto. O erro fatal aqui é distribuir demais no começo e desvalorizar tudo.

Um jogo pequeno pode ter só a moeda primária. Tudo bem. O modelo de fontes e sumidouros vale igual.

Fontes: onde o recurso nasce

Toda fonte tem duas propriedades que você precisa conhecer: taxa (quanto entra por unidade de tempo de jogo) e limite (ela é finita ou infinita?).

Fontes finitas são as mais fáceis de controlar: baú só abre uma vez, quest só completa uma vez. Você sabe exatamente o total que elas injetam na economia ao longo do jogo. Some tudo e pronto, esse é o teto.

Fontes infinitas são onde mora o perigo. Inimigo que respawna, recurso que renasce, qualquer atividade repetível que paga. O jogador vai encontrar a fonte infinita mais eficiente do seu jogo e vai explorá-la até o talo. Não é defeito do jogador, é o jogo funcionando: otimizar é divertido. Seu trabalho é garantir que, mesmo na fonte mais eficiente, a taxa de entrada continue dentro do que a economia aguenta.

Duas ferramentas clássicas pra domar fontes infinitas:

  • Rendimento decrescente: a mesma atividade paga menos a cada repetição em sequência (ou por dia). MMOs fazem isso há décadas com bônus de descanso e caps diários.
  • Custo de oportunidade: farmar moeda custa tempo que o jogador poderia usar pra progredir de outro jeito. Se farmar é a forma mais rápida de tudo, a fonte está pagando demais.

Sumidouros: onde o recurso morre

Aqui está a distinção mais importante do artigo, e a que mais separa economia saudável de economia quebrada: transferência não é sumidouro.

Quando o jogador compra uma espada do NPC, o ouro sai da economia? Sim, se o NPC é só uma interface (o ouro evapora). Mas quando o jogador A vende pro jogador B num mercado, o ouro só mudou de mãos. Continua na economia, continua pressionando preços. Jogos multiplayer quebram exatamente nesse ponto: criam mercados entre jogadores sem criar sumidouros proporcionais, e a moeda acumulada de milhares de jogadores infla os preços até moeda nenhuma valer nada. É o motivo de MMOs cobrarem taxa de leilão, custo de reparo, montaria caríssima: são ralos deliberados pra queimar moeda do sistema.

Em single player o problema é mais brando, mas existe igual. Os sumidouros mais usados, do mais aceito ao mais odiado pelo jogador:

  1. Upgrades permanentes: melhorar arma, expandir inventário, desbloquear habilidade. O jogador adora gastar aqui porque o gasto vira poder.
  2. Consumíveis: poção, munição, comida. Drenagem constante e pequena, ótima pra regular o dia a dia da economia.
  3. Conveniência: viagem rápida, slots extras, reroll de loja. Gasto opcional que o jogador escolhe quando o saldo sobra.
  4. Manutenção: reparo, aluguel, decaimento. Funciona, mas cobra presença. Exagerou, vira trabalho e o jogador se ressente.
  5. Apostas e crafting com chance de falha: drenam muito, mas frustram. Use com cuidado.

A regra prática: seus melhores sumidouros devem ser coisas que o jogador deseja, não coisas que o jogo cobra. Um sumidouro desejado drena mais moeda que dez taxas obrigatórias, e ainda gera satisfação em vez de ressentimento.

Próximo nível
Quer aprender isso na prática?

No CursoGame.Dev você sai dos tutoriais soltos e constrói jogos publicáveis, com trilha progressiva, quests práticas e feedback real.

Conhecer a plataforma
+500 alunos4.9/5Garantia 7 dias

Inflação: quando a torneira vence o ralo

Inflação em jogo tem o mesmo sintoma da vida real: o recurso perde valor. Os sinais aparecem nessa ordem:

  1. O jogador para de pensar antes de gastar (o preço deixou de importar).
  2. Itens que eram recompensa empolgante viram lixo de inventário.
  3. Em multiplayer, os preços do mercado entre jogadores disparam.
  4. As decisões econômicas do seu design viram letra morta: tudo é sim.

O caso mais documentado é o leilão por dinheiro real do Diablo III no lançamento, que distorceu o loop central do jogo (matar monstro pra conseguir item) a ponto de a Blizzard remover o sistema inteiro. E o EVE Online leva isso tão a sério que mantém relatórios econômicos mensais e já teve economista na equipe. Não é exagero: numa economia de jogo persistente, inflação descontrolada mata o jogo.

A causa raiz é quase sempre a mesma: fontes escalam com o progresso do jogador (inimigo mais forte paga mais) e sumidouros não acompanham. No início do jogo a poção custa 50 e o inimigo paga 10, decisão difícil. No fim o inimigo paga 500 e a poção ainda custa 50, decisão inexistente.

A correção estrutural: faça os sumidouros escalarem junto com as fontes. Upgrades em camadas (nível 2 custa o dobro do nível 1), consumíveis melhores em tiers mais caros, conveniências de luxo no late game. O jogador rico precisa de coisas caras pra desejar.

Uma armadilha pra evitar: corrigir inflação cortando recompensa depois que o jogo já está nas mãos do jogador. Nerfar a renda dói muito mais do que nunca ter dado. Sempre que possível, corrija adicionando sumidouros desejáveis em vez de fechando torneiras.

Balanceamento na prática: a planilha antes do código

Balancear economia de jogo no feeling não funciona, porque o problema é cumulativo: cada número parece razoável isolado, e o conjunto explode. O método que funciona é modelar o fluxo antes, numa planilha simples, e medir depois, com telemetria.

A planilha mínima tem três colunas por etapa do jogo (fase, capítulo, hora de jogo, o que fizer sentido):

  • Entrada esperada: tudo que o jogador médio ganha naquela etapa.
  • Saída esperada: tudo que o jogo espera que ele gaste pra progredir confortavelmente.
  • Saldo acumulado: a soma corrente da diferença.

A curva do saldo acumulado conta a história inteira. Ela deve crescer devagar e levar quedas visíveis nos pontos de compra importantes (aquele upgrade caro antes da área nova). Se a curva só sobe, faltam sumidouros à frente. Se ela encosta no zero o tempo todo, o jogador vai travar na primeira vez que jogar pior que o "jogador médio" da sua planilha.

Dois cuidados que valem ouro:

  • Modele o jogador otimizador, não só o médio. Pergunte: qual a fonte mais eficiente desta etapa? Quanto ela paga por minuto se o jogador só fizer isso? Esse número também precisa caber na curva.
  • Decida o excedente alvo. Algo entre "sobra um pouco" e "sobra pra uma compra opcional por etapa" costuma dar a sensação de riqueza sem quebrar nada. O número exato é tuning do seu jogo.

Medindo a economia no Godot

Planilha é hipótese. A realidade vem do playtest, e pra isso a economia precisa estar instrumentada. Em Godot, dois scripts curtos resolvem: uma carteira central e um rastreador de fluxo.

Primeiro, o rastreador, registrado como autoload (Project Settings > Globals) com o nome EconomyTracker:

# economy_tracker.gd (autoload)
extends Node

var earned := {}  # fonte -> total ganho
var spent := {}   # sumidouro -> total gasto

func register_gain(source: String, amount: int) -> void:
    earned[source] = earned.get(source, 0) + amount

func register_spend(sink: String, amount: int) -> void:
    spent[sink] = spent.get(sink, 0) + amount

func report() -> void:
    var total_in := 0
    var total_out := 0
    print("--- FONTES ---")
    for source in earned:
        print("%s: %d" % [source, earned[source]])
        total_in += earned[source]
    print("--- SUMIDOUROS ---")
    for sink in spent:
        print("%s: %d" % [sink, spent[sink]])
        total_out += spent[sink]
    print("Entrou: %d | Saiu: %d | Saldo do fluxo: %d" % [total_in, total_out, total_in - total_out])

Depois, a carteira, também como autoload (Wallet). O ponto chave do design: todo ganho e gasto do jogo passa por aqui, nunca por uma variável solta em outro script. Centralizar é o que torna a economia mensurável e à prova de bug de saldo negativo:

# wallet.gd (autoload)
extends Node

signal balance_changed(new_balance: int)

var balance := 0

func add(amount: int, source: String) -> void:
    balance += amount
    EconomyTracker.register_gain(source, amount)
    balance_changed.emit(balance)

func try_spend(amount: int, sink: String) -> bool:
    if amount > balance:
        return false
    balance -= amount
    EconomyTracker.register_spend(sink, amount)
    balance_changed.emit(balance)
    return true

O uso fica autodocumentado, porque cada transação carrega a etiqueta da fonte ou do sumidouro:

# No inimigo, ao morrer:
Wallet.add(coin_reward, "inimigo_floresta")

# Na loja:
if Wallet.try_spend(price, "loja_pocoes"):
    dar_item(item)
else:
    mostrar_aviso_sem_moeda()

Roda uma sessão de playtest, chama EconomyTracker.report() no fim e compara com a planilha. Quando a fonte inimigo_floresta aparecer pagando três vezes o que você modelou, você descobre em minutos, não em semanas. Esse loop (modelar, medir, ajustar) é o trabalho real de balanceamento. Os números da primeira planilha vão estar errados, e tudo bem: o sistema existe justamente pra te mostrar onde.

Conclusão

Economia de jogo não pede matemática avançada, pede disciplina: classificar fontes e sumidouros, escalar os dois juntos, preferir sumidouros que o jogador deseja, modelar na planilha e medir no playtest. O resto é iteração.

Se você está fazendo seu primeiro jogo com economia, começa pequeno: uma moeda, três fontes, três sumidouros, uma planilha de uma página e o tracker acima. Esse esqueleto aguenta crescer junto com o jogo, e te dá algo que a maioria dos projetos iniciantes não tem: visibilidade sobre o sistema antes de ele quebrar.