Bricks

Esta página foi traduzida automaticamente e pode conter erros. Encontrou um problema? Use o link "Edit this page" para ajudar a corrigir.

Um brick é uma pasta com um package.json que contém scripts, assets e assembly definitions que outros projetos podem instalar. Os rigs de câmera e a UI de jogo do próprio motor são bricks, então um jogo que não os usa não os inclui. package.json, o arquivo de lock e a pasta Bricks/ mantêm seus nomes de pacote; tudo com que você interage se chama brick.

Instalando

Um projeto lista seus bricks em Bricks/manifest.json; o packages-lock.json ao lado registra exatamente o que foi resolvido e deve ser commitado. Novos projetos começam com os bricks embutidos.

{
  "dependencies": {
    "org.mass4.turian.cameras": "builtin:org.mass4.turian.cameras",
    "user.mateo.inventory": "^1.0.0",
    "com.acme.rules": "git+https://github.com/acme/rules.git#v1.2.0",
    "com.acme.levels": "file:../bricks/com.acme.levels-1.0.0.brick"
  }
}

Origem	Significado
`builtin:<id>`	acompanha o motor
`file:<pasta>`	uma pasta usada no lugar, para um brick que você está desenvolvendo
`file:<x.brick>`	um brick empacotado, extraído uma vez para o store
`git+<url>[#ref]`	um repositório git, fixado em um commit no lock
`^1.0.0` (uma faixa de versão)	obtido do registry associado ao nome

Os bricks são guardados uma vez por máquina em ~/.gaya/bricks (defina GAYA_BRICKS para mudar o local, por exemplo para um cache de CI) e nunca são copiados para os projetos. Um projeto tem exatamente uma versão de cada brick.

Pela linha de comando

turian-cli brick … e Project → Bricks… no Studio fazem as mesmas coisas.

Comando
`add`, `remove`, `list`	alteram e mostram o que o projeto instala
`restore [--locked]`	baixa tudo; `--locked` falha quando o manifest e o lock divergem (use no CI)
`update [id…]`	move os bricks git para o commit mais recente
`search`, `registry add\\|list\\|remove`	encontram bricks; escolhem registries e as chaves em que você confia
`new <id>`	começa um brick: manifest, assembly definition, script
`verify [--against <brick>]`	todo asset tem um `.meta` único; com `--against`, um stub ainda corresponde ao brick real
`pack [--precast]`, `publish`	escrevem um `.brick`, ou o adicionam a uma pasta de registry
`embed`, `diff`, `rebase`	fazem fork de um brick no projeto, mostram suas mudanças, mesclam a próxima versão dele
`copy`	copia alguns assets de um brick para `Assets` com novos ids
`stub`	placeholder com os mesmos ids, para equipes que constroem sobre um brick ainda não terminado

Criando um brick

turian-cli brick new user.you.inventory cria a pasta. Os ids são reverse-DNS em minúsculas: use seu domínio (com.acme.inventory), ou user.<nome>.… se você não tiver um.

Os scripts ficam sob uma assembly definition (um .dataasset de New → Scripting → Assembly Definition). Todo script e asset acompanha seu .meta, porque os ids dentro deles são o que outros projetos referenciam; mantenha-os estáveis.
Pastas cujo nome termina em ~ (Samples~, Documentation~, Precast~) não são importadas.
engines indica quais versões do motor funcionam ("turian": ">=1.0 <2"), dependencies outros bricks, nuget os pacotes NuGet que assemblies pré-compilados precisam, license uma expressão SPDX.
turian-cli brick pack --precast compila os assemblies em Precast~/. Quem instala esse arquivo carrega os assemblies em vez de compilar o seu código.

Um workflow reutilizável do GitHub, MASS4ORG/Turian/.github/workflows/brick.yml, verifica, empacota e publica um brick.

Alterando o que você instalou

Os bricks instalados são somente leitura. Em ordem de esforço:

Use-o como está, pelo id.
Crie uma variante de prefab ou uma variante de data asset (turian-cli variant): o original mais os valores que você sobrescreve, e ela acompanha o original quando ele muda.
Mude como os assets de um brick são importados em ProjectSettings/PackageImportOverrides.json ({ "<asset id>": { "GenerateMips": false } }).
Copie um asset para o projeto (brick copy): ele recebe um novo id e deixa de acompanhar o brick.
Faça embed do brick inteiro (brick embed): uma cópia editável em Bricks/<id> que prevalece sobre a instalada. brick diff lista suas mudanças; brick rebase mescla nelas a próxima versão do original.

Registries

Um registry é um site estático com um índice assinado (formato: docs/bricks/registry.md no repositório do motor). Um projeto obtém bricks de um registry para os nomes aos quais ele está associado e confia nas chaves que ele mesmo lista:

"scopedRegistries": [
  { "name": "studio", "url": "https://bricks.studio.example/v1", "scopes": ["com.studio"], "keys": ["ssh-ed25519 AAAA… studio"] }
]

O lock registra a versão, o hash do arquivo e a chave de assinatura de cada brick. As assinaturas são assinaturas OpenSSH ed25519, então quem publica usa as chaves que já tem.

Importando um pacote Unity

turian-cli import unitypackage Crates.unitypackage --brick user.you.crates --out bricks/ (ou --project <pasta>) converte o que tem correspondência e relata o resto. Texturas, modelos e áudio mantêm seus ids e pastas do Unity, e as configurações de textura que existem no Turian vêm junto. Materiais e prefabs/cenas são convertidos; scripts, shaders e animação são listados como ignorados. Verifique a licença do pacote: a ferramenta não a altera.

← Toda a documentação Editar esta página