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.

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.

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.