Contents  Introduction  Resource Files In  Depth  Design and Theory  Implementation  For the Future  Printable version

Resource Files In Depth

Almost everywhere you look you will see some form of a resource file in use – perhaps even unknowingly. You may be wondering if resource files are in fact database files, and indeed, they are. Nevertheless, we still use the term "resource file" to discern between the two: a database usually keeps track of similar items of data, whereas a resource file has the ability of storing dissimilar items of data. Keeping this concept in mind, we can see that resource files are used by a great number of computer games as well as applications. Let's look at a couple specific examples of resource files in use. The "Zip File" archiving file format, in wide use today, is a great illustration of what a resource file is supposed to be. It can take multiple individual files and store them internally in a single file. Additionally, you have the option of compressing the files you add to a Zip file for optimum storage and transference. This is a good example because it shows you that you can take the data you want to add to a resource file and mutate it for the better without destroying it. Another example we'll look at is the WAD file format used by id Software in the Doom engine. The file format allowed the various items of game data to be stored in a single file – this included images, sprites, sounds, music, map data, and the likes. This will be the type of resource file format that we'll be most interested in, although we will implement our own original file format. Nonetheless, this will be that path that we take.

So, why do we even want to go through all the trouble of implementing resource files in our games or game engines? Why not just have all of the individual files located in a number of sub-directories within the directory of our game? Here, I will explain the reasons behind wanting to use resource files to store data for games. Obviously, being able to easily manage multiple items of data was an advantage we already discussed. Without resource files, and in a game where there is a lot of external data (images, sounds, etc.), you would have to store the data as individual files in a complex directory structure. This can amount to a huge mess that is almost impossible to manage and to keep up to date. With resource files, all of your data is located in one or a couple of large resource files – all of the data is there, elegantly encapsulated within a single construct. Additionally, one cannot go on without mentioning the professional "look" that resource files provide – this is a big plus. But, is there another advantage to having all of the files located within a resource file? Indeed, there is and it happens to be something very important - security. Without using resource files, most of the game data would be located out in the open, and most likely in it's native format. This would allow any average Joe, who happened to have your product installed, to modify, replace, or pirate the game data. In many cases, this is rather undesirable. When the data is in a resource file, the end user of your software has greater difficulty getting access to the individual items of data; of course, anyone can get access to data in a resource file with a fair amount of hackin' effort. However, having your data located within a resource file acts as a slight deterrent against this sort of activity. Also, when using resource files you can add additional security support. For instance, you may want to add a form of checksum error checking where you would make sure the size of each lump or the data itself hasn't changed; this would be protection against illegal modification of the data by adding, removing, and modifying bytes. Even though you may decide to restrict the access of the data in your resource files, many people ship game editors with their products anyway. Regardless, you can still restrict unofficial modification of the file.

The question we must ask our selves now is "should we go through all of the trouble of implementing a resource file format?" Sure, you can also tackle security issues by creating your own file formats for the individual types of data like images, sounds, and on and on – plus, you can get around the complex directory structure problem. So, is there another reason for using resource files? The answer is undeniably yes. Due to the inefficiency of the file systems used by Windows and DOS (FAT16 and FAT32), a lot of disk space is lost. In the FAT16 file system, each file block takes up a minimum of 32KB; therefore, if you had a file that was 2KB in size, it in reality would take up 32KB. Of course, the FAT32 file system is much better, but it still isn't perfect. Anyway, when using resource files, all of the data is packed together, allowing for more efficient disk space usage.

Now, if those aren't good enough reasons for using resource files for storing data for your games, I don't know what is! Of course, there are a couple of disadvantages to using resource files. The first such disadvantage is that of requiring more time and effort to implement a good resource file manager. But once you have your implementation up and running, it's smooth riding from there on. The second disadvantage is that of requiring more memory to operate – you must use up a fair amount of RAM when working with resource files. Nonetheless, this is a trivial problem, especially considering that most PC's now ship with at least 64 megabytes of RAM. It is quite lucidly apparent that the advantages most certainly out-weigh the disadvantages – so what are we waiting for! Let's begin our adventure into the technical side of resource files.

Next : Design and Theory