Portfólio de Desenvolvedor Unity: Projetos que Contam

Os unity portfolio projects que convencem um recrutador são poucos e específicos: um jogo pequeno terminado, um sistema bem feito que mostra profundidade (inventário, IA, multiplayer), código legível no GitHub e uma build jogável no navegador. Este guia mostra o que cada tipo de projeto prova, como deixar o repositório Unity apresentável e o que tirar do portfólio para ele não jogar contra você.

O post geral sobre portfólio de desenvolvedor de jogos cobre estrutura de site, apresentação visual e SEO para qualquer engine. Aqui o recorte é Unity: o que um avaliador técnico de vaga Unity abre e o que ele espera achar.

O que o recrutador de Unity abre primeiro

Pense em quem avalia: geralmente um programador sênior ou líder técnico, com outras vinte candidaturas na fila. A sequência costuma ser esta:

1. O link do jogo jogável. Se abre no navegador, ele joga um minuto. Se pede download, muita gente pula.
2. O vídeo ou GIF de 30 segundos, quando o jogo não roda no navegador.
3. O repositório no GitHub: estrutura de pastas, README e um ou dois scripts.

Ele não lê o projeto inteiro. Ele procura sinais: o jogo funciona do começo ao fim? O código tem nome claro, responsabilidade separada e nada de script de 2.000 linhas? A pessoa usa as APIs atuais do Unity 6 ou copiou tutorial antigo?

Seu portfólio precisa responder isso nos primeiros cinco minutos.

Portfolio Unity: 3 tipos de projeto que contam

Três projetos cobrem quase tudo que uma vaga júnior ou pleno de Unity pede:

Os três podem até ser o mesmo jogo, se ele for bem construído. Mas separar ajuda o avaliador a achar rápido o que procura.

Jogo pequeno e terminado

Terminado quer dizer: menu, jogo, fim (vitória ou derrota), recomeçar, som, build que abre em outro computador. Pequeno quer dizer: dá para jogar inteiro em cinco a dez minutos.

Um jogo de plataforma com três fases, um runner, um puzzle com vinte níveis, um shooter de arena com ondas. O gênero importa pouco. O que importa:

• Sensação de controle. Pulo com coyote time e buffer, câmera que acompanha bem (Cinemachine 3 com CinemachineCamera), feedback de impacto.
• Fluxo completo. Nada de "aperte F5 para recomeçar".
• Polimento mínimo. Transição entre cenas, áudio de interface, pausa.

Esse projeto prova a coisa mais rara num candidato júnior: que ele termina. Muitos portfólios têm cinco protótipos parados no meio.

Sistemas que mostram profundidade

O segundo projeto mostra que você sabe pensar em arquitetura. Bons candidatos:

• Inventário com itens definidos em ScriptableObjects, pilhas, slots, drag and drop na UI e salvamento.
• IA de inimigo com máquina de estados (patrulha, perseguição, ataque, fuga) e percepção por raycast ou área.
• Sistema de diálogo com escolhas, condições e dados separados do código.
• Multiplayer simples com Netcode for GameObjects: dois jogadores, sincronização de posição e de um estado de jogo.
• Salvamento e carregamento robusto, com versão do formato do save.

Mostre o sistema numa cena de demonstração clara e explique no README as decisões: por que ScriptableObject em vez de JSON, por que eventos em vez de referência direta.

Projeto ligado à área da vaga

O terceiro projeto muda conforme a vaga que você quer. Ele existe para responder a pergunta "essa pessoa já mexeu no que a gente faz aqui?". Alguns exemplos de recorte:

• Estúdio mobile: um jogo casual com build Android rodando liso num celular de entrada, toque bem resolvido, tela em várias proporções e tamanho de build controlado. Coloque no README o tamanho do APK e o FPS medido no aparelho.
• Estúdio de multiplayer: um protótipo de dois jogadores com Netcode for GameObjects, mostrando sincronização de movimento e de um placar. Grave um vídeo com as duas janelas lado a lado.
• Empresa de realidade aumentada ou virtual: uma cena com AR Foundation ou com o XR Interaction Toolkit, com interação simples (pegar, posicionar, apertar botão).
• Porte e performance: um antes e depois documentado com o Profiler, com captura de tela das duas medições e a explicação do que você mudou.

Esse projeto pode ser menor que os outros dois. O valor dele está em mostrar que você já passou pelos problemas típicos da área: o avaliador vê que você não vai começar do zero no primeiro mês. Se você ainda não sabe qual área quer, escolha mobile, que é onde a Unity mais aparece nas vagas e o que mais se aproveita em outras áreas.

Juntar um inventário, uma IA ou uma camada de rede dentro de um jogo inteiro, com UI, áudio, cenas e build, é onde a maioria trava sozinha: cada parte funciona isolada e o conjunto quebra. No curso de Unity os projetos são montados do começo até a build publicada, com o código organizado do jeito que você mostraria numa entrevista.

Código no GitHub: o que precisa estar legível

O avaliador abre o repositório e olha três coisas.

Estrutura de pastas. Algo como Assets/_Project/Scripts, Assets/_Project/Prefabs, Assets/_Project/Art, com assets de terceiros separados em Assets/ThirdParty. Sem Library, Temp ou Logs no repositório (isso já elimina candidato em alguns processos).

README. Em português e inglês, se você mira vaga fora. Contendo: GIF do jogo, link jogável, versão da Unity (6000.3.x), como abrir, controles e uma seção curta de "decisões técnicas" com os três ou quatro pontos que você quer que ele veja.

Os scripts principais. Nome de classe igual ao do arquivo, campos privados com [SerializeField], métodos curtos, eventos para desacoplar. Um exemplo do nível esperado, no arquivo Health.cs:

using System;
using UnityEngine;

public class Health : MonoBehaviour
{
    [SerializeField] private int maxHealth = 100;

    private int currentHealth;

    public event Action<int, int> HealthChanged;
    public event Action Died;

    public int CurrentHealth => currentHealth;
    public int MaxHealth => maxHealth;
    public bool IsDead => currentHealth <= 0;

    private void Awake()
    {
        currentHealth = maxHealth;
    }

    public void TakeDamage(int amount)
    {
        if (IsDead || amount <= 0)
        {
            return;
        }

        currentHealth = Mathf.Max(currentHealth - amount, 0);
        HealthChanged?.Invoke(currentHealth, maxHealth);

        if (IsDead)
        {
            Died?.Invoke();
        }
    }

    public void Heal(int amount)
    {
        if (IsDead || amount <= 0)
        {
            return;
        }

        currentHealth = Mathf.Min(currentHealth + amount, maxHealth);
        HealthChanged?.Invoke(currentHealth, maxHealth);
    }
}

O que esse arquivo comunica para quem avalia: o componente faz uma coisa só, não conhece a UI (a barra de vida assina HealthChanged), não conhece o Game Over (quem precisa assina Died), valida entrada e não expõe campo público. É pequeno e é exatamente o tipo de código que ele quer ver.

Outros sinais que contam: histórico de commits com mensagens claras (não 40 commits "update"), uso das APIs atuais (linearVelocity, FindFirstObjectByType, Input System com InputAction) e, se você souber, Assembly Definitions separando código de jogo e de Editor.

Build Web jogável no itch.io

A build Web é o maior atalho do portfólio: o avaliador clica e joga, sem baixar nada.

O itch.io hospeda jogos HTML5 de graça e, conforme a documentação para criadores conferida em 19/10/2026, entende os arquivos que a Unity gera: arquivos .br são servidos como Brotli e Gzip é detectado sozinho. Os limites do upload em ZIP são 500 MB extraídos, 200 MB por arquivo e 1.000 arquivos. Para um jogo de portfólio, sobra.

O GitHub Pages também hospeda, mas não deixa configurar o cabeçalho Content-Encoding. Nesse caso, em Edit > Project Settings > Player, aba Web, seção Publishing Settings, ligue Decompression Fallback (a doc da Unity avisa que o carregamento fica menos eficiente) ou desligue a compressão. ArtStation e sites de imagem não rodam build Web; use-os só para arte.

Cuidados com a build Web para portfólio:

• Teste em Chrome e Firefox, numa aba anônima.
• Mostre os controles na tela inicial.
• Se o jogo é mobile, ofereça também um APK ou um vídeo, porque toque e teclado são experiências diferentes.

O passo a passo de exportar e subir está no post de publicar build Web da Unity no itch.io.

O que tirar do portfólio

Tirar coisa é tão importante quanto colocar:

• Clones de tutorial sem nada seu. O avaliador reconhece o jogo do vídeo famoso.
• Protótipos quebrados ou abandonados. Um projeto que trava no segundo nível derruba a impressão do resto.
• Asset flip: jogo montado só com pacotes da Asset Store, sem código relevante seu.
• Projetos antigos que usam API que já mudou e você não atualizou.
• Repositório sem README, ou com o README padrão vazio.
• Projetos de engine que a vaga não usa, quando eles tomam o lugar de um projeto Unity melhor. Godot ou Unreal podem ficar numa seção "outros", não no topo.

Na dúvida, pergunte: se esse fosse o único projeto que ele abrisse, eu seria chamado? Se a resposta é não, ele sai ou desce.

Próximo passo

Escolha o seu projeto Unity mais perto de terminado e liste o que falta para ele ter menu, fim, recomeço e build. Termine isso antes de começar qualquer projeto novo. Depois arrume o README e publique a build no itch.io. Para encaixar o portfólio no resto da candidatura, leia o guia de currículo de desenvolvedor de jogos.