Responsabili delle risorse: sono buoni?

Ho visto molte volte nel codice sorgente, cose come questa [beh, questa è più una mia pseudo idea in C ++]

typedef shared_ptr<Resource> ResourcePtr;// for ease  
ResourcePtr sound1 = resourceManager.Get<SoundResource>("boom.ogg");  
sound1->Play();  
ResourcePtr sprite = resourceManager.Get<Image>("sprite.png");

Mi stavo solo chiedendo quanto fosse utile una classe come questa, qualcosa che:

• File multimediali caricati
• Li ha memorizzati nella memoria
• Fatto questo all'inizio di una schermata di caricamento di livello.
• Pulito

Invece di avere un sistema di:

• Le risorse sono detenute solo da entità o sciolte.
• Responsabile del proprio carico in memoria.

Il primo è un "manager" in quanto tale; qualcosa che sento indica che è sbagliato usare. Tuttavia, consente di passare qualcosa come un vettore di nomi di risorse, piuttosto che dover cercare di trovare tutto ciò che deve essere caricato.

Un buon gestore delle risorse è fondamentale per quanto bene - e quanto flessibile - sarà il tuo "motore" di gioco.

Non solo risolve molti problemi con la gestione delle risorse di basso livello, ma aiuta anche a garantire che le risorse vengano caricate una sola volta e quindi riutilizzate se sono già caricate.

Se il sistema di risorse è astratto, i dettagli sottostanti possono diffidare tra il file system, l'archiviazione di file fisici, sql anche ...

Hai solo richiesto una risorsa e ti è stata data.

Non è necessario preoccuparsi di ID risorse e cose del genere.

Duplicazione della gestione dei conflitti di risorse, ecc.

Lascia che il gestore risorse lo risolva.

A seconda di come lo progetti, se C ++ fai amicizia con le tue classi di scenemanaging per assicurarti che la proprietà sia gestita correttamente.

Pool di risorse?

Nessun problema.

Dimenticando di rilasciare risorse?

Nessun problema.

Stessa interfaccia con le risorse, indipendentemente da dove si trovino: memoria, disco, archivio, rete.

Nessun problema.

Vuoi lo streaming?

Threading?

Lascia che il tuo hub di gestione delle risorse se ne occupi.

E puoi stare certo che ti informerà quando le risorse sono pronte per essere utilizzate.

Ogre 3D ha un sistema di gestione delle risorse molto flessibile, ma sono sicuro che ce ne sono altri "là fuori".

Di recente ho scritto un gestore delle risorse che funziona abbastanza bene per il mio caso. Caratteristiche principali:

• Le risorse sono richieste dall'ID stringa, ad esempio ResourceManager::instance().getTexture("textures/player.png"). L'ID trama è attualmente mappato direttamente a un file su disco, il che è utile durante lo sviluppo, ma questo verrà successivamente sostituito dalla ricerca in alcuni archivi.

• Il gestore risorse mantiene una mappa di ID e risorse, quindi non ricarica una risorsa che è già stata caricata.

• La chiamata sopra non restituisce un Textureoggetto, ma piuttosto un Resource<Texture>oggetto; il chiamante dovrebbe memorizzare l' Resource<Texture>oggetto e non la trama reale. Si Resource<Texture>comporta come un puntatore intelligente a Texture; le sue operator*()dichiarazioni l' Textureoggetto stesso. Il vantaggio è che la trama reale può essere ricaricata o scaricata, senza la necessità di aggiornare tutti i client.

• Il gestore risorse verifica periodicamente se i file sul disco sono stati modificati e li ricarica, se necessario. Questo mi permette di modificare trame o shader e vedere il risultato senza nemmeno riavviare il gioco.

• Le risorse possono dipendere l'una dall'altra. La maggior parte, se non tutte, le risorse dipendono da una Filerisorsa, che è il file da cui sono state caricate. Se, ad esempio, un modello dipende da una trama, il modello verrà ricaricato ogni volta che il file della trama cambia sul disco.

• Quando non è possibile trovare una risorsa o non è possibile caricarla, viene sostituita automaticamente una risorsa predefinita. Questo mi consente di utilizzare risorse che non ho ancora creato, senza interrompere il gioco. (Funzionalità pianificata: indica risorse "essenziali" come gli shader GPGPU, senza i quali il gioco non può funzionare correttamente.)

• Il conteggio dei riferimenti e lo scarico di risorse non utilizzate possono essere aggiunti facilmente. Dato che il mio gioco è piuttosto piccolo, non ne ho ancora avuto bisogno.

Penso che questo elenco di funzionalità mostri che, sì, i gestori delle risorse possono essere bravi!

Uno dei motivi per avere un gestore delle risorse è la condivisione delle risorse. Ad esempio, quando si chiama resourceManager.Get("sprite.png"), se "sprite.png" è già caricato, il gestore delle risorse può semplicemente restituire un puntatore alla risorsa sprite già caricata anziché creare una nuova immagine e ricaricarla dal disco.

Un gestore risorse può anche memorizzare nella cache le risorse, in modo che sebbene sia stato eliminato l'ultimo riferimento a una risorsa, il gestore delle risorse può scegliere di mantenerlo in memoria nel caso in cui venga caricato di nuovo nel prossimo futuro. Il gestore risorse sarebbe programmato per gestire automaticamente tutta la gestione della memoria con le tue risorse.

Infine, penso che una caratteristica molto utile sia il ricaricamento di risorse nel gioco. Poiché il gestore delle risorse gestisce tutte le risorse del gioco, puoi creare una funzione che consente di ricaricare tutte le risorse dal disco e di aggiornare il gioco in tempo reale, il che è estremamente utile per gli artisti / designer che lavorano con il tuo gioco .

Un altro vantaggio è, oltre alla memorizzazione nella cache e al conteggio dei riferimenti, che è in grado di gestire le dipendenze (modello a ha bisogno della trama b? Lo prenderò per te!) E caricare problemi di ordine (modello a deve sapere cosa richiede lo shader b? Fammi caricare shader b prima di caricare il modello!)