The resource "model" is a metaphor used to describe the location of a resource relative to other resources or relative to a specific point of reference, such as the root of a hard drive, regardless of the type of resource or how the resource is encoded. A description is the data structure and specification for a resource. The resource model encompasses absolutely everything required by your application.
For example, a true-color bitmap image resource is described by an array of RGB values. The array is the data structure and the RGB values are the description. The file itself is the resource, not the array that stores RGB values. A 3D model resource is described with arrays and lists. The arrays and lists are the data structure and the actual data, such as floating point coordinates, is the description.
A display context device, which is typically an executable resource, is described in intermediate form by c or c++ files and ultimately as machine language. Description formats are relatively abstract; a description of just about anything can be stored in both binary and ASCII format. The resource model does not need to know about the type of the resource or its method of description, only the display context device is concerned with such matters.
Content is a very broad term that is not necessarily limited to specific elements of a game. Here, content means resources. Resources are everything that is required by the game: 2D and 3D art resources, executable resources, application extension resources, and audio/video resources.
These resources are always stored in one or another form of memory, typically on a hard disk, CDROM, or in the system RAM of a playback device. Make no mistake, the resource model is a data structure, an enormous array if you will, and its design deeply affects the ultimate performance of your project and display context device such as a game engine.
The word "model" is used because the disk-based representation of content is nothing more than a model used by the display context device. The display context device doesn't actually use the resource model when the user is playing the game; it uses a copy of the resource model. Thus, the resource model is a model or template. If the resource model were a resource library or asset library, then like a real library where you take the actual book home, the display context device would use the actual resource and not a copy. This is an important difference as we'll soon see.
The resource model is important because there are many ways to create, store, modify, and activate content. A successful engineering process begins with an understanding of the problems involved and seeks to develop a consistent methodology for solving those problems. Here, in the world of simulation and entertainment, there are many problems with common threads. The resource model provides a foundation upon which to establish a powerful and clear understanding of what is typically an extraordinarily complex data structure. In turn, this understanding helps develop general solutions to a wide variety of problems that are directly related to the complexity, order, and storage issues in the resource model.
A resource model expressed as disk-based directories [DIR] and resources [RES]. This is called a "storage context resource model" because the resource model is currently stored on a hard disk or CDROM, and not in playback device memory. Each resource is a separate granule which may or may not contain additional resources or links to additional resources.
The amount of separation between the resources and inside the resources themselves is called granularity. Instead of using many separate files you could elect to use a single "megafile" that contained all the resources required. This is an essential truth of granularity: You can have as little or as much as you want, but like most things in life, balance is best. Granularity is discussed in subsequent sections.
Resources frequently reference, or are "hyperlinked" to, other resources in the resource model. For example, the display context device might reference a set of image resource files or a set of scene resource files.
In the following example, the display context device references a scene resource file. As you might imagine, the hyperlink [LINK] creates a relationship between the resources that is expressed as a dependency. The hyperlink address is set to the URI of the resource. The resource that contains the link depends on the resource to which it is linked. Here, the game executable resource, game.exe, has a dependency on the three application extension resources, three interface image resources, and five scene resources. Destroying these resources may cause the game engine to malfunction, but destroying the game engine won’t affect the resources in the least.
In the following example the first scene file, LEVEL_01.BOX, references image resources, model resources, and audio resources. Again the link address is set to the URI of the resource. Some resources cannot have any references. Windows Bitmaps [.BMP] and Windows Wave [.WAV] are examples of resources that cannot have references. This is a limitation of the data structure, not the method of description.
The actual "links" themselves are stored inside the resources. The game engine might store its links to a particular file, or the game engine might load a configuration file that stores the links.