Economia de Jogo: Como Projetar Fontes, Sumidouros e Balanceamento

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:
- Upgrades permanentes: melhorar arma, expandir inventário, desbloquear habilidade. O jogador adora gastar aqui porque o gasto vira poder.
- Consumíveis: poção, munição, comida. Drenagem constante e pequena, ótima pra regular o dia a dia da economia.
- Conveniência: viagem rápida, slots extras, reroll de loja. Gasto opcional que o jogador escolhe quando o saldo sobra.
- Manutenção: reparo, aluguel, decaimento. Funciona, mas cobra presença. Exagerou, vira trabalho e o jogador se ressente.
- 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.
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:
- O jogador para de pensar antes de gastar (o preço deixou de importar).
- Itens que eram recompensa empolgante viram lixo de inventário.
- Em multiplayer, os preços do mercado entre jogadores disparam.
- 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.


