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

Design and Theory

I'm sure you're quite worked up about jumping in and implementing a resource file management library, and heck, so am I! But first, we must go over some design issues. I will use the term "lump" to refer to a data item within a resource file; thus, a lump can be an image, or a game object, or any piece of data we may stick in a resource file. Also, when I talk of an interfacing API, I mean a front-end API that can be used to manage resource files. Now, in general, the structure of a resource file can be broken up into three sections: the header, the data lump information table, and the actual data lump section. The header section of a resource file contains general information about the file; for instance, the number of data lumps within the resource file, the location of the Lump Information Table within the file, and a means for identifying resource files from other file types. The Header section is critical because it provides the interfacing API with the information required in order loading the file in from disk. The Lump Information Table section of the resource file contains information about each data lump within the file. The information stored about each lump might entail it's position and size within the file, as well as it's name or identification medium. For each Data Lump in the resource file, there is one corresponding entry or node in the Lump Info Table; thus, the Info Table is a list of nodes where each node corresponds to and contains information about a particular Data Lump. The Data Lump Section is the section in the resource file where the data for each Data Lump is actually stored. The lumps are generally stored in a linear fashion such that the data for "Lump One" is to be located first, the data for "Lump Two" is to be found next, and so on. These data lumps may be compressed or encrypted depending upon the file format implementation desired by the programmer. However, I should mention the position of each of these sections within the file. For a few reasons that will later become apparent, we will position the Data Lump Info Table at the end of the file, having the actual data lump section in the middle. We do this because it is much more efficient to do so, if we didn't do this, we'd end up doing multiple passes during the save process. Anyway, as we now have the general structure of how we're going to set up our files, we'll discuss our interfacing API that we must design.

So, what do we need in a resource file management library? Well, the interface must be elegant and intuitive, whilst at the same time providing enough flexibility and scalability to deem it as reusable. Well, let's first discuss the user-friendly interface, then we'll talk about scalability. So, what sort of functionality are we going to need? We should provide routines for quick creation, modification, and clean up; hence, we'll need three routines for opening, saving, and closing resource files. We must also provide some routines for managing lumps; this will consist of routines for creating, deleting, modifying, loading, and unloading data lumps. Those are the basic routines we'll need; although, some extra routines for error checking and for displaying information about a resource file wouldn't hurt - but what about flexibility and scalability?

Indeed, this is something that we must take into consideration if we're going to use our resource file management library more than once. Basically, we should provide some means of being able to handle different data lump types within our manager. But how are we going to accomplish this? It's all quite simple really – we'll create a lump handler system. A lump handler will consist of three low-level routines, all for managing a particular data lump type. These routines would allow the interfacing API to load, to save, and to unload a particular data type. So, what we would do is create a lump handler for managing a bitmap lump type, a second handler for managing sound lumps, and so on. The interfacing API would then look at a lump, figure out which lump handler to use, and call the correct routines. In order to provide scalability, we should allow a programmer to create his or her very own custom lump handlers and allow the lump handler to be added to the lump-handling list on the fly. So, we'll need two more routines within our interfacing API: one to add a lump handler, another to remove a handler. Because we'll using OOP and C++ to implement our resource file management library, a lump handler will be an object that will be used by the resource file management class. Anyway, now that we have an outline of what we're going to need to do in order to get a good implementation happening, let's actually implement this baby!

Next : Implementation