Por que usar arquivos de manifesto de ativos?

Às vezes, você verá pessoas recomendando isso, em vez de usar gráficos / arquivos de som / etc. como isso...

// Game code
Image myImage = new Image("path/to/image.png");

... você deve usar um arquivo de manifesto como um nível de indireção:

// Manifest file
MY_IMAGE: path/to/image.png

// Game code
Manifest myManifest = new Manifest("path/to/manifest");
Image myImage = myManifest.getImage("MY_IMAGE");

Que razões eu teria para adotar esse tipo de abordagem? Se eu não estiver usando uma linguagem compilada, ainda haverá razões para fazer isso?

Na maioria das vezes, os arquivos de manifesto são associados a algum tipo de formato de arquivo morto. Por exemplo, um arquivo JAR em java é simplesmente um arquivo zip com um arquivo de manifesto que lista os ativos no arquivo zip e onde encontrá-los. Nesse caso, o "caminho / para / imagem.png" não é um caminho real do sistema de arquivos, mas informações sobre como encontrar o objeto dentro de um arquivo compactado. Além da vantagem da compactação em espaço em disco, o uso de um arquivo morto pode melhorar o desempenho, pois o Windows tem muita dificuldade em lidar com dezenas de milhares de arquivos individuais em um pequeno número de diretórios.

Ao usar um arquivo de manifesto desse tipo, você pode abstrair completamente de onde vem um determinado pedaço de dados. Talvez o seu arquivo esteja em um DVD, ou seja transmitido pela Internet ou dentro de um arquivo zip. Você precisará escrever um código adicional para lidar com esses casos, mas, usando um arquivo de manifesto, sua lógica de jogo não precisa se importar de onde algo é carregado.

Agora, se você estiver usando uma linguagem não compilada, esse arquivo de manifesto certamente pode ser um arquivo de origem C #, mas é bom se você pode modificar facilmente o arquivo de manifesto que está usando no tempo de execução do cliente, com base em uma configuração de registro ou algo semelhante. Por exemplo, você pode verificar durante a execução se existe um cache no disco rígido ou se apenas o DVD está disponível. Em seguida, você pode alternar qual manifesto usar, dependendo da configuração disponível.

Um motivo: programação orientada a dados.

Seu código pode querer saber apenas que precisa de uma textura "LightWood" e permitir que o gerente de recursos use essa chave para encontrar o caminho certo para o arquivo. Ainda mais, nos scripts, as pessoas não querem se lembrar dos caminhos dos arquivos. Eles são confusos, podem estar incorretos. Deixe o manifesto descobrir onde está o arquivo e deixe o humano descobrir que material eles precisam pelo nome, não pelo nome do arquivo.

<material name="wood">
  <diffuse color="1,1,1,1">environment.zip/wood_diffuse.jpg</diffuse>
  <normals>environment.zip/wood_normals.jpg</normals>
  <shader>environment.zip/wood.fx</shader>
  <specular color="1,1,1,1" power="0.5" flat="yes" />
</material>

Como padrão geral de design, os manifestos são úteis quando você deseja coletar todas as informações sobre um conjunto diferente de objetos em um único local. Não precisa ser sobre arquivamento / arquivos compactados ou indiretamente para permitir que as coisas sejam movidas sem recompilar / atualizar as referências originais. De fato, o último pode apresentar mais problemas do que resolve, portanto, você faria isso apenas se solucionasse uma necessidade específica que você tinha.

A grande vantagem dos manifestos é que eles atuam como um índice para uma grande quantidade de dados em um único local compacto. Dessa forma, eles melhoram o desempenho (porque você pode simplesmente carregar o manifesto inteiro do disco e mantê-lo na memória), especialmente no caso em que você precisa iterar sobre vários objetos, mas não sabe de antemão quais serão esses objetos . Se os objetos estiverem em disco, especialmente se estiverem em vários lugares, você deverá tocar no sistema de arquivos toda vez que quiser iterar sobre os arquivos. Para sistemas de arquivos baseados em disco, o tempo necessário para tocar no sistema de arquivos é proibitivo, portanto, a iteração sobre arquivos em um diretório é um custo enorme. Ao pré-criar um manifesto de arquivos no tempo de compilação (NB: não no tempo de compilação), você negocia esse custo pelo uso da memória.

Os arquivos de arquivamento exigem o uso de manifestos, simplesmente porque o índice do arquivo é essencialmente um manifesto, para que você obtenha o comportamento gratuitamente. E se você precisar usar manifestos para ativos em um local, pode ser mais fácil insistir em que todos os ativos sejam referenciados por meio de manifestos; permitindo abstrair o local / mecanismo de armazenamento real dos ativos a partir das referências a esses ativos no código. Dessa forma, você pode ter um único tipo de referência de ativo em seu código e não fazer a distinção entre caminhos de arquivo, caminho de arquivo morto + deslocamento ou sub-ativos.

Além das outras respostas, também torna seu código um pouco mais separado dos seus ativos. Você pode, por exemplo, permitir que um artista trabalhe diretamente com os arquivos de manifesto sem precisar que um programador faça a alteração e faça uma nova compilação. Basta mudar o arquivo de manifesto para apontar para uma nova imagem e simplesmente executar o jogo novamente.

Os arquivos de manifesto fornecem uma camada de indireção entre o nome do recurso e sua localização. Muitas camadas extras de indireção são apenas um sinal de excesso de design. No entanto, às vezes essa camada extra é exatamente o que é necessário para criar uma solução elegante e eficiente.

Aqui está um exemplo concreto simples, onde a separação do nome / local do recurso me ajudou. Enquanto em desenvolvimento, meus recursos de arte estão no controle de revisão com o código-fonte. É muito conveniente e me permite iterar rapidamente. Normalmente, o nome do recurso reflete sua localização. O manifesto de desenvolvimento é muito direto.

Não quero distribuir um jogo com os ativos espalhados. Portanto, quando estiver pronto para distribuí-lo, posso facilmente compactar meus ativos em um arquivo de recurso e criar um novo manifesto.

Também os atlas de textura são uma ótima maneira de obter um pouco mais de desempenho do sistema gráfico. Os atlas são rápidos, mas é difícil trabalhar com a arte ainda em desenvolvimento. Minha solução é construir apenas o atlas no final quando estiver otimizando o jogo. Como estou usando manifestos, tudo o que preciso fazer é atualizar o manifesto para apontar para um local do atlas e, agora, o jogo está usando atlas em vez de arquivos diretos.