Práticas recomendadas para organizar seu projeto Unity

Embora não exista uma maneira única de organizar um projeto Unity, aqui estão algumas recomendações importantes:

• Documente suas convenções de nomenclatura e a estrutura de pastas. Um guia de estilo e/ou modelo de projeto facilita a localização e a organização dos arquivos. Escolha o que funciona para a sua equipe e certifique-se de que todos estejam de acordo com isso.
• Seja consistente com suas convenções de nomenclatura. Não se desvie do guia de estilo ou do modelo escolhido. Se for necessário alterar as regras de nomenclatura, analise e renomeie os ativos afetados de uma só vez. Se alguma vez as alterações afetarem um grande número de arquivos, considere automatizar a atualização usando um script.
• Não use espaços nos nomes de arquivos e pastas. As ferramentas de linha de comando do Unity têm problemas com nomes de caminho que incluem espaços. Use CamelCase como alternativa para espaços.
• Áreas de teste ou sandbox separadas. Crie uma pasta separada para cenas de não produção e experimentação. As subpastas com nomes de usuário podem dividir sua área de trabalho por membro da equipe.
• Evite pastas extras no nível da raiz. Em geral, armazene seus arquivos de conteúdo na pasta Assets. Não crie pastas adicionais no nível raiz do projeto, a menos que seja absolutamente necessário.
• Mantenha seus ativos internos separados dos ativos de terceiros. Se você estiver usando ativos da Asset Store ou de outros plug-ins, é provável que eles tenham sua própria estrutura de projeto. Mantenha seus próprios bens separados.

Observação: Se você estiver modificando um ativo ou plug-in de terceiros para o seu projeto, o controle de versão poderá ajudá-lo a obter a atualização mais recente do plug-in. Depois que a atualização for importada, você poderá examinar o diff para ver onde suas modificações podem ter sido substituídas e reimplementá-las.

Embora não haja uma estrutura de pastas definida, as duas seções a seguir mostram exemplos de como você pode configurar seu projeto Unity. Essas estruturas se baseiam na divisão de seu projeto por tipo de ativo.

A página do manual Tipos de ativos descreve os ativos mais comuns em mais detalhes. Você pode usar os projetos Template ou Learn para obter mais inspiração ao organizar sua estrutura de pastas. Embora você não esteja limitado a esses nomes de pastas, eles podem lhe dar um bom ponto de partida.

Se você baixar um dos projetos Template ou Starter do Unity Hub, perceberá que as subpastas estão divididas por tipo de recurso. Dependendo do modelo escolhido, você verá subpastas que representam vários ativos comuns.

A definição de uma estrutura de projeto sólida desde o início pode ajudá-lo a evitar problemas de controle de versão mais tarde. Se você mover ativos de uma pasta para outra, muitos VCS entenderão isso como apenas a exclusão de um arquivo e a adição de outro, em vez de o arquivo ser movido. Isso perde o histórico do arquivo original.

O Plastic SCM pode lidar com movimentações de arquivos dentro do Unity e preservar o histórico de qualquer arquivo que tenha sido movimentado. No entanto, é essencial que você mova os arquivos no Editor para que o arquivo .meta seja movido junto com o arquivo de ativo.

Depois de decidir sobre uma estrutura de pastas para seus projetos, use um script do Editor para reutilizar o modelo e criar a mesma estrutura de pastas para todos os projetos futuros. Quando for colocado em uma pasta do Editor, o script abaixo criará uma pasta raiz em ativos que correspondam à variável "PROJECT_NAME". Isso mantém seu próprio trabalho separado dos pacotes de terceiros.

As pastas vazias correm o risco de criar problemas no controle de versão, portanto, tente criar pastas apenas para o que realmente precisa. Com o Git e o Perforce, as pastas vazias são ignoradas por padrão. Se essas pastas de projeto forem configuradas e alguém tentar confirmá-las, elas não funcionarão de fato até que algo seja colocado na pasta.

Observação: Uma solução comum é colocar um arquivo ".keep" dentro de uma pasta vazia. Isso é suficiente para que a pasta seja confirmada no repositório.

O SCM de plástico pode lidar com pastas vazias. Os diretórios são tratados como entidades pelo Plastic SCM, cada um com seu próprio histórico de versões anexado.

Esse é um ponto que deve ser lembrado ao trabalhar no Unity. O Unity gera um arquivo .meta para cada arquivo do projeto, inclusive para as pastas. Com o Git e o Perforce, um usuário pode facilmente confirmar o arquivo .meta de uma pasta vazia, mas a pasta em si não ficará sob o controle de versão. Quando outro usuário obtiver as alterações mais recentes, haverá um arquivo .meta para uma pasta que não existe no computador dele, e o Unity excluirá o arquivo .meta. O Plastic SCM evita totalmente esse problema ao incluir pastas vazias no controle de versão.

O Unity gera um arquivo .meta para cada outro arquivo dentro do projeto e, embora normalmente não seja aconselhável incluir arquivos gerados automaticamente no controle de versão, o arquivo .meta é um pouco diferente. O modo Arquivos meta visíveis deve ser ativado na janela Controle de versão (a menos que você esteja usando os modos Plastic SCM ou Perforce integrados).

Embora o arquivo .meta seja gerado automaticamente, ele contém muitas informações sobre o arquivo ao qual está associado. Isso é comum para ativos que têm configurações de importação, como texturas, malhas, clipes de áudio, etc. Quando você altera as configurações de importação nesses arquivos, as alterações são gravadas no arquivo .meta (em vez de no arquivo do ativo). É por isso que você envia os arquivos .meta para o seu repositório, para que todos trabalhem com as mesmas configurações de arquivo.

A concordância com os padrões não se limita à estrutura de pastas do projeto. Definir um padrão de nomenclatura específico para todos os recursos do jogo pode facilitar as coisas para a sua equipe ao trabalhar nos arquivos uns dos outros.

Embora não haja um padrão de nomenclatura definitivo para GameObjects, considere a tabela acima.

Cenas únicas e grandes do Unity não se prestam bem à colaboração. Divida suas fases em várias cenas menores para que os artistas e designers possam colaborar sem problemas em uma única fase, minimizando o risco de conflitos.

Em tempo de execução, seu projeto pode carregar cenas aditivamente usando o SceneManager com LoadSceneAsync passando o parâmetro LoadSceneMode.Additive.

É uma prática recomendada dividir o trabalho em Prefabs sempre que possível e aproveitar o poder dos Prefabs aninhados. Se precisar fazer alterações mais tarde, você poderá alterar o Prefab em vez da cena em que ele se encontra, para evitar conflitos com qualquer outra pessoa que esteja trabalhando na cena. As alterações pré-fabricadas geralmente são mais fáceis de ler ao fazer uma comparação no controle de versão.

Caso você acabe tendo um conflito de cena, o Unity também tem uma ferramenta YAML (uma linguagem de serialização de dados legível por humanos) integrada usada para mesclar cenas e Prefabs. Para obter mais informações, consulte Smart merge na documentação do Unity.

As predefinições permitem que você personalize o estado padrão de praticamente tudo em seu Inspector. A criação de predefinições permite que você copie as configurações de componentes ou ativos selecionados, salve-os como seus próprios ativos e, posteriormente, aplique essas mesmas configurações a outros itens.

Use as predefinições para impor padrões ou aplicar padrões razoáveis a novos ativos. Eles podem ajudar a garantir padrões consistentes em toda a sua equipe, de modo que configurações comumente negligenciadas não afetem o desempenho do seu projeto.

Clique no ícone de predefinição no canto superior direito do componente. Para salvar a predefinição como um ativo, clique em Salvar atual em... e selecione uma das predefinições disponíveis para carregar um conjunto de valores.

Aqui estão algumas outras maneiras úteis de usar as predefinições:

• Crie um GameObject com os padrões: Arraste e solte um ativo de predefinição na hierarquia para criar um novo GameObject com um componente correspondente que inclua valores de predefinição.
• Associar um tipo específico a uma predefinição: No Gerenciador de predefinições(Configurações do projeto > Gerenciador de predefinições), especifique uma ou mais predefinições por tipo. A criação de um novo componente terá como padrão os valores predefinidos especificados.
• Dica profissional: Crie várias predefinições por tipo e conte com o filtro para associar a predefinição correta por nome.
• Salvar e carregar as configurações do Manager: Use Predefinições para uma janela do Manager para que as configurações possam ser reutilizadas. Por exemplo, se você planeja reaplicar as mesmas tags e camadas ou configurações de física, as predefinições podem reduzir o tempo de configuração do seu próximo projeto.

Da mesma forma, os padrões de codificação mantêm o trabalho da sua equipe consistente, o que facilita a troca de desenvolvedores entre diferentes áreas do seu projeto. Mais uma vez, não há regras definidas em pedra aqui. Você precisa decidir o que é melhor para a sua equipe, mas, depois de tomar essa decisão, certifique-se de mantê-la.

Por exemplo, os namespaces podem organizar seu código com mais precisão. Eles permitem que você separe os módulos dentro do seu projeto e evite conflitos com ativos de terceiros, onde os nomes das classes podem acabar se repetindo.

Observação: Ao usar namespaces em seu código, divida a estrutura de pastas por namespace para melhor organização.

Um cabeçalho padrão também é recomendado. A inclusão de um cabeçalho padrão no modelo de código ajuda a documentar a finalidade de uma classe, a data em que foi criada e até mesmo quem a criou; essencialmente, todas as informações que poderiam facilmente se perder no longo histórico de um projeto, mesmo quando se usa o controle de versão.

O Unity utiliza um modelo de script para ler sempre que você cria um novo MonoBehaviour no projeto. Toda vez que você cria um novo script ou shader, o Unity usa um modelo armazenado em %EDITOR_PATH%\Data\Resources\ScriptTemplates:

• Windows C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Hub/Editor/[version]/Unity/Unity.app/Contents/ Resources/ScriptTemplates

O modelo padrão do MonoBehaviour é este: 81-C# Script-NewBehaviourScript.cs.txt

Há também modelos para shaders, outros scripts de comportamento e definições de montagem.

Para modelos de script específicos do projeto, crie uma pasta Assets/ScriptTemplates e copie os modelos de script para essa pasta para substituir os padrões.

Você também pode modificar os modelos de script padrão diretamente para todos os projetos, mas certifique-se de fazer backup dos originais antes de fazer qualquer alteração. Cada versão do Unity tem sua própria pasta de modelos, portanto, quando você atualiza para uma nova versão, precisa substituir os modelos novamente. O exemplo de código abaixo mostra a aparência do arquivo original 81-C# Script-NewBehaviourScript.cs.txt.

No exemplo abaixo, há duas palavras-chave que podem ser úteis:

• #SCRIPTNAME# indica o nome de arquivo inserido ou o nome de arquivo padrão (por exemplo, NewBehaviourScript).
• #NOTRIM# garante que os colchetes contenham uma linha de espaço em branco.

Você pode usar suas próprias palavras-chave e substituí-las por um script do Editor para implementar o método OnWillCreateAsset.

Use o cabeçalho no exemplo de script a seguir dentro de seu modelo de script. Dessa forma, qualquer novo script será criado com um cabeçalho que mostra sua data, o usuário que o criou e o projeto ao qual ele pertencia originalmente. Isso é útil para reutilizar o código em projetos futuros.