Навіщо використовувати файли маніфестів активів?

Іноді ви побачите, що люди рекомендують це замість використання графічних / звукових файлів / тощо. подобається це...

// 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-файлі та де їх знайти. У цьому випадку "шлях / до / 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>

Як загальна схема дизайну, маніфести корисні, коли потрібно зібрати всю інформацію про розрізнений набір об’єктів в одне місце. Це не повинно стосуватися архівів / упакованих файлів або непрямості, щоб дозволити переміщення речей без перекомпіляції / оновлення оригінальних посилань. Дійсно, остання може створити більше проблем, ніж вирішує, тож ви зробите це лише в тому випадку, якщо це вирішить ту чи іншу потребу, яку ви мали.

Велика перевага маніфестів полягає в тому, що вони діють як покажчик великої кількості даних в одному компактному місці. Як такі вони покращують продуктивність (тому що ви можете просто завантажити весь маніфест з диска і зберегти його в пам'яті), особливо в тому випадку, коли вам потрібно повторити кілька об'єктів, але ви не знаєте заздалегідь, що будуть ці об'єкти . Якщо об’єкти знаходяться на диску, особливо якщо вони знаходяться в декількох місцях, вам потрібно торкатися файлової системи щоразу, коли ви хочете переглядати файли. Для файлових систем на основі диска час, необхідний для торкання файлової системи, є непомірним, тому ітерація файлів у каталозі - це величезна вартість. Заздалегідь будуючи маніфест файлів під час збирання (зверніть увагу: не час компіляції), ви торгуєте цією витратою на використання пам'яті.

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

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

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

Ось простий конкретний приклад, коли мені допомогли розділення назви ресурсів / місцезнаходження. У процесі розробки мої художні активи знаходяться під контролем редагування з вихідним кодом. Це дуже зручно і дозволяє мені швидко повторити. Зазвичай назва ресурсу відображає його місцезнаходження. Маніфест розвитку дуже прямий вперед.

Я не хочу розповсюджувати гру з активами, розкиданими навколо. Тож коли я готовий розповсюдити його, я можу легко зафіксувати свої активи у файлі ресурсів та створити новий маніфест.

Також текстурні атласи - це чудовий спосіб вивести трохи більшу продуктивність із графічної системи. Атласи швидкі, але з ними болісно працювати, поки мистецтво ще розвивається. Моє рішення - будувати атлас лише в кінці, коли я оптимізую гру. Оскільки я використовую маніфести, все, що мені потрібно зробити, - це оновити маніфест, щоб вказати на розташування атласу і voilà, тепер гра використовує атласи замість прямих файлів.