Perché usare i file manifest dell'asset?

A volte vedrai che le persone lo consigliano piuttosto che usare grafica / file audio / ecc. come questo...

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

... dovresti invece utilizzare un file manifest come livello di riferimento indiretto:

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

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

Quali ragioni dovrei avere per adottare questo tipo di approccio? Se non sto usando un linguaggio compilato, ci sarebbero ancora motivi per farlo?

Il più delle volte i file manifest sono associati a una sorta di formato di file di archivio. Ad esempio, un file JAR in Java è semplicemente un file zip con un file manifest che elenca le risorse all'interno del file zip e dove trovarle. In tal caso, "path / to / image.png" non è un percorso di file system reale ma è invece l'informazione su come trovare l'oggetto all'interno di un archivio compresso. Oltre al vantaggio dello spazio su disco della compressione, l'utilizzo di un archivio di file può migliorare le prestazioni perché Windows ha difficoltà a gestire decine di migliaia di singoli file in un piccolo numero di directory.

Utilizzando un file manifest di questo tipo è possibile estrarre completamente la provenienza di un determinato blocco di dati. Forse il tuo file è su un DVD, o trasmesso in streaming da Internet o all'interno di un file zip. Dovrai scrivere del codice aggiuntivo per affrontare questi casi, ma usando un file manifest la tua logica di gioco non deve preoccuparsi affatto da dove viene caricato qualcosa.

Ora, se stai usando un linguaggio non compilato questo file manifest potrebbe sicuramente essere un file sorgente C #, ma è bello se puoi facilmente modificare quale file manifest stai usando al momento dell'esecuzione del client basato su un'impostazione del registro o qualcosa di simile. Ad esempio, è possibile verificare durante l'esecuzione per vedere se esiste una cache sul disco rigido o se è disponibile solo il DVD. È quindi possibile cambiare quale manifest utilizzare in base alla configurazione disponibile.

Una ragione: programmazione guidata dai dati.

Il tuo codice potrebbe voler solo sapere che ha bisogno di una texture "LightWood" e lasciare che il gestore risorse utilizzi questa chiave per trovare il percorso giusto per il file. Inoltre, negli script, le persone non vogliono ricordare i percorsi dei file. Sono disordinati, possono essere errati. Lascia che il manifest risolva dove si trova il file e lascia che l'umano risolva il materiale di cui ha bisogno con il suo nome, non con il nome del file.

<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>

Come modello di progettazione generale, i manifest sono utili quando si desidera raccogliere tutte le informazioni su un insieme disparato di oggetti in un unico posto. Non deve riguardare i file di archivio / compressi o l'indirizzamento indiretto per consentire lo spostamento delle cose senza ricompilare / aggiornare i riferimenti originali. In effetti, quest'ultimo può introdurre più problemi di quanti ne risolva, quindi lo faresti solo se risolvesse un bisogno particolare che avevi.

Il grande vantaggio dei manifest è che fungono da indice per una grande quantità di dati in un unico posto compatto. Di conseguenza, migliorano le prestazioni (perché puoi semplicemente caricare l'intero manifest dal disco e tenerlo in memoria), specialmente nel caso in cui devi iterare su più oggetti, ma non sai in anticipo quali saranno quegli oggetti . Se gli oggetti sono su disco, specialmente se si trovano in più posizioni, è necessario toccare il filesystem ogni volta che si desidera scorrere i file. Per i file system basati su disco, il tempo necessario per toccare il file system è proibitivo, quindi iterare i file in una directory è un costo enorme. Pre-costruendo un manifest di file in fase di compilazione (NB: non in fase di compilazione), si scambiano i costi per l'utilizzo della memoria.

I file di archivio richiedono l'uso di manifest, semplicemente perché il sommario per l'archivio è essenzialmente un manifest stesso, in modo da ottenere il comportamento gratuitamente. E se ti viene richiesto di utilizzare i manifest per gli asset in un'unica posizione, può essere più pulito insistere sul fatto che tutti gli asset vengano referenziati attraverso i manifest; consentendoti di sottrarre l'ubicazione / meccanismo di archiviazione effettiva delle risorse dai riferimenti a tali risorse nel codice. In questo modo puoi avere un singolo tipo di riferimento di asset nel tuo codice e non devi fare distinzione tra percorsi di file, percorso del file di archivio + offset o risorse secondarie.

Oltre alle altre risposte, rende anche il tuo codice un po 'più separato dalle tue risorse. Ad esempio, potresti consentire a un artista di lavorare direttamente con i file manifest senza che un programmatore debba apportare le modifiche e creare una nuova build. Tutto ciò che serve è cambiare il file manifest in modo che punti a una nuova immagine e semplicemente esegua nuovamente il gioco.

I file manifest forniscono un livello di riferimento indiretto tra il nome della risorsa e la sua posizione. Dopo ulteriori livelli di riferimento indiretto è solo un segno di sovra design. Tuttavia, a volte quel livello aggiuntivo è proprio quello che serve per costruire una soluzione elegante ed efficiente.

Ecco un semplice esempio concreto in cui la separazione nome / posizione della risorsa mi ha aiutato. Durante lo sviluppo, le mie risorse artistiche sono sottoposte a controllo di revisione con codice sorgente. È molto conveniente e mi permette di iterare rapidamente. Di solito il nome della risorsa riflette la sua posizione. Il manifest di sviluppo è molto semplice.

Non voglio distribuire un gioco con le risorse sparse. Quindi, quando sono pronto a distribuirlo, posso facilmente comprimere le mie risorse in un file di risorse e creare un nuovo manifest.

Anche gli atlanti delle trame sono un ottimo modo per ottenere un po 'più di prestazioni dal sistema grafico. Gli atlanti sono veloci ma sono un dolore con cui lavorare mentre l'arte è ancora in fase di sviluppo. La mia soluzione è quella di costruire l'atlante alla fine solo quando sto ottimizzando il gioco. Dato che sto usando manifest, tutto quello che devo fare è aggiornare manifest per indicare una posizione dell'atlante e voilà il gioco ora utilizza atlanti invece di file semplici.