Gerentes de recursos - eles são bons?

Eu já vi muitas vezes no código fonte, coisas assim [bem, isso é mais uma ideia pseudo C ++ minha]

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

Eu só estava me perguntando o quão útil uma classe como essa era, algo que:

• Arquivos de mídia carregados
• Armazenou-os na memória
• Fiz isso no início de uma tela de carregamento de nível.
• Limpo

Em vez de ter um sistema de:

• Os recursos são mantidos apenas por entidades ou estão soltos.
• Responsável pela própria carga na memória.

O primeiro é um 'gerente' como tal; algo que sinto indica que é errado usar. No entanto, ele permite que algo como um vetor de nomes de recursos seja passado, em vez de ter que procurar por tudo o que precisa ser carregado.

Um bom gerenciador de recursos é a chave para o quão bem - e quão flexível - o 'mecanismo' do seu jogo será.

Ele não apenas resolve muitos problemas com o gerenciamento de recursos de baixo nível, mas também ajuda a garantir que os recursos sejam carregados apenas uma vez e depois reutilizados se já estiverem carregados.

Se o sistema de recursos for bem abstraído, os detalhes subjacentes podem ser cautelosos entre sistema de arquivos, armazenamento physfs, sql e até ...

Você acabou de solicitar um recurso, e ele é fornecido a você.

Não precisa se preocupar com identificações de recursos e coisas assim.

Tratamento duplicado de conflitos de recursos, etc.

Deixe o gerente de recursos resolver isso.

Dependendo de como você o projeta - se o C ++, faça amizade com as classes de gerenciamento de cena para garantir que a propriedade seja tratada adequadamente.

Pool de recursos?

Sem problemas.

Esquecendo de liberar recursos?

Sem problemas.

A mesma interface para os recursos, não importa onde eles estejam: memória, disco, arquivo, rede.

Sem problemas.

Você quer transmitir?

Rosqueamento?

Deixe seu hub de gerenciamento de recursos cuidar disso.

E você pode ter certeza de que ele informará quando os recursos estiverem prontos para serem usados.

O Ogre 3D possui um sistema de gerenciamento de recursos muito flexível, mas tenho certeza de que existem outros 'por aí'.

Recentemente, escrevi um gerenciador de recursos que funciona muito bem para o meu caso. Principais características:

• Os recursos são solicitados pelo ID da sequência, por exemplo ResourceManager::instance().getTexture("textures/player.png"),. No momento, o ID da textura é mapeado diretamente para um arquivo no disco, o que é conveniente durante o desenvolvimento, mas isso será substituído posteriormente pela pesquisa em algum arquivo.

• O gerenciador de recursos mantém um mapa de IDs nos recursos, para não recarregar um recurso que já foi carregado.

• A chamada acima não retorna um Textureobjeto, mas um Resource<Texture>objeto; o chamador deve armazenar o Resource<Texture>objeto e não a textura real. O Resource<Texture>age como um ponteiro inteligente a um Texture; seus operator*()retornos do Texturepróprio objeto. A vantagem é que a textura real pode ser recarregada ou descarregada, sem a necessidade de atualizar todos os clientes.

• O gerenciador de recursos verifica periodicamente se os arquivos no disco foram alterados e os recarrega, se necessário. Isso me permite modificar texturas ou shaders e ver o resultado sem nem mesmo reiniciar o jogo.

• Os recursos podem depender um do outro. A maioria dos recursos, se não todos, depende de um Filerecurso, que é o arquivo do qual eles foram carregados. Se, por exemplo, um modelo depender de uma textura, ele será recarregado sempre que o arquivo da textura for alterado no disco.

• Quando um recurso não pode ser encontrado ou falha ao carregar, um recurso padrão é substituído silenciosamente. Isso me permite usar recursos que ainda não criei, sem travar o jogo. (Recurso planejado: indica recursos "essenciais", como shaders de GPGPU, sem os quais o jogo não pode ser executado adequadamente.)

• A contagem de referência e o descarregamento de recursos não utilizados podem ser adicionados facilmente. Como meu jogo é bem pequeno, ainda não precisei disso.

Eu acho que essa lista de recursos mostra que sim, os gerenciadores de recursos podem ser bons!

Um dos motivos para ter um gerenciador de recursos é o compartilhamento de recursos. Por exemplo, quando você chama resourceManager.Get("sprite.png"), se "sprite.png" já estiver carregado, o gerenciador de recursos pode simplesmente retornar um ponteiro para o recurso sprite já carregado, em vez de criar uma nova imagem e recarregá-la do disco.

Um gerenciador de recursos também pode armazenar em cache recursos, de modo que, embora a última referência a um recurso tenha sido descartada, o gerenciador de recursos pode optar por mantê-lo na memória, caso seja carregado novamente no futuro próximo. O gerenciador de recursos seria programado para lidar automaticamente com todo o gerenciamento de memória com seus recursos.

Finalmente, acho que um recurso muito útil é a recarga de recursos no jogo. Como o gerenciador de recursos mantém identificadores para todos os recursos dos jogos, você pode criar uma função que faça com que todos os recursos sejam recarregados do disco e atualize o jogo em tempo real, o que é extremamente útil para artistas / designers que trabalham com seu jogo .

Outro benefício é que, além do cache e da contagem de referência, ele pode lidar com dependências (o modelo a precisa da textura b? Vou buscá-lo para você!) E carregar problemas de ordem (o modelo a precisa saber o que o shader b requer? Deixe-me carregar o shader b antes de carregar o modelo!)