Como Fazer um Metroidvania: Mapa, Habilidades e Exploração

Se você joga Hollow Knight, Ori ou os Metroid e Castlevania clássicos e sente vontade de construir algo assim, aprender como fazer um metroidvania começa por entender uma coisa: o gênero não é sobre combate, nem sobre plataforma, nem sobre chefes difíceis. É sobre um mundo que se abre aos poucos conforme você fica mais capaz. A chave que abre a porta não é um item no inventário, é um movimento novo no seu corpo. Essa troca simples, de chave por habilidade, é o que separa um metroidvania de um jogo de plataforma comum.

Este guia segue o espírito da série de gêneros aqui do blog: desmontar o metroidvania em sistemas e mostrar em que ordem construir cada um, incluindo um exemplo real de código na Godot. Na base, o gênero é um jogo de plataforma com um mundo grande, então se movimento, colisão e câmera ainda não são território conhecido pra você, vale passar antes pelo guia de como fazer um jogo de plataforma na Godot, porque tudo aqui assume esse chão.

O que define um metroidvania

Dois pilares sustentam o gênero, e eles precisam existir juntos.

O primeiro é o mapa interconectado. Em vez de fases separadas com começo e fim, o metroidvania tem um mundo único e contínuo. As áreas se conectam por corredores, poços, elevadores e passagens secretas, e o jogador transita entre elas livremente. Não existe "fase 3", existe "a caverna alagada que fica embaixo da torre".

O segundo é a progressão por habilidade. O jogador encontra caminhos que não consegue atravessar: uma parede alta demais, um vão largo demais, uma porta que exige um golpe que ele ainda não tem. A solução nunca está ali do lado. Ela está em outra área, na forma de uma habilidade nova de movimento ou combate. Quando o jogador ganha o pulo duplo, todas as paredes altas do mundo inteiro se abrem de uma vez, incluindo aquelas que ele viu duas horas atrás e anotou mentalmente.

É daí que nasce o backtracking, o ato de voltar por áreas já visitadas. Em jogo ruim, backtracking é enrolação. Em metroidvania bom, é o momento mais gostoso do jogo: voltar por um lugar conhecido, agora com um poder novo, e colher tudo que estava fora de alcance. A diferença entre os dois é propósito. Se o jogador volta porque quer abrir o que ficou trancado, funciona. Se volta porque o jogo o obriga a atravessar corredores vazios, quebra.

O mapa é o protagonista

Num metroidvania, o level design não é o cenário da história, é a história. O jogador passa o jogo inteiro construindo um modelo mental do mundo: o que conecta com o quê, onde ficou aquela porta trancada, qual caminho leva de volta ao chefe. Projetar esse mundo é o trabalho central do gênero, e os princípios fundamentais de level design valem dobrado aqui, porque cada erro de layout se multiplica pelo número de vezes que o jogador revisita a área.

Três ferramentas fazem esse mundo funcionar.

Gating por habilidade. Cada tipo de bloqueio corresponde a uma habilidade. Vão largo pede dash. Parede alta pede pulo duplo. Poço vertical de paredes lisas pede wall jump. Piso rachado pede um golpe descendente. O truque é que o bloqueio precisa ser legível: quando o jogador vê a parede alta, ele deve pensar "ainda não consigo subir aqui", e não "será que esse é o caminho?". Bloqueio ilegível vira jogador perdido tentando pular a mesma parede por dez minutos.

Atalhos e loops. Mundo interconectado sem atalhos vira caminhada. Os melhores metroidvanias enchem o mapa de conexões que se abrem por dentro: você explora um caminho longo e perigoso, e no final destranca uma porta que despeja de volta perto do ponto de save. Esse loop recompensa a exploração duas vezes, com o conteúdo novo e com a viagem de volta encurtada. Ao desenhar uma área, pense sempre em como o jogador sai dela, não só em como entra.

O mapa in-game. Num mundo desse tamanho, a memória do jogador não dá conta sozinha. O mapa dentro do jogo é o que transforma "estou perdido" em "sei exatamente onde ficou aquela porta". Ele não precisa ser bonito no começo, retângulos indicando salas visitadas já resolvem, mas precisa existir cedo. Marque salas visitadas, pontos de save e, se quiser ser gentil, os bloqueios que o jogador viu e ainda não abriu.

Habilidades como chaves: planeje a ordem antes do mundo

Aqui está o conselho que mais economiza retrabalho no gênero inteiro: decida a lista de habilidades e a ordem delas antes de desenhar o mapa. Não o contrário.

A razão é estrutural. O mundo de um metroidvania é construído em cima dos bloqueios, e cada bloqueio depende de uma habilidade específica. Se você desenha um mundo lindo e depois decide quais poderes o jogador ganha, vai descobrir que a área da esquerda não tem razão pra ser visitada, que dá pra alcançar o chefe final sem nenhuma habilidade e que metade dos seus segredos está acessível desde o minuto um. Aí o retrabalho come o projeto.

O planejamento cabe numa tabela simples, que pode viver numa folha de papel: cada área do jogo numa linha, e ao lado a habilidade que ela exige pra ser explorada por completo. Algo como: a floresta inicial não exige nada, a caverna exige dash, a torre exige pulo duplo, o abismo exige wall jump, e o covil do chefe exige as três. Com essa tabela pronta, a ordem de exploração do jogador está definida antes de qualquer sala existir, e cada área que você desenhar já nasce sabendo qual é o seu papel na progressão.

Repare que as habilidades de metroidvania são quase sempre habilidades de movimento, e é de propósito. Um movimento novo muda como o jogador atravessa o mundo inteiro, não só a porta que ele abre. O pulo duplo destranca a torre, mas também deixa todo o resto do jogo mais fluido. Se a implementação dessas mecânicas ainda está na sua lista, o guia de double jump e wall jump na Godot cobre exatamente as duas habilidades mais clássicas do gênero, com código pronto pra adaptar.

Implementando o desbloqueio de habilidades na Godot

A pergunta prática que todo dev faz na primeira semana de projeto: onde guardo quais habilidades o jogador já tem? A resposta na Godot é um autoload, um script registrado em Projeto, Configurações do Projeto, aba Autoload, que fica vivo o jogo inteiro, independente de qual cena está carregada. É o lugar perfeito pra progressão, porque o jogador troca de área o tempo todo e o estado precisa sobreviver a essas trocas.

Um autoload de progressão minimalista, registrado com o nome Progressao, fica assim:

extends Node

signal habilidade_desbloqueada(nome: String)

var habilidades: Dictionary = {
    "dash": false,
    "pulo_duplo": false,
    "wall_jump": false,
}

func desbloquear(nome: String) -> void:
    if not habilidades.has(nome):
        push_warning("Habilidade desconhecida: " + nome)
        return
    habilidades[nome] = true
    habilidade_desbloqueada.emit(nome)

func tem_habilidade(nome: String) -> bool:
    return bool(habilidades.get(nome, false))

O dicionário lista todas as habilidades do jogo, começando falsas. Quando o jogador pega o power-up, o item chama Progressao.desbloquear("dash"), e o sinal habilidade_desbloqueada avisa quem quiser reagir, como a interface que mostra o poder novo na tela. O push_warning protege contra o erro clássico de digitar o nome errado numa chamada e passar semanas sem entender por que a habilidade não desbloqueia.

No script do player, a checagem entra antes de executar o movimento:

extends CharacterBody2D

const VELOCIDADE_DASH: float = 600.0

func _physics_process(_delta: float) -> void:
    if Input.is_action_just_pressed("dash") and Progressao.tem_habilidade("dash"):
        iniciar_dash()
    move_and_slide()

func iniciar_dash() -> void:
    var direcao: float = Input.get_axis("mover_esquerda", "mover_direita")
    if direcao != 0.0:
        velocity.x = direcao * VELOCIDADE_DASH

A beleza dessa arquitetura é que o código do movimento já existe completo desde o início, e o desbloqueio é só um portão booleano na frente dele. Você programa o dash uma vez, testa ele à vontade deixando o dicionário como true durante o desenvolvimento, e o jogo inteiro de gating se resume a decidir quando cada valor vira verdadeiro. Pra salvar o progresso em disco depois, é só serializar esse dicionário junto com o resto do save.

Combate, save rooms e ritmo

O combate de metroidvania não precisa ser profundo, precisa ser responsivo. O jogador vai atacar milhares de vezes ao longo do jogo, então o golpe básico tem que sair no instante do botão, ter alcance previsível e dar retorno claro quando acerta: um flash no inimigo, um som seco, uma pausa de um ou dois frames. Comece com um ataque corpo a corpo simples e bem temperado antes de pensar em combos ou magias. Hollow Knight sustenta dezenas de horas com pouquíssimos golpes, todos excelentes.

Os pontos de save merecem mais atenção de design do que parecem. Eles não são só função técnica, são a respiração do jogo. A caminhada tensa por área desconhecida, com vida baixa e medo de perder progresso, termina no alívio de encontrar uma sala de save. Esse ciclo de tensão e alívio é o ritmo emocional do gênero. Espalhe os saves de forma que a tensão exista, mas nunca vire punição: um save logo antes de cada chefe e um em cada fronteira de área é um bom ponto de partida.

O ritmo geral do jogo alterna três atividades: explorar caminho novo, lutar contra o que mora nele e, de tempos em tempos, enfrentar um chefe que fecha o capítulo. Se o jogador passa tempo demais só explorando, o jogo fica frouxo. Se é só combate, o mundo deixa de importar. O chefe funciona como pontuação: ele marca o fim de uma região e quase sempre entrega, na sequência, a habilidade nova que reabre o mundo e recomeça o ciclo.

Escopo realista: o metroidvania mínimo viável

Agora a conversa honesta. Metroidvania é um dos gêneros mais caros de produzir pra um indie, porque o mundo é desenhado à mão e tudo é interligado. Cada área nova precisa conversar com as existentes, e mudar um bloqueio no início pode quebrar a progressão lá na frente. Hollow Knight levou anos de trabalho de uma equipe dedicada, e é injusto usar ele como régua pro seu primeiro projeto.

A régua justa é o metroidvania mínimo viável: 3 a 5 áreas, 2 ou 3 habilidades e 1 chefe. Parece pouco, mas repare que isso já contém o ciclo completo do gênero: o jogador explora, esbarra num bloqueio legível, encontra a habilidade em outro canto, volta com propósito e abre o caminho até o chefe. Quem joga esse recorte sente o gosto de metroidvania inteiro. A partir daí, crescer é adicionar linhas na sua tabela de áreas e habilidades, não reinventar o jogo.

E antes mesmo dessas 3 áreas, construa uma vertical slice: um pedaço pequeno com qualidade final, tipo duas salas, uma habilidade e um bloqueio que ela abre. Essa fatia responde às perguntas que importam, se o movimento é gostoso, se o gating é legível e se o loop de voltar e destrancar dá satisfação de verdade. Se a resposta for não, você descobre com duas salas construídas, não com quarenta.

O caminho, então, é esse: tabela de habilidades e áreas primeiro, vertical slice pra validar a diversão, mapa in-game cedo, e o mundo crescendo uma área por vez em volta dos bloqueios. Aqui no CursoGame.Dev a gente repete que jogo se aprende fazendo, e nesse gênero isso significa começar com um mundo pequeno que se dobra sobre si mesmo, não com um continente vazio. Abra a Godot, crie o autoload de progressão e faça sua primeira porta trancada. O resto do mundo cresce a partir dela.