Game Jams: Guia Completo para Criar Jogos em 48 Horas

Game jam é uma maratona onde você sai do zero e entrega um jogo jogável em 24, 48 ou 72 horas, quase sempre em cima de um tema revelado na largada. Eu já entrei em vários, perdi noite, fiz besteira, e saí de cada um sabendo mais do que aprendia em meses lendo tutorial. É a forma mais rápida que conheço de descobrir se você realmente termina um jogo ou se você só gosta de começar.

Este guia é o que eu faria hoje, em ordem, se fosse entrar num jam amanhã.

O que são game jams

São eventos com prazo apertado e tema definido. Você cria tudo dentro da janela: código, arte, som, build. Os mais conhecidos:

• Ludum Dare: um dos mais tradicionais, com modo Compo (solo, do zero, 48h) e Jam (equipe, 72h).
• Global Game Jam: evento presencial mundial, normalmente em janeiro, com 48h e um tema único divulgado simultaneamente em todos os sites.
• GMTK Game Jam: criado pelo canal Game Maker's Toolkit, foco pesado em ideia de design em cima de uma restrição. É hoje uma das maiores do mundo em número de jogos enviados, e virou termômetro do mercado: na edição de 2026, a Godot foi a engine mais usada da jam, com 47% dos jogos, encerrando nove anos de liderança da Unity.
• Brackeys Game Jam: comunidade grande, calorosa com iniciante, janela de cerca de uma semana.
• itch.io: a página de jams do itch.io tem dezenas rolando o ano inteiro, de todo tamanho e tema. É o melhor lugar pra começar sem pressão.

Por que entrar

Não é pela medalha. É por isto:

1. Você aprende na marra. Em 48 horas com prazo você toca em decisões que num projeto solo levaria semanas pra encarar.
2. Você termina algo. Portfólio cheio de protótipo abandonado não conta história. Um jogo finalizado, sim.
3. Você conhece gente. Programador, artista, músico, todo mundo no mesmo barco e com a guarda baixa.
4. Você testa ideia maluca sem risco. Se der ruim, foram 48 horas, não seis meses.
5. Você recebe feedback de verdade. Gente joga, comenta, avalia, e você vê na hora o que funcionou.

Preparação pré-jam

O jam começa antes do tema sair. O que você prepara na semana anterior é tempo que você não gasta brigando com ferramenta no sábado de manhã.

1. Deixe o ambiente pronto

Monte um template de projeto vazio e deixe salvo. Uma estrutura de pastas que funciona bem pra Godot:

• scenes/ separada por player/, enemies/, levels/ e ui/
• scripts/ para código que não vive grudado numa cena específica
• assets/ dividida em sprites/, audio/ e fonts/
• addons/ para os plugins

Deixe também os plugins que você costuma usar já instalados e testados. Plugin que você vai descobrir que não funciona às 3h da manhã não serve pra nada. Alguns que valem o espaço dependendo do tipo de jogo: Dialogic para diálogos, Phantom Camera para câmera 2D/3D mais esperta.

E tenha o resto do arsenal aberto e configurado antes da largada:

• Editor de código do seu jeito (atalhos, tema, o que for)
• Ferramenta de arte (Aseprite, Krita ou o que você já domina)
• Um DAW pra som (Reaper, FL Studio, ou Audacity pra editar)
• Repositório Git criado e clonado, com o primeiro commit feito

2. Pratique antes com mini-jams

Faça um jam solo de 4 a 8 horas algumas semanas antes. A ideia não é fazer um jogo bom, é treinar o ritmo de decidir rápido e cortar escopo. Você descobre seus gargalos enquanto ainda dá tempo de resolver.

Tenha snippets prontos do que sempre se repete. Um controller de plataforma 2D em Godot 4, por exemplo, é quase sempre o mesmo:

extends CharacterBody2D

const SPEED := 300.0
const JUMP_VELOCITY := -400.0

func _physics_process(delta: float) -> void:
    if not is_on_floor():
        velocity += get_gravity() * delta

    if Input.is_action_just_pressed("jump") and is_on_floor():
        velocity.y = JUMP_VELOCITY

    var direction := Input.get_axis("move_left", "move_right")
    velocity.x = direction * SPEED

    move_and_slide()

Vale ter na manga também: um inimigo com IA simples (perseguir ou patrulhar), um sistema básico de vida e dano, câmera seguindo o player, transição entre cenas, e um menu principal com pause. Nenhum desses precisa ser sofisticado. Precisa estar pronto pra colar.

3. Monte a equipe (opcional)

Dá pra jogar solo e dá pra jogar em time. Em time você produz mais, mas paga em coordenação. Uma divisão que funciona bem com quatro pessoas:

• Um programador focado em gameplay
• Um programador ou designer cuidando de level design
• Um artista (sprites ou modelos)
• Um responsável por som e música

Para combinar, o básico resolve: Discord pra voz e chat, um quadro simples no Trello ou Notion pra dividir tarefa, e Git pra versionar sem pisar no código um do outro.

Falando em Git, configure o .gitignore antes de começar pra não versionar lixo da Godot:

# Godot 4
.godot/
*.import
export.cfg
export_presets.cfg

Estratégia durante o jam

Hora 0 a 2: ideia e planejamento

O tema saiu. A pior coisa que você pode fazer agora é começar a programar a primeira ideia que veio. As primeiras ideias são quase sempre as mais óbvias, e óbvio costuma ser o que todo mundo vai fazer.

1. Despeje tudo (15 min): anote toda ideia que vier, sem filtro. Quantidade primeiro.
2. Filtre (30 min): para cada ideia que sobreviveu, pense em encaixe no tema, se você consegue fazer no tempo, se tem potencial de ser divertida, e se foge do óbvio.
3. Escolha uma (15 min): a que melhor equilibra "dá pra fazer" e "é diferente". Na dúvida, escolha a mais simples. Sempre.
4. Escreva um GDD de uma página (60 min): nada de documento gigante. Uma página que cabe na tela:

# Nome do Jogo

## Conceito
Uma frase que descreve o jogo.

## Mecânicas
1. Mecânica principal
2. Variação dela
3. Variação dela

## Progressão
- Começo: ensina a mecânica jogando
- Meio: aumenta a dificuldade
- Fim: o desafio mais duro

## Arte
Pixel art 16x16 (ou low poly, ou vetorial). Paleta de 5 cores.

## Áudio
Uma música em loop + uns 5 efeitos essenciais.

## Escopo
3 fases, 5 a 10 minutos de jogo, 1 mecânica core com 2 variações.

O GDD de uma página não é burocracia. É o seu freio contra o escopo explodir lá pra hora 20.

Hora 2 a 12: protótipo jogável

A meta aqui é uma só: ter o jogo rodando, mesmo que feio. Quadrado pulando em cima de outro quadrado já é um jogo se o controle responde bem.

Quando der pra montar o nível na mão, monte. Mas se você não tem tempo nem arte de cenário ainda, dá pra gerar plataformas por código e seguir testando o movimento:

extends Node2D

func _ready() -> void:
    for i in range(10):
        var platform := StaticBody2D.new()
        var collision := CollisionShape2D.new()
        var shape := RectangleShape2D.new()
        shape.size = Vector2(100, 20)
        collision.shape = shape
        platform.add_child(collision)
        platform.position = Vector2(i * 120, 300 + randi() % 200)
        add_child(platform)

Antes de seguir pra próxima fase, confira o básico: o controle responde bem, o objetivo está claro (chegar em algum lugar, coletar algo, derrotar alguém), tem algum feedback (som de pulo, um efeito ao colidir) e o ciclo fecha do começo ao fim. Se isso está de pé, o resto é conteúdo.

Hora 12 a 24: conteúdo

Agora você enche o esqueleto. Mais fases, inimigos, obstáculos, e uma UI básica com vida e pontuação. Power-up só se sobrar tempo.

Um jeito enxuto de trocar de fase sem ficar carregando cena na mão toda vez:

class_name LevelManager
extends Node

var levels: Array[String] = [
    "res://levels/level_1.tscn",
    "res://levels/level_2.tscn",
    "res://levels/level_3.tscn"
]

var current_level_index: int = 0

func load_next_level() -> void:
    current_level_index += 1
    if current_level_index >= levels.size():
        show_victory_screen()
        return
    get_tree().change_scene_to_file(levels[current_level_index])

func restart_level() -> void:
    get_tree().reload_current_scene()

Sobre arte: comece com forma geométrica e só troque por sprite se sobrar tempo. Consistência ganha de beleza. Um jogo todo com quadrado parece proposital. Um jogo metade bonito e metade quadrado parece inacabado.

Hora 24 a 40: polimento e juice

"Juice" é o conjunto de detalhes que faz o jogo parecer vivo: a tela treme num impacto, o personagem espreme e estica ao pular, um som toca, partículas saltam. Mecanicamente não muda quase nada. Na sensação, muda tudo.

Um screenshake simples numa câmera 2D:

class_name CameraShake
extends Camera2D

var shake_amount: float = 0.0
var shake_decay: float = 5.0

func _process(delta: float) -> void:
    if shake_amount > 0.0:
        shake_amount = lerp(shake_amount, 0.0, shake_decay * delta)
        offset = Vector2(
            randf_range(-shake_amount, shake_amount),
            randf_range(-shake_amount, shake_amount)
        )
    else:
        offset = Vector2.ZERO

func shake(intensity: float = 10.0) -> void:
    shake_amount = intensity

O squash and stretch do pulo é só um tween rápido escalando o sprite e voltando:

func _on_jump() -> void:
    var tween := create_tween()
    tween.tween_property($Sprite2D, "scale", Vector2(0.8, 1.2), 0.1)
    tween.tween_property($Sprite2D, "scale", Vector2(1.0, 1.0), 0.1)

Onde gastar essas horas, em ordem de retorno: som em toda ação principal, partícula nos eventos que importam (morte, coleta, explosão), transição suave entre telas, screenshake nos impactos, e por último squash and stretch e trilhas de movimento. Som e partícula entregam mais sensação por minuto de trabalho do que qualquer outra coisa.

Hora 40 a 46: fechar e buildar

Faltando algumas horas, pare de adicionar coisa. Sério. O que falta agora é garantir que o que você fez chega inteiro na mão de quem vai jogar.

1. Teste de ponta a ponta: jogue do início ao fim umas três vezes e cace bug que trava. Se tiver um amigo por perto, peça pra ele jogar sem você explicar nada. Você vai descobrir que metade do que era "óbvio" não é.
2. Builds: na Godot, vá em Project > Export. Windows é praticamente obrigatório. Linux costuma sair de brinde. Build pra Web (HTML5), quando funciona, é a que mais gente vai jogar, porque roda no navegador sem instalar nada (o passo a passo de exportar jogo da Godot para web cobre as pegadinhas desse export). Mac só se você tiver máquina pra testar, porque build que você não testou é build que pode estar quebrada.
3. Página no itch.io: a maioria dos jams é hospedada lá. Tire um screenshot de cada fase, grave um GIF curto de gameplay (ShareX ou OBS resolvem) e escreva uma descrição direta.

Um esqueleto de descrição que cobre o necessário:

# Nome do Jogo

![screenshot principal]

Criado em 48h para [nome do jam].

## Como jogar
- WASD ou setas: mover
- Espaço: pular

## Objetivo
Em uma ou duas frases.

## Créditos
- Programação: seu nome
- Arte: seu nome ou os asset packs usados
- Música: seu nome ou a fonte
- Feito com Godot Engine

## Bugs conhecidos
Liste os dois ou três que você não teve tempo de consertar.

Última hora: subir e respirar

Nunca, nunca deixe pra enviar nos últimos cinco minutos. Perto do deadline o servidor lota e o upload engasga. Suba sua build pelo menos uma hora antes e confira: ela roda numa máquina diferente da sua (peça pra um amigo abrir, pra pegar dependência que só existe no seu PC), a página do itch.io está completa, screenshots e GIF no lugar, controles descritos, créditos certos e tags marcadas.

Aí sim, respira.

Gestão de tempo e saúde

Um cronograma honesto de 48h

Ninguém produz bem virando a noite inteira. Um plano que reserva sono de verdade:

• Hora 0 a 2: ideia e planejamento
• Hora 2 a 8: protótipo core
• Hora 8 a 14: dormir
• Hora 14 a 20: conteúdo
• Hora 20 a 22: refeição e pausa longa
• Hora 22 a 28: dormir
• Hora 28 a 38: polimento e juice
• Hora 38 a 44: fechar, testar e buildar
• Hora 44 a 48: buffer pra emergência

Ajuste pro seu fuso e pro horário que o jam começa. O ponto é proteger o sono em vez de torcer pra ele caber no que sobrar.

E o óbvio que todo mundo ignora: durma, faça pausa de uns 10 minutos a cada duas horas, coma comida de verdade e não só salgadinho, e beba água. Você decide melhor descansado. Decisão ruim às 4h da manhã custa horas no dia seguinte.

Controle de escopo

Regra de ouro: corte feature, nunca qualidade. É melhor entregar três fases polidas do que dez pela metade.

Na prática, seu escopo vai encolher em camadas durante o jam, e tudo bem:

• No começo, ambicioso: 10 fases, 5 tipos de inimigo, sistema de upgrade, boss, cutscene.
• Lá pela hora 6, realista: 5 fases, 2 tipos de inimigo, dificuldade que sobe, tela de vitória simples.
• Se atrasou na hora 12, mínimo: 3 fases, 1 inimigo, progressão linear, um "You Win" em texto.

Saber de antemão qual camada você vai cortar primeiro é o que separa quem entrega de quem trava.

Pós-jam: tirando proveito

O jogo subiu. Acabou? Não. As 48h depois do jam valem quase tanto quanto as 48h do jam.

1. Jogue e avalie outros jogos

A maioria dos jams tem um período de avaliação onde os participantes jogam uns aos outros. Quanto mais jogos você avalia com comentário de verdade, mais gente vem ver o seu. Mira em uns 20 a 30 jogos nos primeiros dias, deixa comentário específico (elogie a mecânica X, sugira algo concreto sobre o Y) e responde todo mundo que comentou no seu. Comentário genérico tipo "legal, parabéns" não constrói nada.

2. Devlog e post-mortem

Sente e escreva o que rolou enquanto está fresco. Não precisa ser bonito, precisa ser honesto:

# Post-mortem: Nome do Jogo

## O que funcionou
- Escopo controlado deu tempo de polir
- Tal sistema saiu rápido
- Arte ficou consistente mesmo simples

## O que não funcionou
- Perdi 4h num bug bobo
- Faltou testar com outras pessoas
- Áudio ficou pra última hora

## O que aprendi
1. Fazer build intermediária a cada 12h
2. Testar controle em mais de um teclado
3. Algo específico do seu projeto

Esse texto é pra você. Daqui a três jams você vai reler e ver que parou de cometer os mesmos erros.

3. Networking

Entre nos Discords dos jams que você participa, fale com os devs cujos jogos você curtiu, e considere chamar alguém pra fazer dupla no próximo. Jam também é porta de entrada pra cena presencial: muita dessa turma se encontra ao vivo nos eventos de jogos no Brasil, e aparecer lá multiplica as conexões que começaram online. As melhores equipes que vi nasceram de "cara, gostei do seu jogo, bora juntar no próximo?".

Recursos que valem a pena

Assets gratuitos

Arte:

• Kenney.nl: pacotes enormes de sprites e modelos, de graça, licença liberada
• OpenGameArt.org
• Os freebies do próprio itch.io

Áudio:

• Freesound.org para efeitos
• Incompetech para música (faixas do Kevin MacLeod)
• jsfxr ou sfxr para gerar efeitos retrô no navegador

Fontes:

• Google Fonts
• Dafont.com (confira a licença antes de usar)

Ferramentas

Arte:

• Aseprite para pixel art (pago, mas barato e bom)
• Krita, gratuito e poderoso
• Piskel, pixel art direto no navegador

Level design:

• Tiled para mapas 2D
• LDtk, um editor de níveis mais moderno

Áudio:

• Audacity para edição
• BeepBox para música chiptune no navegador
• Reaper, DAW completa com trial generoso

Erros que eu já cometi (e você vai evitar)

1. Scope creep

O erro: ir adicionando feature o jam inteiro. A solução: depois da hora 6, zero feature nova. Só polimento. Toda ideia nova que aparecer, anota pra depois do jam e segue.

2. Não testar com outra pessoa

O erro: testar só você, que já sabe jogar. A solução: peça pra alguém jogar na hora 24 e de novo na hora 40. O que é claro pra você quase nunca é claro pra quem chega de fora.

3. Não fazer build intermediária

O erro: tentar gerar a primeira build na hora 46 e descobrir que ela nem abre. A solução: faça uma build de teste a cada 12 horas. Bug de exportação aparece cedo assim, com tempo de consertar.

Se você quiser deixar isso no automático, um script de shell resolve. Na Godot 4 o comando de exportação é --export-release:

#!/bin/bash
godot --headless --export-release "Windows Desktop" builds/windows/game.exe
godot --headless --export-release "Linux/X11" builds/linux/game.x86_64
godot --headless --export-release "Web" builds/web/index.html
echo "Builds prontas."

4. Ignorar o onboarding

O erro: achar que os controles são óbvios. Não são. A solução: faça a primeira fase ser um tutorial sem texto. Ensine pelo level design: o primeiro pulo é por cima de um buraco pequeno demais pra errar, o segundo é um pouco maior, e só então entra o primeiro inimigo, parado. O jogador aprende jogando, sem parar pra ler.

5. Música em loop curto demais

O erro: 10 segundos de música repetindo pra sempre. Vira tortura em cinco minutos. A solução: um loop de pelo menos 60 a 90 segundos, ou uma trilha ambiente mais sutil que não cansa.

Pra fechar

Game jam é o jeito mais rápido que eu conheço de crescer como dev. Cada um ensina mais sobre cortar escopo, priorizar e terminar do que meses de projeto solo, justamente porque o prazo não deixa você fugir das decisões difíceis.

No seu primeiro, não pense em ganhar. Pense em:

1. Terminar e submeter. Boa parte de quem começa um jam não entrega, e só por entregar você já saiu na frente.
2. Aprender três coisas novas.
3. Fazer algumas conexões com outros devs.
4. Se divertir, porque é pra isso que existe.

O primeiro jam vai ser um caos. O segundo, menos. Lá pelo quinto, terminar um jogo em 48 horas vira rotina. Engine é ferramenta. Base é tudo, e jam é onde você constrói essa base na marra.

Próximo passo: abra a página de jams do itch.io, escolha um com data que cabe na sua agenda, deixe o ambiente pronto e entra. A gente se vê na lista de submissões.