Я всегда думал, что хороший менеджер активов должен иметь несколько режимов работы. Эти режимы, скорее всего, будут отдельными исходными модулями, придерживающимися общего интерфейса. Два основных режима работы:
- Режим производства - все активы являются локальными и лишены всех метаданных
- Режим разработки - оценки хранятся в базе данных (например, MySQL и т. Д.) С дополнительными метаданными. База данных будет двухуровневой системой с локальной базой данных, кеширующей общую базу данных. Создатели контента смогут редактировать и обновлять общую базу данных, а обновления автоматически распространяются на системы разработчика / QA. Также должна быть возможность создавать заполнитель контента. Поскольку все находится в базе данных, к базе данных можно делать запросы и генерировать отчеты для анализа состояния производства.
Вам понадобится инструмент, который может собрать все оценки из общей базы данных и создать производственный набор данных.
За годы моей работы в качестве разработчика я никогда не видел ничего подобного, хотя я работал только на несколько компаний, поэтому мое мнение не является действительно представительным.
Обновить
ОК, некоторые отрицательные голоса. Я подробно остановлюсь на этом дизайне.
Во-первых, вам не нужны фабричные классы, потому что если у вас есть:
TextureHandle tex = pRm->getResource<Texture>( "test.otx" );
вы знаете тип, так что просто сделайте:
TextureHandle tex = new TextureHandle ("test.otx");
но то, что я пытался сказать выше, это то, что вы в любом случае не будете использовать явные имена файлов, текстура для загрузки будет определяться моделью, в которой используется текстура, так что вам на самом деле не нужно удобочитаемое имя, это может быть 32-разрядное целочисленное значение, которое процессору гораздо проще обрабатывать. Итак, в конструкторе для TextureHandle у вас будет:
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 1
AssetStream использует параметр resource_id, чтобы найти местоположение данных. То, как это будет сделано, будет зависеть от среды, в которой вы работаете:
В разработке: поток ищет идентификатор в базе данных (например, с использованием SQL), чтобы получить имя файла, а затем открывает файл, файл может быть кэширован локально или извлечен с сервера, если локальный файл не существует или является устаревший.
В выпуске: поток ищет идентификатор в таблице ключ / значение, чтобы получить смещение / размер в большом упакованном файле (например, в файле WAD в Doom).