architecture - Why use asset manifest files?

Sometimes you'll see people recommend that rather than using graphics/sound files/etc. like this...

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

... you should use a manifest file as a level of indirection instead:

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

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

What reasons would I have of taking this sort of approach? If I'm not using a compiled language, would there still be reasons to do this?

Answer

Most of the time manifest files are associated with some sort of archive file format. For instance, a JAR file in java is simply a zip file with a manifest file that lists the assets within the zip file, and where to find them. In that case the "path/to/image.png" is not a real filesystem path but is instead information on how to find the object inside a compressed archive. In addition to the disk space advantage of compression, using a file archive can improve performance because windows has a very difficult time dealing with tens of thousands of individual files in a small number of directories.

By using a manifest file of this sort you can completely abstract where a given chunk of data is coming from. Maybe your file is on a DVD, or streamed off the internet, or inside a zip file. You'll have to write some additional code to deal with these cases, but by using a manifest file your game logic doesn't have to care at all where something is loaded from.

Now, if you're using a non-compiled language this manifest file could certainly be a C# source file, but it's nice if you can easily modify what manifest file you are using at client execution time based on a registry setting or something similar. For instance, you could check during execution to see if a on-hard-drive cache exists, or if only the DVD is available. You could then switch which manifest to use depending on the available setup.