Qual è l'approccio migliore alla progettazione di un AssestManager che conterrà riferimenti alla grafica, ai suoni, ecc. Di un gioco?
Queste risorse devono essere archiviate in una coppia di mappe chiave / valore? Cioè chiedo asset "di sfondo" e la mappa restituisce la bitmap associata? C'è un modo ancora migliore?
In particolare sto scrivendo un gioco Android / Java, ma le risposte possono essere generiche.
Risposte:
Dipende dall'ambito del tuo gioco. Un gestore patrimoniale è assolutamente essenziale per titoli più grandi, meno per giochi più piccoli.
Per i titoli più grandi devi gestire problemi come i seguenti:
Per i titoli più piccoli queste cose sono meno problematiche, quadri come XNA hanno gestori patrimoniali al loro interno - non ha molto senso reinventarlo.
Se ti accorgi che hai bisogno di un gestore patrimoniale, non esiste davvero una soluzione unica per tutti, ma ho scoperto che una mappa hash con la chiave come hash * del nome file (abbassata e separatori tutti 'fissi') funziona bene per i progetti a cui ho lavorato.
Di solito non è consigliabile codificare i nomi dei file nella tua app, di solito è meglio avere un altro formato di dati (come xml) che descriva i nomi dei file in "ID".
(Cercando di evitare la discussione "non usare un gestore patrimoniale" qui, poiché lo considero offtopico.)
Una mappa chiave / valore è un approccio molto utilizzabile.
Abbiamo un'implementazione di ResourceManager in cui è possibile registrare fabbriche per diversi tipi di risorsa.
Il metodo "getResource" utilizza i modelli per trovare la Factory corretta per il tipo di risorsa desiderato e restituisce uno specifico ResourceHandle (usando nuovamente il modello per restituire uno SpecificResourceHandle).
Le risorse vengono ricontattate da ResourceManager (all'interno di ResourceHandle) e rilasciate quando non sono più necessarie.
Il primo addon che abbiamo scritto è stato il metodo "ricaricare (XYZ)", che ci consente di cambiare le risorse dall'esterno del motore in esecuzione senza cambiare alcun codice o ricaricare il gioco. (Questo è essenziale quando gli artisti lavorano su console;))
Il più delle volte abbiamo solo un'istanza di ResourceManager, ma a volte creiamo una nuova istanza solo per un livello o una mappa. In questo modo possiamo semplicemente chiamare "shutdown" sul levelResourceManager e assicurarci che non vi siano perdite.
// very abbreviated!
// this code would never survive our coding guidelines ;)
ResourceManager* pRm = new ResourceManager;
pRm->initialize( );
pRm->registerFactory( new TextureFactory );
// [...]
TextureHandle tex = pRm->getResource<Texture>( "test.otx" ); // in real code we use some macro magic here to use CRCs for filenames
tex->storeToHardware( 0 ); // channel 0
pRm->releaseResource( pRm );
// [...]
pRm->shutdown(); // will log any leaked resourceLe classi di Manager dedicati non sono quasi mai lo strumento di ingegneria giusto. Se hai bisogno dell'asset una sola volta (come uno sfondo o una mappa), dovresti richiederlo solo una volta e lasciarlo morire normalmente quando hai finito con esso. Se è necessario memorizzare nella cache un particolare tipo di oggetto, è necessario utilizzare una factory che prima controlla una cache e carica altrimenti qualcosa, la mette nella cache e quindi la restituisce - e quella factory può essere solo una funzione statica che accede a una variabile statica , non un tipo a sé stante.
Steve Yegge (tra molti, molti altri) ha scritto una bella storia su come inutili classi manageriali, attraverso il modello singleton, finiscano per essere. http://sites.google.com/site/steveyegge2/singleton-considered-stupid
Ho sempre pensato che un buon gestore patrimoniale dovrebbe avere diverse modalità operative. Molto probabilmente queste modalità sarebbero moduli sorgente separati che aderiscono a un'interfaccia comune. Le due modalità operative di base sarebbero:
Avresti bisogno di uno strumento in grado di catturare tutti i test dal database condiviso e creare il set di dati di produzione.
Nei miei anni come sviluppatore, non ho mai visto nulla di simile, anche se ho lavorato solo per una manciata di aziende, quindi il mio punto di vista non è davvero rappresentativo.
Aggiornare
OK, alcuni voti negativi. Espanderò su questo disegno.
In primo luogo, non hai davvero bisogno delle classi di fabbrica perché se hai:
TextureHandle tex = pRm->getResource<Texture>( "test.otx" );conosci il tipo, quindi basta:
TextureHandle tex = new TextureHandle ("test.otx");ma poi, quello che stavo cercando di dire sopra è che non avresti comunque usato nomi di file espliciti, la trama da caricare sarebbe specificata dal modello su cui la trama è usata, quindi in realtà non hai bisogno di un nome leggibile dall'uomo, potrebbe essere un valore intero a 32 bit, che è molto più facile da gestire per la CPU. Quindi, nel costruttore di TextureHandle avresti:
if (texture already loaded)
update texture reference count
else
asset_stream = new AssetStream (resource_id)
asset_stream->ReadBytes
create texture
set texture ref count to 1AssetStream utilizza il parametro resource_id per trovare la posizione dei dati. Il modo in cui lo ha fatto dipenderà dall'ambiente in cui si esegue:
In sviluppo: lo stream cerca l'ID in un database (usando SQL per esempio) per ottenere un nome file e quindi apre il file, il file potrebbe essere memorizzato nella cache locale o estratto da un server se il file locale non esiste o è obsoleto.
Nella versione: lo stream cerca l'ID in una tabella chiave / valore per ottenere un offset / dimensione in un file grande e compresso (come il file WAD di Doom).
Quello che mi piace fare per le risorse è creare un gestore di capitale . Ispirati dal motore Doom, i grumi sono pezzi di dati che contengono risorse, memorizzati in un file di grumi che dichiara i nomi dei grumi, le lunghezze, il tipo (bitmap, suono, shader, ecc.) E il tipo di contenuto (file, un altro grumo, all'interno il file lump stesso). All'avvio, questi grumi vengono inseriti in un albero binario, ma non ancora caricati. Ogni mappa (che è anche un nodulo) ha un elenco di dipendenze, che sono semplicemente i nomi di noduli che la mappa deve funzionare. Questi grumi, a meno che non siano già stati caricati, vengono caricati al momento del caricamento della mappa. Inoltre, i grumi delle mappe adiacenti della mappa vengono caricati, non solo allo stesso tempo, ma quando il motore è al minimo per qualche motivo. Questo può rendere le mappe senza soluzione di continuità e non esiste una schermata di caricamento.
Il mio metodo è perfetto per le mappe del mondo aperto, ma un gioco basato su livelli non trarrà beneficio dalla continuità di questo metodo. Spero che sia di aiuto!