Como subir o build do jogo na Steam (SteamPipe)

Você terminou o jogo, pagou a taxa do Steam Direct, montou a página na loja e agora precisa colocar o arquivo pra dentro da Steam. É aqui que muita gente trava. Saber como subir o build do jogo na Steam não é difícil, mas é um processo cheio de termos novos (app, depot, build, branch) que assustam na primeira vez. O sistema por trás disso se chama SteamPipe, e neste guia eu vou destrinchar cada peça dele.

Se você ainda não passou pelas etapas anteriores de cadastro e página, vale ler antes o guia de como publicar um jogo na Steam e voltar pra cá quando chegar na parte de subir o executável.

O que é o SteamPipe

SteamPipe é o sistema de distribuição de conteúdo da Steam. É ele que pega os arquivos do seu jogo, empacota, sobe pros servidores da Valve e entrega pros jogadores de forma incremental (só o que mudou de uma versão pra outra). Entender três conceitos resolve 90% da confusão.

App

O app é o seu jogo visto de cima. Ele tem um identificador numérico, o AppID, que a Valve te dá quando você cria o produto no Steamworks. Tudo gira em torno desse número: a página da loja, as conquistas, os depots e os builds pertencem a um AppID.

Depot

O depot é um pacote de arquivos dentro do seu app. Cada depot tem o seu próprio número, o DepotID. Um jogo simples de Windows pode ter um único depot com o executável e os assets. Jogos maiores separam em vários: um depot pro conteúdo comum, um pros binários de Windows, um pros de Linux, um pra um idioma específico. Você decide a divisão de acordo com o que faz sentido entregar junto ou separado.

Build

O build é uma versão específica do conteúdo que você sobe. Cada vez que você envia arquivos pelo SteamPipe, a Valve guarda aquilo como um build novo e dá a ele um BuildID. O ponto que confunde: subir um build não publica nada. O build fica guardado, numerado, esperando. Quem decide se e quando os jogadores recebem aquele build é a etapa de apontar o build pra uma branch e dar set live.

As duas formas de subir o build

A Steam oferece dois caminhos pra fazer o upload. Os dois usam o SteamPipe por baixo, então o resultado é o mesmo. A diferença é conforto contra controle.

SteamPipe GUI (o jeito mais simples)

O Steamworks SDK vem com uma ferramenta visual, o SteamPipe GUI. Você abre o programa, aponta a pasta com os arquivos do jogo, informa o AppID e o DepotID, e clica pra fazer o build e o upload. Ele monta os scripts de configuração por baixo dos panos pra você. É o caminho que eu recomendo pro seu primeiro envio, porque você vê o processo acontecendo sem precisar acertar sintaxe de arquivo nenhum.

steamcmd via linha de comando (o jeito controlável)

O outro caminho é o steamcmd, a versão de terminal do cliente Steam, rodando scripts de configuração no formato .vdf. Dá mais trabalho pra montar da primeira vez, mas depois vira uma linha só de comando que você repete a cada atualização. É o caminho natural pra quem quer automatizar o deploy, encaixar num pipeline de build ou simplesmente não depender de clicar em janela. O resto do guia foca nesse caminho, porque entender o .vdf te ensina o que o GUI faz escondido.

Fazer o jogo já foi a parte difícil. Chegar no fim, com o jogo rodando liso, e empacar numa tela de AppID, DepotID e arquivo .vdf que não bate é frustrante de um jeito específico: parece que a loja inteira está entre você e o botão de publicar. Dá pra atravessar essa parte técnica com método, um passo de cada vez, sem achar que você é a única pessoa que travou aqui.

Configurando o conteúdo e os scripts .vdf

No caminho do steamcmd, você descreve o upload em dois arquivos .vdf. Um é o script do app (o build geral), o outro é o script do depot (o que vai dentro de cada pacote). A estrutura padrão do Steamworks SDK organiza as pastas assim: uma pasta content com os arquivos do jogo, uma pasta output pros logs e caches, e uma pasta scripts com os .vdf.

O script do app aponta quais depots fazem parte do build e para onde cada depot é descrito. Um exemplo real e enxuto, para um app de AppID 1000 com um depot 1001:

"appbuild"
{
    "appid" "1000"
    "desc"  "Patch 1.0.3 - correcao de crash no menu"
    "buildoutput"   "..\output\"
    "contentroot"   "..\content\"
    "setlive"   ""
    "preview"   "0"

    "depots"
    {
        "1001"  "depot_build_1001.vdf"
    }
}

Vale entender cada campo:

• appid: o AppID do seu jogo.
• desc: uma descrição livre do build, só pra você se achar depois na lista. Coloque algo que diga o que mudou.
• contentroot: a pasta raiz de onde os arquivos vão sair.
• buildoutput: onde o SteamPipe guarda logs e os caches de upload (acelera os envios seguintes).
• setlive: o nome da branch de beta que recebe esse build automaticamente ao fim do upload. Deixe vazio para só guardar o build e decidir depois.
• preview: em 1, o SteamPipe simula o upload sem enviar nada, e escreve um relatório do que faria. Ótimo pra conferir a configuração antes de valer.

O script do depot descreve o que entra naquele pacote. O mesmo depot 1001:

"DepotBuildConfig"
{
    "DepotID"   "1001"
    "ContentRoot"   "..\content\"

    "FileMapping"
    {
        "LocalPath" "*"
        "DepotPath" "."
        "Recursive" "1"
    }

    "FileExclusion" "*.pdb"
}

Aqui o FileMapping com LocalPath em * e Recursive em 1 manda pegar tudo que está em ContentRoot, inclusive subpastas, e colocar na raiz do depot. O FileExclusion tira arquivos que você não quer no jogo final, como os .pdb de debug. Se você exporta o jogo com a Godot, por exemplo, o ContentRoot aponta pra pasta onde ficam o executável e o .pck depois de exportar o jogo da Godot para Windows.

Como subir o build do jogo na Steam com o steamcmd

Com os dois .vdf prontos, o upload é uma linha. Você chama o steamcmd, faz login na conta de parceiro, roda o script do app e sai:

steamcmd +login usuario_parceiro +run_app_build ..\scripts\app_build_1000.vdf +quit

Na primeira vez, o steamcmd vai pedir a senha e o Steam Guard (o código do seu autenticador ou e-mail). Depois disso ele guarda a sessão e os envios seguintes não pedem de novo na mesma máquina. Enquanto roda, você vê o progresso de empacotamento e de upload no terminal. Quando terminar sem erro, o build está nos servidores da Valve, com um BuildID novo. Repito o ponto importante: nesse momento nenhum jogador recebeu nada ainda.

Antes de valer a pena mandar de verdade, rode com "preview" "1" no script do app. O SteamPipe gera um relatório na pasta de output mostrando exatamente quais arquivos entrariam, o tamanho e o que seria excluído. É a forma mais barata de pegar um caminho errado ou um arquivo de sobra antes de gastar banda.

Branches: default, beta e o set live

Branch é o canal pelo qual um jogador recebe uma versão do jogo. A branch default (a pública) é o que todo mundo baixa por padrão. As branches de beta são canais extras que você cria no Steamworks, podem ser abertas ou protegidas por senha, e servem pra entregar uma versão só pra quem você quer.

O set live é o ato de dizer "essa branch, a partir de agora, serve esse build". No painel do Steamworks, em SteamPipe > Builds, você vê a lista de todos os builds que subiu, cada um com seu BuildID. Você escolhe o build, escolhe a branch de destino e confirma. Só nesse clique a atualização sai pros jogadores daquela branch.

Um detalhe de segurança que vale gravar: você não consegue dar set live na branch default pelo campo setlive do script .vdf. O script só aceita apontar pra branches de beta. Liberar algo pra base inteira de jogadores é sempre uma ação manual e consciente no painel. Isso existe justamente pra ninguém publicar um build quebrado pra todo mundo por causa de uma linha errada no script.

Boas práticas que evitam dor de cabeça

Teste numa beta antes de ir pro default. Crie uma branch de beta, dê set live do build nela, e baixe o jogo pela própria Steam usando o código da beta (botão direito no jogo, Propriedades, Betas). Jogue de ponta a ponta na versão que o jogador vai receber, não na sua pasta de desenvolvimento. É comum um arquivo que existe na sua máquina não ter entrado no depot, e a beta pega isso na hora.

Mantenha os AppID e DepotID conferidos. Subir conteúdo pro depot errado é um erro clássico de quem tem mais de um produto. O número no .vdf precisa bater com o que está no Steamworks.

Use descrições de build que digam algo. Daqui a três meses, "build novo" não te ajuda a achar qual versão corrigiu qual bug. "Patch 1.0.3 - correcao de crash no menu" sim.

Guarde a pasta de output entre os uploads. O SteamPipe usa o cache dela pra mandar só o que mudou. Apagar a pasta não quebra nada, mas faz o próximo envio ser inteiro de novo.

Se o seu jogo é feito na Godot e você vai integrar conquistas ou nuvem, deixe a parte do SDK resolvida antes de montar o depot, seguindo o passo a passo de integrar a Steam na Godot com o GodotSteam. Assim o build que você sobe já é o que o jogador vai usar de verdade, com a integração dentro.

Entendido o SteamPipe, o resto das atualizações do seu jogo vira rotina: você edita os arquivos, roda uma linha de steamcmd, testa na beta e dá set live no default. O que parecia um labirinto de termos vira três passos que você repete a cada patch.