Estrutura de Pastas na Unity: Organizar o Projeto

A estrutura de pastas na Unity define se você acha um arquivo em cinco segundos ou em cinco minutos, e se o projeto aguenta seis meses sem virar uma gaveta de bagunça. A resposta curta para "qual unity folder structure usar" é: crie uma pasta raiz sua dentro de Assets, escolha organizar por tipo ou por feature, respeite as pastas com nome especial da Unity e versione só o que precisa. Este post traz uma estrutura pronta para jogo indie, explica cada pasta especial e fecha com o .gitignore certo.

As regras de pastas especiais seguem o manual do Unity 6.3 LTS, conferido em outubro de 2026.

Por que organizar o projeto Unity desde o início

Projeto Unity começa limpo: uma cena de exemplo, uma pasta Settings e pouco mais. Em duas semanas aparecem trinta scripts soltos em Assets, sprites misturados com materiais, três pacotes da Asset Store cada um com sua própria pasta na raiz e uma cena chamada SampleScene 2. Ninguém planejou a bagunça; ela acontece porque a pasta padrão para tudo é a raiz.

Organizar cedo custa quinze minutos. Organizar com o projeto grande custa uma tarde, e corre o risco de quebrar referências se alguém mover arquivos fora da Unity. Os ganhos práticos:

• Você acha qualquer asset pela estrutura, sem depender da busca.
• Pacotes de terceiros ficam separados do seu código, e atualizar um pacote não mistura arquivos com os seus.
• Separar o código em pastas facilita criar Assembly Definitions depois, o que reduz o tempo de compilação.
• Outra pessoa (ou você daqui a três meses) entende o projeto lendo os nomes das pastas.

Se você já trabalhou no Godot, a lógica é parecida com a do post sobre organizar projeto Godot e estrutura de pastas; muda o conjunto de pastas com regra especial.

Por tipo ou por feature: as duas escolas

Por tipo agrupa pelo formato do arquivo: Scripts, Sprites, Audio, Prefabs, Scenes, Materials. É a estrutura que quase todo tutorial usa, e funciona muito bem em jogo pequeno: tudo que é som está em Audio, ponto.

O problema aparece quando o jogo cresce. Para mexer no inimigo Slime você abre Scripts/Enemies/Slime.cs, Sprites/Enemies/Slime.png, Prefabs/Enemies/Slime.prefab, Animations/Enemies/Slime.anim e Audio/SFX/Enemies/slime_hit.wav: cinco pastas para uma feature.

Por feature agrupa pelo que a coisa é no jogo: Player, Enemies/Slime, UI, Inventory, Audio. Dentro de Enemies/Slime ficam o script, o sprite, o prefab, a animação e o som do Slime. Apagar ou duplicar uma feature é mexer numa pasta.

A desvantagem é a decisão de onde vai o que é compartilhado (um shader usado por vários inimigos, uma fonte usada na UI e nos créditos). A solução é uma pasta Shared ou Common para o que serve a mais de uma feature.

Minha regra para projeto indie: comece por feature no nível de cima e por tipo dentro de cada feature, quando ela tiver muitos arquivos. Em jogo de game jam, por tipo puro resolve.

Estrutura sugerida para jogo indie

Assets/
  _Project/
    Art/
      Shared/            (paletas, materiais e shaders comuns)
    Audio/
      Music/
      SFX/
    Features/
      Player/
        Scripts/
        Sprites/
        Animations/
        Player.prefab
      Enemies/
        Slime/
        Archer/
        Shared/
      UI/
        Scripts/
        Prefabs/
        Fonts/
    Scenes/
      Boot.unity
      MainMenu.unity
      Levels/
        Level_01.unity
    Settings/            (assets de URP, Input Actions, Audio Mixer)
    Data/                (ScriptableObjects de configuração)
  Plugins/               (pacotes de terceiros que pedem essa pasta)
  ThirdParty/            (assets da Asset Store e de outras fontes)

Por que _Project com sublinhado? A janela Project ordena por nome, e o sublinhado coloca sua pasta no topo, acima de tudo que pacotes de terceiros criam na raiz. Mais importante que o nome é a regra: nada seu fica solto na raiz de Assets. Tudo que é seu está em _Project, tudo que não é está fora dela.

Scenes fica fora de Features porque uma fase usa várias features. Data concentra os ScriptableObjects de configuração (armas, inimigos, fases), o que facilita o trabalho de balanceamento.

Pastas especiais: Editor, Resources, StreamingAssets, Plugins

Alguns nomes de pasta mudam o comportamento da Unity, onde quer que estejam (ou só na raiz, em alguns casos). Segundo o manual do Unity 6.3:

• Editor: scripts que estendem o editor (inspectors customizados, menus, ferramentas). Não entram na build e não podem ser anexados a GameObjects como componentes. Pode haver várias pastas Editor espalhadas pelo projeto.
• Editor Default Resources: assets que scripts de editor carregam sob demanda. Só uma, na raiz de Assets.
• Gizmos: imagens usadas como ícones no Scene view. Só uma, na raiz de Assets.
• Resources: assets carregados por nome em runtime com Resources.Load, sem referência numa cena. Tudo que está ali entra na build e aumenta o tamanho dela, usado ou não.
• StreamingAssets: arquivos que vão para a build no formato original, acessíveis em runtime (vídeos, bancos de dados, JSON de configuração que você quer ler como arquivo). Só uma, na raiz de Assets.
• Plugins: plugins de terceiros (bibliotecas nativas, DLLs). O manual remete à documentação de cada plataforma para os caminhos válidos.

E o que a Unity ignora na importação: pastas ocultas, arquivos e pastas que começam com ponto (exceto dentro de StreamingAssets), arquivos e pastas que terminam com til (~), pastas chamadas cvs e arquivos .tmp. O til é útil: uma pasta Docs~ dentro de _Project guarda referências, rascunhos e PSDs de trabalho sem a Unity importar nada. Um detalhe do manual: se você criar uma pasta começando com ponto pelo editor, a Unity troca o ponto por sublinhado; para manter o ponto, crie pelo sistema de arquivos.

O que nunca colocar em Assets: builds do jogo, arquivos .zip de pacotes baixados, vídeos de referência pesados, arquivos de projeto de outras ferramentas que você não vai importar. Tudo em Assets é importado, e importar coisa inútil deixa a abertura do projeto mais lenta. Use uma pasta irmã de Assets (fora dela, na raiz do projeto) ou a pasta com til.

Sobre Resources: ela é prática e por isso vira depósito. Coloque ali só o que realmente precisa ser carregado por nome. Para o resto, prefira referência direta num campo [SerializeField] ou o pacote Addressables.

Organização é a parte invisível de um jogo que chega ao fim. Quem aprende engine por vídeo avulso costuma ter dez projetos começados com estruturas diferentes e nenhum terminado, porque cada tutorial organiza de um jeito e ninguém mostra o projeto inteiro crescendo do primeiro script até a build publicada.

Assets de terceiros: onde colocar

Pacotes da Asset Store e de outras fontes chegam com a estrutura do autor, e muitos se instalam na raiz de Assets com nomes que você não escolheu. Três regras:

1. Não edite arquivos de terceiros no lugar. Se precisar mudar um script ou prefab do pacote, copie para _Project (ou crie uma variante do prefab) e mexa na cópia. Assim, atualizar o pacote não apaga sua mudança.
2. Agrupe numa pasta só quando der. Muitos pacotes funcionam movidos para ThirdParty/NomeDoPacote. Alguns não funcionam, porque o código procura caminhos fixos ou pede a pasta Plugins na raiz. Teste depois de mover e, se quebrar, deixe onde o autor colocou.
3. Prefira pacotes pelo Package Manager. O que é instalado como pacote (via registro ou Git) fica em Packages, fora de Assets, e não polui sua estrutura.

Nomenclatura de arquivos e cenas

Regras simples que evitam dor de cabeça:

• Sem espaços e sem acentos nos nomes de arquivos. Slime_Idle.anim, não slime idle (cópia).anim. Alguns sistemas de build e ferramentas de linha de comando tropeçam em espaço e acento.
• Nome de script igual ao nome da classe. PlayerController.cs contém public class PlayerController. Se forem diferentes, a Unity não consegue anexar o componente.
• Prefixo por tipo quando ajuda na busca. SFX_Jump, MUS_Level01, UI_Button. Útil em pastas grandes; desnecessário em pastas pequenas.
• Cenas numeradas com zero à esquerda. Level_01 a Level_12, para a ordenação alfabética bater com a ordem do jogo.
• Uma cena de boot. Boot.unity carrega serviços (áudio, save, configuração) e depois o menu. Facilita testar e evita depender da ordem em que as cenas foram abertas.

Git e .gitignore: o que versionar

Um projeto Unity tem três pastas que importam para o Git e várias que não:

• Versione: Assets, Packages e ProjectSettings. Dentro de Assets, versione todos os arquivos .meta: eles guardam o GUID de cada asset, e é pelo GUID que cenas e prefabs se referenciam.
• Ignore: Library, Temp, Obj, Logs, UserSettings, MemoryCaptures, Recordings e as pastas de build (Build, Builds). Também ignore os .csproj e .sln gerados, que a Unity recria.

Um .gitignore mínimo, na raiz do projeto (ao lado de Assets):

/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Uu]ser[Ss]ettings/
/[Mm]emoryCaptures/
/[Rr]ecordings/
*.csproj
*.sln
*.user
*.pidb
*.booproj
*.apk
*.aab
.vs/
.vscode/
.idea/

Confira também duas opções em Edit > Project Settings: na seção Version Control, o modo Visible Meta Files; na seção Editor, Asset Serialization em Force Text. Em projeto novo as duas já vêm assim, mas projetos antigos ou importados podem estar diferentes. Com texto, cenas e prefabs viram arquivos legíveis e o Git consegue mostrar diffs. Para arquivos binários grandes (PSD, WAV, FBX), configure Git LFS. O post sobre .gitignore para projetos de jogos Godot e Unity traz a versão completa, com LFS e os casos de cada engine.

Próximo passo

Abra seu projeto atual e faça a faxina em três passos: crie _Project, mova tudo que é seu para dentro dela pela janela Project da Unity e mova os pacotes de terceiros para ThirdParty quando eles aceitarem. Depois escreva um README.md curto na raiz do repositório com a regra escolhida (por tipo ou por feature). Com o código já separado em pastas, o passo seguinte é dividir os scripts em Assembly Definitions e cortar o tempo de recompilação.