So what is the idea behind resource management? Well we’re writing a game, which as software goes, has rather a lot of resources to be managed. Textures. Models. Sounds. Music. Player save files. It seems to me that we have three options, and here they are in order of increasing usefulness.
1. Manage all resources as we go: if we need an image, type all the loading code for an image; if we need another, type it again. This is the easiest solution, and might be fine for small projects. But since we’re trying to write a reusable engine which is hopefully applicable to larger projects, it just won’t do. (Also, we’d have to be very careful to be sure we unloaded all the resources at the end when we’re done with them.)
2. Write manager classes: one to manager images, one to manage sounds and so forth. Clearly, this is better than option 1. We can save on typing by putting the loading code into a reusable member function. We can also add some nice extras like prevention of multiple loading of the same resource, referring to resources by string IDs, and automatic unloading of resources at shutdown time.
3. Number 2 is nice, but there’s still some code redundancy remaining. What’s the difference between managing sound resources and image resources? Just the loading (and unloading) process. All management that goes on in between is pretty much the same. Thus our final option: a generic resource manager – a single class which can be used for managing images, sounds, music, you name it! If it can be loaded and unloaded, our manager will handle it!
In fact, there are going to be several resource managers, since I have two designs in mind, along with a subtle tweak to one of them. But more of that in the next post: for now I just wanted you to know the motivation for generic resource management methods.
There’s one other thing I just want to remark on now: the structure of my posts regarding each engine component. For each one, I shall release the following components in this order:
- An article discussing the features of the component, without any actual code
- A “code summary” post showing some or all of the header file for the class, to demonstrate its intended public interface
- An “implementation” post in which I not only provide all the code, but also detailed descriptions as to how it works
- A “usage” post, with a simple (but often contrived) example to show you how I intend the component to be used
- A “testing/debugging” post in which we write another sample which tests the component’s behaviour in every different situation we can think of
- A “samples” post in which I give some more useful examples of usage
- A summary post, with a brief textual summary of the component’s purpose, plus a copy of it’s public interface
That’s all for now. The next post on resource management will be an article on my first resource management construct, but before then there might be some posts about video tutorials and setting up SFML 2.0 in various IDES.
