Зачем использовать файлы манифеста активов?

Иногда вы увидите, что люди рекомендуют это вместо использования графических / звуковых файлов и т. Д. как это...

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

... вы должны использовать файл манифеста в качестве уровня косвенности:

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

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

Какие у меня были бы причины для такого подхода? Если я не использую скомпилированный язык, будут ли еще причины делать это?

Большинство файлов манифеста времени связаны с каким-то форматом архивных файлов. Например, JAR-файл в java - это просто zip-файл с файлом манифеста, в котором перечислены ресурсы внутри zip-файла и где их найти. В этом случае «path / to / image.png» не является реальным путем к файловой системе, а представляет собой информацию о том, как найти объект в сжатом архиве. В дополнение к преимуществу сжатия на диске, использование файлового архива может повысить производительность, поскольку Windows очень трудно справляться с десятками тысяч отдельных файлов в небольшом количестве каталогов.

Используя файл манифеста такого рода, вы можете полностью абстрагироваться от источника данных. Может быть, ваш файл находится на DVD-диске, или передан из Интернета, или внутри zip-файла. Вам придется написать некоторый дополнительный код, чтобы справиться с этими случаями, но при использовании файла манифеста вашей игровой логике совсем не нужно заботиться о том, откуда что-то загружается.

Теперь, если вы используете не скомпилированный язык, этот файл манифеста, безусловно, может быть исходным файлом C #, но было бы хорошо, если вы можете легко изменить, какой файл манифеста вы используете во время выполнения клиента, основываясь на параметре реестра или чем-то подобном. Например, вы можете проверить во время выполнения, чтобы увидеть, существует ли кэш на жестком диске или доступен только DVD. Затем вы можете выбрать, какой манифест использовать в зависимости от доступных настроек.

Одна из причин: программирование на основе данных.

Возможно, ваш код хочет знать, что ему нужна текстура LightWood, и пусть менеджер ресурсов использует этот ключ, чтобы найти правильный путь к файлу. Более того, в сценариях люди не хотят запоминать пути к файлам. Они грязные, они могут быть неверными. Пусть манифест определит, где находится файл, и пусть человек определит, какой материал ему нужен, по его имени, а не по имени файла.

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

Как общий шаблон проектирования, манифесты полезны, когда вы хотите собрать всю информацию о разрозненном наборе объектов в одном месте. Это не должно быть о архивных / упакованных файлах, или о косвенности, чтобы позволить вещам быть перемещены без перекомпиляции / обновить оригинальные ссылки. Действительно, последний может создать больше проблем, чем решает, так что вы сделаете это только в том случае, если он решит конкретную вашу потребность.

Большое преимущество манифестов заключается в том, что они выступают в качестве указателя для большого количества данных в одном компактном месте. Таким образом они улучшают производительность (потому что вы можете просто загрузить весь манифест с диска и сохранить его в памяти), особенно в том случае , когда вам нужно перебрать несколько объектов, но вы не знаете заранее , что эти объекты будут . Если объекты находятся на диске, особенно если они находятся в разных местах, вы должны коснуться в файловой системе каждый раз , когда вы хотите перебрать файлы. Для файловых систем дисков на основе, время , необходимое , чтобы коснуться файловой системы непомерно высока, поэтому итерация файлов в каталоге , это огромная стоимость. Предварительно создавая манифест файлов во время сборки (примечание: не время компиляции), вы обмениваете эти затраты на использование памяти.

Архивные файлы требуют использования манифестов, просто потому что оглавление для архива по сути является самим манифестом, так что вы получаете поведение бесплатно. И если от вас требуется использовать манифесты для активов в одном месте, может быть лучше настаивать на том, чтобы на все активы ссылались через манифесты; позволяет вам абстрагировать фактическое место хранения / механизм активов от ссылок на эти активы в коде. Таким образом, в вашем коде может быть один тип ссылки на актив, и вам не нужно будет различать пути к файлам, путь к архивному файлу + смещение или подэлементы.

В дополнение к другим ответам, он также делает ваш код немного более отделенным от ваших ресурсов. Например, вы можете разрешить художнику работать непосредственно с файлами манифеста, не требуя от программиста внесения изменений и создания новой сборки. Все, что нужно, это изменить файл манифеста, чтобы указать на новое изображение, и просто запустить игру снова.

Файлы манифеста обеспечивают уровень косвенности между именем ресурса и его местоположением. Следующие дополнительные слои косвенности являются лишь признаком чрезмерного дизайна. Однако иногда этот дополнительный слой - это то, что нужно для создания элегантного и эффективного решения.

Вот простой конкретный пример, где разделение имени ресурса и местоположения помогло мне. В процессе разработки мои художественные активы находятся в процессе контроля версий с исходным кодом. Это очень удобно и позволяет быстро выполнять итерации. Обычно имя ресурса отражает его местоположение. Манифест развития очень прост.

Я не хочу распространять игру с разбросанными ресурсами. Поэтому, когда я буду готов распространять его, я могу легко заархивировать свои ресурсы в файл ресурсов и создать новый манифест.

Кроме того, текстурные атласы являются отличным способом повысить производительность графической системы. Атласы быстрые, но с ними трудно работать, пока искусство находится в стадии разработки. Мое решение состоит в том, чтобы создать атлас только в конце, когда я оптимизирую игру. Поскольку я использую манифесты, все, что мне нужно, это обновить манифест, чтобы он указывал на местоположение атласа, и вуаля, теперь игра использует атласы вместо прямых файлов.