Godot 4.7: Cria um Jogo 2D em 12 Passos [2026]

O Godot passou de motor “alternativo” a opção séria de produção em pouco mais de quatro anos. Em 2020 representava 0,9% dos jogos analisados pela newsletter GameDiscover. Em 2025 já ia em 7,1%, e sobe para 8,6% quando se olha só para jogos ainda por lançar. A versão estável mais recente, Godot 4.7.2, saiu a 16 de agosto de 2026 (a 4.7 base tinha chegado a 18 de junho), e é gratuita, open source, sem royalties e sem letras miúdas. Este tutorial mostra, passo a passo, como instalar o Godot 4.7, programar um jogo 2D completo em GDScript e exportá-lo para Windows, Linux, macOS e Web, com todo o código incluído para copiares e testares.

No final vais ter um projeto real: jogador controlável, inimigos gerados aleatoriamente, pontuação, som, HUD com ecrã de “game over” e reinício, além de builds exportadas para quatro plataformas diferentes. Não é um exemplo teórico de “Hello World” – é a base mínima que qualquer jogo 2D indie precisa, e serve como ponto de partida para projetos maiores depois de dominares os conceitos aqui explicados.

O que é o Godot e porque está a crescer tanto em 2026

O Godot é um motor de jogo 2D e 3D gratuito e de código aberto, licenciado sob MIT, o que significa que podes vender jogos feitos com ele sem pagar comissões nem pedir autorização a ninguém. Ao contrário da Unity, que cobrou preços por instalação numa polémica decisão em 2023 e nunca recuperou totalmente a confiança de parte da comunidade, o Godot não tem modelo de negócio nenhum a monetizar em cima do teu jogo.

Já o Godot ultrapassou a Unity pela primeira vez numa game jam em 2026, sinal de que a mudança de comportamento não é passageira. Os números mostram uma migração real, não só ruído nas redes sociais. O inquérito oficial Godot Community Poll 2025, com 9.661 respostas, apurou que 57,1% dos utilizadores (5.521 pessoas) vieram da Unity, com a Unreal a ficar distante em segundo lugar (23,8%) e a GameMaker em terceiro (19,4%). Em eventos de game jam o fenómeno é ainda mais visível: no GMTK Game Jam 2025, com 9.724 jogos submetidos, cerca de 39% usaram Godot, contra 13% em 2021. No Global Game Jam 2025, com 4.108 respostas recolhidas de 35.427 participantes, a distribuição foi Unity 64%, Godot 20%, Unreal 11% e GameMaker 3%.

Nos lançamentos comerciais a fasquia ainda é mais baixa: segundo o “Big Game Engines Report 2025” da Video Game Insights, o Godot ficou em 5% dos jogos lançados na Steam em 2024, contra 51% da Unity e 28% da Unreal. E no inquérito State of the Game Industry 2026 da GDC, a Unreal ultrapassou pela primeira vez a Unity como motor principal declarado pelos programadores (42% contra 30%). Ou seja: o Godot está a crescer depressa entre principiantes e equipas indie, mas ainda não domina os lançamentos grandes. Para quem está a começar do zero em 2026, isso é o cenário ideal: comunidade em expansão, motor gratuito e sem a pressão de concorrer com produções AAA.

Parte desta velocidade vem do modelo de desenvolvimento aberto do próprio motor. A versão 4.3, por exemplo, somou mais de 3.500 commits de 521 contribuidores diferentes numa única release, segundo o anúncio oficial da equipa. Não há uma empresa a decidir sozinha o roteiro. Há centenas de programadores voluntários e patrocinadores a votar prioridades em público, o que explica porque funcionalidades pedidas pela comunidade (como o suporte a Wayland no Linux, que chegou na versão 4.4) avançam mais depressa do que em motores fechados.

Godot vs Unity vs Unreal: qual escolher em 2026

Antes de instalar seja o que for, vale a pena perceber onde o Godot se encaixa. Não é a ferramenta certa para todos os projetos, mas para jogos 2D, protótipos rápidos e primeiros projetos de aprendizagem é provavelmente a opção com menos fricção em 2026.

Critério	Godot 4.7	Unity	Unreal Engine 5
Licença	MIT (gratuita, sem royalties)	Gratuita até certo limite, depois subscrição	Gratuita, royalties acima de $1M de receita
Linguagem principal	GDScript (nativa), C#, C++	C#	C++, Blueprints visuais
Tamanho do editor instalado	~150 MB	Vários GB (Hub + módulos)	Vários GB
Curva de aprendizagem	Baixa a média	Média	Média a alta
Melhor para	2D, protótipos, jogos indie	2D e 3D multiplataforma	3D de alta fidelidade gráfica
Quota em lançamentos Steam 2024	5%	51%	28%
Motor primário (GDC 2026)	Ainda residual nesta métrica	30%	42%

A relação entre os dois grandes motores comerciais também está a mudar, como mostra o anúncio de que a Unity vai correr dentro do Unreal Engine. Se já conheces C# e queres um caminho direto para estúdios que usam Unity comercialmente, faz sentido continuar lá. Se procuras um motor gratuito, leve, sem restrições de licenciamento e com uma linguagem de scripting desenhada para ser fácil de aprender, o Godot ganha claramente para este primeiro projeto.

Vale sublinhar que a escolha não precisa de ser definitiva. Muitos criadores usam o Godot precisamente para prototipar mecânicas rapidamente, mesmo que o jogo final acabe noutro motor, porque o ciclo entre escrever código e ver o resultado em ecrã é mais curto do que em projetos Unity ou Unreal de maior escala. Para quem vem de fora da programação de jogos, essa iteração rápida costuma pesar mais na decisão do que qualquer tabela de comparação de funcionalidades.

Pré-requisitos: o que precisas antes de começar

Este tutorial não assume conhecimento prévio de programação de jogos, mas assume que sabes navegar num sistema de ficheiros e já escreveste algum código, nem que seja HTML ou uma folha de cálculo com fórmulas. A lista abaixo resume tudo o que precisas ter pronto antes do Passo 1.

Requisito	Versão / especificação mínima
Godot Engine	4.7.2-stable (build “x86_64” ou “x86_64 · C# support” para usar C#)
Sistema operativo	Windows 10/11, Ubuntu 22.04+ ou macOS 12+
Memória RAM	4 GB mínimo, 8 GB recomendado
Espaço em disco	1 GB livre (editor + projeto + modelos de exportação)
GPU	Suporte a OpenGL 3.3 / Vulkan 1.0 (qualquer placa dos últimos 8 anos serve)
Modelos de exportação (opcional)	Export Templates 4.7.2, só necessários no Passo 11
Editor de texto (opcional)	VS Code com a extensão “Godot Tools”, se preferires editar fora do editor interno

Não precisas de conta paga em lado nenhum. O Godot não pede registo, não tem telemetria obrigatória e corre offline depois de instalado. Também não precisas de placa gráfica dedicada: o jogo que vamos construir é 2D e corre perfeitamente em gráficos integrados.

Uma vantagem prática para quem experimenta várias versões: como o editor é um único executável portátil, sem instalador nem registo no sistema, podes ter o Godot 4.6, o 4.7.2 e a LTS 3.6.3 em pastas separadas no mesmo computador, sem conflitos. Isto é útil se mantiveres um projeto antigo na linha 3.x enquanto aprendes a 4.x com este tutorial.

Passo 1: Instalar o Godot 4.7

Vai a godotengine.org e descarrega a build “Standard” para o teu sistema operativo. Se quiseres usar C# em vez de (ou a par de) GDScript, escolhe a build com “.NET” no nome. É maior, mas inclui o suporte necessário. O Godot não tem instalador tradicional: é um executável único que corres diretamente.

Depois de descarregado, confirma que a versão está correta antes de avançar. No Linux e macOS podes verificar pela linha de comandos:

# Linux / macOS: dar permissão de execução e confirmar a versão
chmod +x Godot_v4.7.2-stable_linux.x86_64
./Godot_v4.7.2-stable_linux.x86_64 --version

# Saída esperada (aproximada):
# 4.7.2.stable.official [xxxxxxxxx]

No Windows basta correr o .exe descarregado. O Windows Defender pode assinalar o ficheiro como “não reconhecido” na primeira execução, porque o Godot não paga certificado de assinatura de código. Isto é normal e está documentado pela própria equipa. Escolhe “Mais informações” e depois “Executar mesmo assim”.

Passo 2: Criar o projeto e configurar a janela do jogo

Abre o Godot e clica em “Criar Novo Projeto”. Escolhe uma pasta vazia (por exemplo ~/jogos/foge-dos-meteoros), dá um nome ao projeto e seleciona o renderizador “Forward+” se tiveres GPU recente, ou “Mobile” se estiveres num portátil mais antigo ou numa máquina virtual. O modo “Mobile” usa menos recursos e é suficiente para um jogo 2D.

Depois de criado o projeto, define a resolução base em Projeto → Definições do Projeto → Display → Window. Usa 480×720 (formato retrato, ideal para um jogo simples de desviar de obstáculos) e ativa o modo de esticamento “canvas_items” para que o jogo se adapte a diferentes tamanhos de ecrã sem distorcer os sprites.

Aproveita para deixar duas definições já corretas antes de escreveres uma única linha de código. Em Physics → Common, confirma que “Physics Ticks per Second” está em 60, o valor por omissão e suficiente para um jogo 2D deste tipo. Em Display → Window → V-Sync, mantém a sincronização vertical ativa durante o desenvolvimento: evita que a framerate dispare para números artificialmente altos no teu PC e esconda problemas de desempenho que só apareceriam em hardware mais modesto.

Passo 3: Perceber a interface – cenas, nós e sistema de ficheiros

O Godot organiza tudo em torno de dois conceitos: cenas e nós. Uma cena é uma árvore de nós guardada num ficheiro .tscn. Um nó é um bloco de comportamento (um sprite, um som, um corpo físico, um temporizador). Um jogador é uma cena com um nó raiz do tipo CharacterBody2D, dentro do qual colocas um Sprite2D (a imagem) e um CollisionShape2D (a área de colisão).

No painel esquerdo tens a árvore de cenas. No painel direito fica o “Inspector”, onde ajustas propriedades sem escrever código, e em baixo o “FileSystem”, que mostra os ficheiros do projeto. Esta separação entre “o que a coisa é” (nós) e “onde ela vive” (ficheiro .tscn) é a principal diferença mental para quem vem da Unity, onde tudo passa mais por scripts anexados a GameObjects genéricos.

Ainda na zona inferior do editor encontras separadores adicionais que vais usar ao longo deste tutorial. O “Output” mostra tudo o que os teus scripts imprimem com print(), o “Debugger” aparece automaticamente quando um script falha e aponta a linha exata do erro, o “Animation” permite criar sequências de movimento sem código, e o “Shader Editor” abre quando precisas de escrever efeitos visuais personalizados, algo que vamos referir mais à frente na secção de dicas avançadas.

Passo 4: Criar a cena e o sprite do jogador

Clica em “Nova Cena” e escolhe CharacterBody2D como raiz. Renomeia-o para Jogador. Dentro dele, adiciona um AnimatedSprite2D (podes usar qualquer conjunto de imagens PNG, mesmo formas coloridas feitas rapidamente num editor de imagem) e um CollisionShape2D com uma forma retangular ou circular ajustada ao tamanho do sprite.

Adiciona ainda um nó filho Area2D, com um segundo CollisionShape2D dentro dele. É este nó que vai detetar colisões com inimigos, separado da física de movimento do CharacterBody2D. Grava a cena como jogador.tscn.

Antes de programar o movimento, define as teclas de input em Projeto → Definições do Projeto → Input Map. Cria quatro ações: mover_cima, mover_baixo, mover_esquerda, mover_direita, e associa as setas do teclado (ou WASD) a cada uma.

Passo 5: Programar o movimento em GDScript

Com o nó Jogador selecionado, clica no ícone de script para anexar um novo ficheiro .gd. A documentação oficial de GDScript é a melhor referência para consultar a sintaxe completa sempre que precisares. O GDScript tem sintaxe muito próxima de Python: sem chavetas, indentação obrigatória, tipagem opcional. Aqui está o script completo de movimento:

extends CharacterBody2D

signal game_over

@export var velocidade: float = 400.0
var ecra_tamanho: Vector2

func _ready() -> void:
    ecra_tamanho = get_viewport_rect().size
    hide()

func _physics_process(delta: float) -> void:
    var direcao := Vector2.ZERO

    if Input.is_action_pressed("mover_direita"):
        direcao.x += 1
    if Input.is_action_pressed("mover_esquerda"):
        direcao.x -= 1
    if Input.is_action_pressed("mover_baixo"):
        direcao.y += 1
    if Input.is_action_pressed("mover_cima"):
        direcao.y -= 1

    if direcao.length() > 0:
        direcao = direcao.normalized()
        $AnimatedSprite2D.play()
    else:
        $AnimatedSprite2D.stop()

    velocity = direcao * velocidade
    move_and_slide()

    position = position.clamp(Vector2.ZERO, ecra_tamanho)

func iniciar(posicao: Vector2) -> void:
    position = posicao
    show()
    $CollisionShape2D.disabled = false

func _on_area_2d_body_entered(_body: Node2D) -> void:
    hide()
    game_over.emit()
    $CollisionShape2D.set_deferred("disabled", true)

Repara em dois pontos importantes: @export torna a variável velocidade editável no Inspector sem tocar em código, e position.clamp() impede o jogador de sair do ecrã sem precisar de paredes físicas invisíveis. O sinal game_over é emitido quando a área de colisão do jogador toca num inimigo. Vamos ligá-lo à cena principal no Passo 8.

Passo 6: Adicionar física, colisões e limites de ecrã

Repara que o script acima usa CharacterBody2D em vez de um simples Node2D com posição manual. A diferença é física: o CharacterBody2D integra-se automaticamente com o sistema de camadas de colisão do Godot 4.x, que desde a versão 4.4 usa o motor Jolt Physics por omissão em 3D (em 2D continua a usar o motor próprio do Godot, mais leve).

Configura as camadas de colisão em Projeto → Definições do Projeto → Layer Names → 2D Physics: define a camada 1 como “jogador” e a camada 2 como “inimigos”. No CollisionShape2D do jogador, ativa deteção apenas da camada 2, para que o jogador não colida com elementos de cenário que não devem parar o movimento.

Repara na distinção entre “layer” e “mask” no Inspector de cada corpo físico: a layer diz a que grupo esse nó pertence, a mask diz com que grupos ele deteta colisão. É comum confundir os dois quando se começa, porque um Area2D pode estar na camada “jogador” mas ter a mask configurada para detetar apenas “inimigos” – se trocares os valores, o sinal de colisão simplesmente nunca dispara, sem qualquer erro visível no editor para te avisar.

Passo 7: Criar inimigos com posições aleatórias

Cria uma nova cena com raiz RigidBody2D, chamada Mob, com um AnimatedSprite2D, um CollisionShape2D e um VisibleOnScreenNotifier2D. Este último remove o inimigo da memória automaticamente quando sai do ecrã, evitando fugas de memória em sessões de jogo longas. O script do inimigo faz o spawn com animação aleatória:

extends RigidBody2D

func _ready() -> void:
    var tipos := ["walk", "swim", "fly"]
    $AnimatedSprite2D.animation = tipos[randi() % tipos.size()]
    $AnimatedSprite2D.play()

func _on_visible_on_screen_notifier_2d_screen_exited() -> void:
    queue_free()

A geração aleatória de posição e ângulo de entrada fica no script da cena principal, porque é lá que decidimos onde e quando cada inimigo nasce. Manter o script do inimigo focado apenas no seu próprio comportamento é uma boa prática de organização que evita scripts gigantes difíceis de depurar.

Vale notar porque o movimento destes inimigos fica suave mesmo em ecrãs de alta taxa de atualização: a versão 4.3 do Godot introduziu interpolação de física 2D, que desacopla os ticks de física (fixos em 60 por segundo, como definiste no Passo 2) da framerate real de renderização. Sem esta funcionalidade, jogos com física a 60 Hz pareciam “aos soluços” em monitores de 120 Hz ou 144 Hz. Com ela, o movimento é interpolado visualmente entre ticks, sem qualquer alteração ao teu código de gameplay.

Passo 8: Sistema de pontuação e ecrã de jogo

Cria a cena principal (Main.tscn) com um nó raiz Node, e dentro dela instância as cenas Jogador e um Timer para controlar o spawn de inimigos e outro para a contagem de pontos. O script principal liga tudo através de sinais, em vez de referências diretas entre nós. Este é o padrão recomendado na documentação oficial do Godot para manter os componentes desacoplados:

extends Node

@export var cena_mob: PackedScene
var pontuacao: int = 0

func novo_jogo() -> void:
    pontuacao = 0
    $Jogador.iniciar($PosicaoInicial.position)
    $TimerSpawn.start()
    $TimerPontuacao.start()
    $HUD.mostrar_mensagem("Prepara-te")
    $HUD.atualizar_pontuacao(pontuacao)

func game_over() -> void:
    $TimerSpawn.stop()
    $TimerPontuacao.stop()
    $HUD.mostrar_game_over()

func _on_timer_pontuacao_timeout() -> void:
    pontuacao += 1
    $HUD.atualizar_pontuacao(pontuacao)

func _on_timer_spawn_timeout() -> void:
    var mob := cena_mob.instantiate()
    var posicao_spawn := $CaminhoSpawn/PosicaoMob
    posicao_spawn.progress_ratio = randf()
    mob.position = posicao_spawn.position

    var direcao := posicao_spawn.rotation + PI / 2
    direcao += randf_range(-PI / 4, PI / 4)
    mob.rotation = direcao
    mob.linear_velocity = Vector2(randf_range(150.0, 250.0), 0).rotated(direcao)

    add_child(mob)

No Inspector, arrasta a cena mob.tscn para a propriedade exportada cena_mob. Isto evita “hardcodar” o caminho do ficheiro no script: se mudares o nome ou local do ficheiro mais tarde, o script continua a funcionar sem alterações.

Falta ainda o próprio HUD, a camada de interface que mostra a pontuação e o ecrã de “game over”. Cria uma cena separada com raiz CanvasLayer (para garantir que fica sempre por cima do jogo, independentemente da câmara), com um Label para a pontuação, outro Label para mensagens centrais e um Button de “Jogar Novamente” que começa escondido. O script fica assim:

extends CanvasLayer

signal iniciar_jogo

func mostrar_mensagem(texto: String) -> void:
    $Mensagem.text = texto
    $Mensagem.show()

func atualizar_pontuacao(pontuacao: int) -> void:
    $Pontuacao.text = str(pontuacao)

func mostrar_game_over() -> void:
    mostrar_mensagem("Fim de Jogo")
    $BotaoReiniciar.show()

func _on_botao_reiniciar_pressed() -> void:
    $BotaoReiniciar.hide()
    $Mensagem.hide()
    iniciar_jogo.emit()

Liga o sinal iniciar_jogo do HUD à função novo_jogo() da cena principal através do painel “Node → Signals”, exatamente da mesma forma que ligaste a colisão do jogador ao sinal game_over no Passo 5. Com isto o ciclo fica completo: o jogador colide, a cena principal para os temporizadores, o HUD mostra o botão, e clicar nele reinicia tudo do zero sem precisar de recarregar a cena inteira.

Passo 9: Som, música e polish visual

Adiciona dois nós AudioStreamPlayer à cena principal: um para música de fundo e outro para efeitos sonoros (colisão, game over). Importa ficheiros .ogg ou .wav para a pasta do projeto. O Godot converte automaticamente na importação, não precisas de nenhuma ferramenta externa.

func game_over() -> void:
    $TimerSpawn.stop()
    $TimerPontuacao.stop()
    $MusicaFundo.stop()
    $SomGameOver.play()
    $HUD.mostrar_game_over()

Para dar um pouco de “polish” sem esforço extra, usa duas ou três frames de animação no AnimatedSprite2D do jogador e dos inimigos. Já dá sensação de movimento muito mais viva do que um sprite estático, e o custo de implementação é mínimo.

Se o volume da música de fundo e dos efeitos sonoros não estiver equilibrado, cria buses de áudio separados em Áudio → Buses (um chamado “Música”, outro “SFX”) e liga cada AudioStreamPlayer ao bus correspondente através da propriedade “Bus” no Inspector. Isto permite mais tarde adicionar um menu de opções de volume que controla música e efeitos de forma independente, sem tocar em nenhum script.

Passo 10: Testar e depurar o jogo

Prime F5 para correr o projeto (ou F6 para correr apenas a cena atualmente aberta, útil para testar o jogador isoladamente sem esperar pelo jogo completo). Na primeira execução o Godot pergunta qual é a cena principal. Escolhe Main.tscn.

Usa o painel “Debugger” na parte inferior do editor para ver erros em tempo real, incluindo o número exato da linha do script onde algo falhou. O separador “Monitors” mostra uso de memória e FPS ao vivo, útil para perceberes se os queue_free() dos inimigos estão mesmo a libertar memória à medida que saem do ecrã.

Para depuração mais fina, clica na margem esquerda de qualquer linha de um script para colocar um breakpoint: o jogo pausa exatamente nesse ponto e o painel “Debugger” mostra o valor de todas as variáveis locais nesse momento. O separador “Remote” da árvore de cenas (visível só enquanto o jogo corre) mostra a árvore de nós real em memória, incluindo os inimigos instanciados dinamicamente, o que ajuda a confirmar se o add_child(mob) do Passo 8 está mesmo a criar os nós esperados.

Exemplo de saída típica no painel “Output” quando tudo corre bem:

Godot Engine v4.7.2.stable.official
OpenGL API 3.3.0 - Compatibility - Using Device: Mesa Intel(R) UHD Graphics
Jogo iniciado. A aguardar input do jogador...
Pontuação atual: 12
Jogador colidiu com Mob. A emitir sinal game_over.

Passo 11: Exportar para Windows, Linux, macOS e Web

Antes de exportar, vai a Editor → Gestor de Modelos de Exportação e descarrega os “Export Templates” correspondentes à tua versão exata do Godot (4.7.2). Usar templates de uma versão diferente do editor é a causa mais comum de builds que não abrem depois de exportadas.

Em Projeto → Exportar, adiciona um preset para cada plataforma-alvo (Windows Desktop, Linux/X11, macOS, Web) e exporta manualmente pela interface, ou usa a linha de comandos para automatizar builds. Isto é útil se quiseres mais tarde ligar isto a um pipeline de integração contínua:

# Exportar em modo headless (sem abrir a interface gráfica)
godot --headless --export-release "Windows Desktop" build/jogo.exe
godot --headless --export-release "Linux/X11" build/jogo.x86_64
godot --headless --export-release "Web" build/index.html

Para a build Web, o Godot 4.3 reintroduziu a exportação single-threaded, o que aumenta a compatibilidade com navegadores que bloqueiam SharedArrayBuffer por omissão, como acontece em alguns hospedeiros gratuitos sem cabeçalhos COOP/COEP configurados. Se a versão multi-thread não carregar no browser, este é o primeiro ajuste a testar.

Passo 12: Publicar no itch.io

Com a build Web pronta, comprime a pasta de exportação num .zip e faz upload direto no itch.io como “jogo HTML”, marcando a opção “This file will be played in the browser”. Para as builds de Windows, Linux e macOS, faz upload dos executáveis separadamente e usa o cliente Butler da itch.io se quiseres automatizar atualizações futuras sem repetir o upload manual a cada nova versão.

Este é também o momento de escrever uma descrição curta, escolher tags corretas (2D, Arcade, Godot) e definir um preço. Mesmo que seja “paga o que quiseres” com mínimo de zero, isto ajuda a validar se há interesse real antes de investires mais tempo num projeto maior.

Depois de publicado, o painel de estatísticas do itch.io mostra visualizações, downloads e taxa de conversão por origem de tráfego, o que ajuda a perceber se vale a pena continuar a promover aquele jogo específico ou passar para o próximo protótipo. Muitos criadores que usam o Godot tratam cada jogo pequeno como um teste de mercado antes de comprometerem semanas de trabalho num projeto maior, e este ciclo curto entre “código” e “feedback real de jogadores” é uma das razões práticas para começar com um motor leve como o Godot em vez de saltar diretamente para um projeto 3D ambicioso. Se preferires seguir outro tutorial passo a passo antes de voltar a este, o nosso guia de configuração do Xbox Cloud Gaming segue uma estrutura semelhante, e a secção de notícias e tutoriais de gaming reúne o resto da cobertura sobre motores de jogo e plataformas.

Estrutura final do projeto completo

Chegado a este ponto tens um jogo funcional de raiz a raiz: menu implícito no ecrã inicial, jogador controlável, inimigos com spawn aleatório, pontuação, som e exportação para quatro plataformas. Antes de avançar para os erros comuns, vale a pena olhar para a árvore de ficheiros completa, porque é isto que separa um “monte de scripts soltos” de um projeto organizado que outra pessoa (ou tu, daqui a seis meses) consegue abrir e perceber de imediato:

foge-dos-meteoros/
├── project.godot
├── icon.svg
├── cenas/
│   ├── jogador.tscn
│   ├── jogador.gd
│   ├── mob.tscn
│   ├── mob.gd
│   ├── main.tscn
│   ├── main.gd
│   ├── hud.tscn
│   └── hud.gd
├── assets/
│   ├── sprites/
│   │   ├── jogador.png
│   │   └── mob.png
│   └── audio/
│       ├── musica_fundo.ogg
│       └── som_game_over.wav
└── export_presets.cfg

Repara que cada cena guarda o script correspondente ao lado, e que os recursos visuais e sonoros ficam isolados na pasta assets. Esta separação simples entre lógica (cenas/) e conteúdo (assets/) é a convenção mais comum em projetos Godot de qualquer dimensão, e facilita muito substituir arte placeholder por arte final sem tocar em código.

Controlo de versões: usar Git com projetos Godot

Um projeto Godot é só uma pasta de ficheiros de texto (.tscn, .gd, .godot) e binários de recursos, o que o torna perfeitamente compatível com Git desde o primeiro commit. A única armadilha é a pasta .godot/, gerada automaticamente pelo editor para cache de importação: não deve entrar no repositório, porque é recriada sempre que o projeto abre e só ocupa espaço desnecessário no histórico.

# .gitignore recomendado para projetos Godot 4.x
.godot/
.import/
export.cfg
export_credentials.cfg
*.translation

# Builds exportadas não devem ir para o repositório
build/

Inicializa o repositório logo a seguir ao Passo 2, antes de escreveres qualquer script, e faz commits pequenos por funcionalidade (movimento do jogador, depois inimigos, depois HUD) em vez de um único commit gigante no fim. Isto tem uma vantagem prática específica do Godot: os ficheiros .tscn são texto simples, por isso o git diff mostra exatamente que nó ou propriedade mudou entre commits, algo que motores com formatos de cena binários não permitem.

Erros comuns que travam projetos em Godot

Estes cinco erros aparecem com frequência em fóruns e no Discord oficial do Godot, e a maioria demora minutos a corrigir depois de identificada:

Confundir CharacterBody2D com RigidBody2D. O primeiro é para controlo direto por script (jogador), o segundo é para física simulada (objetos que reagem a forças). Usar o tipo errado produz movimento estranho difícil de depurar sem perceber a causa.
Esquecer o _physics_process em vez de _process para movimento. Código de física corrido em _process fica dependente da framerate, causando movimento inconsistente entre máquinas diferentes.
Não desativar o CollisionShape2D depois do game over. Sem isto, o sinal de colisão continua a disparar repetidamente enquanto o jogador está “morto” mas ainda visível no ecrã.
Misturar versões de Export Templates. Exportar com templates de uma versão diferente da instalada no editor gera builds corrompidas ou que fecham imediatamente ao abrir.
Caminhos de ficheiro escritos à mão em vez de exportados via @export. Renomear ou mover um ficheiro referenciado por caminho fixo parte o projeto silenciosamente, sem erro visível no editor.
Trocar layer com mask nas definições de colisão. Como referido no Passo 6, isto faz sinais de colisão nunca dispararem, e como não há erro no editor, o instinto é procurar o problema no script em vez de nas propriedades do nó.

Resolução de problemas: erros frequentes e soluções

Problema	Causa provável	Solução
Windows bloqueia o executável do Godot	Falta de certificado de assinatura de código	Clicar “Mais informações” → “Executar mesmo assim”
Jogo abre em janela preta	Renderizador incompatível com a GPU	Mudar de “Forward+” para “Mobile” nas definições do projeto
Sinais não disparam	Função de callback não ligada no editor ou nome trocado	Verificar no separador “Node → Signals” se a ligação existe
Build exportada não abre	Export Templates de versão diferente do editor	Reinstalar templates pela versão exata (4.7.2)
Jogo lento apenas em modo debug	Overhead normal do depurador ligado	Testar a build exportada, não a execução via F5
Inimigos não desaparecem e o jogo abranda com o tempo	Falta de `queue_free()` ao sair do ecrã	Ligar o sinal do VisibleOnScreenNotifier2D à função de remoção
Build Web não carrega no navegador	Falta de cabeçalhos COOP/COEP no servidor	Usar exportação single-threaded ou configurar os cabeçalhos no hosting
Som não toca na primeira vez	Política de autoplay dos navegadores modernos	Só reproduzir áudio depois da primeira interação do utilizador (clique/tecla)
Input não responde num dos eixos	Ação não mapeada em “Input Map”	Confirmar que todas as quatro ações de movimento têm tecla associada

Se o teu erro específico não estiver nesta lista, o fórum oficial do Godot e os separadores de “Issues” no repositório do GitHub costumam ter a resposta em minutos, porque a maioria dos problemas de principiante já foi discutida centenas de vezes por outros programadores a passar exatamente pela mesma fase de aprendizagem.

Dicas avançadas para ir além do tutorial

Depois de teres o jogo base a funcionar, há três direções que compensam explorar. A primeira é o sistema de shaders do Godot, que usa uma linguagem muito próxima de GLSL e permite efeitos visuais (brilho, distorção, dano no ecrã) sem sair do editor nem depender de plugins externos.

A segunda é migrar partes do projeto para C# se estiveres a construir algo mais complexo com muita lógica de dados. O Godot 4.7 mantém builds dedicadas com suporte .NET lado a lado com o GDScript, e podes misturar os dois no mesmo projeto sem conflito: GDScript para lógica de cena e C# para sistemas mais pesados como inventário, save/load ou IA.

A terceira é olhar para o motor de física Jolt, introduzido no Godot 4.4 para 3D. Se o teu próximo projeto for tridimensional, vale a pena testar as definições de física antes de assumir comportamento idêntico ao 2D deste tutorial. Junta a isto o uso de AnimationTree para transições de animação mais complexas do que o simples play/stop usado aqui, e já tens material para um segundo projeto bem mais ambicioso.

Uma quarta direção, mais avançada, é a API de multiplayer de alto nível incluída no próprio motor, com nós como MultiplayerSpawner e MultiplayerSynchronizer que tratam da replicação de estado entre clientes sem precisares de escrever sockets à mão. Não é necessária para o jogo deste tutorial, mas é o caminho natural se quiseres transformar este projeto num jogo cooperativo ou competitivo online mais tarde, sem trocar de motor.

Depois de exportado, o teu jogo corre em qualquer PC compatível, incluindo handhelds como o Steam Deck. Se quiseres testar a build lá, os passos são semelhantes aos descritos no nosso tutorial sobre como configurar dual boot com Windows 11 no Steam Deck, e vale a pena acompanhar também as atualizações de firmware cobertas em SteamOS 3.8.25 e o suporte a handhelds de outras marcas, já que afetam a compatibilidade de builds exportadas do Godot nesses dispositivos.

Perguntas frequentes

O Godot é mesmo gratuito para uso comercial?
Sim. A licença MIT permite vender jogos feitos com o Godot sem pagar royalties nem pedir autorização, ao contrário de motores com limites de receita.

Preciso de saber programar antes de começar?
Ajuda ter alguma experiência prévia com qualquer linguagem, mas o GDScript foi desenhado para ser a porta de entrada mais simples possível na programação de jogos, com sintaxe próxima de Python.

Qual a diferença entre Godot 4.7 e a linha LTS 3.6?
Segundo a política oficial de lançamentos, a linha 3.6 (atualmente na versão de manutenção 3.6.3) só recebe correções de segurança e compatibilidade para projetos antigos. Toda a funcionalidade nova, incluindo Jolt Physics e melhorias de rendering, entra na linha 4.x.

Consigo fazer jogos 3D com o Godot ou é só para 2D?
O Godot suporta 3D nativamente, mas a sua reputação e maior parte da adoção em 2026 continua concentrada em jogos 2D, onde a curva de aprendizagem é mais suave para principiantes.

Posso exportar o mesmo projeto para telemóvel?
Sim, o Godot exporta para Android e iOS a partir do mesmo projeto, embora seja necessário instalar o Android SDK ou configurar um certificado de developer da Apple consoante a plataforma-alvo.

O que muda ao usar C# em vez de GDScript?
C# compila para código mais rápido em cálculos intensivos e beneficia de ferramentas como o Visual Studio, mas exige instalar o .NET SDK à parte. O GDScript integra-se de forma mais direta no editor sem passos extra de configuração.

Vale a pena migrar um projeto Unity para Godot?
Depende da fase do projeto. Para protótipos ou projetos ainda em fase inicial, muitos criadores fazem essa troca, como mostra o facto de mais de metade dos utilizadores no inquérito da comunidade Godot 2025 virem da Unity. Para projetos avançados com muito código específico da Unity, o custo de reescrita pode não compensar.

Onde posso publicar o jogo depois de exportado?
O itch.io é o destino mais simples para começar, sem custos de submissão. Para chegar a mais jogadores, a Steam também aceita jogos feitos em Godot sem qualquer restrição relacionada com o motor escolhido.

Godot 4.7: Cria um Jogo 2D em 12 Passos, 90 Min [2026]