Como Fazer um Jogo Tycoon: Design e Código do Gênero Management na Godot

RollerCoaster Tycoon, Game Dev Tycoon, Prison Architect. Jogos de gerenciamento têm uma capacidade rara de prender o jogador por horas usando gráficos simples e quase nenhuma ação na tela. Neste guia você vai aprender como fazer um jogo tycoon na Godot 4: as mecânicas que definem o gênero, o tick econômico que faz tudo funcionar, a estrutura de dados das unidades, a curva de custo que sustenta o jogo inteiro e a UI de management. Tudo com GDScript tipado e APIs reais da engine.

E tem um detalhe importante: esse é um dos gêneros mais amigáveis para quem desenvolve sozinho. A arte pode ser feita de ícones e painéis, não precisa de animação elaborada, e o desafio de verdade está no design da economia. Ou seja, exatamente o tipo de problema que você resolve iterando, sem depender de uma equipe. Se você curte esse desafio de sistemas e economia, outro gênero na mesma pegada é o auto battler.

Por que jogos de gerenciamento prendem tanto

Três ingredientes explicam por que alguém passa seis horas administrando um parque virtual:

1. Loop de decisão e consequência. O jogador toma uma decisão (construir a montanha-russa ou contratar mais faxineiros?), vê o resultado nos números e ajusta a próxima decisão. Cada escolha alimenta a seguinte, e o cérebro adora fechar esse ciclo.
2. Crescimento visível. O parque que começou com um carrossel vira um complexo gigante. O número que era 100 vira 100.000. Ver o próprio progresso materializado na tela é uma recompensa constante, sem precisar de cutscene ou chefão.
3. Otimização. Sempre existe um jeito mais eficiente de arranjar as peças. O jogador não joga só para vencer, joga para vencer melhor. É o mesmo prazer de resolver um quebra-cabeça, só que o quebra-cabeça é a sua própria fábrica.

Para o dev solo, a lista de vantagens é prática: o gênero não exige combate, não exige IA sofisticada de inimigos, não exige level design artesanal de dezenas de fases. Uma tela, alguns painéis e uma economia bem desenhada já são um jogo completo. O custo disso é que o design precisa ser bom, porque não tem espetáculo visual para esconder uma economia mal balanceada.

Anatomia de um jogo tycoon

Praticamente todo management game é feito das mesmas cinco peças:

• Recurso principal. Quase sempre dinheiro. É o número que o jogador olha o tempo todo e a régua de todas as decisões.
• Produção. Unidades que geram recurso ao longo do tempo: brinquedos vendendo ingressos, funcionários produzindo, máquinas operando.
• Custo operacional (upkeep). O que impede o dinheiro de só subir: salários, manutenção, aluguel. Sem upkeep, não existe risco, e sem risco as decisões perdem peso.
• Expansão. Novas unidades, upgrades, áreas desbloqueáveis. É o destino natural do lucro.
• Eventos. Acontecimentos que sacodem a rotina: uma máquina quebra, chega um cliente especial, o mercado muda.

Olhe para os clássicos com essa lente. Em RollerCoaster Tycoon, os brinquedos e as lojas geram receita enquanto manutenção e salários drenam o caixa. Em Game Dev Tycoon, você administra um estúdio: os jogos lançados vendem, a folha de pagamento consome. Em Prison Architect, a prisão recebe dinheiro pelos presos e gasta com construção e equipe. Os temas mudam completamente, o esqueleto é o mesmo. Se quiser se aprofundar em como essas engrenagens se conectam, o post sobre economia de jogo e design destrincha fontes e ralos de recursos em detalhe.

Como fazer um jogo tycoon na prática: o tick econômico

O coração de um tycoon é o tick: um pulso regular em que a simulação avança um passo. A cada tick, o jogo soma a receita, subtrai a despesa e atualiza a interface. Simular em passos discretos é muito mais simples de programar e balancear do que simular continuamente a cada frame, e o jogador nem percebe a diferença.

Na Godot 4, o jeito mais direto é um nó Timer dentro de um autoload (Projeto > Configurações do Projeto > Globals) chamado, por exemplo, Economia:

extends Node

signal dinheiro_alterado(novo_valor: int)

var dinheiro: int = 100
var receita_por_tick: int = 0
var despesa_por_tick: int = 0

func _ready() -> void:
    var timer: Timer = Timer.new()
    timer.wait_time = 1.0
    timer.autostart = true
    timer.timeout.connect(_on_tick_timeout)
    add_child(timer)

func _on_tick_timeout() -> void:
    dinheiro += receita_por_tick - despesa_por_tick
    dinheiro_alterado.emit(dinheiro)

Repare em duas escolhas. Primeiro, o signal dinheiro_alterado: a economia não sabe que a UI existe, ela só anuncia que o valor mudou, e quem quiser reagir se conecta. Isso mantém o código desacoplado. Segundo, dinheiro é int, não float. Dinheiro em ponto flutuante gera erros de arredondamento que se acumulam; se precisar de centavos, guarde tudo em centavos como inteiro.

O wait_time = 1.0 significa um tick por segundo. Esse número vira uma alavanca de game feel depois: ticks mais rápidos deixam o jogo mais frenético, mais lentos dão tempo de planejar.

Prédios e unidades com Resource customizado

As coisas que o jogador compra (barracas, máquinas, atrações) são dados, não lógica. O lugar certo para dados na Godot 4 é um Resource customizado:

class_name Unidade
extends Resource

@export var nome: String = ''
@export var custo_base: int = 50
@export var producao_por_tick: int = 5
@export var upkeep_por_tick: int = 1
@export var icone: Texture2D

Com o class_name Unidade, você cria arquivos .tres direto pelo editor (botão direito no FileSystem > Criar Novo > Recurso > Unidade) e preenche os valores no Inspector. Quer adicionar uma unidade nova ao jogo? Cria um .tres, ajusta os números, pronto, sem tocar em código. Isso também torna o balanceamento infinitamente mais rápido, porque você edita valores em arquivos de dados em vez de caçar constantes espalhadas por scripts.

A regra de leitura é simples: producao_por_tick alimenta a receita_por_tick da economia, upkeep_por_tick alimenta a despesa. Uma unidade boa tem produção bem maior que o upkeep, mas o upkeep existe para que expandir demais sem caixa seja um risco real.

A curva de custo: a decisão de design mais importante

Aqui está o segredo que separa um tycoon envolvente de uma planilha entediante: o custo das unidades cresce exponencialmente, a produção cresce linearmente.

Se a segunda barraca custa o mesmo que a primeira, a estratégia ótima é comprar a mesma coisa para sempre, e o jogo morre. Com custo exponencial, cada compra repetida fica proporcionalmente mais cara, e em algum momento vale mais a pena diversificar para outra unidade. É essa tensão que gera escolha interessante.

A fórmula clássica, usada em praticamente todo jogo incremental:

var quantidades: Dictionary = {}

func custo_atual(unidade: Unidade) -> int:
    var possui: int = quantidades.get(unidade.nome, 0)
    return int(unidade.custo_base * pow(1.15, possui))

func comprar(unidade: Unidade) -> bool:
    var custo: int = custo_atual(unidade)
    if dinheiro < custo:
        return false
    dinheiro -= custo
    quantidades[unidade.nome] = quantidades.get(unidade.nome, 0) + 1
    receita_por_tick += unidade.producao_por_tick
    despesa_por_tick += unidade.upkeep_por_tick
    dinheiro_alterado.emit(dinheiro)
    return true

O fator 1.15 é o coração do balanceamento. Valores típicos ficam entre 1.07 (crescimento suave, compras frequentes) e 1.2 (crescimento agressivo, cada compra é um evento). Teste com o seu tempo de tick e ajuste até o ritmo parecer certo. O post sobre balanceamento com fórmulas e técnicas mostra como modelar essas curvas antes de sair chutando números.

Essa espinha dorsal de custo exponencial contra produção linear é a mesma dos jogos incrementais. Se quiser vê-la na versão mais enxuta possível antes de encarar um tycoon completo, veja como fazer um jogo idle clicker na Godot. A diferença é que o tycoon coloca decisões ativas em cima dela: o quê comprar, quando, e o que sacrificar.

UI de management: painel de recursos e botão que respeita o dinheiro

Num tycoon, a UI não é enfeite, ela É o jogo. Duas regras mínimas: o recurso principal fica sempre visível, e o jogador nunca clica num botão de compra que não pode pagar. Botão desabilitado comunica "ainda não" muito melhor que uma mensagem de erro.

extends Control

@export var unidade: Unidade

@onready var label_dinheiro: Label = %LabelDinheiro
@onready var botao_comprar: Button = %BotaoComprar

func _ready() -> void:
    Economia.dinheiro_alterado.connect(_on_dinheiro_alterado)
    botao_comprar.pressed.connect(_on_comprar_pressed)
    _on_dinheiro_alterado(Economia.dinheiro)

func _on_dinheiro_alterado(novo_valor: int) -> void:
    label_dinheiro.text = 'R$ %d' % novo_valor
    var custo: int = Economia.custo_atual(unidade)
    botao_comprar.text = '%s (R$ %d)' % [unidade.nome, custo]
    botao_comprar.disabled = novo_valor < custo

func _on_comprar_pressed() -> void:
    Economia.comprar(unidade)

O %LabelDinheiro usa nomes únicos de cena (clique direito no nó > Access as Unique Name), o que evita caminhos frágeis quando você reorganiza a árvore. E note que a UI inteira reage ao signal da economia: quando o dinheiro muda, o texto atualiza e o botão habilita ou desabilita sozinho. Escrever o preço atual no próprio botão também é essencial, já que com a curva exponencial o custo muda a cada compra.

Eventos aleatórios para quebrar a monotonia

Uma economia estável demais vira piloto automático. Eventos aleatórios reintroduzem tensão e obrigam o jogador a reagir em vez de só executar o plano. A implementação mínima é uma chance baixa a cada tick:

signal evento_disparado(mensagem: String)

func _sortear_evento() -> void:
    if randf() > 0.05:
        return
    match randi_range(0, 2):
        0:
            dinheiro += 150
            evento_disparado.emit('Um cliente famoso visitou o local. Bônus de R$ 150!')
        1:
            dinheiro = maxi(0, dinheiro - 100)
            evento_disparado.emit('Uma máquina quebrou. Reparo: R$ 100.')
        2:
            receita_por_tick *= 2
            evento_disparado.emit('Movimento dobrado! Receita em dobro neste turno.')

Chame _sortear_evento() no final de _on_tick_timeout(). Os 5% de chance por tick significam um evento a cada vinte segundos, em média, com tick de um segundo. Duas dicas de design: misture eventos bons e ruins para que a notificação não vire sinônimo de punição, e escale o impacto junto com a economia do jogador (um desconto de R$ 100 é drama no início e irrelevante no final). Esse escalonamento conversa direto com a curva de dificuldade do jogo: eventos são uma das poucas ferramentas do gênero para controlar tensão ao longo do tempo.

Um primo direto do tycoon é o city builder, que troca a empresa pela cidade inteira: veja como fazer um city builder com escopo realista.

O escopo mínimo do seu primeiro tycoon

O erro clássico é começar clonando RollerCoaster Tycoon. Não faça isso. O primeiro tycoon que você termina vale mais que dez que você abandona. Escopo recomendado:

• 1 recurso: dinheiro. Sem madeira, sem energia, sem reputação. Um número.
• 3 unidades: uma barata de retorno rápido, uma média, uma cara de retorno alto. Três .tres e acabou. Exemplo com tema de lanchonete: barraca de suco, chapa de lanches, forno de pizza.
• 1 objetivo: uma condição de vitória clara, tipo "junte R$ 10.000". De preferência com pressão de tempo ou um upkeep que cresce sozinho, para existir derrota possível.

O que fica de fora da primeira versão: funcionários, mapa com posicionamento, múltiplas moedas, tecnologias, save game. Tudo isso é expansão para depois que o loop central estiver divertido. E o teste é honesto: se com um recurso, três unidades e um objetivo o jogo já prende por dez minutos, você tem um tycoon de verdade nas mãos. Se não prende, nenhuma feature extra vai consertar.

Com o tick econômico, as unidades em Resource, a curva de custo exponencial e a UI reativa deste guia, você tem o esqueleto completo do gênero rodando na Godot 4. O resto é tema, conteúdo e balanceamento. Escolha um negócio que você acharia engraçado administrar, monte os três .tres e coloque o Timer para rodar. E se quiser aprender a construir jogos completos com método, do design ao lançamento, é exatamente isso que ensinamos no CursoGame.Dev.