It’s a great example, though, of the kind of results we’ll see as more people with classic art and graphic design backgrounds (with a sprinkling of programming experience) are brought into the gamedev fold. The in-development footage on his sight is hauntingly beautiful, and an inspiration to say the least. Makes me remember those first few hours playing Out of this World, still one of the few games to deliver so much on so little.

Speaking of Out of this World, I’ve always thought it’d be awesome to see that game remade in Flash (it’s largely rotoscoped with a vector-like graphic style, very applicable to Flash development). Hell, if it fit on a 1.44MB floppy and ran on a 286, surely it can run full-speed in Flash on a modern day machine? Those are the kind of side-scrollers people need to be making… there’s a lot of life left in that very simple mechanic! (And the side-scroller view? Well, that aesthetic has worked for “comics” for a hundred years.)

I’m going to define a resource manager as needing to have the following qualities:

• Provide universal access to all modules needing to retrieve externally persisted data (resources).
• Ensure that resources exists as a single, shared instance in memory.
• Ensure that resources are properly garbage-collected as necessary.
• Allow resources to be retrieved/referenced by unique key.

These requirements immediately evoke several classic design patterns that we should be leveraging. First, the universal access requirement means that the resource manager should be a singleton. Second, the two requirements of shared instance and garbage-collected means smart pointers. Finally, retrieving by unique key smells of some variation on the factory method.

The current implementation I’m playing with is based off of templates. The two key template parameters are the resource’s type and the unique key’s type. My implementation could also be thought of as a specialization of the std::map to automatically construct an object if it doesn’t exist in the map. Here’s an example of how a resource is retrieved:

Texture *texture = Resources<Texture>::Get("mytexture.tga");
Mesh *mesh = Resources<Mesh, int>::Get(37);

The first method is using a const char * as the unique key (this is the default type for the template) and the second is using an int as the unique key. Either can be useful. The only drawback to making this a template parameter is that you cannot mix them; in other words, resources retrieved by string are managed separately (and are considered unique from) resources retrieved by integer.

I’m also debating whether the resource manager should have its singleton aspect factored out of it. In this scenario, we could have local resource managers of the following form:

Resources<Texture> localResMgr;
Texture *texture = localResMgr.Get("mytexture.tga");

This may be desirable in reusing the code for internal resource management inside of particular sub-systems.

Another aspects of the resource manager is the desire to register resource creators. Creators are invoked when a resource is first accessed. The canoncial creator is one that uses an existing API to load a resource (for example, a text file creator simply creates a buffer filled with the contents of the text file, basically a giant string). My template above also allows the user to specify a creator functor to invoke when creating a specific type of resource (this is where the hints of the factory method come in). So far, I’ve not found a particularly good replacement creator, but building in that generalization is trivial (and free with templates).

A question that should likely be addressed in this scenario, and in most low-level system development, is whether we are creating a service or a type. When sitting down to write code, particularly code where you can envision most of its usage scenarios, this distinction may not be clear. But, having dealt with library code (RenderWare) for three years now, the difference between designing services and designing types seems pretty clear to me (I apologize if the terminology is wrong).

I see services as representing functional hooks for manipulating data, while types provide new classes of data (with their manipulations implicit to their definition). I guess this could be seen as the debate of functional vs. object-oriented programming. In the case of my resource manager, do I desire to have a resource management type that I can use throughout various systems, or do I desire a resource management service that I can use throughout various sytems.

The first invocation I showed at the top of this post would be an example of providing the resource manager as a service. It may be enclosed in a class, but this is actually just an implementation detail (there are differences between how template default parameters work for templated functions and templated classes, so I had to use a class). What the original resource manager does is define an interace for retrieving resources, and since it is essentially a single function, it is doing so globally (which was the original desire).

The second invocation of the resource manager shown demonstrates its definition as a type of object. If I desired for it to be globally accessible (like a service conceptually would be), then I can make it the specific type of a singleton template. This touches on my key point, I guess…

Decomposing this problem into its component pieces is the right path to go because it allows me to choose either service or type without changing the implementation details. For example:

Singleton<Resources<Texture> > ResourceManagerService;
Texture *texture = ResourceManagerService.theInstance().Get("mytexture.tga");

The above exposes my resource manager as a service. Using the exact same implementation of the Resources template, I can create a resource manager type to be used locally in a sub-system:

Resources<WaveData> AudioResourceManager;
WaveData *waves = AudioResourceManager.Get("mysound.wav");

So, what’s the point of this exercise? The point is this: go out right now and purchase Modern C++ Design by Andrei Alexandrescu. This book is devoted to maximizing your use of C++’s template facilities to get this type of easy, easy code construction. It’s the ultimate in generic programming.

Windows-style messaging takes the form of a message handler function (WndProc under Win32) that receives all of the messages. This function is then responsible for dispatching them appropriately, usually through a large switch statement. By default, your message handler will be notified of all messages without have to specifically express interest for them.

Java-style listeners are very lightweight but are hard-coded, not dat-driven. In this case you create a class that handles a specific message (or group of related messages). The class handles the messages by implementing a specific interface for specific messages, i.e. handleMouseMove, handleMouseDown, etc. This interface works for implementing UI widgets but does not handle soft-binding of messages at run-time, or scenarios where senders and receivers are unaware of each other.

This is where the Chain-of-Responsibility pattern comes into play. This pattern separates sender from receiver. It also allows event handlers to prematurely discontinue the handling of events by simply not pass the event further down the chain. This seems like the preferred approach.

Well, not much more to say right now. The implementation is not finished so it may end up looking different. And it’s 3:40am, so it’s time to stop posting…