🥇Unity Package Manager

Unity — uma plataforma que existe há bastante tempo e está sempre em evolução. No entanto, ao trabalhar nela em vários projetos simultaneamente, ainda podem surgir dificuldades no uso de fontes comuns (.cs), bibliotecas (.dll) e outros ativos (imagens, sons, modelos, prefabs). Neste artigo, compartilharemos nossa experiência com uma solução nativa para esse problema no Unity.

Métodos de compartilhamento de recursos comuns

Existem mais de uma maneira de utilizar recursos comuns para diferentes projetos, mas cada abordagem tem suas vantagens e desvantagens.

1. Duplicação — duplicamos os recursos manualmente entre os projetos.

Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.

Adequado para todos os tipos de recursos.
Sem problemas com dependências.
Sem problemas com GUIDs de ativos.

Pontos negativos:

Repositórios gigantes.
Sem possibilidade de versionamento.
Dificuldade em rastrear mudanças em recursos compartilhados.
Dificuldade em atualizar recursos compartilhados.

2. Submódulos Git — compartilhamento de recursos comuns através de submódulos externos.

Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.

É possível trabalhar com as fontes.
É possível compartilhar ativos.
Sem problemas com dependências.

Pontos negativos:

Necessário ter habilidade em Git.
Git não lida bem com arquivos binários — será necessário adicionar LFS.
Divisão de acesso para repositórios.
Dificuldades ao aumentar ou diminuir versões.
Possibilidade de colisões de GUIDs e comportamento ambíguo por parte do Unity para resolvê-las.

3. NuGet — compartilhamento de bibliotecas comuns através de pacotes NuGet.

Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.

Trabalho prático com projetos que não dependem do Unity.
Versionamento conveniente e resolução de dependências.

Pontos negativos:

Unity não consegue trabalhar com pacotes NuGet "pronto para uso" (no GitHub, é possível encontrar o NuGet Package Manager for Unity que resolve isso, mas há algumas nuances).
Dificuldade ao compartilhar outros tipos de ativos.

4. Unity Package Manager — compartilhamento de recursos comuns através de uma solução nativa para o Unity.

Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.

Interface nativa para trabalhar com pacotes.
Proteção contra sobrescrição de arquivos .meta em pacotes em caso de conflitos de GUIDs.
Possibilidade de versionamento.
Possibilidade de compartilhar todos os tipos de recursos para Unity.

Pontos negativos:

Ainda podem ocorrer conflitos de GUIDs.
Sem documentação para implementação.

O último método tem mais vantagens do que desvantagens. No entanto, atualmente não é muito popular devido à falta de documentação, e por isso, abordaremos este assunto em mais detalhes.

Gerenciador de Pacotes Unity

O Unity Package Manager (a seguir UPM) é uma ferramenta para gerenciar pacotes. Foi adicionado ao Unity 2018.1 e era utilizado apenas para pacotes desenvolvidos pela Unity Technologies. No entanto, a partir da versão 2018.3, surgiu a possibilidade de adicionar pacotes personalizados.

Interface do Unity Package Manager

Os pacotes não aparecem nos arquivos do projeto (diretório Assets). Eles ficam em um diretório separado %projectFolder%/Library/PackageCache e não afetam o projeto de forma alguma, sua única menção nos arquivos é no arquivo packages/manifest.json.

Pacotes no sistema de arquivos do projeto

Fontes dos pacotes

O UPM pode usar várias fontes de pacotes:

1. Sistema de arquivos.

Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.

Velocidade de implementação.
Não requer ferramentas de terceiros.

Pontos negativos:

Complexidade de versionamento.
É necessário ter acesso compartilhado ao sistema de arquivos para todos que trabalham no projeto.

2. Repositório Git.

Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.

Somente um repositório Git é necessário.

Pontos negativos:

Não é possível alternar entre versões através da interface do UPM.
Não funciona com todos os repositórios Git.

3. Repositório npm.

Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.

Suporta totalmente a funcionalidade do UPM e é usado para a distribuição de pacotes oficiais do Unity.

Pontos negativos:

Atualmente, ignora todas as versões de string dos pacotes, exceto "-preview".

Abaixo, discutiremos a implementação do UPM + npm. Essa combinação é conveniente, pois permite trabalhar com todos os tipos de recursos e gerenciar versões de pacotes, além de suportar completamente a interface nativa do UPM.

Como repositório npm, pode-se usar Verdaccio. Há um guia detalhado sobre isso documentação, e para sua execução, bastará literalmente alguns comandos.

Configuração do ambiente

Primeiro, é necessário instalar node.js.

Criação de um pacote

Para criar um pacote, é necessário colocar o arquivo package.json, que o descreverá, no diretório com o conteúdo desse pacote. É preciso fazer o seguinte:

Ir para o diretório do projeto que queremos tornar um pacote.

Executar o comando npm init e, durante o diálogo, inserir os valores necessários. Para o nome, deve-se indicar o nome no formato de domínio reverso, por exemplo, com.plarium.somepackage.
Para uma exibição conveniente do nome do pacote — adicione a propriedade displayName ao package.json e preencha-a.

Como o npm é orientado a js, o arquivo contém propriedades desnecessárias para nós, como main e scripts, que o Unity não utiliza. É melhor removê-las para não poluir a descrição do pacote. O arquivo deve se parecer com isto:

Ir para o diretório do projeto que queremos tornar um pacote.
Executar o comando npm init e, durante o diálogo, inserir os valores necessários. Para o nome, deve-se indicar o nome no formato de domínio reverso, por exemplo, com.plarium.somepackage.
Para uma exibição conveniente do nome do pacote — adicione a propriedade displayName ao package.json e preencha-a.
Como o npm é orientado a js, o arquivo contém propriedades desnecessárias para nós, como main e scripts, que o Unity não utiliza. É melhor removê-las para não poluir a descrição do pacote. O arquivo deve se parecer com isto:
```
{
 "name": "com.plarium.somepackage",
 "displayName": "Some Package",
 "version": "1.0.0",
 "description": "Descrição do Some Package",
 "keywords": [
   "Unity",
   "UPM"
 ],
 "author": "AUTOR",
 "license": "NÃO LICENCIADO"
}
```
Abra o Unity e gere um arquivo .meta para o package.json (o Unity não reconhece assets sem arquivos .meta, pacotes do Unity abrem apenas como leitura).

Envio do pacote

Para enviar o pacote, a seguinte comando deve ser executada: npm publish --registry *endereço do repositório de pacotes*.

Instalação e atualização de pacotes através do Unity Package Manager

Para adicionar um pacote a um projeto Unity, você deve:

Inserir no arquivo manifest.json as informações sobre a fonte dos pacotes. Para isso, você deve adicionar a propriedade scopedRegistries e especificar os escopos e o endereço da fonte, onde os escopos específicos serão procurados.
```
"scopedRegistries": [
   {
     "name": "Principal",
     "url": "endereço do repositório de pacotes",
     "scopes": [
       "com.plarium"
     ]
   }
 ]
```
Vá para o Unity e abra a janela do Package Manager (trabalhar com pacotes personalizados não é diferente de trabalhar com os embutidos).
Selecione Todos os Pacotes.
Encontre o pacote necessário e adicione-o.

Trabalhando com fontes e depuração

Para que os fontes se conectem ao projeto, é necessário criar um Assembly Definition para o pacote.

O uso de pacotes não limita as opções para depuração. No entanto, ao trabalhar com pacotes no Unity, você não pode acessar o IDE clicando em um erro no console, caso o erro tenha ocorrido no pacote. Isso se deve ao fato de que o Unity não reconhece scripts como arquivos separados, pois, ao usar a Assembly Definition, eles são agrupados em uma biblioteca e conectados ao projeto. Ao trabalhar com fontes do projeto, a transição para o IDE ao clicar está disponível.

Script no projeto com pacote conectado:

Script do pacote com breakpoint funcionando:

Correções urgentes em pacotes

Pacotes Unity adicionados ao projeto estão abertos apenas para leitura, mas podem ser editados no cache dos pacotes. Para isso, você deve:

Ir para o pacote no cache dos pacotes.
Fazer as alterações necessárias.
Atualizar a versão no arquivo package.json.
Enviar o pacote npm publish --registry *endereço do repositório de pacotes*.
Atualizar a versão do pacote corrigido através da interface UPM.

Conflitos de importação de pacotes

Ao importar pacotes, os seguintes conflitos de GUID podem ocorrer:

Pacote — pacote. Se ao importar um pacote for descoberto que existem assets com o mesmo GUID em pacotes já adicionados, os assets com GUIDs coincidentes do pacote importado não serão adicionados ao projeto.
O pacote é o projeto. Se, ao importar um pacote, houver activos no projeto com GUIDs coincidentes, os activos do pacote não serão adicionados ao projeto. No entanto, os activos que dependem deles começarão a usar os activos do projeto.

Transferindo activos do projeto para o pacote

Se você transferir um activo do projeto para o pacote enquanto o Unity estiver aberto, sua funcionalidade será mantida, e os links em activos dependentes começarão a usar o activo do pacote.

Importante: ao copiar um activo do projeto para o pacote, ocorrerá um conflito "Pacote - projeto", conforme descrito na seção acima.

Possíveis soluções para conflitos

Reatribuição de GUIDs de acordo com algoritmos próprios ao importar todos os activos, para evitar colisões.
Adicionar todos os activos em um único projeto e depois separá-los em pacotes.
Criar um banco de dados contendo os GUIDs de todos os activos e realizar validação ao enviar pacotes.

Conclusão

UPM é uma nova solução para distribuição de recursos comuns no Unity, que pode se tornar uma alternativa viável aos métodos existentes. As recomendações descritas no artigo foram baseadas em casos reais. Esperamos que sejam úteis para você.

Fonte: habr.com