Câmera 2D que segue o jogador no Godot: guia prático

Uma câmera 2D que segue o jogador no Godot é um daqueles recursos que parece trivial, mas faz toda a diferença entre um protótipo travado e um jogo que dá gosto de jogar. Se o personagem sai da tela ou a visão fica presa num canto do mapa, o jogador se perde. A boa notícia: no Godot 4 isso é resolvido com o nó Camera2D, sem uma linha de código no caso mais simples. Neste tutorial você vai montar a câmera do zero, ligar a suavização, travar os limites do mapa e entender quando vale a pena controlar tudo por script.

O nó Camera2D no Godot 4

O Godot 4 traz o nó Camera2D pronto para uso. Ele define qual parte do mundo 2D aparece na tela. Quando existe uma Camera2D ativa numa cena, a viewport passa a enquadrar a posição dela em vez de mostrar sempre a origem do mundo.

A forma mais direta de fazer a câmera acompanhar o personagem é adicioná-la como filha do player. Assim, sempre que o corpo do jogador se move, a câmera se move junto de graça, porque no Godot os nós filhos herdam a transformação do pai.

Monte a cena do player mais ou menos assim:

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

Com a Camera2D selecionada no editor, verifique no inspetor a propriedade enabled. No Godot 4 ela vem marcada por padrão e, sendo a única câmera na árvore, já assume o controle assim que a cena entra em execução. Rode o projeto: o personagem anda, a câmera segue. Esse é o ponto de partida, e para muitos jogos de plataforma ou top-down ele já é suficiente.

Se você ainda está montando o movimento do personagem, vale revisar a base de lógica em GDScript do zero antes de seguir, porque daqui em diante o código pressupõe que o player já se mexe.

Suavização de movimento com position smoothing

Uma câmera colada no player pode parecer dura, especialmente em jogos com movimento rápido. O Godot 4 resolve isso com a suavização de posição, que faz a câmera deslizar até o alvo com uma leve inércia em vez de saltar instantaneamente.

No inspetor da Camera2D, abra a seção Position Smoothing e ative position_smoothing_enabled. Depois ajuste position_smoothing_speed. Esse valor controla a velocidade da suavização: quanto maior, mais rápido a câmera alcança o player; quanto menor, mais preguiçoso e cinematográfico fica o movimento. Um valor entre 5 e 10 costuma ficar agradável.

Você também pode configurar isso por código, o que é útil para mudar o comportamento em tempo de jogo, por exemplo deixar a câmera mais lenta durante uma cena de diálogo:

extends Camera2D

@export var velocidade_suavizacao: float = 8.0

func _ready() -> void:
    position_smoothing_enabled = true
    position_smoothing_speed = velocidade_suavizacao

Repare na tipagem estática: velocidade_suavizacao: float e o retorno -> void. No Godot 4 essa é a forma recomendada de escrever GDScript, porque o editor avisa erros de tipo antes de você rodar o jogo e o código roda um pouco mais rápido.

Um detalhe importante: a suavização de posição só se aplica quando a câmera está seguindo o pai. Se você teleportar o player para outro ponto do mapa e não quiser que a câmera faça um deslize longo até lá, chame reset_smoothing() logo após reposicionar. Isso força a câmera a assumir a posição final na hora.

func teleportar_player(destino: Vector2) -> void:
    global_position = destino
    var cam: Camera2D = $Camera2D
    cam.reset_smoothing()

Limites do mapa: limit_left, right, top e bottom

Nada quebra mais a imersão do que a câmera mostrando o vazio cinza além da borda do nível. Para prender o enquadramento dentro do mapa, o Camera2D tem quatro propriedades de limite, todas em pixels no espaço global:

• limit_left: borda esquerda máxima que a câmera enxerga.
• limit_right: borda direita.
• limit_top: borda superior.
• limit_bottom: borda inferior.

Digamos que seu nível tenha 2000 pixels de largura e 1200 de altura, começando na origem. Você configuraria os limites assim:

extends Camera2D

func _ready() -> void:
    limit_left = 0
    limit_top = 0
    limit_right = 2000
    limit_bottom = 1200

Com isso, mesmo que o player chegue na borda do mapa, a câmera para de acompanhar naquela direção e mantém o cenário preenchendo a tela toda. O player continua andando até o canto, mas a visão não passa do limite.

Se você quiser que a câmera respeite o smoothing também ao bater nos limites, ative limit_smoothed. Sem isso, a câmera para seca ao encostar na borda. Para jogos de plataforma isso é ótimo. Para prototipar níveis rápido, vale ler também nossas dicas sobre como testar mecânicas cedo em prototipar um jogo rápido.

Uma dica prática: em vez de números fixos, calcule os limites a partir do tamanho do seu TileMap ou de um Marker2D colocado nos cantos do nível. Isso evita corrigir valores na mão toda vez que o mapa muda de tamanho.

Drag margins: a zona morta no centro da tela

As drag margins, ou margens de arraste, criam uma área central onde o player pode se mover sem arrastar a câmera junto. Só quando o personagem cruza essa zona morta a câmera começa a acompanhar. O efeito é comum em jogos de plataforma clássicos: você pula e anda um pouco sem a tela mexer, o que reduz a sensação de enjoo.

No inspetor, abra a seção Drag e ative drag_horizontal_enabled e drag_vertical_enabled conforme a necessidade. Depois ajuste as margens, que vão de 0 a 1 e representam a fração da tela a partir do centro. Uma margem de 0.2 significa que o player pode andar até 20 por cento da metade da tela antes de puxar a câmera.

Por código fica assim:

extends Camera2D

func _ready() -> void:
    drag_horizontal_enabled = true
    drag_vertical_enabled = true
    drag_left_margin = 0.2
    drag_right_margin = 0.2
    drag_top_margin = 0.15
    drag_bottom_margin = 0.15

Você pode combinar drag margins com position smoothing sem problema. A drag margin define quando a câmera começa a mover, e o smoothing define como ela chega lá. Juntas, dão aquele acompanhamento macio e natural que os jogos comerciais têm.

Câmera como filha do player ou câmera separada por código

Até aqui usamos a Camera2D como filha do player, que é a escolha certa para a maioria dos casos. Mas existe uma segunda abordagem: uma câmera separada na cena principal que segue o player por script. Vale entender quando cada uma faz sentido.

Deixe a câmera como filha do player quando:

• O jogo tem um único personagem controlável.
• Você quer o seguimento funcionando sem código.
• O enquadramento é sempre centrado no player.

Use uma câmera separada seguindo por código quando:

• Precisa mirar entre vários alvos, como dois jogadores num co-op de tela dividida ou um chefão que exige mostrar player e boss juntos.
• Quer transições entre salas no estilo Metroidvania, com a câmera pulando de uma zona para outra.
• Precisa de efeitos como tremor de tela, zoom dinâmico ou travamento temporário sem mexer no player.

Na abordagem por código, a câmera vive na cena do nível e recebe uma referência ao player. O seguimento acontece no _physics_process, que roda em sincronia com a física e evita o tremor causado por atualizar a posição no _process:

extends Camera2D

@export var alvo_path: NodePath
@onready var alvo: Node2D = get_node(alvo_path)

@export var velocidade: float = 6.0

func _physics_process(delta: float) -> void:
    if alvo == null:
        return
    global_position = global_position.lerp(alvo.global_position, velocidade * delta)

O lerp interpola a posição atual da câmera em direção ao alvo a cada quadro, criando uma suavização manual equivalente ao position smoothing. A vantagem de fazer no código é o controle total: você pode trocar o alvo a qualquer momento, calcular um ponto médio entre dois jogadores ou aplicar um deslocamento para mostrar mais do cenário à frente do player.

Se o comportamento da câmera muda conforme o estado do jogo, por exemplo modo exploração contra modo combate, faz sentido organizar essas transições com uma máquina de estados no Godot. Assim cada estado define seu próprio alvo e velocidade sem virar um emaranhado de ifs.

Juntando tudo num exemplo testável

Para fechar, aqui está um script completo de uma Camera2D filha do player que liga suavização, limites e drag margins de forma organizada. Cole numa Camera2D dentro da cena do jogador, rode e ajuste os valores no inspetor via @export:

extends Camera2D

@export var suavizacao: float = 8.0
@export var margem_horizontal: float = 0.2
@export var margem_vertical: float = 0.15

@export var mapa_largura: int = 2000
@export var mapa_altura: int = 1200

func _ready() -> void:
    position_smoothing_enabled = true
    position_smoothing_speed = suavizacao

    drag_horizontal_enabled = true
    drag_vertical_enabled = true
    drag_left_margin = margem_horizontal
    drag_right_margin = margem_horizontal
    drag_top_margin = margem_vertical
    drag_bottom_margin = margem_vertical

    limit_left = 0
    limit_top = 0
    limit_right = mapa_largura
    limit_bottom = mapa_altura
    limit_smoothed = true

Rode o projeto e ande com o personagem pelo mapa. A câmera desliza atrás dele, respeita a zona morta central e trava nas bordas do nível. Mude os valores de suavizacao e das margens direto no inspetor para sentir na prática como cada um afeta o resultado, sem parar de rodar o jogo.

Essa mesma câmera se encaixa em jogos top-down, plataforma e até em cenas 2.5D. E se o próximo passo do seu projeto for dar o salto para três dimensões, a lógica de acompanhamento muda, mas o raciocínio continua parecido: vale conferir como montar seu primeiro jogo 3D na Godot para comparar as abordagens.

Conclusão

Fazer uma câmera 2D que segue o jogador no Godot 4 começa fácil, um nó Camera2D como filho do player, e vai ficando mais rico conforme você adiciona suavização, limites de mapa e drag margins. O segredo é ir por camadas: primeiro o seguimento básico, depois o polimento. Quando o enquadramento simples não der conta, parta para a câmera separada por código e ganhe controle total sobre alvos e transições. Com os exemplos deste guia você já tem tudo para testar cada propriedade no seu próprio projeto e sentir a diferença na hora.