Melhores práticas para organizar seu projeto do Unity

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

• Documente suas convenções de nomenclatura e estrutura de pastas. Um guia de estilo e/ou modelo de projeto facilita a localização e a organização de arquivos. Escolha o que funciona para a sua equipe e verifique se todos estão de acordo.
• Seja consistente com suas convenções de nomenclatura. Não desvie do guia ou modelo de estilo escolhido. Se você precisar alterar suas regras de nomenclatura, analise e renomeie seus assets afetados de uma só vez. Se as alterações afetarem um grande número de arquivos, considere automatizar a atualização usando um script.
• Não use espaços em nomes de arquivos e pastas. As ferramentas de linha de comando do Unity apresentam problemas com nomes de caminhos que incluem espaços. Use o CamelCase como alternativa para espaços.
• Separe as áreas de teste ou sandbox. Crie uma pasta separada para cenas não produtivas e experimentação. Subfolders com nomes de usuários podem dividir sua área de trabalho por membro da equipe.
• Evite pastas extras no nível raiz. No 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 assets internos separados de assets de terceiros. Se você estiver usando assets da Asset Store ou outros plug-ins, a probabilidade é que eles tenham sua própria estrutura de projeto. Mantenha seus próprios assets separados.

Observação: Se você estiver modificando um asset ou plug-in de terceiros para o seu projeto, o Version Control pode ajudar você a obter a atualização mais recente para o plug-in. Assim que a atualização for importada, você poderá analisar o diferencial para ver onde suas modificações poderiam ter sido substituídas e reimplementá-las.

Embora não exista estrutura de pasta de configuração, as seções a seguir apresentam exemplos de como configurar seu projeto do Unity. Ambas são baseadas em dividir seu projeto por tipo de asset.

A página Asset Types manual descreve os assets mais comuns com mais detalhes. Você pode usar os projetos Template ou Learn para obter mais inspiração ao organizar sua estrutura de pasta. Embora você não esteja limitado a esses nomes de pastas, eles podem fornecer um bom ponto de partida.

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

Definir uma estrutura de projeto forte desde o início pode ajudar você a evitar problemas de Version Control posteriormente. Se você mover assets de uma pasta para outra, muitos VCS perceberão isso como simplesmente excluir um arquivo e adicionar 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 movido. No entanto, é essencial que você mova arquivos no Editor para que o arquivo .meta se mova junto com o arquivo de asset.

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

As pastas vazias correm o risco de criar problemas no Version Control, então tente criar apenas pastas para o que você realmente precisa. Com Git e Perforce, pastas em branco são ignoradas por padrão. Se essas pastas de projeto estiverem configuradas e alguém tentar enviá-las, na verdade não funcionará até que algo seja colocado na pasta.

Observação: Uma solução recomendada é colocar um arquivo “.keep” dentro de uma pasta vazia. Isso é suficiente para que a pasta seja enviada ao repositório.

O Plastic Scm pode lidar com pastas em branco. Diretórios são tratados como entidades pelo Plastic Scm, cada um com seu próprio histórico de versão associado.

Este é um ponto que deve ser mantido em mente ao trabalhar na Unity. O Unity gera um arquivo .meta para cada arquivo no projeto, incluindo pastas. Com Git e Perforce, um usuário pode facilmente enviar o arquivo .meta para uma pasta vazia, mas a pasta em si não ficará sob Version Control. Quando outro usuário receber as alterações mais recentes, haverá um arquivo .meta para uma pasta que não existe em seu computador e, em seguida, a Unity excluirá o arquivo .meta. O Plastic Scm evita esse problema totalmente ao incluir pastas em branco sob Version Control.

O Unity gera um arquivo .meta para cada outro arquivo dentro do projeto e, embora seja normalmente desaconselhado incluir arquivos gerados automaticamente no Version Control, o arquivo .meta é um pouco diferente. O modo Meta Files visíveis deve ser ativado na janela Version Control (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 assets que têm configurações de importação, como texturas, malhas, clipes de áudio, etc. Ao alterar as configurações de importação desses arquivos, as alterações são gravadas no arquivo .meta (em vez do arquivo asset). É por isso que você compromete os arquivos .meta em seu repositório, para que todos trabalhem com as mesmas configurações de arquivo.

Concordar com padrões não acaba na estrutura da pasta do projeto. Definir um padrão de nomenclatura específico para todos os assets do seu jogo pode facilitar as coisas para sua equipe ao trabalhar nos arquivos uns dos outros.

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

Cenas grandes e individuais do Unity não se prestam muito à colaboração. Divida seus níveis em cenas menores para que artistas e designers possam colaborar tranquilamente em um único nível enquanto minimiza o risco de conflitos.

No tempo de execução, seu projeto pode carregar cenas de maneira aditiva usando SceneManager com LoadSceneAsync passando pelo modo de parâmetro LoadSceneMode.Additive.

É prática recomendada dividir o trabalho em Prefabs sempre que possível e aproveitar o poder dos Prefabs aninhados. Se você precisar fazer alterações posteriormente, você pode alterar o Prefab em vez da cena em que está, para evitar conflitos com qualquer outra pessoa que trabalhe na cena. As alterações de Prefab costumam ser mais fáceis de ler ao realizar um diferencial sob Version Control.

Se você acabar com 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 a mesclagem inteligente na documentação do Unity.

As Predefinições permitem que você personalize o estado padrão de praticamente tudo no Inspector. Criar as Predefinições permite que você copie as configurações de componentes ou assets selecionados, salve-as como seus próprios assets e, posteriormente, aplique as mesmas configurações a outros itens.

Use Predefinições para impor padrões ou aplique padrões razoáveis a novos assets. Eles podem ajudar a garantir padrões consistentes em toda a sua equipe, para que configurações comumente ignoradas 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 asset, clique em Save current to... e selecione uma das Predefinições disponíveis para carregar um conjunto de valores.

Aqui estão algumas outras maneiras úteis de usar Presets:

• Criar um GameObject com padrões: Arraste e solve um asset Predefinido na hierarquia para criar um novo GameObject com um componente correspondente que inclui valores Predefinidos.
• Asociar um tipo específico a uma Predefinição: No Preset Manager (Project Settings > Preset Manager), especifique uma ou mais Presets por tipo. A criação de um novo componente será inicializada para os valores Preset especificados.
• Dica Pro: Crie várias Predefinições por tipo e confie no filtro para associar a Predefinição correta por nome.
• Salvar e carregar configurações do Manager: Use Predefinições para uma venda 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 para seu próximo projeto.

Os padrões de codificação também mantêm o trabalho de sua equipe consistente, o que facilita para os desenvolvedores alternarem entre diferentes áreas do seu projeto. Novamente, não há regras definidas aqui em pedra. Você precisa decidir o que é melhor para a sua equipe, mas uma vez que tiver decidido, mantenha-o.

Por exemplo, namespaces podem organizar seu código com mais precisão. Eles permitem que você separe módulos dentro de seu projeto e evite conflitos com assets de terceiros nos quais os nomes de classe podem acabar sendo repetidos.

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

Um cabeçalho padrão também é recomendado. Incluir um cabeçalho padrão em seu modelo de código ajuda você a documentar a finalidade de uma classe, a data de sua criação e até mesmo quem a criou. Essencialmente, todas as informações que poderiam ser facilmente perdidas no longo histórico de um projeto, mesmo ao usar o Version Control.

O Unity utiliza um modelo de script para ler sempre que criar um novo MonoBehaviour no projeto. Toda vez que criar 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/[versão]/Unity/Unity.app/Contents/Resources/ScriptTemplates

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

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

Para modelos de script específicos para projetos, crie uma folder Assets/ScriptTemplates e copie os modelos de script nessa 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 alterações. Cada versão do Unity tem sua própria pasta de modelo, portanto, ao atualizar para uma nova versão, você precisará substituir os modelos novamente. O exemplo de código abaixo mostra o 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 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 pertencia originalmente. Isso é útil para reutilizar o código em projetos futuros.