Como Criar um Portfólio de Desenvolvedor de Jogos que Impressiona

Quem avalia portfólio de game dev (recrutador de estúdio, cliente de freela, parceiro) bate o olho e decide rápido se vale continuar. Não é injusto, é volume: chegam dezenas de links parecidos. O que faz o seu não ser ignorado raramente é talento bruto. É clareza. Um portfólio que mostra exatamente o que você sabe fazer, com prova de que terminou alguma coisa, ganha de dez portfólios cheios de projeto pela metade.

Esse guia é sobre montar isso. Sem fórmula mágica, sem template que resolve sua vida. O trabalho de fazer um jogo bom continua sendo seu. O que dá pra fazer aqui é parar de sabotar o seu próprio trabalho com uma apresentação ruim.

O que quem contrata olha de verdade

Vou ser direto sobre como funciona a avaliação, porque entender isso muda o que você prioriza.

Os primeiros segundos são visuais. A pessoa abre o link e decide se a página parece a de alguém que sabe o que está fazendo. Depois ela procura uma coisa só: você já terminou e publicou algum jogo? Jogo finalizado, mesmo que pequeno, vale mais do que dez protótipos bonitos. Terminar é a habilidade mais rara no game dev, e todo mundo do outro lado da mesa sabe disso.

Em seguida vem a parte técnica: código que dá pra ler, decisões de arquitetura que fazem sentido, problema difícil que você resolveu de um jeito que dá pra explicar. E por último o encaixe com a vaga ou o projeto: um estúdio de mobile não está procurando seu protótipo de simulador de física, por mais legal que ele seja.

A ordem importa. Se você só tem tempo pra arrumar uma coisa no portfólio, arrume o projeto mais bem acabado e coloque ele primeiro.

Os erros que fazem fechar a aba na hora

Algumas coisas derrubam o portfólio antes de qualquer mérito ser avaliado:

• Só projeto inacabado, com "em breve" em tudo
• Link quebrado, build que não roda, jogo que dá erro ao abrir
• Asset comprado ou pego de pacote gratuito apresentado como se fosse seu
• Página que demora pra carregar ou trava no celular
• Cinquenta projetos medianos em vez de três bons

O denominador comum é o mesmo: a pessoa não consegue ver rápido o que você faz bem. Se ela precisa caçar, ela desiste.

Quem está do outro lado muda o que você mostra

Vale pensar em quem você quer atingir, porque o mesmo portfólio fala diferente pra cada um:

• Estúdio AAA quer especialização profunda e jogos publicados. Mostre que você é fundo em alguma coisa.
• Estúdio indie valoriza versatilidade e gente que termina projeto sozinho. Mostre que você dá conta do ciclo todo.
• Cliente de freela quer confiabilidade e comunicação clara. Mostre entrega no prazo e papo reto.

Você não precisa de três portfólios. Precisa de um que deixe claro o seu eixo principal sem esconder que você sabe se virar no resto.

Estrutura de um portfólio que funciona

A página inicial: deixe óbvio quem você é

A primeira tela tem que responder três perguntas em poucos segundos: quem é você, o que você faz, e por onde começar a olhar. Nome, uma linha dizendo sua especialidade (algo como "programador de gameplay, foco em Godot e C#") e um botão claro pra ir aos projetos. Se você tem um vídeo curto mostrando seus melhores momentos de jogo, coloque rodando logo de cara.

Não invente número que você não tem. Se você publicou dois jogos, escreva dois. "Mais de 2 milhões de downloads" numa página de quem está começando não engana ninguém e queima sua credibilidade quando a pessoa clica e vê a realidade. Prova social honesta vale mais que estatística inflada.

Projetos: três bons batem dez medianos

Para cada projeto que você decidir mostrar, a estrutura que funciona é mais ou menos essa:

• Topo: título, plataformas, uma frase do que é o jogo, e um botão pra jogar ou baixar bem visível.
• Ficha rápida: tempo de desenvolvimento, tamanho do time, qual foi o seu papel, e as tecnologias usadas.
• A história: qual era o desafio, como você atacou, e o que saiu disso. Dois ou três parágrafos, não uma dissertação.
• A parte técnica: os sistemas que você implementou, com trechos de código de verdade e, se ajudar, um diagrama de como as peças conversam.
• Mídia: GIFs de gameplay leves, screenshots de qualidade, e se possível um link jogável.
• O que você aprendeu: o que funcionou, o que você faria diferente. Essa parte humaniza e mostra maturidade.

A seção de "o que eu faria diferente" parece contraintuitiva mas é uma das mais fortes. Quem já lançou jogo sabe que ele sempre tem defeito. Admitir um defeito e explicar como você resolveria mostra que você entende o ofício de verdade, não só decorou tutorial.

Como mostrar código

Aqui mora um erro comum: colar um arquivo inteiro de 300 linhas pra "provar" que você programa. Ninguém lê. O que funciona é escolher um trecho pequeno que mostra uma decisão técnica boa e explicar o porquê dela.

Veja um exemplo em GDScript: um sistema de combo que guarda os últimos comandos numa fila e descarta os que ficaram velhos demais. É o tipo de coisa simples que mostra que você pensa em janela de tempo e em limpeza de estado, não só em fazer o personagem bater.

extends Node

# Quanto tempo (em segundos) um comando fica valido na fila
@export var buffer_time: float = 0.3

# Sequencias reconhecidas: lista de comandos -> nome do combo
var combos := {
    ["soco", "soco", "chute"]: "rajada",
    ["baixo", "frente", "soco"]: "especial",
}

var _buffer: Array = []  # cada item: { "comando": String, "tempo": float }

func registrar_comando(comando: String) -> void:
    var agora := Time.get_ticks_msec() / 1000.0
    _buffer.append({ "comando": comando, "tempo": agora })
    _limpar_antigos(agora)
    _checar_combo()

func _limpar_antigos(agora: float) -> void:
    # Remove comandos que estouraram a janela de tempo
    while _buffer.size() > 0 and agora - _buffer[0].tempo > buffer_time:
        _buffer.pop_front()

func _checar_combo() -> void:
    var sequencia := _buffer.map(func(item): return item.comando)
    for padrao in combos:
        if _termina_com(sequencia, padrao):
            executar_combo(combos[padrao])
            _buffer.clear()
            return

func _termina_com(sequencia: Array, padrao: Array) -> bool:
    if sequencia.size() < padrao.size():
        return false
    var inicio := sequencia.size() - padrao.size()
    return sequencia.slice(inicio) == padrao

func executar_combo(nome: String) -> void:
    print("Combo executado: ", nome)

Não precisa ser sofisticado. Precisa ser correto, ler bem, e vir acompanhado de duas linhas explicando a ideia. Um trecho curto e claro vale mais que um sistema inteiro despejado sem contexto.

Se um sistema seu tem várias peças conversando (input, lógica, animação, áudio), um diagrama simples ajuda quem lê a entender a arquitetura num relance. Você pode desenhar com Mermaid direto no markdown:

graph TD
    A[Input] --> B[Sistema de Combo]
    B --> C[Animacao]
    B --> D[Dano]
    B --> E[Efeitos e Som]

Sobre você e suas skills

A seção "sobre" não precisa de manifesto. Uma apresentação curta, honesta, com um pouco de personalidade funciona melhor que parágrafo motivacional. Diga há quanto tempo você mexe com isso, o que te interessa no game dev, e o que você procura agora. Se você é bom em escrever código que designer e artista conseguem mexer sem te chamar toda hora, diga isso, porque é exatamente o que time procura.

Na lista de skills, seja honesto sobre nível. "C# em projeto real há 3 anos" diz mais que uma barrinha colorida em 95%. Barra de proficiência inventada é fácil de fabricar e todo mundo sabe disso. Tempo de uso real e onde você usou são informações que a pessoa consegue checar e confiar.

Tipos de projeto que valem a pena mostrar

O jogo completo

Um jogo terminado e publicado é o ativo mais forte do seu portfólio. Não importa se vendeu pouco. Importa que você levou do começo ao fim. Coloque o link pra jogar ou baixar, um trailer curto se tiver, e um post-mortem honesto: o que deu certo, o que deu errado, o que você aprendeu lançando.

Se o jogo tem números bons (downloads, avaliações), mostre os números reais. Se os números são modestos, não esconda atrás de vaguidão. "Lançado na itch.io, 800 downloads no primeiro mês" é uma frase honesta que mostra que você de fato colocou algo no mundo. Quem contrata respeita isso mais do que promessa.

O projeto técnico

Para vaga mais técnica, vale ter um projeto que mostra profundidade num assunto: um sistema de física customizado, uma otimização que ganhou performance, um problema de arquitetura que você resolveu. O segredo aqui é mostrar o antes e o depois e explicar a decisão.

Se você fez uma otimização, mostre o número de verdade que você mediu no seu profiler: quadros por segundo antes e depois, uso de memória, o que for. Não invente "60% mais rápido" se você não cronometrou. Um número honesto e pequeno é prova. Um número redondo e grande sem medição é suspeito.

O projeto de game jam

Game jam mostra que você consegue escopar e entregar sob pressão, que é uma habilidade real e valorizada. Não precisa ter ganhado nada. O valor está em mostrar um projeto fechado em 48 ou 72 horas, com uma ideia clara executada até o fim. Se você participou de uma jam conhecida, linke a página da sua submissão, que normalmente já tem rating e comentários públicos. Isso é prova social que você não fabricou.

Apresentação visual

Screenshots e GIFs

A diferença entre um portfólio que parece amador e um que parece profissional muitas vezes está nas imagens. Capture momentos de ação, não tela parada vazia. Tire o HUD de debug, esconda o console, não deixe arte de placeholder aparecer. Mantenha proporção e qualidade consistentes entre as imagens.

Para os GIFs de gameplay, o problema clássico é peso. Um GIF pesado trava a página. Você consegue gerar GIFs leves a partir de um vídeo com FFmpeg, controlando taxa de quadros e largura:

ffmpeg -i gameplay.mp4 -vf "fps=15,scale=640:-1:flags=lanczos" output.gif

A linha fps=15 segura o número de quadros e scale=640:-1 redimensiona pra 640px de largura mantendo a proporção. Se quiser mais qualidade com menos peso, a ferramenta gifski costuma render melhor que o FFmpeg pra esse caso. Em muitos sites, na real, vale converter o gameplay pra um vídeo .mp4 ou .webm em vez de GIF, porque pesa bem menos e a maioria dos navegadores toca em loop sem problema.

Performance da página

Uma página de portfólio que demora a carregar perde visitante antes de mostrar qualquer coisa. As coisas que mais ajudam: imagens em formato moderno como WebP, vídeo comprimido, e carregar mídia só quando ela entra na tela em vez de tudo de uma vez.

Esse último ponto, o lazy loading, hoje em dia você consegue na maioria dos casos sem JavaScript nenhum. O atributo nativo resolve para imagens:

<img src="screenshot.webp" loading="lazy" alt="Gameplay do jogo" />

Para vídeo, o equivalente é não dar autoplay no que está fora da tela e usar preload="none" para o navegador só buscar o arquivo quando precisar. Você só precisa de uma solução customizada com IntersectionObserver se quiser controle fino sobre quando cada mídia começa a tocar. Pra um portfólio, o atributo nativo costuma bastar.

Onde hospedar o portfólio

Você tem duas escolhas grandes: site próprio ou plataforma pronta. Cada uma tem seu encaixe.

Site próprio te dá controle total, domínio próprio e cara profissional. O custo é manutenção e setup técnico. Faz sentido se você quer programar a coisa e tratar o próprio portfólio como mais um projeto de showcase, o que para programador é coerente.

itch.io é o lugar natural pra quem tem jogo jogável. A distribuição já vem embutida, tem comunidade, e a pessoa joga seu jogo ali mesmo sem instalar nada. Se você ainda não tem nada lá, vale seguir o passo a passo de como publicar um jogo na itch.io antes de linkar no portfólio. A contrapartida é que a aparência é mais de catálogo que de portfólio pessoal.

GitHub Pages é gratuito, versionado, e dá credibilidade técnica porque mostra seu código junto. É ótimo pra programador. Exige saber o básico de web pra montar.

Uma combinação que funciona bem: site próprio ou GitHub Pages como porta de entrada, com os jogos jogáveis hospedados na itch.io e linkados de lá. Você fica com o melhor dos dois.

Se for de site próprio e você não quer reinventar a roda, geradores de site estático como Astro, Next.js ou mesmo o Nuxt (que roda esse blog) resolvem bem, e deploy gratuito em Vercel, Netlify ou Cloudflare Pages fecha a conta sem dor.

SEO e ser encontrado

Se você quer que o portfólio apareça quando alguém busca seu nome, o básico de SEO ajuda. Um título de página descritivo, uma meta description que diz o que você faz, e as tags de Open Graph pra quando o link for compartilhado em rede social. Esse é o trio que dá mais retorno pelo esforço:

<title>Seu Nome - Programador de Jogos | Godot e C#</title>
<meta name="description" content="Programador de gameplay com foco em Godot e C#. Veja meus jogos publicados e código no GitHub." />
<meta property="og:title" content="Seu Nome - Programador de Jogos" />
<meta property="og:description" content="Jogos publicados, código aberto e projetos de game jam." />
<meta property="og:image" content="https://seusite.dev/og-image.jpg" />

A imagem de Open Graph é a que aparece quando você manda o link no Discord, no LinkedIn ou no Twitter. Vale fazer uma boa, porque é o primeiro contato visual de muita gente com o seu trabalho.

Além disso, o que mais traz visita pra portfólio de game dev é estar presente onde a comunidade está: postar devlog, participar de game jam com o link na bio, responder dúvida técnica em fórum e comunidade. Não é truque de SEO, é só estar visível no lugar certo. E o portfólio anda de mãos dadas com o currículo de desenvolvedor de jogos: um aponta pro outro quando você se candidata às vagas de desenvolvimento de jogos no Brasil e lá fora.

Erros comuns

Junto os que mais aparecem, porque evitar esses já te coloca à frente de boa parte.

Síndrome do "em breve". Página cheia de "mais projetos em breve", "versão 2 chegando", "seção em construção". Isso comunica que nada está pronto. Publique o que está pronto agora e melhore depois. Portfólio é sempre trabalho em andamento, mas o visitante não pode sentir isso.

Excesso. Cinquenta projetos medianos cansam e não convencem. Três projetos bons contam uma história clara. Curadoria é parte do trabalho. Tirar coisa fraca do portfólio é tão importante quanto adicionar coisa boa.

Falta de clareza no seu papel. Em projeto de grupo, deixe explícito o que foi você que fez. "Trabalhei nesse jogo" não diz nada. "Fiz toda a programação de gameplay e o sistema de save" diz. Sem isso, quem avalia assume o pior.

Projeto de tutorial apresentado como autoral. Quem é da área reconhece o jogo do tutorial famoso na hora. Tutorial serve pra aprender, não pra portfólio. Mostre trabalho original, mesmo que mais simples.

Mantendo o portfólio vivo

Portfólio não é coisa que você faz uma vez. Mas também não precisa virar segundo emprego. Um ritmo realista: de vez em quando, conferir se os links ainda funcionam e responder mensagens; quando terminar um projeto novo que valha, adicionar e tirar o mais fraco que estiver lá; e de tempos em tempos olhar com olho crítico se a página ainda representa onde você está hoje.

A regra simples: seu portfólio deve sempre mostrar a sua melhor versão atual, não um histórico de tudo que você já tocou. Quando um projeto velho ficar abaixo do seu nível de hoje, tire ele. Crescer no portfólio às vezes é remover.

Trate o portfólio como você trata um jogo

A melhor mentalidade pra montar portfólio é a mesma de fazer jogo: iterar, pedir feedback de gente real, e polir. Mostre pra alguém da área e veja onde a pessoa trava ou perde interesse. Esse é o seu playtest.

Não existe portfólio perfeito, existe portfólio publicado que você melhora com o tempo. Se você está esperando ter projeto suficiente pra "finalmente" montar, está esperando demais. Escolha seus dois ou três melhores trabalhos, escreva sobre eles com honestidade, mostre o código e os números reais, e publique. Depois melhora.

O primeiro passo é colocar no ar. O resto é iteração.