Checklist Completo para Lançar um Jogo na Steam: do Build ao Dia do Lançamento

Lançar um jogo na Steam não falha por falta de talento. Falha por detalhe esquecido: o build que sobe sem o executável certo, a página que entra em review na semana do lançamento, o botão verde que você descobre que não pode apertar porque faltou um requisito que existia há meses. Este checklist para lançar jogo cobre o caminho inteiro, na ordem em que as coisas precisam acontecer: conta e taxas, build no Steamworks, página da loja, processo de review, branches de teste e o dia do lançamento em si.

A regra de ouro que organiza tudo: na Steam, quase nada é instantâneo. Página passa por review. Build passa por review. A página precisa ficar pública um tempo mínimo antes do lançamento. Quem trata o lançamento como um evento de um dia se machuca. Quem trata como um processo de semanas lança tranquilo.

Antes de tudo: Steamworks e a taxa do Steam Direct

O ponto de partida é a conta de parceiro no Steamworks. O cadastro pede dados bancários e fiscais (a Steam paga em dólar, então você vai preencher formulários de imposto americano como o W-8BEN, mesmo sendo brasileiro). Esse processo de verificação leva dias, não horas. Faça com antecedência.

Depois vem a taxa do Steam Direct: USD 100 por jogo. Esse valor é recuperável: quando o jogo passa de USD 1.000 em receita bruta ajustada, a Valve devolve a taxa. Pagou, você recebe um App ID, que é a identidade do seu jogo dentro da plataforma. Tudo daqui pra frente (builds, página, estatísticas) gira em torno desse ID.

Checklist desta fase:

• Conta Steamworks criada e verificação fiscal/bancária concluída
• Taxa do Steam Direct paga e App ID recebido
• Nome do jogo definitivo (mudar depois é possível, mas confunde wishlist e busca)

O build: depots, SteamPipe e upload

O sistema de distribuição da Steam se chama SteamPipe. Os conceitos que você precisa dominar são três:

• App: o jogo em si, identificado pelo App ID.
• Depot: um pacote de arquivos. O caso comum é um depot por plataforma (Windows, Linux, macOS).
• Build: uma versão enviada dos depots. Cada upload gera um build novo, e você escolhe qual build fica ativo em cada branch.

Exportando o jogo

Antes de subir qualquer coisa, gere o build final em modo release, não debug. No Godot 4 dá pra automatizar isso por linha de comando, o que evita o erro clássico de exportar com a configuração errada na pressa:

godot --headless --export-release "Windows Desktop" build/windows/meujogo.exe

Isso usa o preset "Windows Desktop" definido no export_presets.cfg do projeto. Rode o executável exportado numa máquina que não é a sua de desenvolvimento. Builds que só foram testados na máquina do dev têm o costume de quebrar por dependência que só existe lá.

Subindo com o steamcmd

O upload oficial é feito com o steamcmd e um script de build em formato VDF. Um exemplo mínimo, com um app e um depot:

"AppBuild"
{
    "AppID" "1234560"
    "Desc" "Versao 1.0.0 - build de lancamento"
    "ContentRoot" "..\build\windows\"
    "BuildOutput" "..\steam_output\"
    "Depots"
    {
        "1234561"
        {
            "FileMapping"
            {
                "LocalPath" "*"
                "DepotPath" "."
                "Recursive" "1"
            }
        }
    }
}

E o comando que executa o upload:

steamcmd +login SEU_USUARIO +run_app_build ../scripts/app_build_1234560.vdf +quit

O build aparece no painel do Steamworks em "SteamPipe > Builds", e ali você decide em qual branch ele entra. Que nos leva ao ponto que mais gente ignora.

Branches: teste como jogador antes de lançar

O Steamworks permite múltiplas branches do seu jogo. A default é a que o público recebe. As outras você cria à vontade, com nome e senha, e elas são a sua rede de segurança:

• default: o que está no ar. Antes do lançamento, fica vazia ou com o build final travado.
• beta: protegida por senha, para testers externos baixarem pelo próprio cliente Steam.
• staging (ou o nome que preferir): onde você valida o build candidato exatamente como o jogador vai receber.

O fluxo saudável: todo build novo entra primeiro numa branch de teste. Você instala pelo cliente Steam de verdade, numa máquina limpa se possível, e verifica o que só aparece nesse contexto: o jogo abre direto da biblioteca? O overlay da Steam funciona? Conquistas disparam? Cloud save sincroniza? O tamanho do download está razoável?

Só depois disso o build é promovido pra default. Promover build de branch é um clique no painel, então não existe desculpa de "não deu tempo de testar na Steam".

Checklist do build:

• Build exportado em release e testado fora da máquina de desenvolvimento
• Upload via SteamPipe funcionando e repetível (script salvo no repositório)
• Branch de teste com senha criada e build instalado pelo cliente Steam
• Overlay, conquistas e cloud save verificados no build real
• Build final promovido pra default e marcado como o de lançamento

A página da loja: sua vitrine passa por review

A página da loja vende o jogo antes de qualquer review da imprensa. E ela tem requisitos formais que a Valve confere manualmente:

• Cápsulas (as imagens da loja) em todos os tamanhos exigidos, sem texto ilegível
• Pelo menos 5 screenshots reais do gameplay
• Trailer (não é tecnicamente obrigatório, mas página sem trailer converte visivelmente pior)
• Descrição curta e longa, marcação de gênero e tags
• Questionário de conteúdo preenchido (violência, conteúdo adulto, etc.)

Dois prazos mandam no seu cronograma:

1. A página precisa ser aprovada pela equipe da Valve. O review da página costuma levar alguns dias úteis. Se vier reprovada (cápsula fora do padrão, screenshot com mockup em vez de gameplay, classificação de conteúdo inconsistente), você corrige e entra na fila de novo.
2. A página precisa ficar pública como "Coming Soon" por no mínimo 2 semanas antes do lançamento. Esse é um requisito da Steam, não uma sugestão. Na prática, você quer muito mais que isso: a página no ar é o que acumula wishlists, e wishlist é o ativo de marketing mais importante de um lançamento indie, porque a Steam notifica por e-mail quem adicionou o jogo quando ele lança.

Minha recomendação honesta: publique a página "Coming Soon" meses antes, não semanas. Cada dia de página no ar é dia de wishlist acumulando, e o algoritmo da Steam dá mais visibilidade no lançamento pra jogos que chegam com tração.

Checklist da página:

• Cápsulas em todos os formatos, legíveis em tamanho pequeno
• Mínimo de 5 screenshots de gameplay real
• Trailer de até 60-90 segundos que mostra o jogo nos primeiros 5 segundos
• Descrição com o gancho na primeira frase (o "acima da dobra" importa)
• Tags escolhidas comparando com jogos parecidos que vendem bem
• Questionário de conteúdo preenchido com honestidade
• Página submetida a review com folga e aprovada
• Página "Coming Soon" pública há pelo menos 2 semanas (idealmente meses)

O review do build e a janela de lançamento

Além da página, o build de lançamento também passa por review. A Valve roda o jogo pra conferir que ele instala, abre e corresponde ao que a página promete. Esse review também leva dias úteis, e só depois dele o botão de lançamento fica disponível.

A consequência prática: o build de lançamento precisa estar pronto e submetido com pelo menos uma ou duas semanas de folga. Quem termina o jogo na véspera não lança na data, simples assim.

Sobre a data em si, alguns cuidados que custam pouco e rendem muito:

• Evite colidir com lançamentos gigantes do seu gênero. Você não controla tudo, mas dá pra checar o calendário.
• Olhe os festivais da Steam (Next Fest e os sazonais). Participar do Next Fest com demo antes do lançamento é dos melhores geradores de wishlist que existem pra indie.
• Lance em dia útil, de manhã no horário dos EUA. A maior parte da imprensa, dos curadores e do tráfego da loja opera nesse fuso.
• Desconto de lançamento é configurado antes, no painel. A faixa de 10-15% é comum em indie e ativa o selo verde de promoção na loja.

Checklist para lançar o jogo: o dia D

Se você seguiu tudo acima, o dia do lançamento é apertar um botão e trabalhar a comunicação. O botão de "Release App" no Steamworks é manual: nada lança sozinho na data marcada, você precisa estar lá pra apertar.

A sequência que eu sigo:

1. Confirme o build na branch default uma última vez, e jogue os primeiros 10 minutos dele.
2. Aperte o botão de lançamento. A propagação pra loja não é instantânea; pode levar um tempo até a página virar "Comprar" em todas as regiões.
3. Verifique a compra real. Compre o próprio jogo numa conta secundária ou peça pra alguém. Instala? Abre? O preço regional está certo?
4. Dispare a comunicação: post nas redes, e-mail pra lista se tiver, mensagem nas comunidades onde você construiu presença, press kit pra imprensa e curadores. Tudo isso escrito e agendado antes, no dia você só publica.
5. Fique online nas primeiras horas. Os primeiros bug reports chegam rápido, e responder rápido nos fóruns da comunidade e nas primeiras reviews negativas muda a percepção do jogo. Crash de primeira hora com hotfix no mesmo dia vira história boa; crash ignorado por três dias vira review bomba.
6. Tenha o pipeline de hotfix pronto. É aqui que o script de upload salvo no repositório paga o investimento: bug crítico encontrado, fix feito, build sobe pra branch de teste, valida, promove pra default. Se esse caminho já está ensaiado, um hotfix sai em horas.

Conclusão

Lançar na Steam é menos sobre o dia do lançamento e mais sobre as semanas anteriores. Os prazos invisíveis (review de página, review de build, 2 semanas mínimas de Coming Soon) são o que derruba data de lançamento, então comece por eles e trabalhe de trás pra frente no calendário.

E uma verdade que ninguém gosta de ouvir mas todo indie precisa: o lançamento não termina no dia D. As duas primeiras semanas de respostas, hotfixes e atualização de página fazem parte do lançamento. Planeje energia pra elas também. Boa sorte com o botão verde.